CN100525291C - Link management method - Google Patents

Abstract

The invention discloses a link management method, which is applied in an automatic switching optical network, and the automatic switching optical network includes a plurality of nodes. The method includes the following steps: a) establishing an adjacency relationship between nodes; b) maintaining the adjacency relationship between nodes by exchanging the first message of a reservation protocol between nodes; c) sending a reservation between nodes with adjacency protocol messages to manage the link. The LMP link management of the present invention maintains the adjacency relationship between nodes by sending keep-alive messages to each other, and the sending of messages can be realized through routing. Compared with the prior art, since the control channel is no longer maintained, only the adjacency relationship is maintained , can reduce message interaction, reduce system burden, and link management operation and maintenance are simple.

Description

link management method

technical field

The invention relates to the technical field of optical communication, in particular to a link management method suitable for ASON (Automatically Switched Optical Network).

Background technique

Optical network includes SDH/Sonet (Synchronous Digital Hierarchy/Synchronous Optical Network), wavelength network, etc. The traditional optical network is based on centralized management, and nodes (or called network elements) use permanent connections to realize communication. The adoption of the above-mentioned permanent connection method has achieved good results in the initial stage of optical network development because of its simple design and low cost. However, the establishment, maintenance, and removal of optical connections in the permanent connection mode require manual or network management system intervention. With the continuous growth of data traffic, this connection mode can no longer meet the requirements for dynamic and flexible configuration of optical network systems.

The key to solving the above problems is to realize dynamic optical switching. For this reason, ITU-T (International Telecommunications Union) proposed the ASON (or intelligent optical network) architecture, which adds a control plane to the traditional optical network, and proposes Concept of exchange connection. According to this idea, the node of the optical network first obtains the connection relationship between the node and other optical nodes through the local link discovery technology, and then publishes the node and the link status related to the node through the control plane, and receives other nodes in the network. The status of the nodes is released, and finally each optical node has a "network map" that describes the precise topology of the network. The "network map" includes various information such as nodes, links, and resources. When the client equipment or management system requires to establish a node connection, the node uses the information of the "network map" combined with a certain routing algorithm to obtain a feasible path, and then drives the nodes on the path to establish a cross-connection through the signaling protocol. When network connections are dynamically established, removed, or link resources change due to failures, the corresponding nodes will release updated node and link status information in a timely manner to achieve resynchronization of the "network map".

LMP (Link Management Protocol) is part of the GMPLS (General Multi-Protocol Label Switching) protocol cluster defined by IETF (Internet Engineering Task Force) to meet the basic structure and requirements of ASON. It is used to manage links between adjacent nodes. Local nodes The connection relationship with other nodes is found by running LMP on the corresponding node, and the connection relationship discovered is called a data link.

Usually, there may be many data links between two nodes, and if all of them are diffused through the control plane, the corresponding message volume will be very large. In order to reduce the number of diffused packets, data links with the same attributes need to be combined into a virtual logical link. When calculating a feasible path, the routing algorithm needs to know the relevant information of all links, including the maximum bandwidth of the link, These attributes, such as available bandwidth, are called TE (traffic engineering) attributes of a link, and correspondingly, this logical link is called a TE link.

When managing the data link between nodes, LMP first needs to establish an adjacency relationship between the nodes at both ends of the data link. The LMP establishes an adjacency relationship between nodes by establishing a bidirectionally reachable control channel between the nodes. The control channel may be an in-band control channel established on data link overhead bytes, or an out-of-band control channel passing through an IP network.

In LMP, the underlying physical implementation of the control channel is not limited. It is independent of the data link. It can be a wavelength in an optical fiber, an Ethernet link, an IP tunnel or data link passing through a certain network. Overhead bytes on . Multiple control channels may be enabled simultaneously between a pair of nodes. Control channel parameters must be negotiated individually on the respective control channel. The LMP maintains the connectivity of each control channel by exchanging Hello messages on each control channel.

There are four LMP messages used to maintain independent control channels. These four messages are: Config, ConfigAck, ConfigNack and Hello messages. These four messages must be transmitted on the designated control channel, and all other LMP messages can be transmitted on any one of the available control channels between a pair of adjacent nodes. In order to maintain the LMP adjacency, at least one control channel must be available between a pair of adjacent nodes.

In summary, the prior art has the following disadvantages:

1. The existing LMP link management method needs to maintain all the control channels separately, there are many interactive messages, the system burden is heavy, and the operation and maintenance are complicated. In fact, what LMP link management really needs to maintain is the adjacency relationship between nodes, and it is not necessary to maintain all control channels.

2. When there are multiple control channels between two nodes, except for the four LMP messages mentioned above that need to be transmitted on the designated control channel, all other LMP messages will be transmitted on one of the control channels. This control channel is selected by the LMP according to its own rules. However, LMP is not clear about the underlying physical implementation of the control channel, and the selected primary control channel may not be the optimal control channel between two nodes.

3. In order to maintain the control channel, four messages related to the control channel need to be sent on the designated control channel. All other LMP messages are also transmitted on a control channel selected by the LMP itself. That is to say, all LMP messages need to be sent through a specified interface. When the control channel between nodes passes through a certain network, sending unicast packets through a specified interface may cause a routing loopback. While this problem can be avoided by creating a tunnel between nodes across the network, this adds extra work.

4. The specified interface transmission is not a standard implementation of the TCP/IP protocol stack. To realize the specified interface transmission, the existing protocol stack needs to be extended. Interoperability needs to be considered between the expansions of various manufacturers to avoid problems in the connection between devices of different manufacturers, which is not conducive to future expansion.

5. Assume that there is only one available control channel between two nodes, and it is a control channel carried on the same physical link as the data link, as shown in Figure 1. If the optical fiber where this control channel is located fails, the service When a switchover occurs, this control channel will be unavailable because the overhead cannot be transparently transmitted. As shown in FIG. 2 , at this time, the service channel is still available, but no control channel will be available between the two nodes. In this case, the LMP link management also loses the ability to control and manage resources between nodes.

Contents of the invention

In order to solve the problem that all control channels need to be maintained for LMP link management in the prior art, resulting in complicated operation and maintenance, the present invention provides a link management method, which can make link management simpler and more effective.

According to the link management method provided by the present invention, it is applied in the automatic switching optical network, and the automatic switching optical network includes a plurality of nodes, and the nodes support the link management protocol LMP, and the method includes the following steps:

a. Obtain a routable control interface address of the adjacent node, and establish an adjacency relationship between the nodes; the control interface address is used by the receiving end node as the remote control interface address of the control channel to be established;

b. Establishing a physical control channel according to a predetermined routing protocol between nodes according to the control interface address, sending the first message of the predetermined protocol to each other on the physical control channel, and passing the first message of the predetermined protocol reachable between nodes A message maintains the adjacency relationship between nodes; the first message of the predetermined protocol is an LMP keep-alive message;

c. Between nodes with adjacency, according to the control interface address, send a predetermined protocol message on the physical control channel to manage the link through the routing method; the routing method is to obtain physical control according to the predetermined routing protocol channel, the predetermined routing protocol is Open Shortest Path First Protocol OSPF protocol or Intermediate System-to-Intermediate System Protocol IS-IS protocol.

Wherein, step a establishes an adjacency relationship between nodes through automatic discovery of adjacent nodes or manual configuration.

Specifically, the step a further includes establishing an adjacency relationship between nodes by automatically discovering adjacent nodes:

a1. The local node multicasts the second message of the predetermined protocol to obtain the control interface address of the adjacent node, and negotiates with the adjacent node of the control interface address the interval between sending the first message of the predetermined protocol and the timeout period;

a2. If the negotiation is passed, return the local node negotiation acknowledgment message, otherwise return the local node negotiation rejection message.

In addition, said step a further includes establishing an adjacency through manual configuration:

Manually setting the control interface address of the adjacent node of the local node, and unicasting the second message of the predetermined protocol to the adjacent node of the control interface address, so as to negotiate with the adjacent node of the control interface address on the sending interval time of the first message of the predetermined protocol and timeout;

If the negotiation is passed, the local node negotiation confirmation message is returned, otherwise the local node negotiation rejection message is returned.

In addition, the step b further includes:

Sending the predetermined protocol first message according to the negotiated interval, and confirming that the adjacency relationship is unavailable if the predetermined protocol first message is not received within the negotiated timeout period.

Preferably, the predetermined protocol first message, the unicast predetermined protocol second message, the negotiation confirmation message and the negotiation rejection message are sent by routing.

Optionally, the predetermined protocol is a link management protocol (LMP protocol), the second message of the predetermined protocol is an LMP negotiation configuration message, the negotiation confirmation message is an LMP negotiation confirmation message, and the negotiation rejection message is an LMP negotiation Decline message.

Optionally, the predetermined protocol is a link management protocol (LMP protocol), the second message of the predetermined protocol is an LMP bootstrapping message, the negotiation confirmation message is an LMP negotiation confirmation message, and the negotiation rejection message is an LMP negotiation rejection message;

Said step a1 further comprises that after the local node multicasts the LMP bootstrapping message and obtains the control interface address of the adjacent node, unicasts the LMP negotiation configuration message to the adjacent node of the control interface address, so as to adjoin with the control interface address Nodes negotiate the interval and timeout for sending LMP keep-alive messages.

Preferably, the LMP keep-alive message, the unicast LMP negotiation configuration message, the LMP negotiation confirmation message and the LMP negotiation rejection message are sent by routing.

Compared with the prior art, the present invention has the following advantages:

1. The LMP link management of the present invention maintains the adjacency relationship between nodes by sending keep-alive messages between nodes, and the sending of messages can be realized through routing. Compared with the prior art, since the control channel is no longer maintained, only the The adjacency relationship can reduce the exchange of messages, reduce the burden on the system, and the link management operation and maintenance are simple.

2. In addition to multicast Config messages and bootstrapping messages, other LMP protocol control messages can be sent by way of routing. Compared with the transmission of the control channel that needs to be specified in the prior art, the message sending of the present invention is more flexible and easier to implement .

3. When the control channel between two nodes passes through a certain network, if the unicast message is sent on a specified interface, it may cause a routing loopback. In order to solve this problem in the original LMP link management method, a tunnel must first be established on the corresponding control interface between the two nodes. This requires additional resources and increases complexity. However, the present invention does not need to specify an interface to send the message because it sends the message through routing, so the problem of routing loopback will not occur, and there is no need to build additional tunnels.

4. Since there is no need to expand the existing protocol stack, the LMP message can be sent by routing. Sending packets by route is already a mature standard, and does not require additional work. It is easy to implement and is conducive to further expansion in the future.

5. When there is only one available in-band physical control channel between two nodes, if the optical fiber where the physical control channel is located undergoes multiplex section ring protection switching, this physical control channel will no longer be available, because the present invention uses routing to send message, the routing protocol can quickly find that the link is unavailable, and reselect an available path to reach the adjacent node. This process is transparent to LMP. As long as the Hello message arrives correctly within a certain period of time, the LMP simply does not know that the underlying physical control channel has changed.

Description of drawings

FIG. 1 is a schematic diagram of a normal multiplex section ring protection service in the prior art;

Fig. 2 is a schematic diagram of the multiplex section ring protection service after the service channel in Fig. 1 is switched;

Fig. 3 is a flowchart of a specific embodiment of the link management method of the present invention;

Fig. 4 is a flow chart of establishing an adjacency relationship between nodes by automatically discovering adjacent nodes in the link management method of the present invention;

FIG. 5 is a schematic diagram of adjacent nodes with in-band control channels in the prior art;

Fig. 6 is a schematic diagram of negotiation between node A and node B shown in Fig. 5;

FIG. 7 is a schematic diagram of adjacent nodes with out-of-band control channels in the prior art;

FIG. 8 is a flow chart of establishing an adjacency relationship between nodes by manually setting adjacent node addresses.

Detailed ways

In this specific embodiment, the predetermined protocol referred to is the LMP protocol, and the predetermined protocol message referred to is the LMP protocol message, which is different from the control channel of the prior art LMP protocol logic. The following control channel refers to the physical control channel, that is, between nodes Actual transport channel for interactive link management messages. The link management method of the present invention is implemented based on the LMP protocol. Different from the prior art, the LMP link management in the present invention will no longer maintain and manage its own control channel, but only maintain the adjacency relationship between nodes.

As shown in FIG. 3 , it is described with a specific embodiment applied in an automatic switching optical network. The automatic switching optical network includes a plurality of nodes, and the nodes are connected by data links. As introduced in the background technology, in the automatic optical network A control plane etc. is also introduced. In order to manage the link between nodes so as to maintain normal communication, the specific embodiment of the link management method of the present invention mainly includes the following steps:

Step 1 establishes the adjacency relationship between nodes.

An adjacency relationship can be established between two nodes supporting the LMP function, but not all neighbors will form an adjacency relationship. Generally, an adjacency relationship between nodes can be established in two ways: automatic discovery of adjacent nodes or manual configuration. In the prior art, an adjacency relationship between nodes is established by establishing a bidirectionally reachable logical control channel between nodes. The present invention weakens the concept of the logical control channel, that is, it only cares about whether the messages between nodes can communicate with each other, and does not need to care about how the messages are transmitted. The effect can be realized by sending according to the route.

In step 2, the adjacency between nodes is maintained by exchanging the first message of the predetermined protocol between the nodes. In this embodiment, the first message of the predetermined protocol may be a keep-alive message (ie, Hello message) of the LMP protocol.

The adjacency relationship between nodes is established above, and the adjacency relationship between nodes also needs to be maintained. As introduced in the background technology section, in the prior art, Hello messages are sent to each other on the bidirectionally reachable logical control channels established between nodes to verify whether the logical control channels are available, and then when all logical control channels between nodes are unavailable When it is used, it is determined that the adjacency relationship between nodes is not available. As mentioned above, this method has many disadvantages due to the need to maintain all logical control channels during link management. In this embodiment, the adjacency relationship between the nodes can be maintained by sending the Hello messages between the nodes, that is, as long as two nodes can communicate with each other, the adjacency relationship between the nodes is considered available, and it is not necessary to care about how many messages there are between the nodes. The logical control channel is available, and the first message of the predetermined protocol (that is, the Hello message) can be sent in a routing manner.

In step 3, a predetermined protocol message is sent between nodes having an adjacency in a routing manner to manage links.

Between nodes with adjacency relationship, in addition to the Hello message for maintaining the adjacency relationship between nodes, other LMP protocol messages for link management can also be sent through routing, that is, the original link management needs to be based on the LMP protocol Select a certain logic control channel and specify the LMP protocol message transmitted by the interface. In the present invention, the LMP protocol message can be sent by routing, that is, the LMP protocol message can be transmitted according to the route obtained by the predetermined routing protocol. The predetermined routing protocol can adopt the open shortest route. Path priority protocol (OSPF routing protocol) or intermediate system to intermediate system protocol (IS-IS routing protocol), and other routing protocols can also be used according to the actual situation.

The following explains in detail how to establish the adjacency relationship between nodes. First, let's look at the process of automatically discovering adjacent nodes and establishing the adjacency relationship between nodes. When the control channel for transmitting link management messages between two nodes is carried on the same physical link as the data link, you can use the automatic discovery of adjacent nodes to obtain the NODE_ID (node identifier) and control interface address of the adjacent node, as shown in the figure 4. The automatic discovery of adjacent nodes to establish an adjacency relationship between nodes includes the following process:

Step 41: Multicast the second message of the predetermined protocol to obtain the address of the adjacent node. After the address of the adjacent node is obtained, the interval between sending the first message of the predetermined protocol and the timeout time can be negotiated with the adjacent node. In order to send the first message of the predetermined protocol and other predetermined protocol messages through routing, the address of the adjacent node is preferably a routable address, which may include the NODE_ID and the address of the control interface of the adjacent node.

Step 42 judges whether the negotiation is passed. If the negotiation is passed, go to step 43 and return the local node negotiation confirmation message, otherwise go to step 44 and return the local node negotiation rejection message.

Specifically, the predetermined protocol second message in step 41 can be an LMP configuration message (Config message), the negotiation confirmation message can be an LMP negotiation confirmation message (ConfigAck message), and the negotiation rejection message can be an LMP negotiation rejection message (ConfigNack message). After the address of the adjacent node is acquired by multicast, the LMP negotiation confirmation message and the LMP negotiation rejection message are sent through routing. In addition, according to the manner described in the LMP protocol, the address of the adjacent node is automatically discovered by multicasting the Config message, and the format of the Config message is as follows:

<Config Message>::=<Common Header><MESSAGE_ID>

<LOCAL_NODE_ID>

<CONFIG>

The detailed definitions of each part in the Config message are as follows:

<Common Header>: Common message header object, all LMP messages (except the TEST message to be sent on the specified data link) have this common message header object. This object specifies the message type, length and other information of the current message.

<MESSAGE_ID>: message identification object, this object is used to identify a message, and the receiver should bring the value in this object when sending the corresponding response message.

<LOCAL_NODE_ID>: local node identification object, used to identify the ID of the node that generated this message.

<CONFIG>: This object contains the interval time and timeout time of Hello messages, and these two values need to be negotiated by two nodes.

In addition, since the LMP link management in the present invention no longer maintains and manages its own logical control channel, the CCID defined in the LMP protocol draft (the unique 32-bit non-zero integer within the node range, which uniquely identifies the logic that sends this message control channel) will no longer be needed in the present invention.

The specific process of automatically discovering adjacent nodes and establishing the adjacency relationship between nodes is as follows:

Referring to FIG. 5 , there are three data links connecting two nodes (node A and node B) described in FIG. 5 , and these three data links are combined into one TE link. A physical control channel is established on the overhead bytes of one of the data links, and this control channel is an in-band control channel. Since the control channel and the data link are carried on the same physical link, the NODE_ID and control interface address of the adjacent node at the far end of the control channel can be dynamically obtained by exchanging Config messages, that is, the address of the adjacent node.

In the above case, node A first multicasts the Config message on all local control channels that are carried on the same physical link as the data link, wherein the source address of the Config message sent by node A is the unicast local node control interface address, The destination address is a multicast address (such as 224.0.0.1). After node B receives the Config message, it can obtain the control interface address of the adjacent node (that is, the source address in the received Config message), take out the NODE-ID (that is, the identity of node A) carried in the Config message, and The NODE-ID is checked, and if the NODE-ID is the same as the local NODE-ID, the message is discarded. If this is a newly discovered adjacent node, node B responds with a message to node A according to whether it accepts the parameters in the Config message, if accepted, it responds with a ConfigAck message, otherwise it responds with a ConfigNack message. In addition, if node B has discovered the NODE-ID and has responded to the other party with a ConfigAck message, it will directly respond to node A with a ConfigNack message. The destination IP address of the ConfigAck message and the ConfigNack message is filled with the newly obtained adjacent node control interface address, and the source address is the control interface address of the local node.

The format of the ConfigAck message is as follows:

<ConfigAck Message>::=<Common Header><LOCAL_NODE_ID>

<MES SAGE_ID_ACK><REMOTE_NODE

_ID>

The ConfigAck message is defined in detail as follows:

The contents of <Common Header> and <LOCAL_NODE_ID> are the same as those mentioned above.

<MESSAGE_ID_ACK>: Confirmation message object, used to identify the confirmed message, this value is copied from the <MESSAGE_ID> object of the confirmed message.

<REMOTE_NODE_ID>: remote node identification object, used to identify the remote node.

The format of the ConfigNack message is as follows:

<ConfigNack Message>::＝<Common Header>

<LOCAL_NODE_ID>

<MESSAGE_ID_ACK>

REMOTE_NODE_ID><CONFIG>

The objects used in the ConfigNack message have been introduced earlier. When node B does not accept the interval time and timeout time in the Config message sent by node A, it will respond to node A with a ConfigNack message. The value carried in the Config object of the ConfigNack message is the interval time and timeout time that the Node B wants to adopt.

FIG. 6 shows the negotiation process between node A and node B. If node B agrees with the interval time and timeout time carried in the Config message, it will respond to node A with a ConfigAck message; otherwise, it will respond with a ConfigNack message. If the NODE_ID carried in the Config message received by node B is a discovered adjacent node NODE_ID, and has responded to the other party with a ConfigAck message, it will respond with a ConfigNack message without a Config object. After node A receives the ConfigAck or ConfigNack message, it can obtain the NODE_ID and control interface address of node B at the remote end of the control channel.

The above is described by multicasting Config messages to automatically discover adjacency relationships. During specific implementation, the automatic discovery of adjacent nodes can also be implemented by multicasting LMP bootstrapping messages on the data link in the manner described in [LMP-BOOTSTRAP].

Specifically described LMP bootstrapping message (Bootstrap message), its format is as follows:

<Bootstrap Message>::=<Common Header><LOCAL_INTERFACE_ID>

<LOCAL_NODE_ID>[<LOCAL_CONTROL_ADDRESS>...]

The definitions of the <Common Header> and <LOCAL_NODE_ID> objects in the message are the same as before, the <LOCAL_INTERFACE_ID> object is the interface identifier of the local data link, which is used to identify a data link interface of the local node, and the <LOCAL_CONTROL_ADDRESS> object is the local Node control interface address, used to identify a control interface required to establish a control channel.

If the above Bootstrap message does not contain <LOCAL_CONTROL_ADDRESS>, then the message content contained in the <LOCAL_NODE_ID> object must be a routable address (that is, this address can be reached through ordinary routing), and this address will be used by the receiver as the remote end of the control channel Control interface address to establish a control channel. The process of establishing a control channel is the same as the process realized through the multicast LMP negotiation configuration message (Config message), that is, the control interface address of the adjacent node is obtained through the multicast Bootstrap message, and then the LMP keep-alive can be negotiated with the adjacent node through the unicast Config message Message sending interval time and timeout time. If the negotiation is passed, the local node LMP negotiation acknowledgment message is returned, otherwise the local node LMP negotiation rejection message is returned. Since the addresses of routable adjacent nodes are obtained by multicasting, the unicast Config message, LMP negotiation confirmation message and LMP negotiation rejection message can all be sent in a routing manner. In addition, multiple <LOCAL_CONTROL_ADDRESS>s can be included in a single Bootstrap message, that is, multiple destination control interface addresses can be used to reach the other party.

The following describes the process of establishing an adjacency through manual configuration.

Figure 7 shows an out-of-band control channel. The control channel shown in Figure 7 traverses an IP network. For the out-of-band control channel, it is necessary to manually configure the address of the adjacent node to establish the adjacency relationship between the nodes. With reference to Figure 8, the manual configuration to establish the adjacency relationship between nodes includes the following steps:

Step 81 manually sets the address of the adjacent node of the local node, the address of the adjacent node is the NODE_ID of the adjacent node and the address of the control interface, and then the address of the control interface can be used as the destination address to unicast the second message of the predetermined protocol to the node to Negotiating with the node the predetermined protocol first message sending interval and timeout;

Step 82 judges whether the negotiation is passed; if the negotiation is passed, go to step 83 and return the local node negotiation confirmation message; otherwise, go to step 84 and return the local node negotiation rejection message.

The second message of the above-mentioned unicast predetermined protocol is an LMP configuration message (ie, Config message), and the message format is the same as the above, and the process of establishing the control channel is the same as the previous description, and will not be repeated here.

After the adjacency relationship between nodes is established, that is, after the negotiation between the two nodes is passed, the two adjacent nodes start to send keep-alive messages (that is, Hello messages) to each other regularly according to the interval time passed through the negotiation, telling each other that they are still alive. If no Hello message is received from the other party within the timeout period passed through negotiation, the adjacency relationship between nodes is considered to be unavailable.

Among all the above-mentioned LMP messages, except the Config message required to establish the adjacency relationship between nodes, which needs to be sent by multicast, among the nodes with adjacency relationship, the LMP protocol message can be sent to the adjacent node through routing, and no longer specified in sent on a control channel.

With the above-mentioned technical scheme of the present invention, when two nodes have only established one control channel and it is an in-strip control channel, if the business on the data link where the control channel is located is switched and this control channel is unavailable, it can be Reselect a path to the adjacent node to transmit the LMP link management message through routing. This process is transparent to LMP, that is, for LMP link management, as long as the Hello message can arrive correctly within a certain period of time, LMP link management does not know at all. The underlying physical implementation has changed to facilitate future extensions.

For the out-of-band control channel, routing loopback may be caused if the specified interface of the unicast message is sent. In the present invention, the unicast message does not need to be sent through the specified interface, as long as the set adjacent node control interface address is a routable address, the message can be sent to the adjacent node through the route, and there is no need to establish a tunnel between the corresponding control interfaces between the two nodes. Therefore, it does not need to occupy additional resources, and the implementation is simple.

In summary, the LMP link management in the present invention no longer maintains its own control channel, but only maintains the adjacency relationship between nodes, which reduces message interaction and system burden. At the same time, except for the multicast Config message, other All LMP messages can be sent in routing mode, without extending the existing protocol stack, and sending messages by routing is already a mature standard, which does not require additional work, reduces the burden of implementation, and is conducive to further expansion in the future.

The above only describes the present invention with preferred embodiments, and does not therefore limit the scope of rights of the present invention. Therefore, without departing from the idea of the present invention, all equivalent changes made by using the description and accompanying drawings of the present invention are all It is equally included in the scope of the claims of the present invention.

Claims (9)

1, a kind of link management method, is applied in the automatic switching optical network, described automatic switching optical network comprises a plurality of nodes, and described node supports link management protocol LMP, it is characterized in that, described method comprises the following steps: a. Obtain a routable control interface address of the adjacent node, and establish an adjacency relationship between the nodes; the control interface address is used by the receiving end node as the remote control interface address of the control channel to be established; b. Establishing a physical control channel according to a predetermined routing protocol between nodes according to the control interface address, sending the first message of the predetermined protocol to each other on the physical control channel, and passing the first message of the predetermined protocol reachable between nodes A message maintains the adjacency relationship between nodes; the first message of the predetermined protocol is an LMP keep-alive message; c. Between nodes with adjacency, according to the control interface address, send a predetermined protocol message on the physical control channel to manage the link through the routing method; the routing method is to obtain physical control according to the predetermined routing protocol channel, the predetermined routing protocol is Open Shortest Path First Protocol OSPF protocol or Intermediate System-to-Intermediate System Protocol IS-IS protocol. 2. The link management method according to claim 1, wherein step a establishes an adjacency relationship between nodes through automatic discovery of adjacent nodes or manual configuration. 3. The link management method according to claim 2, wherein said step a further comprises: establishing an adjacency relationship between nodes by automatically discovering adjacent nodes: a1. The local node multicasts the second message of the predetermined protocol to obtain the control interface address of the adjacent node, and negotiates with the adjacent node of the control interface address the interval between sending the first message of the predetermined protocol and the timeout period; a2. If the negotiation is passed, return the local node negotiation acknowledgment message, otherwise return the local node negotiation rejection message. 4. The link management method according to claim 2, wherein said step a further comprises: establishing an adjacency through manual configuration: Manually setting the control interface address of the adjacent node of the local node, and unicasting the second message of the predetermined protocol to the adjacent node of the control interface address, so as to negotiate with the adjacent node of the control interface address on the sending interval time of the first message of the predetermined protocol and timeout; If the negotiation is passed, the local node negotiation confirmation message is returned, otherwise the local node negotiation rejection message is returned. 5. The link management method according to claim 3 or 4, wherein said step b further comprises: Sending the predetermined protocol first message according to the negotiated interval, and confirming that the adjacency relationship is unavailable if the predetermined protocol first message is not received within the negotiated timeout period. 6. The link management method according to claim 5, characterized in that the first predetermined protocol message, the unicast second predetermined protocol message, the negotiation confirmation message and the negotiation rejection message are sent by routing. 7. The link management method according to claim 6, wherein the predetermined protocol is a link management protocol (LMP), the second message of the predetermined protocol is an LMP negotiation configuration message, and the negotiation confirmation message is an LMP negotiation A confirmation message, where the negotiation rejection message is an LMP negotiation rejection message. 8. The link management method according to claim 3, wherein the predetermined protocol is a link management protocol (LMP), the second message of the predetermined protocol is an LMP bootstrapping message, and the negotiation confirmation message is an LMP negotiation A confirmation message, the negotiation rejection message is an LMP negotiation rejection message; Said step a1 further comprises that after the local node multicasts the LMP bootstrapping message and obtains the control interface address of the adjacent node, unicasts the LMP negotiation configuration message to the adjacent node of the control interface address, so as to adjoin with the control interface address Nodes negotiate the interval and timeout for sending LMP keep-alive messages. 9. The link management method according to claim 8, characterized in that the LMP keep-alive message, the unicast LMP negotiation configuration message, the LMP negotiation confirmation message and the LMP negotiation rejection message are sent by routing.

Images