CN1492601A - Recovering method for controlling plane after multi-node restarting in intelligent optical network - Google Patents
Recovering method for controlling plane after multi-node restarting in intelligent optical network Download PDFInfo
- Publication number
- CN1492601A CN1492601A CNA021474400A CN02147440A CN1492601A CN 1492601 A CN1492601 A CN 1492601A CN A021474400 A CNA021474400 A CN A021474400A CN 02147440 A CN02147440 A CN 02147440A CN 1492601 A CN1492601 A CN 1492601A
- Authority
- CN
- China
- Prior art keywords
- node
- instance
- value
- hello message
- dst
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
This invention provides a method for controlling restoration of a panel. During restoration, the first restart nexus can start synchronization to the down-stream restart nexus only after finishing the synchronous restoration with the up-stream nexus start a resume timer, before finishing synchronous restoration to two adjacent nexuses, the Dst instance value in Hello information exchanged between them is always zero. After restoring the super time of the timer, the up-stream nexus informs the down-stream nexus to finish the synchronous restoration, realized by changing the value of Dst instance in Hello information exchanged between them is always zero. After restoring the super time of the timer, the up-stream nexus informs the down-stream nexus to finish the synchronous restoration, realized by changing the value of Dst instance in Hello information sent to the downstream nexus to the value of Src instance in Hello information received by the said nexus from the said down-stream nexus.
Description
Technical field
The present invention relates to optical communication field, the restoration methods of control plane after particularly multinode is restarted in ASON.
Background technology
In ASON, a basic principle is arranged: the failure of control plane can not influence service plane, causes the infringement to business.Therefore,, after restarting as node, recover original control information, again business is controlled the very necessity and important that seems when control plane is failed.In ASON, the failure of control plane can be divided into two kinds of situations: a kind of is that failure has taken place the network element node, restarts as node, and control information is lost, but the business of bottom has also preserved; Another kind of situation is the control channel failure, has broken the control channel communicating interrupt between them as two internodal optical fiber.What the application was related is after node is restarted, and is used to recover the method for control plane.
At existing IETF (Internet Engineering Task Force, the internet engineering task group), OIF (Optical Internetworking Forum, optical-fiber network forum) in the standard and draft about ASON, for by RSVP (Resource reSerVation Protocol, RSVP) or RSVP-TE (Resource reSerVation Protocol with TrafficEngineering Extension, RSVP with traffic engineering expansion) connection of setting up, only provided the method that is used to recover control plane after single node is restarted, for how recovering after having a plurality of continuous nodes to restart handling, then not providing solution.
Above-mentionedly restart the back about single node and recover the technical solution of control plane and be documented in " User Network Interface signaling protocol 1.0; optical-fiber network forum; 2000.125.7; October 1 calendar year 2001 " (UserNetwork Interface (UNI) 1.0 Signaling Specification, OIF2000.125.7, October, 1,2001) in.
In above-mentioned known technical solution, because recover synchronously is to be with the Path message of Recovery_Label to initiate by upstream node by transmission, on the node of restarting, started RecoveryTimer (recovery timer), like this, under the situation that a plurality of continuous nodes are restarted, adopt the solution that provides in the above-mentioned agreement can have following problem.Suppose that two continuous Node B and C that certain bar in the network connects process have taken place to restart, and node C finishes earlier than Node B and restarts, like this, node C just might can not receive the Path message of the band Recovery_Label (recovery label) that Node B sends at Recovery Timer in the overtime time, therefore, after Recovery Timer was overtime, node C can delete the interconnection of bottom.In optical-fiber network, the failure of key-course should not influence operation layer, i.e. the failure of key-course can not cause the failure of operation layer, and in these cases, the failure of key-course has caused deleting the interconnection of bottom, has influenced the business of bottom, and this situation should not take place.
Summary of the invention
The present invention proposes at the deficiency in the above-mentioned existing technical solution just, and the method according to this invention can realize the recovery of the control plane after continuous a plurality of node is restarted.Described method of the present invention is based on that such basic principle designs, and promptly has only the upstream node to recover synchronously to have finished, and could initiate downstream node is recovered synchronously.
For realizing the invention described above purpose, embody above-mentioned basic design philosophy, the invention provides a kind of being used for restarts the method that control plane is recovered in the back at the ASON multinode, described ASON be according to RSVP or RSVP-TE set up, the connection of deletion, in this connection, have three adjacent node A at least, B and C, wherein, a node A is non-reset node, is positioned at the upstream of other Node B and C, Node B and C are adjacent successively reset node, said method comprising the steps of:
(1) communication disruption of described non-reset node A discovery and adjacent node B, the value of Src_instance remains unchanged in the Hello message that this Node B sends, the value of Dst_instance is set to zero, and described non-reset node A self-refresh and the relevant state of this adjacent node B;
(2) after the reset node B adjacent with non-reset node A restarted, send Hello message to adjacent node A and C, the value of Src_instance changes with respect to the value of the Src_instance before restarting with this node in this Hello message, and the value of Dst_instance is set to zero;
(3) another reset node C adjacent with above-mentioned Node B of restarting judges Node B according to the Dst_instance=0 from the Hello message that Node B receives and recovers synchronously as yet, and node C sends Dst_instance=0 in the Hello message of response to Node B;
(4) described non-reset node A receives the Hello message of sending from Node B, if variation has taken place in the value of the Src_instance before the value of the Src_instance in this message is restarted with respect to this Node B, then judging Node B has taken place to restart, node A stops above-mentioned self-refresh, start RecoveryTimer (recovery timer), the value of Dst_instance in the Hello message that Node B sends remains zero, and send the Path message of carrying Recovery_Label to Node B, be used for the synchronous recovery of Node B;
(5) described non-reset node A is after Recovery Timer is overtime, the value that the value that sends to the Dst_instance in the Hello message of Node B is arranged to send to Node B the Src_instance in the Hello message of node A is identical, is used to notify Node B same EOS;
(6) Node B and node A synchronously after, Node B starts Recovery Timer, the value of Dst_instance in the Hello message that node C sends remains zero, and sends the Path message of carrying Recovery Label to node C, is used for the synchronous recovery of node C;
(7) described Node B is after Recovery Timer is overtime, the value that the value that sends to the Dst_instance in the Hello message of node C is arranged to send to node C the Src_instance in the Hello message of Node B is identical, is used to notify node C same EOS.
Be applicable to that from the invention described above is described continuous a plurality of node restarts the technical scheme of the method that the back control plane recovers as can be seen, the method for the invention is different from existing protocol, is mainly reflected in the following aspects:
(1) last node only after the synchronous recovery process of finishing with upstream node, could initiate to downstream node synchronously;
(2) node of not restarted by the upstream or the node that recovered to finish synchronously with upstream node start Recovery Timer timer;
(3) before two adjacent nodes did not recover to finish synchronously, the value of the Dst_instance in the Hello message that exchanges between them was set to 0 all the time; Behind Recovery Timer timer expiry, notify the synchronous recovery process of downstream node to finish by upstream node,
(4) value that changes the Src_instance of this node from the Hello message that this downstream node is received into of the value by the Dst_instance in the Hello message that will mail to downstream node realizes.
Therefore, method of the present invention can overcome the deficiencies in the prior art, solves the correct recovery that continuous a plurality of node is restarted the back control plane, does not influence the business of bottom.
Description of drawings
Fig. 1 schematically illustrates the flow process that is used for restarting at continuous a plurality of nodes the method for back recovery control plane provided by the invention.
Embodiment
Those of ordinary skills understand the present invention for convenience, before explaining the specific embodiment of the present invention, do following hypothesis earlier:
(1) node A, the B among Fig. 1, C are three continuous nodes, are followed successively by the upstream and downstream node;
(2) before node takes place restarting, node A issues the Src_instance=11 in neighbours' the Hello message, and Node B is issued the Src_instance=2 in neighbours' the Hello message, and node C issues the Src_instance=3 in neighbours' the Hello message;
(3) node A is non-reset node (Non Restart Node), and Node B and C are reset node (Restart Node).After restarting, Node B is issued the Src_instance=22 in neighbours' the Hello message, and node C issues the Src_instance=33 in neighbours' the Hello message.
Next, with reference to Fig. 1, the method that is used for restarting at continuous a plurality of nodes back recovery control plane of the present invention based on above-mentioned hypothesis is described.
1, after Node B is finished and restarted, sends Hello message to neighbor node
After Node B is finished and restarted, send Hello message, the Src_instance=22 in the Hello message, Dst_instance=0 to node A and node C respectively.
2, node C receive Node B send come the processing after the Hello message
According to the present invention, node C should be restarted after Node B is finished synchronous recovery with node A.Node C is according to the Dst_instance=0 from the above-mentioned Hello message that Node B is received, predicate node B does not also finish synchronous recovery.At this moment, node C must finish synchronous recovery by wait node B.In described wait process, the Src_instance=33 of node C in the Hello message of Node B transmission response, Dst_instance=0.
Node B is after the Hello message of receiving from the response of node C, because this node is not also finished synchronous recovery, so issue Src_instance=22 in the Hello message of node A and node C, Dst_instance=0.
That is to say that according to the present invention, if upstream node is not finished synchronous recovery, the Dst_instance=0 in the Hello message that exchanges between the neighbor node in this node and its downstream should remain.
The present invention guarantees at upstream node that by this mechanism before for example Node B was not finished synchronous recovery, its downstream node for example node C just can not start recovery process just.
3, node A receives the processing after the Hello message that Node B sends over
As shown in Figure 1, node A is non-reset node.As be known in the art in a single day node A finds the communication disruption with neighbours like that, the Src_instance=11 of this node in the Hello message of the neighbor node B that communication disruption takes place, Dst_instance=0.At this moment, the state that node A is relevant with Node B enters the self-refresh state.
According to the hypothesis of front, before node takes place restarting, Node B is issued the Src_instance=2 in neighbours' the Hello message.Yet, as mentioned before, this moment Node B has taken place and restarted, as mentioned above, node A is Src_instance=22 from the HELLO message that Node B receives, Dst_instance=0.
Node A is by comparing the value (Src_instance=2) of the Src_instance of the Node B of its preservation with Src_instance (Src_instance=22) value of just having received from the Hello message of Node B, variation has taken place in the two, in view of the above, node A can take place to restart by decision node B.So node A stops self-refresh, start Recovery Timer, send Hello message, Src_instance=11 in this Hello message, Dst_instance=0 to Node B.It should be noted that before failing to finish synchronous recovery the Dst_instance that node A issues in the Hello message of node C should be always 0 with Node B.
Simultaneously, node A generates Path message according to all states relevant with Node B, and carries the Recovery_Label object and send to Node B, so that Node B is recovered synchronously.
If the Recovery Timer that 4 node A start is overtime, node A can delete not to be had and the synchronous state of Node B, the Dst_instance that node A issues in the Hello message of Node B is set to 22, and no longer is 0, and doing like this is to be used to notify Node B same EOS.
5, Node B receives that Path message processing and the prior art afterwards of the band Recovery_Label that node A sends over is in full accord.In brief, Node B is at first checked the corresponding RSVP state of Path message whether it has and accepted.If have and the corresponding state of this Path message, then this Path message handled according to the normal handling flow process.
If not with the corresponding state of this Path message, and do not carry the Recovery_Label object in this message, then this Path message is to be used to set up a new LSP (label switched path), does the processing of creating new connection;
If not with the corresponding state of this Path message, carry the Recovery_Label object in this message, just in cross-connect matrix, searched the identical interconnection of mark of carrying in the identical and incoming_label (going into mark) of the incoming interface that carries in incoming interface (incoming interface) and the Path message and the Recovery_Label object.If such interconnection is not found, just think that this Path message is to be used to set up a new connection.
If such interconnection has been found, then create corresponding RVSP state.Then, when sending Path message to downstream node, comprise a Suggested_Label (suggestion label) object, its value is identical with the value of this cross-coupled Outgoing_label (going out mark), and Outgoing Interface (outgoing interface) is identical with the value of this cross-coupled Outgoing Interface.If the next node of this node has also been restarted, then also in Path message, carry a Recovery_label object.
For bidirectional LSP, it is identical to search the incoming interface that carries in incoming interface and the Path message in cross-connect matrix, the mark that carries in incoming_label and the Recovery_label object is identical, the identical interconnection of mark of carrying among outgoing_label and the Upstream_lable (upstream label).If such interconnection is not found, just think that this Path message is to be used to set up a new connection.
If such interconnection has been found, then create corresponding RSVP state.This interconnection is just thought by synchronous.If this node is not the end-node of LSP, the value of the Upstream_lable that carries in the Path message that then sends accordingly is the value of this cross-coupled incoming_label.
6, after Node B is received the Hello message that node A sends over, if the Dst_instance=0 in the Hello message of finding to receive, then explanation and node A also do not finish synchronously, and the Dst_instance that Node B is issued in the Hello message of node A still is set to 0; If the Dst_instance=22 in the Hello message of receiving is promptly identical with the Src_instance that Node B sends in the Hello message of node A, then thus can decision node A and the synchronous recovery process of Node B finish.Only finished and its upstream node for example after the synchronous recovery of node A in Node B, Node B could be initiated the synchronous recovery process with node C.
7, the synchronous recovery process of Node B initiation and node C
The Node B initiation is similar with the processing procedure of the synchronous recovery of Node B with the disposition and the node A initiation of the synchronous recovery process of node C.Specifically, Node B starts Recovery Timer, to node C send Hello message (Src_instance=22, Dst_instance=0).Equally, before Node B failed to finish synchronous recovery with node C, the Dst_instance of Node B in the HELLO message that node C sends was always zero.
Be similar to the synchronous recovery that node A initiates Node B, Node B also will be according to all states relevant with node C generation PATH message, and carry the Recovery_Label object and send to node C, to finish the synchronous recovery to node C.After node C received the Hello message that Node B sends over, if the Dst_instance=0 in the Hello message of finding to receive, then explanation and Node B were not also finished synchronously, and the Dst_instance that node C issues in the Hello message of Node B still is set to 0; If the Dst_instance=33 in the Hello message of receiving is promptly identical with the Src_instance that node C sends in the Hello message of Node B, then thus can decision node B and the synchronous recovery process of node C finish.
After continuous nodes A in this connects, B and C recovered synchronously, the recovery of control plane was promptly accused and is finished.
Need to prove that during specific description of embodiments of the present invention, said connection referred to that all the light that uses RSVP (RSVP-TE) agreement to set up, delete connects in ASON aforementioned.The various hypothesis of being done only are used for the purpose of explanation, should not be construed as limitation of the invention.The present invention has proposed to be applicable to that continuous a plurality of node restarts the method that the back control plane recovers on the basis of existing scheme, the Several principles that described method should be followed is:
(1) last node only after the synchronous recovery process of finishing with upstream node, could initiate to downstream node synchronously;
(2) node of not restarted by the upstream or the node that recovered to finish synchronously with upstream node start Recovery Timer timer;
(3) before two adjacent nodes did not recover to finish synchronously, the value of the Dst_instance in the Hello message that exchanges between them was set to 0 all the time; Behind Recovery Timer timer expiry, notify the synchronous recovery process of downstream node to finish by upstream node;
(4) value that changes the Src instance of this node from the Hello message that this downstream node is received into of the value by the Dst_instance in the Hello message that will mail to downstream node realizes.
The present invention just is being based on above-mentioned have novelty and creationary several principles, and control plane recovers to realize restarting afterwards by continuous a plurality of node.Those of ordinary skills are under above-mentioned instruction of the present invention, and the concrete application scenarios according to the present invention can carry out various remodeling to the present invention, yet the technical scheme that does not depart from the above-mentioned thought of the present invention all should be subjected to the protection of claims of the present invention.
Claims (4)
1, be used for the ASON multinode and restart the method that control plane is recovered in the back, described ASON is according to RSVP (Resource reSerVation Protocol, RSVP) or RSVP-TE (Resource reSerVation Protocol with Traffic Engineering Extension, RSVP with traffic engineering expansion) sets up, the connection of deletion, in this connection, have three adjacent node A at least, B and C, wherein, a node A is non-reset node, be positioned at the upstream of other Node B and C, Node B and C are adjacent successively reset node, said method comprising the steps of:
(1) communication disruption of described non-reset node A discovery and adjacent node B, the value of Src_instance (source instance) remains unchanged in the Hello message that this Node B sends, the value of Dst_instance (purpose example) is set to zero, and described non-reset node A self-refresh and the relevant state of this adjacent node B;
(2) after the reset node B adjacent with non-reset node A restarted, send Hello message to adjacent node A and C, the value of Src_instance changes with respect to the value of the Src_instance before restarting with this node in this Hello message, and the value of Dst_instance is set to zero;
(3) another reset node C adjacent with above-mentioned Node B of restarting judges Node B according to the Dst_instance=0 from the Hello message that Node B receives and recovers synchronously as yet, and node C sends Dst_instance=0 in the Hello message of response to Node B;
(4) described non-reset node A receives the Hello message of sending from Node B, if variation has taken place in the value of the Src_instance before the value of the Src_instance in this message is restarted with respect to this Node B, then judging Node B has taken place to restart, node A stops above-mentioned self-refresh, start Recovery Timer (recovery timer), the value of Dst_instance in the Hello message that Node B sends remains zero, and send the Path message of carrying Recovery_Label to Node B, be used for the synchronous recovery of Node B;
(5) described non-reset node A is after Recovery Timer is overtime, the value that the value that sends to the Dst_instance in the Hello message of Node B is arranged to send to Node B the Src_instance in the Hello message of node A is identical, is used to notify Node B same EOS;
(6) Node B and node A synchronously after, Node B starts Recovery Timer, the value of Dst_instance in the Hello message that node C sends remains zero, and sends the Path message of carrying Recovery_Label to node C, is used for the synchronous recovery of node C;
(7) described Node B is after Recovery Timer is overtime, the value that the value that sends to the Dst_instance in the Hello message of node C is arranged to send to node C the Src_instance in the Hello message of Node B is identical, is used to notify node C same EOS.
2, the ASON multinode that is used for according to claim 1 is restarted the method that control plane is recovered in the back, wherein in step (4), after node A stops self-refresh, start Recovery Timer, the value of Dst_instance in the Hello message that Node B sends should remain zero, recovers synchronously up to Node B and Node B.
3, the ASON multinode that is used for according to claim 1 is restarted the method that control plane is recovered in the back, wherein in above-mentioned steps (3), node C waits for that upstream reset node B and node A finish synchronous recovery, at waiting time, the value that node C sends to the Dst_instance of Node B should remain zero.
4, the ASON multinode that is used for according to claim 1 is restarted the method that control plane is recovered in the back, and wherein in step (5), non-reset node A deletes not synchronous with Node B state after Recovery Timer is overtime.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB021474400A CN1269321C (en) | 2002-10-25 | 2002-10-25 | Recovering method for controlling plane after multi-node restarting in intelligent optical network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB021474400A CN1269321C (en) | 2002-10-25 | 2002-10-25 | Recovering method for controlling plane after multi-node restarting in intelligent optical network |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1492601A true CN1492601A (en) | 2004-04-28 |
| CN1269321C CN1269321C (en) | 2006-08-09 |
Family
ID=34232979
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB021474400A Expired - Fee Related CN1269321C (en) | 2002-10-25 | 2002-10-25 | Recovering method for controlling plane after multi-node restarting in intelligent optical network |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN1269321C (en) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007065294A1 (en) * | 2005-12-07 | 2007-06-14 | Zte Corporation | A method for processing rsvp gr when multiple neighbor nodes restart simultaneously |
| WO2007140689A1 (en) * | 2006-06-09 | 2007-12-13 | Huawei Technologies Co., Ltd. | A failure processing method and a system and a device thereof |
| WO2008086644A1 (en) * | 2007-01-05 | 2008-07-24 | Zte Corporation | Method for realizing synchronization of the connection state in automatic switched optical network |
| WO2009155799A1 (en) * | 2008-06-23 | 2009-12-30 | 华为技术有限公司 | Method for recovering information based on graceful restarting and the router thereof |
| CN101646107A (en) * | 2009-08-14 | 2010-02-10 | 中兴通讯股份有限公司 | Method, device and system for restoring service connection and node equipment |
| CN101212340B (en) * | 2006-12-25 | 2010-05-19 | 中兴通讯股份有限公司 | Method for restarting control nodes in automatic switching optical network |
| CN101141825B (en) * | 2007-08-24 | 2010-09-29 | 中兴通讯股份有限公司 | Function freezing/defreezing method in automatic switch optical network |
-
2002
- 2002-10-25 CN CNB021474400A patent/CN1269321C/en not_active Expired - Fee Related
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007065294A1 (en) * | 2005-12-07 | 2007-06-14 | Zte Corporation | A method for processing rsvp gr when multiple neighbor nodes restart simultaneously |
| CN101283543B (en) * | 2005-12-07 | 2011-07-06 | 中兴通讯股份有限公司 | Method for processing RSVP GR when restarting a plurality of neighbor nodes |
| WO2007140689A1 (en) * | 2006-06-09 | 2007-12-13 | Huawei Technologies Co., Ltd. | A failure processing method and a system and a device thereof |
| CN101087207B (en) * | 2006-06-09 | 2010-05-12 | 华为技术有限公司 | A processing method for multi-node communication failure |
| US8040793B2 (en) | 2006-06-09 | 2011-10-18 | Huawei Technologies Co., Ltd. | Method, system and device for processing failure |
| CN101212340B (en) * | 2006-12-25 | 2010-05-19 | 中兴通讯股份有限公司 | Method for restarting control nodes in automatic switching optical network |
| WO2008086644A1 (en) * | 2007-01-05 | 2008-07-24 | Zte Corporation | Method for realizing synchronization of the connection state in automatic switched optical network |
| CN101141825B (en) * | 2007-08-24 | 2010-09-29 | 中兴通讯股份有限公司 | Function freezing/defreezing method in automatic switch optical network |
| WO2009155799A1 (en) * | 2008-06-23 | 2009-12-30 | 华为技术有限公司 | Method for recovering information based on graceful restarting and the router thereof |
| CN101646107A (en) * | 2009-08-14 | 2010-02-10 | 中兴通讯股份有限公司 | Method, device and system for restoring service connection and node equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN1269321C (en) | 2006-08-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1986371B1 (en) | A failure processing method and a system and a device thereof | |
| EP1953958B1 (en) | Management of protection path bandwidth and changing of path bandwidth | |
| CN101047440A (en) | Method of service route return | |
| EP1753182A1 (en) | A method for node restart recovery in the general multi-protocol label-switching path | |
| CN1441574A (en) | High speed switchover route using automatic protective switchover and its switchover method | |
| CN1266896C (en) | Fast replacing method of elastic group loop network | |
| CN1269321C (en) | Recovering method for controlling plane after multi-node restarting in intelligent optical network | |
| CN1812401A (en) | Method for establishing return tag exchange route in multiprotocol tag exchange system | |
| CN1505409A (en) | Rerouting method based on network entrance node | |
| CN1933423A (en) | Recovery method and apparatus for optical network LSP occuring abnormal delete | |
| CN1859157A (en) | Service protective method | |
| CN1499747A (en) | Method for implementing protection and restoration for intelligent optical network | |
| CN1194507C (en) | Bidirectional channel restitution in automatic optical exchange network | |
| CN1812360A (en) | Intelligent optical network business re-routing trigging method | |
| CN1082299C (en) | Method for rerouting a packet-mode data connection | |
| CN101123473B (en) | Recovery method for control plane after node restart in automatic switching optical network | |
| CN1805398A (en) | Optical transmission network protection method | |
| CN1949724A (en) | Ether port protection method | |
| CN1251447C (en) | Method for realizing network to network interface connection synchronization and restoration | |
| CN1149761C (en) | Protection method based on business in optical network | |
| CN101345590A (en) | SNCP business collocation method | |
| CN1863108A (en) | Method for controlling SC/SPC connection in automatic exchange optical network | |
| CN1642123A (en) | Business promoting method based on multi element address for automatic switch optical nework element | |
| CN1983908B (en) | Method for automatically correcting label resource management | |
| CN1744568A (en) | Network-node for exchanging data information via a path or a detour path |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| C17 | Cessation of patent right | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20060809 Termination date: 20111025 |