U.S. patent application number 12/191499 was filed with the patent office on 2008-12-11 for communication device.
This patent application is currently assigned to FUJITSU LIMITED. Invention is credited to Toshifumi Yokoyama.
Application Number | 20080304494 12/191499 |
Document ID | / |
Family ID | 34191536 |
Filed Date | 2008-12-11 |
United States Patent
Application |
20080304494 |
Kind Code |
A1 |
Yokoyama; Toshifumi |
December 11, 2008 |
COMMUNICATION DEVICE
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.
Inventors: |
Yokoyama; Toshifumi;
(Fukuoka, JP) |
Correspondence
Address: |
KATTEN MUCHIN ROSENMAN LLP
575 MADISON AVENUE
NEW YORK
NY
10022-2585
US
|
Assignee: |
FUJITSU LIMITED
Kawasaki-shi
JP
|
Family ID: |
34191536 |
Appl. No.: |
12/191499 |
Filed: |
August 14, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10808757 |
Mar 25, 2004 |
|
|
|
12191499 |
|
|
|
|
Current U.S.
Class: |
370/400 |
Current CPC
Class: |
H04W 48/02 20130101;
H04W 8/06 20130101; H04W 84/105 20130101; H04W 84/16 20130101; H04W
36/10 20130101; H04W 92/12 20130101; H04W 60/04 20130101; H04W
92/14 20130101 |
Class at
Publication: |
370/400 |
International
Class: |
H04Q 11/00 20060101
H04Q011/00 |
Foreign Application Data
Date |
Code |
Application Number |
Sep 3, 2007 |
JP |
2007-227525 |
Claims
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 to claim 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 to claim 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 to claim 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 to claim 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 to claim 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.
Description
[0001] 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
[0002] 1. Field of the INVENTION
[0003] 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).
[0004] 2. Description of the Related Art
[0005] 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.
[0006] 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. In FIG. 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.
[0007] Herein, the head-end node of the LSP (which is the node H in
the case of the LSP#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 the LSP#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 in FIG. 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 in FIG. 1) is called an MP (Merge Point).
[0008] 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.
[0009] 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).
[0010] 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.
[0011] In a normal state, data traffic from the node H is carried
via the Protected LSP to the node T.
[0012] FIG. 27 is a diagram showing an outline of an FRR operation
if a link fault occurs. As illustrated in FIG. 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).
[0013] 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.
[0014] 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.
[0015] 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. In FIG. 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 an LSP#3 extending from the node X down to a node Y as
the Egress node via the node B and the node C, the LSP#3 is
normally set up because of the free resource between the node B and
the node C. [0016] [Patent document 1] Japanese Patent Laid-Open
Publication No. 2005-39362
SUMMARY OF THE INVENTION
[0017] 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 in
FIG. 29, the LSP#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.
[0018] When recovered from the link fault occurring between the
node A and the node B in FIG. 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).
[0019] 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.
[0020] The present invention adopts the following means in order to
solve the problems given above.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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
[0029] FIG. 1 is a view showing an example of a network
architecture in a normal state.
[0030] FIG. 2 is a diagram showing a method of setting up a
Protected LSP.
[0031] FIG. 3 is a diagram showing a method of setting up a Backup
LSP.
[0032] FIG. 4 is a diagram showing signaling of the Protected LSP
after the Backup LSP has been set up.
[0033] FIG. 5 is a diagram showing an operation in a state where a
fault occurs in a protection zone.
[0034] FIG. 6 is a diagram showing an operation in a state of being
recovered from the link fault in the protection zone.
[0035] FIG. 7 is a diagram illustrating an example of a
configuration of a node.
[0036] FIG. 8 is a diagram showing a configuration when generating
the Protected LSP.
[0037] FIG. 9 is a diagram showing a transmission Path Msg and Path
State of individual nodes when setting up the Protected LSP.
[0038] FIG. 10 is a diagram showing a transmission Resv Msg and
Resv State of individual nodes when setting up the Protected
LSP.
[0039] FIG. 11 is a diagram showing a configuration after
generating the Backup LSP.
[0040] FIG. 12 is a diagram showing the transmission Path Msg and
Path State of the individual nodes after setting up the Backup
LSP.
[0041] FIG. 13 is a diagram showing the transmission Resv Msg and
Resv State of the individual nodes after setting up the Backup
LSP.
[0042] FIG. 14 is a diagram showing processing conditions for
adding and deleting an LPAO.
[0043] FIG. 15 is a diagram showing an operation when the fault
occurs on the Protected LSP.
[0044] FIG. 16 is a diagram showing an operation when the fault
occurs on the Protected LSP.
[0045] FIG. 17 is a diagram showing the transmission Path Msg and
Path State of the respective nodes during the occurrence of the
fault.
[0046] FIG. 18 is a diagram showing the transmission Resv Msg and
Resv State of the respective nodes during the occurrence of the
fault.
[0047] FIG. 19 is a diagram showing conditions for determining an
operation of Refreshing the Path Message.
[0048] FIG. 20 is a diagram illustrating an operational example
when requested to set up a new LSP (other than LSP#1 and
LSP#2).
[0049] FIG. 21 is a diagram showing an operation when requested to
delete the LSP during the occurrence of the fault on the Protected
LSP.
[0050] FIG. 22 is a diagram the transmission Path Msg and Path
State of the respective nodes after receiving the Path Tear
Message.
[0051] FIG. 23 is a diagram showing the transmission Resv Msg and
Resv State of the individual nodes after receiving the Path Tear
Message.
[0052] FIG. 24 is a diagram showing conditions for an MP to
transmit a Resv Tear Msg.
[0053] FIG. 25 is a diagram showing an operational configuration
when the link fault occurs between a node B and a node C.
[0054] FIG. 26 is a diagram showing conditions for Refreshing the
Path Message of the Protected LSP in a PLR.
[0055] FIG. 27 is a diagram showing an outline of an FRR operation
(a case in which the link fault occurs in a protection zone).
[0056] FIG. 28 is a diagram showing the outline of the FRR
operation (a case of being recovered from the fault in the
protection zone).
[0057] 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.
[0058] 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
[0059] 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
[0060] 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. In FIG. 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
[0061] To begin with, a standard operational example of the
communication network in FIG. 1 will be described.
[0062] <<Setup of Protected LSP>>
[0063] 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.
[0064] 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.
[0065] 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.
[0066] 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.
[0067] The SAO is an Object representing a session attribute. The
SAO is stored with information for requesting Local Protection.
[0068] 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.
[0069] 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.
[0070] 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.
[0071] 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.
[0072] 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.
[0073] 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.
[0074] The Path Message and the Resv Message can contain other
Objects that are not shown above.
[0075] 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.
[0076] As illustrated in FIG. 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.
[0077] 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.
[0078] 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.
[0079] <<Setup of Backup LSP>>
[0080] 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 in FIG. 2. The Path
Message used in the Backup LSP does not, however, contain the
FRO.
[0081] 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.
[0082] The node A as a PLR can recognize from receiving the Resv
Message that the Backup LSP has been set up.
[0083] <<Signaling of Protected LSP after the Setup of the
Backup LSP>>
[0084] 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.
[0085] 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). In FIG. 4, the Path
Message and the Resv Message of the Backup LSP are omitted.
[0086] <<Operation at Occurrence of Fault in Link>>
[0087] 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)
[0088] 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.
[0089] <<Operation when Recovered from Link Fault>>
[0090] 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.
[0091] 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.
[0092] <Device>
[0093] <<Node>>
[0094] 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.
[0095] FIG. 7 is a diagram showing an example of a configuration of
the node. A node 200 includes an external input/output IF
(InterFace) unit 206, a reception packet processing unit 202, a
transmission packet processing unit 204, a reception Path State
management unit 212, a transmission Path Message management unit
214, a reception Resv State management unit 222, a transmission
Resv Message management unit 224, a label/route information
management unit 230 and a label table & forwarding processing
unit 240.
[0096] (External I/O IF Unit)
[0097] The external I/O IF unit 206 is an interface for control of
the self-node and collecting the information.
[0098] (Reception Packet Processing Unit)
[0099] The reception packet processing unit 202 checks whether an
abnormal state exists in the packet received from the input
interface or not. The reception packet processing unit 202, if the
received packet is normal, transmits the received packet to a
proper management unit.
[0100] The reception packet processing unit 202, if the received
packet is the Path Message, sends this received packet to the
reception Path State management unit 212. The reception packet
processing unit 202, if the received packet is the Resv Message,
sends this received packet to the reception Resv State management
unit 222. The reception packet processing unit 202, if the received
packet is of main signal traffic, transmits this received packet to
the label table & forwarding processing unit 240.
[0101] FIG. 7 illustrates the two reception packet processing units
202, however, the single reception packet processing unit may
execute the processes given above.
[0102] (Transmission Packet Processing Unit)
[0103] The transmission packet processing unit 204 transmits, to
the output interface, the packets received from the transmission
Path Message management unit 214, the transmission Resv Message
management unit 224 or the label table & forwarding processing
unit 240.
[0104] FIG. 7 illustrates the two transmission packet processing
units 204, however, the single transmission packet processing unit
may execute the processes given above.
[0105] (Reception Path State Management Unit)
[0106] The reception Path State management unit 212 queries the
label/route information management unit 230 about whether the route
information of the received Path Message is proper or not. Further,
the reception Path State management unit 212 manages each Object of
the received Path Message, and checks whether the Path State is
periodically Refreshed.
[0107] (Transmission Path Message Management Unit)
[0108] The transmission Path Message management unit 214, 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 IF unit 206 in order to set up the
LSP.
[0109] The transmission Path Message management unit 214, when
functioning as the Egress node, does not transmit the Path
Message.
[0110] The transmission Path Message management unit 214, 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 Path Message management unit 214 queries the
label/route information management unit 230 about the route
information.
[0111] The transmission Path Message management unit 214, when
functioning as the PLR and when receiving the notification that the
Backup LSP has been set up from the reception Path State management
unit 212, allocates an LPAO (Local Protection Available Object) to
the LSP having the FRO.
[0112] The transmission Path Message management unit 214, when
functioning as the MP and when receiving the LPAO, deletes the
LPAO. If not the MP and when receiving the LPAO, the transmission
Path Message management unit 214 lets the LPAO pass through as it
is.
[0113] The transmission Path Message management unit 214, when
recognizing the uplink fault, transmits the Path Tear Message to
the downlink node. The transmission Path Message management unit
214 does not, however, transmit the Path Tear Message to the
downlink node with respect to the LSP having the LPAO.
[0114] The transmission Path Message management unit 214 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.
[0115] (Reception Resv State Management Unit)
[0116] The reception Resv State management unit 222 transmits the
label information of the receive Resv Message to the label/route
information management unit 230 from the downlink node, and manages
the received Resv State. On this occasion, the reception Resv State
management unit 222 checks whether the Resv State is Refreshed at
fixed time. Further, the reception Resv State management unit 222,
when the Backup LSP is set up, notifies the transmission Resv
Message management unit 224 of this purport.
[0117] (Transmission Resv Message Management Unit)
[0118] The transmission Resv Message management unit 224, when
functioning as the Ingress node, does not transmit the Resv
Message.
[0119] The transmission Resv Message management unit 224, 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 Resv Message management unit 224
queries the label/route information management unit 230 about the
to-be-allocated label information and route information.
[0120] (Label/Route Information Management Unit)
[0121] The label/route information management unit 230 manages the
label information and the route information. The label/route
information management unit 230 responds to the queries given from
the respective blocks (the reception Path State management unit
212, the transmission Path Message management unit 214, the
reception Resv State management unit 222, the transmission Resv
Message management unit 224, the label table & forwarding
processing unit 240, etc). The label/route information management
unit 230 sends the label-related information to the label table
& forwarding processing unit 240.
[0122] The reception Path State management unit 212, the
transmission Path Message management unit 214, the reception Resv
State management unit 222, the transmission Resv Message management
unit 224 and the label/route information management unit 230 may be
realized as one route information management unit.
[0123] The node can confirm from receiving the Path Message and the
Resv Message of the LSP that the LSP resource is ensured.
[0124] (Label Table & Forwarding Processing Unit)
[0125] The label table & forwarding processing unit 240
receives the label-related information from the label/route
information management unit 230 and retains the label information
in a label table.
[0126] The label table & forwarding processing unit 240, when
functioning as the Ingress node and when receiving the packet from
the reception packet processing unit 202, determines a forwarding
destination, then, thereafter, attaches a label to the packet and
transmits the label-attached packet to the transmission packet
processing unit 204.
[0127] The label table & forwarding processing unit 240, when
functioning as the Transit node and when receiving the packet from
the reception packet processing unit 202, 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 transmission packet processing unit
204.
[0128] The label table & forwarding processing unit 240, when
functioning as the Egress node and when receiving the packet from
the reception packet processing unit 202, 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 transmission packet processing unit
204.
Operational Example in Present Embodiment
[0129] Given below is an operational example of the communication
network using the nodes described above.
[0130] 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.
[0131] <<Setup of Protected LSP>>
[0132] FIG. 8 is a diagram showing a configuration when generating
the Protected LSP. In FIG. 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.
[0133] FIG. 9 is a diagram showing a transmission Path Msg and Path
State of each node when setting up the Protected LSP.
[0134] FIG. 10 is a diagram showing a transmission Resv Msg and
Resv State of each node when setting up the Protected LSP.
[0135] 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 in FIG. 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).
[0136] In the node H, the external I/O IF unit 206 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 IF unit 206 transmits the received
information to the transmission Path Message management unit
214.
[0137] The transmission Path State management unit 214 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 in FIG. 9.
[0138] The transmission Path State management unit 214 transmits
the generated Path Message to the transmission packet processing
unit 204. The transmission packet processing unit 204 sends the
received Path Message toward the node A according to the Path
Message.
[0139] 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).
[0140] In the node A, the transmission packet processing unit 204
receives the Path Message from the node H. The transmission packet
processing unit 204, since the received packet is the Path Message,
transmits the received packet to the reception Path State
management unit 212. The reception Path State management unit 212
of the node A queries the label/route information management unit
230 about whether the route information of the received Path
Message is proper or not. The reception Path State management unit
212 retains intactly the information of each Object of the received
Path Message as Path State T154.
[0141] The reception Path State management unit 212 of the node A
updates the Path State T154 when receiving the next Path Message.
The reception Path State management unit 212, 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.
[0142] The reception Path State management unit 212 transmits the
received Path Message to the transmission Path Message management
unit 214.
[0143] The transmission Path Message management unit 214 of the
node A receives the Path Message from the reception Path State
management unit 212. The transmission Path Message management unit
214 deletes the reception IF information (A-IF1) of the self node A
from the ERO of the Path Message. Further, the transmission Path
State management unit 214 changes the HOP Object of the Path
Message to the transmission IF information (A-IF2) of the self node
A.
[0144] The transmission Path Message management unit 214 of the
node A transmits the Path Message with the updated information to
the transmission packet processing unit 204. The transmission
packet processing unit 204 sends the received Path Message toward
the node B according to the Path Message.
[0145] 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.
[0146] In the node T (Egress node), the transmission packet
processing unit 204 receives the Path Message from the node C. The
transmission packet processing unit 204, as the received packet is
the Path Message, transmits the packet to the reception Path State
management unit 212.
[0147] The reception Path State management unit 212 of the node T
queries the label/route information management unit 230 as to
whether the route information of the received Path Message is
proper or not. The reception Path State management unit 212 retains
intactly the information of each Object of the received Path
Message as a Path State T160.
[0148] The reception Path State management unit 212 of the node T,
when receiving the next Path Message, updates the Path State T160.
The reception Path State management unit 212, 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.
[0149] 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).
[0150] The transmission Resv Message management unit 224 of the
node T (Egress node) generates (Refresh), based on a transmission
Resv Msg T260, the Resv Message at the fixed cycle. The
transmission Resv Message management unit 224 transmits the
generated Resv Message to the transmission packet processing unit
204. The transmission packet processing unit 204 sends the Resv
Message received from the transmission Resv Message management unit
224 toward the node C based on the Resv Message.
[0151] In the node C (Transit node), the transmission packet
processing unit 204 receives the Resv Message from the node T. The
transmission packet processing unit 204, since the received packet
is the Resv Message, transmits the packet to the reception Resv
State management unit 222.
[0152] The reception Resv State management unit 222 retains
intactly the information of each Object of the received Resv
Message as a Resv State T208. The reception Resv State management
unit 222 of the node C extracts the label information from the
received Resv Message. The extracted label information is
transmitted to the label/route information management unit 230. The
label/route information management unit 230 transmits the label
information received from the reception Resv State management unit
222 to the label table & forwarding processing unit 240. The
label table & forwarding processing unit 240 retains the
received label information in the label table.
[0153] The reception Resv State management unit 222 of the node C
updates, when receiving the next Resv Message, a Resv State T208.
The reception Resv State management unit 222, 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.
[0154] The reception Resv State management unit 222 transmits the
received Resv Message to the transmission Resv Message management
unit 224.
[0155] The transmission Resv Message management unit 224 receives
the Resv Message from the reception Resv State management unit 222.
The transmission Resv Message management unit 224 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
Resv Message management unit 224 changes the HOP Object of the Resv
Message to the transmission IF information (C-IF1) of the self node
C.
[0156] The transmission Resv Message management unit 224 transmits
the Resv Message with the updated information to the transmission
packet processing unit 204. The transmission packet processing unit
204 sends the received Resv Message to the node B according to the
Resv Message.
[0157] 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.
[0158] In the node H (Ingress node), the transmission packet
processing unit 204 receives the Resv Message from the node A. The
transmission packet processing unit 204, as the received packet is
the Resv Message, transmits the packet to the reception Resv State
management unit 222.
[0159] The reception Resv State management unit 222 of the node H
extracts the label information from the received Resv Message, and
sends the extracted label information to the label/route
information management unit 230. The reception Resv State
management unit 222 retains intactly the information of each Object
of the received Resv Message as Resv State T202.
[0160] 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.
[0161] The reception Resv State management unit 222 of the node H,
when receiving the next Resv Message, updates the Resv State T202.
The reception Resv State management unit 222, 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.
[0162] 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.
[0163] <<Setup of Backup LSP>>
[0164] The Backup LSP is set up in the same way as setting up the
Backup LSP in the example of the standard operation illustrated in
FIG. 3.
[0165] <<Signaling of Protected LSP after Setup of Backup
LSP>>
[0166] 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.
[0167] 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.
[0168] 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.
[0169] FIG. 12 is a diagram showing the transmission Path Msg and
the Path State of the respective nodes after setting up the Backup
LSP.
[0170] FIG. 13 is a diagram showing the transmission Resv Msg and
the Resv State of the respective nodes after setting up the Backup
LSP.
[0171] When the node A as the PLR recognizes that the Backup LSP is
set up, the reception Path State management unit 212 of the node A
notifies the transmission Path Message management unit 214 that the
Backup LSP is set up.
[0172] 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.
[0173] The transmission Path Message management unit 214 newly adds
the LPAO to the LSP#1 having the FRO of the transmission Path Msg
(FIG. 12: a transmission Path Msg T304 of the node A). The
transmission Path Message management unit 214 transmits the
LPAO-added Path Message to the transmission packet processing unit
204.
[0174] The transmission packet processing unit 204 sends the
received Path Message toward the node B according to the Path
Message.
[0175] In the node B serving as the Transit node, the transmission
packet processing unit 204 receives the Path Message from the node
A. The transmission packet processing unit 204, as the received
packet is the Path Message, sends the packet to the reception Path
State management unit 212.
[0176] The reception Path State management unit 212 of the node B
queries the label/route information management unit 230 about
whether the route information of the received Path Message is
proper or not. The reception Path State management unit 212 retains
the information of each Object (containing the LPAO) of the
received Path Message as a Path State T356 as it is.
[0177] The reception Path State management unit 212 of the node B,
when receiving the next Path Message, updates the Path State. The
reception Path State management unit 212, 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.
[0178] The reception Path State management unit 212 of the node B
sends the received Path Message to the transmission Path Message
management unit 214.
[0179] The transmission Path Message management unit 214 of the
node B receives the Path Message from the reception Path State
management unit 212. The transmission Path Message management unit
214 deletes reception IF information (B-IF1) of the self-node B
from the ERO of the Path Message. Further, the transmission Path
Message management unit 214 changes the HOP Object of the Path
Message to transmission IF information (B-IF2) of the self-node
B.
[0180] The transmission Path Message management unit 214 of the
node B transmits the Path Message (containing the LPAO) with the
updated information to the transmission packet processing unit 204.
The transmission packet processing unit 204 sends the received Path
Message to the node C according to the Path Message.
[0181] In the node C serving as the MP, the reception packet
processing unit 202 receives the Path Message from the node B. The
reception packet processing unit 202, since the received packet is
the Path Message, transmits the packet to the reception Path State
management unit 212.
[0182] The reception Path State management unit 212 of the node C
queries the label/route information management unit 230 as to
whether the route information of the received Path Message is
proper or not. The reception Path State management unit 212 retains
the information of each Object (containing the LPAO) of the
received Path Message as a Path State T358 as it is.
[0183] The reception Path State management unit 212 of the node C,
when receiving the next Path Message, updates the Path State. The
reception Path State management unit 212, 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.
[0184] The reception Path State management unit 212 of the node C
transmits the received Path Message to the transmission Path
Message management unit 214.
[0185] The transmission Path Message management unit 214 of the
node C receives the Path Message from the reception Path State
management unit 212. The transmission Path Message management unit
214 deletes reception IF information (C-IF1) of the self-node C
from the ERO of the Path Message. Further, the transmission Path
Message management unit 214 changes the HOP Object of the Path
Message to transmission IF information (C-IF2) of the self-node
C.
[0186] The transmission Path Message management unit 214 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).
[0187] The transmission Path Message management unit 214 of the
node C transmits the Path Message with the updated information to
the transmission packet processing unit 204. The transmission
packet processing unit 204 sends the received Path Message to the
node T according to the Path Message.
[0188] 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.
[0189] 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 in FIG. 13.
[0190] <<Operation when Link Fault Occurs>>
[0191] FIG. 15 is a view showing an outline of an operation when
the link fault occurs on the Protected LSP. In FIG. 15, the link
fault occurs between the node A and the node B.
[0192] 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.
[0193] FIG. 16 is a view showing a configuration when the link
fault occurs on the Protected LSP.
[0194] 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.
[0195] 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.
[0196] 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 Resv State management unit
222 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 Path Message management unit 214 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 Path Message management unit 214
transmits the element-changed Path Message to the transmission
packet processing unit 204.
[0197] The transmission packet processing unit 204 sends the
received Path Message to the node C from the Backup LSP side
according to the Path Message.
[0198] In the node C, the transmission packet processing unit 204
receives the Path Message from the node A on the side of the Backup
LSP. The transmission packet processing unit 204, as the received
packet is the Path Message, sends the packet to the reception Path
State management unit 212.
[0199] The reception Path State management unit 212 of the node C
queries the label/route information management unit 230 about
whether the route information of the received path is proper or
not.
[0200] The reception Path State management unit 212 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).
[0201] The reception Path State management unit 212 of the node C
transmits the received Path Message to the transmission Path
Message management unit 214.
[0202] The transmission Path Message management unit 214 of the
node C receives the Path Message from the reception Path State
management unit 212. The transmission Path Message management unit
214 deletes the reception IF information (C-IF3) of the self-node C
from the ERO of the Path Message. Further, the transmission Path
Message management unit 214 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 Path Message
management unit 214 deletes the LPAO from the received Path
Message.
[0203] The transmission Path Message management unit 214 transmits
the Path Message with the updated information to the transmission
packet processing unit 204. The transmission packet processing unit
204 sends the received Path Message to the node T according to the
Path Message.
[0204] 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 Path State management unit 212 from the node A, can
therefore recognize the fault between the node A and the node B.
The transmission Path Message management unit 214 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 in FIG. 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.
[0205] 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.
[0206] 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.
[0207] 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 in FIG. 18, the Resv
Message is sent to both of the node A and the node B.
[0208] Further, the node A receives the Resv Message from the
Backup LSP side. The reception Resv State management unit 222 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 Resv State management unit 222
sends the received Resv Message to the transmission Resv Message
management unit 224.
[0209] The transmission Resv Message management unit 224 of the
node A receives the Resv Message from the reception Resv State
management unit 222. The transmission Resv Message management unit
224 updates the transmission Resv Msg. The transmission Resv
Message management unit 224 transmits the Resv Message to the
transmission packet processing unit 204. The transmission packet
processing unit 204 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.
[0210] 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.
[0211] 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.
[0212] 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.
[0213] 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.
[0214] <<Operation when Requested to Set Up New
LSP>>
[0215] FIG. 20 is a view showing an operational example when
requested to set up a new LSP (other than LSP#1 and LSP#2).
[0216] As shown in FIG. 20, an assumption is that an LSP#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 the LSP#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
the LSP#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.
[0217] <<Operation if Delete Request of LSP is Made on
Protected LSP during Occurrence of Link Fault>>
[0218] 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.
[0219] 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.
[0220] FIG. 22 is a diagram showing the transmission Path Msg and
the Resv State of the individual nodes after receiving the Path
Tear Message.
[0221] FIG. 23 is a diagram showing the transmission Resv Msg and
the Resv State of the individual nodes after receiving the Path
Tear Message.
[0222] The node H, when receiving the delete request of the LSP#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 the LSP#1 via the Backup LSP is released.
[0223] 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.
[0224] 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 the LSP#1
after the Path Tear.
[0225] 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.
[0226] <<Operation if Link Fault Occurs between Node B and
Node C>>
[0227] 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.
[0228] 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.
[0229] 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.
[0230] On the other hand, as shown in FIG. 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.
[0231] FIG. 26 is a diagram showing conditions for Refreshing the
Path Message of the Protected LSP on the PLR.
[0232] 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.
[0233] 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.
[0234] 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.
[0235] 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.
[0236] In the node serving as the PLR, if the uplink is abnormal,
the Path Tear Message is transmitted.
[0237] 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.
* * * * *