US20080304494A1 - Communication device - Google Patents

Abstract

A communication device comprising: a checking unit checking whether a bandwidth from the ingress of first path down to the egress thereof and a bandwidth from the ingress of second path down to the egress thereof as a standby of a partial zone of first path, are established or not; a route information management unit generating, when the checking unit confirms that the bandwidth from the ingress of first path down to the egress thereof and the bandwidth from the ingress of second path down to the egress thereof as the standby of the partial zone of first path are established, route maintaining information for maintaining the bandwidth of the partial zone of first path; and a transmission unit transmitting the route maintaining information generated by the route information management unit to the neighboring communication device on the side of the egress of first path.

Description

• This application claims the benefit of Japanese Patent Application No. 2007-227525 filed on Sep. 3, 2007 in the Japanese Patent Office, the disclosure of which is herein incorporated in its entirety by reference.
BACKGROUND OF THE INVENTION
• 1. Field of the INVENTION
• The present invention relates generally to a communication device and a network system in an MPLS (Multi Protocol Label Switching) network. The present invention relates more particularly to a communication device and a network system, which perform switching back based on a local Revertive system by setting up a communication path (LSP (Label Switched Path)) for an FRR (Fast ReRoute, which is a facility backup technique)) using RSVP-TE (Resource Reservation Protocol-Traffic Engineering).
• 2. Description of the Related Art
• The MPLS is a packet forwarding technique using the label switching system. The MPLS involves utilizing a piece of identifying information (label) having a short fixed length in place of an IP header as routing information when forwarding a packet received by a router from another router to a different router. An MPLS-based routing method is exemplified by the FRR. The FRR is a method of preparing a communication path employed as a standby path beforehand in the MPLS network, then switching over, if a fault occurs in an active communication path, the path to the standby path, and recovering the communications. The FRR prepares the standby path beforehand and enables the communications to be quickly recovered from the fault.
• FIG. 1 is a view showing an example of a network architecture in a normal state. In the MPLS network, a Protected LSP (an LSP (active system LSP) to be protected) and a Backup LSP (a detour route (standby system LSP) for occurrence of a fault in the Protected LSP) are set up as LSPs for the FRR using the PSVP-TE (RSVP-TE) signaling. InFIG. 1, the Protected LSP (LSP#1) is set up extending from a node H down to a node T via a node A, a node B and a node C. Further, the Backup LSP (LSP#2) is set up from the node A down to the node C via the node D.
• Herein, the head-end node of the LSP (which is the node H in the case of theLSP#1 and is the node A in the case of the LSP #2) is referred to as an Ingress node, while the tail-end node of the LSP (which is the node T in the case of theLSP#1 and is the node C in the case of the LSP #2) is termed an Egress node. Further, the node corresponding to a branch point of the LSP (which is the node A inFIG. 1) is called a PLR (Point of Local Repair), while the node corresponding to a merge point (confluent point) of the LSP (which is the node C inFIG. 1) is called an MP (Merge Point).
• The node A is configured as the PLR explicitly, and the node C is configured as the MP explicitly, and thereafter the respective LSPs are set up. The Protected LSP is set up by assigning the node A serving as the Ingress node a piece of route information of a route extending from the node H down to the node T as the Egress node via the node A, the node B and the node C.
• Moreover, similarly, the Backup LSP is set up by assigning the node A serving as the Ingress node a piece of route information of a route extending from the node A down to the node C as the Egress node via the node D. Thereafter, the PLR (node A) generates an associative relation between the Protected LSP and the Backup LSP, i.e., a pair relation between the Protected LSP (LSP#1) and the Backup LSP (LSP#2).
• As a result, a detour (bypass) route against occurrence of a link fault between the node A and the node B, a link fault between the node B and the node C or a node fault of the node B, is generated in a protection zone (between the node A, the node B and the node C) on the Protected LSP.
• In a normal state, data traffic from the node H is carried via the Protected LSP to the node T.
• FIG. 27 is a diagram showing an outline of an FRR operation if a link fault occurs. As illustrated inFIG. 27, an assumption is that the link fault occurs in the protection zone between the node A and the node B. The PLR (node A), upon recognizing this link fault, switches over (reroute) the data traffic from the node H to the Backup LSP side. The MP (node C) transmits the incoming data traffic via the node D toward the node T. Thus, the data traffic from the node H is carried to the node T via the Backup LSP defined as the detour route when the link fault occurs in the protection zone. This switching operation can be executed fast and is therefore called FRR (Fast ReRoute).
• FIG. 28 is a diagram showing an outline of an FRR operation when recovered from the link fault. It is assumed that the protection zone between the node A and the node B is recovered from the link fault (the link fault is obviated). The PLR, when recognizing the recovery from the link fault and that the zone between the node A and the node B reverts to the normal state owing to the signaling, the data traffic from the node H is switched back to the Protected LSP side from the Backup LSP side. The data traffic from the node H is carried from the node H to the node T via the node A, the node B and the node C.
• This switch-back is referred to as a Local Revertive method. The Backup LSP might not be more optimal path than the Protected LSP (in terms of a delay and a bandwidth). Hence, in order to transmit the data traffic invariably along the optimal path (in terms of the delay and the bandwidth), the path is switched back to the Protected LSP from the Backup LSP.
• FIG. 29 is a diagram showing an operational example when a new LSP is set up in the protection zone during the occurrence of the fault. InFIG. 29, the link fault occurs between the node A and the node B. During the occurrence of the link fault, the data traffic from the node H defined as the Ingress node of the Protected LSP is transmitted from the node H to the node T as the Egress node via the node A, the node D and the node C. At this time, a resource between the node B and the node C is released, Thereafter, a node X is set as the Ingress node, and, when trying to set up anLSP#3 extending from the node X down to a node Y as the Egress node via the node B and the node C, theLSP#3 is normally set up because of the free resource between the node B and the node C.
• [Patent document 1] Japanese Patent Laid-Open Publication No. 2005-39362
SUMMARY OF THE INVENTION
• FIG. 30 is a diagram showing an operational example if a resource conflict arises due to the setup of the new LSP during the occurrence of the fault in the protection zone. As illustrated inFIG. 29, theLSP#3 is set up from the node A serving as the Ingress node down to the node Y as the Egress node via the node B and the node C.
• When recovered from the link fault occurring between the node A and the node B inFIG. 30 (the link fault is obviated), the PLR (node A) recognizing the recovery sends a Path Message for the Protected LSP to the node B. The node B receiving the Path Message notifies the node A by a Path Error Message that the Protected LSP can not be set up because of no resource between the node B and the node C. As a result, the Protected LSP for the Local Revertive cannot be set up, and the detoured data traffic cannot be switched back. This is because when the fault occurs in the Protected LSP, a downlink resource (e.g., the resource between the node B and the node C) with no occurrence of the fault is released (Path Tear).
• It is an object of the present invention to provide a technology enabling switch-back to a middle zone from a second communication path in a network system including a first communication path and a second communication path generated so as to bypass the middle zone of the first communication path, data sent from an ingress of the first communication path being forwarded to an egress of the first communication path via the second communication path in place of the middle zone during a fault in the middle zone.
• The present invention adopts the following means in order to solve the problems given above.
• Namely, a first mode of the present invention is a communication device, in a communication network including: a first communication path, along which a plurality of communication devices is cascade-connected, having an ingress and an egress; and a second communication path, along which the plurality of communication devices is cascade-connected, the communication devices existing both ends thereof being different from each other on the first communication path, having its ingress corresponding to the communication device, of the communication devices at both ends, located on the side of the ingress of the first communication path and its egress corresponding to the communication device, of the communication devices at both ends, located on the side of the egress of the first communication path, the communication device being the communication device located at the ingress of the second communication path, comprising:
• a checking unit checking whether a bandwidth from the ingress of the first communication path down to the egress thereof and a bandwidth from the ingress of the second communication path down to the egress thereof as a standby of a partial zone of the first communication path, are established or not;
  a route information management unit generating, when the checking unit confirms that the bandwidth from the ingress of the first communication path down to the egress thereof and the bandwidth from the ingress of the second communication path down to the egress thereof as the standby of the partial zone of the first communication path are established, route maintaining information for maintaining the bandwidth of the partial zone of the first communication path; and
  a transmission unit transmitting the route maintaining information generated by the route information management unit to the neighboring communication device on the side of the egress of the first communication path.
• Further, a second mode of the present invention is a communication device, in a communication network including: a first communication path, along which a plurality of communication devices is cascade-connected, having an ingress and an egress; and a second communication path, along which the plurality of communication devices is cascade-connected, the communication devices existing both ends thereof being different from each other on the first communication path, having its ingress corresponding to the communication device, of the communication devices at both ends, located on the side of the ingress of the first communication path and its egress corresponding to the communication device, of the communication devices at both ends, located on the side of the egress of the first communication path, the communication device being the communication device located on the first communication path between the ingress and the egress of the second communication path, comprising:
• a reception unit receiving route maintaining information for maintaining a bandwidth in a partial zone of the first communication path from the neighboring communication device on the side of the ingress of the first communication path;
  a route information management unit stored with the route maintaining information; and
  a transmission unit transmitting the route maintaining information to the neighboring communication device on the side of the egress of the first communication path.
• Still further, a third mode of the present invention is a communication device, in a communication network including: a first communication path, along which a plurality of communication devices is cascade-connected, having an ingress and an egress; and a second communication path, along which the plurality of communication devices is cascade-connected, the communication devices existing both ends thereof being different from each other on the first communication path, having its ingress corresponding to the communication device, of the communication devices at both ends, located on the side of the ingress of the first communication path and its egress corresponding to the communication device, of the communication devices at both ends, located on the side of the egress of the first communication path, the communication device being the communication device located at the egress of the second communication path, comprising:
• a reception unit receiving route maintaining information for maintaining a bandwidth in a partial zone of the first communication path from the neighboring communication device on the side of the ingress of the first communication path; and
  a route information management unit stored with the route maintaining information.
• According to the modes of the present invention, when the standby communication path is established in the partial zone of the main communication path, the communication device residing in the zone with the standby communication path established can be notified of this purport.
• Moreover, according to the first mode of the present invention, the communication device may further comprise a reception unit receiving, from the neighboring communication device on the side of the egress of the first communication path, route error information showing occurrence of a link fault on the egress side from the neighboring communication device on the side of the egress of the first communication path, wherein when the checking unit confirms that the bandwidth from the ingress of the first communication path down to the egress thereof and the bandwidth from the ingress of the second communication path down to the egress thereof as the standby of the partial zone of the first communication path are established and when the reception unit receives, from the neighboring communication device on the side of the egress of the first communication path, the route error information showing the occurrence of the link fault on the egress side from the neighboring communication device on the side of the egress of the first communication path, the transmission unit may transmit the route maintaining information to the neighboring communication device on the side of the egress of the first communication path.
• Furthermore, according to the second mode of the present invention, if the link fault occurs between the self communication device and the neighboring communication device on the side of the ingress of the first communication path, the transmission unit may transmit the route maintaining information stored in the route information management unit to the neighboring communication device on the side of the egress of the first communication path.
• According to the modes of the present invention, if the link fault occurs on the first communication path, the bandwidth on the first communication path can be maintained by continuing to transmit the route maintaining information.
• According to the present invention, it is feasible to provide a technology enabling switch-back to the middle zone from the second communication path in the network system including the first communication path and the second communication path generated so as to bypass the middle zone of the first communication path, the data sent from the ingress of the first communication path being forwarded to the egress of the first communication path via the second communication path in place of the middle zone during the fault in the middle zone.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is a view showing an example of a network architecture in a normal state.
• FIG. 2 is a diagram showing a method of setting up a Protected LSP.
• FIG. 3 is a diagram showing a method of setting up a Backup LSP.
• FIG. 4 is a diagram showing signaling of the Protected LSP after the Backup LSP has been set up.
• FIG. 5 is a diagram showing an operation in a state where a fault occurs in a protection zone.
• FIG. 6 is a diagram showing an operation in a state of being recovered from the link fault in the protection zone.
• FIG. 7 is a diagram illustrating an example of a configuration of a node.
• FIG. 8 is a diagram showing a configuration when generating the Protected LSP.
• FIG. 9 is a diagram showing a transmission Path Msg and Path State of individual nodes when setting up the Protected LSP.
• FIG. 10 is a diagram showing a transmission Resv Msg and Resv State of individual nodes when setting up the Protected LSP.
• FIG. 11 is a diagram showing a configuration after generating the Backup LSP.
• FIG. 12 is a diagram showing the transmission Path Msg and Path State of the individual nodes after setting up the Backup LSP.
• FIG. 13 is a diagram showing the transmission Resv Msg and Resv State of the individual nodes after setting up the Backup LSP.
• FIG. 14 is a diagram showing processing conditions for adding and deleting an LPAO.
• FIG. 15 is a diagram showing an operation when the fault occurs on the Protected LSP.
• FIG. 16 is a diagram showing an operation when the fault occurs on the Protected LSP.
• FIG. 17 is a diagram showing the transmission Path Msg and Path State of the respective nodes during the occurrence of the fault.
• FIG. 18 is a diagram showing the transmission Resv Msg and Resv State of the respective nodes during the occurrence of the fault.
• FIG. 19 is a diagram showing conditions for determining an operation of Refreshing the Path Message.
• FIG. 20 is a diagram illustrating an operational example when requested to set up a new LSP (other thanLSP#1 and LSP#2).
• FIG. 21 is a diagram showing an operation when requested to delete the LSP during the occurrence of the fault on the Protected LSP.
• FIG. 22 is a diagram the transmission Path Msg and Path State of the respective nodes after receiving the Path Tear Message.
• FIG. 23 is a diagram showing the transmission Resv Msg and Resv State of the individual nodes after receiving the Path Tear Message.
• FIG. 24 is a diagram showing conditions for an MP to transmit a Resv Tear Msg.
• FIG. 25 is a diagram showing an operational configuration when the link fault occurs between a node B and a node C.
• FIG. 26 is a diagram showing conditions for Refreshing the Path Message of the Protected LSP in a PLR.
• FIG. 27 is a diagram showing an outline of an FRR operation (a case in which the link fault occurs in a protection zone).
• FIG. 28 is a diagram showing the outline of the FRR operation (a case of being recovered from the fault in the protection zone).
• FIG. 29 is a diagram showing an operational example when setting up a new LSP during the occurrence of the fault in the protection zone.
• FIG. 30 is a diagram showing an operational example when a resource conflict arises due to the setup of the new LSP during the occurrence of the fault in the protection zone.
DETAILED DESCRIPTION OF THE INVENTION
• An embodiment of the present invention will hereinafter be described with reference to the drawings. A configuration in the embodiment is an exemplification, and the present invention is not limited to the configuration in the embodiment.
Embodiment
• FIG. 1 is a view showing an example of a network architecture in a normal state. An MPLS network sets up Protected LSP and Backup LSP as LSPs for FRR using PSVP-TE (RSVP-TE) signaling. InFIG. 1, Protected LSP (LSP#1) is set up from a node H up to a node T via a node A, a node B and a node C. Further, the Backup LSP (LSP#2) is set up from the node A up to the node C via the node D. The node A is defined as a PLR (Point of Local Repair), and the node C is defined as an MP (Merge Point). The PLR corresponds to a branch point of the Protected LSP, and the MP corresponds to a merge point of the LSP. Moreover, the Backup LSP detours (bypasses) the PLR and the MP based on the Protected LSP.
Standard Operational Example
• To begin with, a standard operational example of the communication network inFIG. 1 will be described.
• <<Setup of Protected LSP>>
• FIG. 2 is a diagram showing a setup method of the Protected LSP. The LSP is setup based on the RSVP-TE signaling. The signaling protocol is a protocol for distributing a label. The signaling protocol requests a necessary bandwidth on an arbitrary route while transmitting a Path Message to an Egress node from an Ingress node, and also request a label needed for forwarding the data. Further, the signaling protocol transmits a Resv Message (Reserve Message) defined as a response to the Path Message to the Ingress node from the Egress node along a route reversed to the Path Message, and meanwhile notifies of the label while ensuring the necessary bandwidth.
• An Object of the Path Message will be explained. The Object of the Path Message contains a Session Object (SO), a Fast Reroute Object (FRO), a Session Attribute Object (SAO), an Explicit Route Object (ERO), and an HOP Object.
• The SO is an Object for identifying a session of the LSP. The SO is stored with pieces of information (IP addresses etc) of the Ingress node and the Egress node of the LSP.
• The FRO is an Object which requests the setup with the LSP serving as the Protected LSP. The FRO is stored with a bandwidth needed in the LSP. The FRO is invariably contained in the Path Message of the Protected LSP.
• The SAO is an Object representing a session attribute. The SAO is stored with information for requesting Local Protection.
• The ERO is an Object for explicitly specifying a route of the LSP. The ERO is stored with an IP address of an Interface for receiving the Message.
• The HOP Object is an Object showing a sender of the Message. The HOP Object is stored with an IP address of an Interface for transmitting the Message.
• An Object of the Resv Message will be described. The Object of the Resv Message contains the Session Object (SO), a Record Route Object (RRO) and an HOP Object.
• The SO is the Object for identifying the session of the LSP. In the same way as the SO of the Path Message is, the SO is stored with the information (IP addresses etc) for specifying the Ingress node and the Egress node of the LSP.
• The RRO is an Object showing a sender of the Message. The RRO is stored with an IP address of an Interface for transmitting the Message. Further, the RRO is stored with reserved label information. Still further, the RRO is stored with information showing whether the Local Protection can be utilized or not.
• The HOP Object is an Object showing a sender of the Message. The HOP Object is the same as the HOP Object of the Path Message.
• The Path Message and the Resv Message can contain other Objects that are not shown above.
• The Path Message and the Resv Message are route information for reserving a resource (bandwidth) of the communication path and also route information for updating the reservation of the resource (bandwidth) of the communication path.
• As illustrated inFIG. 2, when the node A receives the Path Message sent from the Ingress node (node H), the node A deletes one ERO (A-IF1) and transmits the Path Message toward the downlink node (node B) by changing the HOP Object (A-IF2). The node B and the node C execute the same process, thereby transmitting the Path Messages toward the downlink nodes.
• The Egress node (node T) sends the Resv Message back to the uplink node (node C) as a response to the received Path Message. The node C adds one RRO (C-IF1, Label200) to the received Resv Message, and sends the Message back to the uplink node (node B) by changing the HOP Object (C-IF1). The node B and the node A transmit the Resv Message toward the uplink node by executing the same process.
• Thereafter, as for the Path Message and the Resv Message, in principle the same information is transmitted to the same node at a fixed cycle (e.g., 30 seconds). The transmitting operation at this fixed cycle is called “Refresh”. The Refresh maintains the LSP that has been set up.
• <<Setup of Backup LSP>>
• FIG. 3 is a diagram showing a setup method of the Backup LSP. The Message used in the Backup LSP is basically the same as the Message employed in the Protected LSP shown inFIG. 2. The Path Message used in the Backup LSP does not, however, contain the FRO.
• The Path Message is transmitted to the node C serving as the Egress node of the Backup LSP via the node D from the node A as the Ingress node of the Backup LSP. On the other hand, the Resv Message is transmitted to the node A as the Ingress node of the Backup LSP via the node D from the node C as the Egress node of the Backup LSP. Thus, the Backup LSP is set up and maintained by conducting the Refresh.
• The node A as a PLR can recognize from receiving the Resv Message that the Backup LSP has been set up.
• <<Signaling of Protected LSP after the Setup of the Backup LSP>>
• FIG. 4 is a diagram showing the signaling of the Protected LSP after setting up the Backup LSP. In the node serving as the PLR, the Backup LSP for the Protected LSP is set up.
• The node A as the PLR notifies the Ingress node (node H) of the Protected LSP of a purport that the Backup LSP has been set up in the form of Local Protection available (LP available) information of the RRO. Through this notification, the Ingress node (node H) of the Protected LSP can recognize that the downlink and the downlink node are protected (Protection). InFIG. 4, the Path Message and the Resv Message of the Backup LSP are omitted.
• <<Operation at Occurrence of Fault in Link>>
• FIG. 5 is a diagram showing an operation in a state where a fault occurs in a protection zone. When the fault occurs in the link between the node A and the node B through which the Protected LSP passes, the PLR switches over, after recognizing the link fault, the Path Message sent to the node B to the Backup LSP side in the same way as the data traffic is. This Path Message is transmitted via the Backup LSP to the node C (MP)
• On the other hand, the node B determines from the recognition of the fault in the uplink that the Path Message is not Refreshed any more from the node A, and therefore transmits a Path Tear Message to the downlink node C. The Path Tear Message is a Message that requests a reserved resource with the Path Message to release. The node C receiving the Path Tear Message deletes the reserved-and-related reservation information. Note that in the node C, the Path Message is Refreshed from the Backup LSP side, and hence the Path Message is Refreshed to the node T from the node C.
• <<Operation when Recovered from Link Fault>>
• FIG. 6 is a diagram showing an operation in a state where the link is recovered from the fault in the protection zone. The PLR (node A) transmits, after recognizing the recovery from the link fault, the Path Message toward the node B. The node B receiving the Path Message transmits afresh the Path Message to the node C. The node C sends the Resv Message to the node B, and the node B sends the Resv Message to the node A. The PLR (node A) receiving the Resv Message recognizes that the Protected LSP gets recovered normally, then switches back the data traffic, and stops transmitting the Path Message which has been sent so far to the Backup LSP side. With this operation, the Local Revertive is completed.
• Herein, a purpose for executing the Local Revertive will be explained. Supposing that a link is, if another route exists, established between, e.g., the node A and anode X, after being switched over to the Backup LSP during the occurrence of the link fault between the node A and the node B, another LSP can be again set up on a route established by the node H, the node A, the node X, the node B, the node C and the node T. Thereafter again, however, a new Backup LSP must be prepared for this LSP (the nodes H, A, X, B, C and T). The already-set-up Backup LSP between the node A, the node D and the node C becomes an unnecessary LSP and therefore needs deleting. It is required that an administrator needs to execute these processes each time the fault occurs. It is, however, feasible to avoid these complicated processes by conducting the Local Revertive.
• <Device>
• <<Node>>
• Next, the nodes in the present embodiment will be described. The nodes can function as the Ingress node, the Egress node, a Transit node (relay node), the PLR, the MP, etc, depending on their allocated positions and so on.
• FIG. 7 is a diagram showing an example of a configuration of the node. Anode200 includes an external input/output IF (InterFace)unit206, a receptionpacket processing unit202, a transmissionpacket processing unit204, a reception PathState management unit212, a transmission PathMessage management unit214, a reception ResvState management unit222, a transmission ResvMessage management unit224, a label/routeinformation management unit230 and a label table & forwardingprocessing unit240.
• (External I/O IF Unit)
• The external I/O IFunit206 is an interface for control of the self-node and collecting the information.
• (Reception Packet Processing Unit)
• The receptionpacket processing unit202 checks whether an abnormal state exists in the packet received from the input interface or not. The receptionpacket processing unit202, if the received packet is normal, transmits the received packet to a proper management unit.
• The receptionpacket processing unit202, if the received packet is the Path Message, sends this received packet to the reception PathState management unit212. The receptionpacket processing unit202, if the received packet is the Resv Message, sends this received packet to the reception ResvState management unit222. The receptionpacket processing unit202, if the received packet is of main signal traffic, transmits this received packet to the label table & forwardingprocessing unit240.
• FIG. 7 illustrates the two receptionpacket processing units202, however, the single reception packet processing unit may execute the processes given above.
• (Transmission Packet Processing Unit)
• The transmissionpacket processing unit204 transmits, to the output interface, the packets received from the transmission PathMessage management unit214, the transmission ResvMessage management unit224 or the label table & forwardingprocessing unit240.
• FIG. 7 illustrates the two transmissionpacket processing units204, however, the single transmission packet processing unit may execute the processes given above.
• (Reception Path State Management Unit)
• The reception PathState management unit212 queries the label/routeinformation management unit230 about whether the route information of the received Path Message is proper or not. Further, the reception PathState management unit212 manages each Object of the received Path Message, and checks whether the Path State is periodically Refreshed.
• (Transmission Path Message Management Unit)
• The transmission PathMessage management unit214, when functioning as the Ingress node, generates the Path Message on the basis of the route information and the bandwidth information inputted from the external I/O IFunit206 in order to set up the LSP.
• The transmission PathMessage management unit214, when functioning as the Egress node, does not transmit the Path Message.
• The transmission PathMessage management unit214, when functioning neither as the Ingress node nor as the Egress node but as the relay node (Transit node), generates the transmission Path Message based on the received Path Message. At this time, the transmission PathMessage management unit214 queries the label/routeinformation management unit230 about the route information.
• The transmission PathMessage management unit214, when functioning as the PLR and when receiving the notification that the Backup LSP has been set up from the reception PathState management unit212, allocates an LPAO (Local Protection Available Object) to the LSP having the FRO.
• The transmission PathMessage management unit214, when functioning as the MP and when receiving the LPAO, deletes the LPAO. If not the MP and when receiving the LPAO, the transmission PathMessage management unit214 lets the LPAO pass through as it is.
• The transmission PathMessage management unit214, when recognizing the uplink fault, transmits the Path Tear Message to the downlink node. The transmission PathMessage management unit214 does not, however, transmit the Path Tear Message to the downlink node with respect to the LSP having the LPAO.
• The transmission PathMessage management unit214 can be realized as a reservation unit for reserving (ensuring) the LSP resource and also as a reservation updating unit for updating (maintaining) a reserved status of the LSP resource.
• (Reception Resv State Management Unit)
• The reception ResvState management unit222 transmits the label information of the receive Resv Message to the label/routeinformation management unit230 from the downlink node, and manages the received Resv State. On this occasion, the reception ResvState management unit222 checks whether the Resv State is Refreshed at fixed time. Further, the reception ResvState management unit222, when the Backup LSP is set up, notifies the transmission ResvMessage management unit224 of this purport.
• (Transmission Resv Message Management Unit)
• The transmission ResvMessage management unit224, when functioning as the Ingress node, does not transmit the Resv Message.
• The transmission ResvMessage management unit224, when functioning as the Egress node or the Transit node, generates the transmission Resv Message based on the received Resv Message. At this time, the transmission ResvMessage management unit224 queries the label/routeinformation management unit230 about the to-be-allocated label information and route information.
• (Label/Route Information Management Unit)
• The label/routeinformation management unit230 manages the label information and the route information. The label/routeinformation management unit230 responds to the queries given from the respective blocks (the reception PathState management unit212, the transmission PathMessage management unit214, the reception ResvState management unit222, the transmission ResvMessage management unit224, the label table & forwardingprocessing unit240, etc). The label/routeinformation management unit230 sends the label-related information to the label table & forwardingprocessing unit240.
• The reception PathState management unit212, the transmission PathMessage management unit214, the reception ResvState management unit222, the transmission ResvMessage management unit224 and the label/routeinformation management unit230 may be realized as one route information management unit.
• The node can confirm from receiving the Path Message and the Resv Message of the LSP that the LSP resource is ensured.
• (Label Table & Forwarding Processing Unit)
• The label table & forwardingprocessing unit240 receives the label-related information from the label/routeinformation management unit230 and retains the label information in a label table.
• The label table & forwardingprocessing unit240, when functioning as the Ingress node and when receiving the packet from the receptionpacket processing unit202, determines a forwarding destination, then, thereafter, attaches a label to the packet and transmits the label-attached packet to the transmissionpacket processing unit204.
• The label table & forwardingprocessing unit240, when functioning as the Transit node and when receiving the packet from the receptionpacket processing unit202, determines, based on the label attached to the received packet, the forwarding destination, then reattaches a label to the packet, and transmits the label-reattached packet to the transmissionpacket processing unit204.
• The label table & forwardingprocessing unit240, when functioning as the Egress node and when receiving the packet from the receptionpacket processing unit202, determines, based on the label attached to the received packet, the forwarding destination, then removes the label from the packet, and transmits the label-removed packet to the transmissionpacket processing unit204.
Operational Example in Present Embodiment
• Given below is an operational example of the communication network using the nodes described above.
• When the fault occurs in the Protected LSP, a method of preventing the release of the resources of the downlink as viewed from an occurrence point of the fault by use of the LPAO, will be explained.
• <<Setup of Protected LSP>>
• FIG. 8 is a diagram showing a configuration when generating the Protected LSP. InFIG. 8, the Protected LSP (LSP#1) is set up extending from the node H (Ingress node) down to the node T (Egress node). The Backup LSP is not yet set up.
• FIG. 9 is a diagram showing a transmission Path Msg and Path State of each node when setting up the Protected LSP.
• FIG. 10 is a diagram showing a transmission Resv Msg and Resv State of each node when setting up the Protected LSP.
• The Protected LSP (LSP#1) is set up from the node H (Ingress node) toward the node T (Egress node). The network administrator explicitly designates the PLR and the MP as roles of the nodes within the network. An assumption inFIG. 8 is that the node A is designated as the PLR, and the node C is designated as the MP. The network administrator supplies the node H with information for setting up the Protected LSP (LSP#1).
• In the node H, the external I/O IFunit206 receives the information (e.g., the route information and the bandwidth information) for setting up the Protected LSP (LSP#1) from the outside. The external I/O IFunit206 transmits the received information to the transmission PathMessage management unit214.
• The transmission PathState management unit214 generates, based on the received information, the Path Message for setting up the Protected LSP (LSP#1). This Path Message corresponds to a transmission Path Msg (Message) T102 of the node H inFIG. 9.
• The transmission PathState management unit214 transmits the generated Path Message to the transmissionpacket processing unit204. The transmissionpacket processing unit204 sends the received Path Message toward the node A according to the Path Message.
• The transmission Path Msg T102 of the node H is recorded with the information necessary for generating the Path Message. For example, these necessary pieces of information are LSP identifying information, Session management information (SO), a request (FRO) for the bandwidth with respect to Fast Reroute, a request (SAO) for the Local Protection, explicit route information (ERO) and transmission Interface information (HOP). The node H generates, based on these pieces of information, the Path Message at the fixed cycle and transmits the Path Message (Refresh).
• In the node A, the transmissionpacket processing unit204 receives the Path Message from the node H. The transmissionpacket processing unit204, since the received packet is the Path Message, transmits the received packet to the reception PathState management unit212. The reception PathState management unit212 of the node A queries the label/routeinformation management unit230 about whether the route information of the received Path Message is proper or not. The reception PathState management unit212 retains intactly the information of each Object of the received Path Message as Path State T154.
• The reception PathState management unit212 of the node A updates the Path State T154 when receiving the next Path Message. The reception PathState management unit212, if the Path Message is not received for a predetermined period of time (e.g., 150 seconds, which may also be the same as the fixed time described above) from the node H, clears the information of each Object of the Path State T154.
• The reception PathState management unit212 transmits the received Path Message to the transmission PathMessage management unit214.
• The transmission PathMessage management unit214 of the node A receives the Path Message from the reception PathState management unit212. The transmission PathMessage management unit214 deletes the reception IF information (A-IF1) of the self node A from the ERO of the Path Message. Further, the transmission PathState management unit214 changes the HOP Object of the Path Message to the transmission IF information (A-IF2) of the self node A.
• The transmission PathMessage management unit214 of the node A transmits the Path Message with the updated information to the transmissionpacket processing unit204. The transmissionpacket processing unit204 sends the received Path Message toward the node B according to the Path Message.
• Hereafter, in the case of the nodes B and C, in the same way as in the case of the node A, the Path Message is received and, after executing the predetermined processes, transmitted to the next node. In each of the nodes, the Path State and the transmission Path Msg are recorded, and the pieces of information such as the ERO and the HOP Object are sequentially updated.
• In the node T (Egress node), the transmissionpacket processing unit204 receives the Path Message from the node C. The transmissionpacket processing unit204, as the received packet is the Path Message, transmits the packet to the reception PathState management unit212.
• The reception PathState management unit212 of the node T queries the label/routeinformation management unit230 as to whether the route information of the received Path Message is proper or not. The reception PathState management unit212 retains intactly the information of each Object of the received Path Message as a Path State T160.
• The reception PathState management unit212 of the node T, when receiving the next Path Message, updates the Path State T160. The reception PathState management unit212, if the Path Message is not received from the node C for the predetermined time, clears the information of each Object of the Path State T160.
• FIG. 10 is a diagram showing the information of each node with respect to the Resv Message on the occasion of setting up the Protected LSP (LSP#1). This information contains the following items of information needed for generating the Resv Message. For example, the information is exemplified by the LSP identifying information, the Session management information (SO), the route information, the label information, record information (RRO) containing the Local Protection information, and the transmission Interface information (HOP).
• The transmission ResvMessage management unit224 of the node T (Egress node) generates (Refresh), based on a transmission Resv Msg T260, the Resv Message at the fixed cycle. The transmission ResvMessage management unit224 transmits the generated Resv Message to the transmissionpacket processing unit204. The transmissionpacket processing unit204 sends the Resv Message received from the transmission ResvMessage management unit224 toward the node C based on the Resv Message.
• In the node C (Transit node), the transmissionpacket processing unit204 receives the Resv Message from the node T. The transmissionpacket processing unit204, since the received packet is the Resv Message, transmits the packet to the reception ResvState management unit222.
• The reception ResvState management unit222 retains intactly the information of each Object of the received Resv Message as a Resv State T208. The reception ResvState management unit222 of the node C extracts the label information from the received Resv Message. The extracted label information is transmitted to the label/routeinformation management unit230. The label/routeinformation management unit230 transmits the label information received from the reception ResvState management unit222 to the label table & forwardingprocessing unit240. The label table & forwardingprocessing unit240 retains the received label information in the label table.
• The reception ResvState management unit222 of the node C updates, when receiving the next Resv Message, a Resv State T208. The reception ResvState management unit222, if the Resv Message is not received from the node T for the predetermined time (e.g., 150 seconds, which may be the same as the fixed time described above), clears the information of each Object of the Resv State T208.
• The reception ResvState management unit222 transmits the received Resv Message to the transmission ResvMessage management unit224.
• The transmission ResvMessage management unit224 receives the Resv Message from the reception ResvState management unit222. The transmission ResvMessage management unit224 adds transmission IF information (C-IF1) and the label information (200) of the self node C to the RRO of the Resv Message. Further, the transmission ResvMessage management unit224 changes the HOP Object of the Resv Message to the transmission IF information (C-IF1) of the self node C.
• The transmission ResvMessage management unit224 transmits the Resv Message with the updated information to the transmissionpacket processing unit204. The transmissionpacket processing unit204 sends the received Resv Message to the node B according to the Resv Message.
• Hereafter, in the case of the nodes B and A, in the same way as in the case of the node C, the Resv Message is received and, after executing the predetermined processes, transmitted. In each of the nodes, the Resv State and the transmission Resv Msg are recorded, and the pieces of information such as the RRO and the HOP Object are sequentially updated.
• In the node H (Ingress node), the transmissionpacket processing unit204 receives the Resv Message from the node A. The transmissionpacket processing unit204, as the received packet is the Resv Message, transmits the packet to the reception ResvState management unit222.
• The reception ResvState management unit222 of the node H extracts the label information from the received Resv Message, and sends the extracted label information to the label/routeinformation management unit230. The reception ResvState management unit222 retains intactly the information of each Object of the received Resv Message as Resv State T202.
• Each node receives the Path Message and the Resv Message of the LSP and is thereby enabled to recognize that the LSP is set up, i.e., the resource is ensured.
• The reception ResvState management unit222 of the node H, when receiving the next Resv Message, updates the Resv State T202. The reception ResvState management unit222, if the Resv Message is not received from the node A for the predetermined time, clears the information of each Object of the Resv State T202.
• The node H receives the Resv Message and is thereby enabled to recognize that the Protected LSP is set up, i.e., the resource is ensured.
• <<Setup of Backup LSP>>
• The Backup LSP is set up in the same way as setting up the Backup LSP in the example of the standard operation illustrated inFIG. 3.
• <<Signaling of Protected LSP after Setup of Backup LSP>>
• FIG. 11 is a diagram showing an outline of signaling of the Protected LSP after setting up the Protected LSP and the Backup LSP. In the node A serving as PLR, the Backup LSP for the Protected LSP is set up. The Backup LSP (LSP#2) is set up toward the node C via the node D from the node A.
• The node A as the PLR, upon a trigger that the Protected LSP and the Backup LSP have been set up, adds an LPAO (Local Protection Available Object) to the Path Message and transmits the Path Message to the downlink node. The node B serving as the Transit node let the LPAO pass through as it is, and the node C as the MP deletes this LPAO from the Path Message and transmits the Path Message to the downlink node.
• Herein, the LPAO (Local Protection Available Object) is an Object showing that the Backup LSP is set up for the Protected LSP. The LPAO is the Object that does not exist in the standard signaling message. The LPAO is the Object, which is newly added according to the present embodiment. The LPAO is transmitted between the PLR and the MP.
• FIG. 12 is a diagram showing the transmission Path Msg and the Path State of the respective nodes after setting up the Backup LSP.
• FIG. 13 is a diagram showing the transmission Resv Msg and the Resv State of the respective nodes after setting up the Backup LSP.
• When the node A as the PLR recognizes that the Backup LSP is set up, the reception PathState management unit212 of the node A notifies the transmission PathMessage management unit214 that the Backup LSP is set up.
• A check as to whether the Protected LSP and the Backup LSP are set up may be realized by way of a check unit of the node.
• The transmission PathMessage management unit214 newly adds the LPAO to theLSP#1 having the FRO of the transmission Path Msg (FIG. 12: a transmission Path Msg T304 of the node A). The transmission PathMessage management unit214 transmits the LPAO-added Path Message to the transmissionpacket processing unit204.
• The transmissionpacket processing unit204 sends the received Path Message toward the node B according to the Path Message.
• In the node B serving as the Transit node, the transmissionpacket processing unit204 receives the Path Message from the node A. The transmissionpacket processing unit204, as the received packet is the Path Message, sends the packet to the reception PathState management unit212.
• The reception PathState management unit212 of the node B queries the label/routeinformation management unit230 about whether the route information of the received Path Message is proper or not. The reception PathState management unit212 retains the information of each Object (containing the LPAO) of the received Path Message as a Path State T356 as it is.
• The reception PathState management unit212 of the node B, when receiving the next Path Message, updates the Path State. The reception PathState management unit212, if the Path Message is not received from the node A for the predetermined time, clears the information of each Object of the Path State T356.
• The reception PathState management unit212 of the node B sends the received Path Message to the transmission PathMessage management unit214.
• The transmission PathMessage management unit214 of the node B receives the Path Message from the reception PathState management unit212. The transmission PathMessage management unit214 deletes reception IF information (B-IF1) of the self-node B from the ERO of the Path Message. Further, the transmission PathMessage management unit214 changes the HOP Object of the Path Message to transmission IF information (B-IF2) of the self-node B.
• The transmission PathMessage management unit214 of the node B transmits the Path Message (containing the LPAO) with the updated information to the transmissionpacket processing unit204. The transmissionpacket processing unit204 sends the received Path Message to the node C according to the Path Message.
• In the node C serving as the MP, the receptionpacket processing unit202 receives the Path Message from the node B. The receptionpacket processing unit202, since the received packet is the Path Message, transmits the packet to the reception PathState management unit212.
• The reception PathState management unit212 of the node C queries the label/routeinformation management unit230 as to whether the route information of the received Path Message is proper or not. The reception PathState management unit212 retains the information of each Object (containing the LPAO) of the received Path Message as a Path State T358 as it is.
• The reception PathState management unit212 of the node C, when receiving the next Path Message, updates the Path State. The reception PathState management unit212, if the Path Message is not received from the node B for the predetermined time, clears the information of each Object of the Path State T358.
• The reception PathState management unit212 of the node C transmits the received Path Message to the transmission PathMessage management unit214.
• The transmission PathMessage management unit214 of the node C receives the Path Message from the reception PathState management unit212. The transmission PathMessage management unit214 deletes reception IF information (C-IF1) of the self-node C from the ERO of the Path Message. Further, the transmission PathMessage management unit214 changes the HOP Object of the Path Message to transmission IF information (C-IF2) of the self-node C.
• The transmission PathMessage management unit214 deletes the LPAO from the received Path Message, and retains the Path Message as transmission Path Msg (FIG. 12: transmission Path Msg T308 of the node C).
• The transmission PathMessage management unit214 of the node C transmits the Path Message with the updated information to the transmissionpacket processing unit204. The transmissionpacket processing unit204 sends the received Path Message to the node T according to the Path Message.
• FIG. 14 is a diagram showing add/delete processing conditions of the LPAO. The self-node is the PLR, the Path Message containing the FRO is received, and the Backup LSP is set up, in which case the LPAO is added to the Path Message toward the downlink. The self-node is the MP, and the Path Message containing the FRO is received, in which case the LPAO is deleted.
• Furthermore, the node A as the PLR, when recognizing that the Backup LSP is set up, notifies the node H as the Ingress node that the Local Protection becomes available (LP available) as shown in the RRO of the Resv Msg T454 of the node A inFIG. 13.
• <<Operation when Link Fault Occurs>>
• FIG. 15 is a view showing an outline of an operation when the link fault occurs on the Protected LSP. InFIG. 15, the link fault occurs between the node A and the node B.
• The node B recognizes that the Path Message is not Refreshed due to the link fault on the uplink. The node B, as the Path Message of the LSP has the FRO and the LPAO, does not release the resource based on the Path Tear Message but continues the Refresh operation to the downlink node (node C). With this scheme, it follows that the resource between the node B and the node C with respect to the Protected LSP (LSP#1) is maintained without being released. Namely, the release of the resource between the node B and the node C with respect to the Protected LSP (LSP#1) is inhibited.
• FIG. 16 is a view showing a configuration when the link fault occurs on the Protected LSP.
• FIG. 17 is a diagram showing the transmission Path Msg and the Path State of the respective nodes during the occurrence of the link fault.
• FIG. 18 is a diagram showing the transmission Resv Msg and the Resv State of the individual nodes during the occurrence of the link fault.
• The node A as the PLR, when recognizing the fault between the node A and the node B, switches over the data traffic to the Backup LSP side. The node A as the PLR, upon recognizing the fault between the node A and the node B, switches back the data traffic to the Backup LSP side. The reception ResvState management unit222 does not receive the Resv Message from the node B, whereby the node A can recognize the fault between the node A and the node B. The node A thus detects the fault. The node A switches over the Path Message sent to the node B side to the Backup LSP side. At this time, the transmission PathMessage management unit214 of the node A changes the [B-IF1] and [C-IF1] of the ERO of the transmission Path Msg of the node A to [C-IF3] and changes [A-IF2] of the HOP to [A-IF3] (FIG. 17: transmission Path Msg T504 of the node A). The transmission PathMessage management unit214 transmits the element-changed Path Message to the transmissionpacket processing unit204.
• The transmissionpacket processing unit204 sends the received Path Message to the node C from the Backup LSP side according to the Path Message.
• In the node C, the transmissionpacket processing unit204 receives the Path Message from the node A on the side of the Backup LSP. The transmissionpacket processing unit204, as the received packet is the Path Message, sends the packet to the reception PathState management unit212.
• The reception PathState management unit212 of the node C queries the label/routeinformation management unit230 about whether the route information of the received path is proper or not.
• The reception PathState management unit212 adds LSP#1-BU (BackUp) to the Path State, and retains the information of each Object of the received Path Message (FIG. 17: Path State T558 of the node C).
• The reception PathState management unit212 of the node C transmits the received Path Message to the transmission PathMessage management unit214.
• The transmission PathMessage management unit214 of the node C receives the Path Message from the reception PathState management unit212. The transmission PathMessage management unit214 deletes the reception IF information (C-IF3) of the self-node C from the ERO of the Path Message. Further, the transmission PathMessage management unit214 changes the HOP Object of the Path Message to the transmission IF information (C-IF2) of the self-node C. The node C is the MP, and hence the transmission PathMessage management unit214 deletes the LPAO from the received Path Message.
• The transmission PathMessage management unit214 transmits the Path Message with the updated information to the transmissionpacket processing unit204. The transmissionpacket processing unit204 sends the received Path Message to the node T according to the Path Message.
• On the other hand, the node B as the Transit node, when recognizing the fault between the node A and the node B, clears the Path State of the node B (FIG. 17: Path State T556 of the node B). The node B, none of the Path Message being received by the reception PathState management unit212 from the node A, can therefore recognize the fault between the node A and the node B. The transmission PathMessage management unit214 of the node B maintains the transmission Path Msg T506 of the node B as it is. This is because the transmission Path Message T506 of the node B contains the FRO and LPAO and the continuous Refresh is required. With this scheme, as illustrated inFIG. 16, the node B continuously transmits the Path Message toward the node C even during the occurrence of the fault between the node A and the node B. It is therefore feasible to maintain the resource for the Protected LSP (LSP#1) between the node B and the node C.
• It follows that the node C receives the Path Message (LSP#1-BU) from the node A and the Path Message (LSP#1-P) from the node B.
• FIG. 19 is a diagram showing a condition for determining whether the Transit node (e.g., the node C) residing in the protection zone continues the Refresh operation of the Path Message or not. In the Transit node residing in the protection zone, if the uplink is normal and the Path Message is Refreshed from the uplink, the node Refreshes also the Path Message to the downlink. In the Transit node residing in the protection zone, if the Path Message to be transmitted even if the abnormal state occurs in the uplink contains the FRO and the LPAO, the node Refreshes also the Path Message to the downlink. In cases other than this, the Path Tear is set without Refreshing.
• During the occurrence of the fault between the node A and the node B, the node C receives the Path Message from the Protected LSP side and from the Backup LSP side as well. Hence, as shown in the transmission Resv Msg T658 of the node C inFIG. 18, the Resv Message is sent to both of the node A and the node B.
• Further, the node A receives the Resv Message from the Backup LSP side. The reception ResvState management unit222 of the node A changes [C-IF1] of the RRO of the Resv State of the node A to [C-IF3] and changes the HOP to [B-IF1] (FIG. 18: Resv State T604 of the node A). The reception ResvState management unit222 sends the received Resv Message to the transmission ResvMessage management unit224.
• The transmission ResvMessage management unit224 of the node A receives the Resv Message from the reception ResvState management unit222. The transmission ResvMessage management unit224 updates the transmission Resv Msg. The transmission ResvMessage management unit224 transmits the Resv Message to the transmissionpacket processing unit204. The transmissionpacket processing unit204 sends the Resv Message toward the node H according to the Resv Message. These operations enable avoidance of a conflict among the resources during the occurrence of the fault.
• The resource of the Protected LSP can be maintained by use of the LPAO showing that the Backup LSP is set up for the Protected LSP. The LPAO can be realized by route maintaining information.
• The node A as the PLR, upon recognizing the recovery from the link fault, transmits the Path Message toward the node B. The node B receiving the Path Message sends the Path Message to the node C. The node C transmits the Resv Message to the node B, and the node B sends the Resv Message to the node A. The PLR (node A) receiving the Resv Message recognizes that the Protected LSP is normally recovered, then switches back the data traffic, and stops transmitting the Path Message sent toward the Backup LSP side.
• According to this configuration, during even the occurrence of the link fault, the resource on the Protected LSP can be maintained, and therefore the data traffic can be switched back on the occasion of the recovery from the link fault.
• The detection of the link fault can be realized by way of a detection unit. The switch-back of the data traffic can be actualized by way of a switch control unit. The maintenance of the resource of the Protected LSP can be realized by way of an inhibiting unit which inhibits the resource from being released.
• <<Operation when Requested to Set Up New LSP>>
• FIG. 20 is a view showing an operational example when requested to set up a new LSP (other thanLSP#1 and LSP#2).
• As shown inFIG. 20, an assumption is that anLSP#3 extending from the node X down to the node Y via the node B and the node C is requested to be set up. At this time, the node B receiving the Path Message of theLSP#3, as there is no resource between the node B and the node C, notifies the node X by a Path Error Message that the LSP can not be set up. As a result, in the node B, the resource conflict between the Protected LSP (LSP#1) and theLSP#3 can be avoided (the priority is given to the resource of the Protected LSP (LSP#1)), and hence the Local Revertive can be surely done when recovered from the fault between the node A and the node B.
• <<Operation if Delete Request of LSP is Made on Protected LSP during Occurrence of Link Fault>>
• An operation in the case of receiving a delete request (Path Tear) of the LSP on the Protected LSP during the occurrence of the fault, will be explained.
• FIG. 21 is a view showing a configuration when the delete request of the LSP is made on the Protected LSP during the occurrence of the fault.
• FIG. 22 is a diagram showing the transmission Path Msg and the Resv State of the individual nodes after receiving the Path Tear Message.
• FIG. 23 is a diagram showing the transmission Resv Msg and the Resv State of the individual nodes after receiving the Path Tear Message.
• The node H, when receiving the delete request of theLSP#1, sends the Path Tear Message to the node T from the node H via the node A, the node D and the node C. According to this configuration, the resource of theLSP#1 via the Backup LSP is released.
• The node B can not receive the Path Tear Message from the uplink (the node A) due to the occurrence of the fault between the node A and the node B. Consequently, the resource between the node B and the node C is not released. Such being the case, for avoiding the maintenance of the unnecessary resource, the node C as the MP, upon a trigger that the node C receives the Path Tear Message from the Backup LSP side, transmits the Resv Tear Message toward the uplink node B. The node B, when receiving the Resv Tear Message, releases the resource between the node B and the node C. According to this configuration, the resource between the node B and the node C is released.
• FIG. 24 is a diagram showing conditions under which the MP transmits the Resv Tear Message to the uplink on the side of the Protected LSP. The self-node is the MP, the MP has the Path States of the Protected LSP and of the Backup LSP with respect to the same LSP and receives the Path Tear Message from the Backup LSP side, under which conditions the MP transmits the Resv Tear Message to the uplink on the side of the Protected LSP.FIGS. 22 and 23 show the results of clearing all items of information about theLSP#1 after the Path Tear.
• According to this configuration, it is possible to handle the delete request of the LSP, which is received when switched over to the Backup LSP.
• <<Operation if Link Fault Occurs between Node B and Node C>>
• An operation (a method of preventing the uplink resource from being released at a point where the link fault occurs) if the link fault occurs not nearest to the node A as the PLR described above but between the node B and the node C, will be explained.
• FIG. 25 is a diagram showing a configuration in the case of the occurrence of the link fault between the node B and the node C.
• As described above, when the link fault occurs between the node A and the node B, the node A as the PLR can directly detect the abnormal state of the nearest downlink. The node A recognizing the link fault between the node A and the node B switches over the data traffic and the Path Message to the Backup LSP side.
• On the other hand, as shown inFIG. 25, if the link fault occurs between the node B and the node C, the node B transmits the Path Error Message toward the uplink node A. The Path Error Message is route error information for notifying of the downlink fault etc. The node A as the PLR receiving the Path Error Message from the node B recognizes the occurrence of the link fault on the downlink. The node A switches over the data traffic and the Path Message sent to the node B to the Backup LSP side. Moreover, if the Path Message sent from the node A to the node B contains the FRO and the LPAO, it is required that the resource between the node A and the node B be maintained. Therefore, the node A continues to transmit the Path Message also to the node B. This operation enables the avoidance of the resource conflict with the LSP of the route built up by, e.g., the node Z, the node A, the node B and the node X.
• FIG. 26 is a diagram showing conditions for Refreshing the Path Message of the Protected LSP on the PLR.
• In the node serving as the PLR, the uplink is normal, the Path Message is Refreshed from the uplink, the nearest downlink is normal, and the Path Error Message is not received from the downlink, in which case the Path Message is Refreshed only on the side of the Protected LSP.
• In the node serving as the PLR, the uplink is normal, the Path Message is Refreshed from the uplink, and the nearest downlink is abnormal, in which case the Path Message is Refreshed (switched over) on the side of the Backup LSP.
• In the node serving as the PLR, the uplink is normal, the Path Message is Refreshed from the uplink, the Path Message to be transmitted contains the FRO and the LPAO, the nearest downlink is normal, and the Path Error Message is received from the downlink, in which case the Path Message is Refreshed on the side of the Protected LSP and on the side of the Backup LSP.
• In the node serving as the PLR, the uplink is normal, the Path Message is Refreshed from the uplink, the Path Message to be transmitted contains neither the FRO nor the LPAO, the nearest downlink is normal, and the Path Error Message is received from the downlink, in which case the Path Message is Refreshed (switched over) on the side of the Backup LSP.
• In the node serving as the PLR, if the uplink is abnormal, the Path Tear Message is transmitted.
• According to this configuration, the node serving as the PLR changes the Refresh operation of the Path Message corresponding to the fault status of the downlink, whereby the resource conflict between the Protected LSP and another LSP can be avoided.

Claims (10)

1. A communication device, in a communication network including: a first communication path, along which a plurality of communication devices is cascade-connected, having an ingress and an egress; and a second communication path, along which the plurality of communication devices is cascade-connected, the communication devices existing both ends thereof being different from each other on the first communication path, having its ingress corresponding to the communication device, of the communication devices at both ends, located on the side of the ingress of the first communication path and its egress corresponding to the communication device, of the communication devices at both ends, located on the side of the egress of the first communication path, the communication device being the communication device located at the ingress of the second communication path, comprising:

a checking unit checking whether a bandwidth from the ingress of the first communication path down to the egress thereof and a bandwidth from the ingress of the second communication path down to the egress thereof as a standby of a partial zone of the first communication path, are established or not;

a route information management unit generating, when the checking unit confirms that the bandwidth from the ingress of the first communication path down to the egress thereof and the bandwidth from the ingress of the second communication path down to the egress thereof as the standby of the partial zone of the first communication path are established, route maintaining information for maintaining the bandwidth of the partial zone of the first communication path; and

a transmission unit transmitting the route maintaining information generated by the route information management unit to the neighboring communication device on the side of the egress of the first communication path.

2. A communication device according toclaim 1, further comprising a reception unit receiving, from the neighboring communication device on the side of the egress of the first communication path, route error information showing occurrence of a link fault on the egress side from the neighboring communication device on the side of the egress of the first communication path,

wherein when the checking unit confirms that the bandwidth from the ingress of the first communication path down to the egress thereof and the bandwidth from the ingress of the second communication path down to the egress thereof as the standby of the partial zone of the first communication path are established and when the reception unit receives, from the neighboring communication device on the side of the egress of the first communication path, the route error information showing the occurrence of the link fault on the egress side from the neighboring communication device on the side of the egress of the first communication path, the transmission unit transmits the route maintaining information to the neighboring communication device on the side of the egress of the first communication path.

3. A communication device, in a communication network including: a first communication path, along which a plurality of communication devices is cascade-connected, having an ingress and an egress; and a second communication path, along which the plurality of communication devices is cascade-connected, the communication devices existing both ends thereof being different from each other on the first communication path, having its ingress corresponding to the communication device, of the communication devices at both ends, located on the side of the ingress of the first communication path and its egress corresponding to the communication device, of the communication devices at both ends, located on the side of the egress of the first communication path, the communication device being the communication device located on the first communication path between the ingress and the egress of the second communication path, comprising:

a reception unit receiving route maintaining information for maintaining a bandwidth in a partial zone of the first communication path from the neighboring communication device on the side of the ingress of the first communication path;

a route information management unit stored with the route maintaining information; and

a transmission unit transmitting the route maintaining information to the neighboring communication device on the side of the egress of the first communication path.

4. A communication device according toclaim 3, wherein if the link fault occurs between the self communication device and the neighboring communication device on the side of the ingress of the first communication path, the transmission unit transmits the route maintaining information stored in the route information management unit to the neighboring communication device on the side of the egress of the first communication path.

5. A communication device according toclaim 3, wherein when the reception unit receives delete request information for deleting the bandwidth of the first communication path from the neighboring communication device on the side of the egress of the first communication path, the route information management unit deletes the route maintaining information.

6. A communication device according toclaim 3, wherein if the link fault occurs between the self communication device and the neighboring communication device on the side of the egress of the first communication path, the transmission unit transmits route error information showing the occurrence of the link fault on the side of the egress of the first communication path to the neighboring communication device on the side of the ingress of the first communication path.

7. A communication device, in a communication network including: a first communication path, along which a plurality of communication devices is cascade-connected, having an ingress and an egress; and a second communication path, along which the plurality of communication devices is cascade-connected, the communication devices existing both ends thereof being different from each other on the first communication path, having its ingress corresponding to the communication device, of the communication devices at both ends, located on the side of the ingress of the first communication path and its egress corresponding to the communication device, of the communication devices at both ends, located on the side of the egress of the first communication path, the communication device being the communication device located at the egress of the second communication path, comprising:

a reception unit receiving route maintaining information for maintaining a bandwidth in a partial zone of the first communication path from the neighboring communication device on the side of the ingress of the first communication path; and a route information management unit stored with the route maintaining information.

8. A communication device according toclaim 7, further comprising a transmission unit transmitting, if the link fault occurs on the first communication path between the ingress and the egress of the second communication path, when the route information management unit is stored with the route maintaining information, and when the reception unit receives delete request information for deleting a resource of the first communication path from the communication device on the second communication path, the delete request information to the neighboring communication device on the side of the ingress of the first communication path.

9. A network system including a first communication path having an ingress and an egress, and a second communication path, of which a branch point and a merge point, as viewed from the first communication path, are specified as an ingress and an egress, generated so as to bypass a middle zone of the first communication path that is specified from the branch point to the merge point, data to be sent, if any fault does not occur in the middle zone, from the ingress of the first communication path being forwarded to the egress of the first communication path via the middle zone, the system comprising:

a detection unit detecting the fault in the middle zone;

a switch control unit switching over, when the fault in the middle zone is detected, a part of a forwarding route of the data from the ingress down to the egress of the first communication path to the second communication path from the middle zone, and switching back, if recovered from the fault in the middle zone, the part of the forwarding route of the data from the ingress down to the egress of the first communication path to the middle zone from the second communication path; and

an inhibiting unit inhibiting, during a period from the occurrence of the fault in the middle zone up to the recovery, a release of a resource for the first communication path with respect to a fault-not-yet-occurring area of the middle zone.

10. A communication device in a network system including a first communication path having an ingress and an egress, and a second communication path, of which a branch point and a merge point, as viewed from the first communication path, are specified as an ingress and an egress, generated so as to bypass a middle zone of the first communication path that is specified from the branch point to the merge point, data to be sent from the ingress of the first communication path being forwarded to the egress of the first communication path via the middle zone if any fault does not occur in the middle zone, a forwarding route of the data sent from the ingress of the first communication path being switched over to the second communication path from the middle zone if the fault occurs in the middle zone, and the forwarding route of the data sent from the ingress of the first communication path being switched over to the middle zone from the second communication path if the middle zone is recovered from the fault, the communication device disposed in the middle zone, comprising:

a reservation unit reserving a resource for the first communication path that is related to the middle zone when generating the first communication path; and

a reservation updating unit updating a reserved status of the resource for the first communication path,

wherein the reserved status of the resource for the first communication path is not canceled due to the occurrence of the fault in the middle zone, and

the reservation updating unit updates the reserved status even when the fault occurs in the middle zone.

Images