Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 02233395 1998-10-29
Title of Invention
DYNAMIC BANDWIDTH MANAGEMENT AND REROUTING
Field of Invention
The invention generally relates to a network resource management of ATM
networks. In particular, it is directed to a technique of performing reroute
procedures in the event of a bandwidth change request.
Cross References
This invention relates to an applicant's pending U.S. application Serial No.
09/048,844 filed on Mar. 27, 1998 which is based upon U.S. Provisional
applications Serial Nos 60/044, 563 filed Apr. 24, 1997 and 60/051767 filed
July
7, 1997.
Background of Invention
The current ITU-T Q.2963.2 Recommendation (B-ISDN DSS2 Connection
Modification - ATM Traffic Descriptor Modification by connection owner)
provides the capability for the connection owner to initiate the MODIFY
message
to adjust the PCR (peak cell rate), SCR (sustainable cell rate) and MBS (?)
dynamically on an active connection. However, in an ATM network environment
which integrates with a variety of technologies, such as IMA (inverse
multiplexing
on ATM), WATM (wireless ATM), ADSL (asymmetric digital subscriber loop)
and MPOA etc., there is a need for the network as well as the called party to
have
the capability to request the connection's bandwidth to be changed
dynamically.
Rather than introducing unnecessary complex changes to the existing ITU-
T Q.2963.2 procedures to handle the collisions of multiple "modify" requests,
which are originated at the different points of a connection, the above
referenced
patent application introduces a new signalling capability to complement the
ITU-T
Q.2963.2 feature to manage connection bandwidth dynamically. The new
capability defines a new information element called "dynamic bandwidth
management option" in the existing "setup" message and allows the connection
owner (i.e. the originator of the connection who initiates the "setup"
message) to
specify the dynamic bandwidth management option for point-to-point
connections,
and for the first party of the point-to-multipoint connections, during the
connection establishment phase. When the network or the called party have the
CA 02233395 1998-10-29
2
need to adjust the bandwidth on an active connection, it can follow the
specified
bandwidth management option, if given, to initiate the proper action to deal
with
the changes.
In order to accommodate the requested bandwidth changes, the network or
the connection owner may perform certain maintenance procedures. For example,
the connection owner may send a "modify" message on the connection to increase
or reduce the bandwidth or such other characteristics of the connection. It is
also
possible that the connection may have to be rerouted to a new connection path
with an adjusted bandwidth. However such maintenance actions taken in one
domain are only effected within the same domain, because a different domain
may
have different maintenance procedures. Telecommunication connections often
span more than one domain and a request for bandwidth adjustment must be
considered differently for a proper maintenance action, whether or not the
request
originated within or outside the domain.
One of many maintenance actions is rerouting a connection path, which is
normally performed by the network. A connection path between a source node
and a destination node span across one or more network domains and is made up
of one or more connection segments involving one or more intermediate nodes.
An edge-based rerouting is a rerouting mechanism which replaces a
connection segment within a network domain starting from a source node of the
domain and ending at a destination node of the domain. In the context of
rerouting, the network domain is a collection of nodes which participate in
rerouting decisions and actions. Figure 1 shows a rerouting operation within
the
domain 10. A rerouting node 12 is a node which is responsible for establishing
an
alternative connection path 14 to a predetermined terminating node 16 which is
called a rendezvous node. In this example, the rerouting node is the source
node
of the domain and the rendezvous node is the destination node of the domain.
Figure 1 also show variety of intermediate nodes. An original path 18 must be
rerouted because of a failed link 20 between two nodes, which will be called a
rebounce node 22 and a blocking node 24, depending upon the direction of
connection. A potential cross-over node 26 is also shown.
There are two types of edge-based rerouting, e.g., "break-before-make" and
"make-before-break". They are also referred as "hard reroute" and "soft
reroute"
respectively. "Hard reroute" can be used for connection recovery or priority
CA 02233395 1998-10-29
control features. For other rerouting features such as path optimization and
administrative rerouting etc., "soft reroute" is required.
For the edge-based rerouting, the rerouting node and rendezvous node
participate in the connection control of a rerouting operation. To have a
simple
solution to handle the possible collision between the "hard reroute" and "soft
reroute", a rerouting state machine is designed to run at each end of a
connection
segment to coordinate the protocol handshake. In order to simplify the
rerouting
procedures, an agreement was made to allow one and only one rerouting
operation
to be executed in a switch for a connection at one time. However, due to the
l0 different nature of triggering the soft reroute versus the hard reroute, it
is possible
that the soft reroute operation may be interrupted by the hard reroute. In
this case,
the hard reroute will preempt the soft reroute and proceed with the hard
rerouting
operation. Consequently, the design of the rerouting state machine is based on
this
assumption.
Figure 2 shows an operation model of an edge-based rerouting between a
rerouting node 30 and a rendezvous node 32. For each connection, the rerouting
state machine 34 is operating in parallel with the connection state machine at
the
edges of a PNNI network (domain) 36. Therefore, in some cases when a switch is
performing a "soft reroute", up to three state machines may be running
2o simultaneous to reroute a connection, e.g. two connection state machines
(one for
the incumbent connection 38 and one for the rerouting connection 40), and one
rerouting machine. It should be noted that the rerouting connection in Figure
2 is
going through a different interface than the incumbent one. However, it is
possible that the rerouting connection resides at the same interface as the
incumbent connection.
It should be noted that the feature described herein is not designed solely
for supporting the ITU-T Q.2963.2 feature. It is an useful capability to
inform the
connection owner as well as the network operator regarding a significant
resource
change demand in a network and whether or not the demand originated within the
domain. As a result, a decision can be made to initiate a proper maintenance
action or to continue/abort performing the action started so that the changes
requested can be effectively dealt with.
CA 02233395 1998-10-29
4
Objects of Invention
It is therefore an object of the invention to provide a mechanism that
allows determination of a proper maintenance procedure to be performed in
response to a resource change request of an active connection.
It is another object of the invention to provide a mechanism to inform the
connection owner or the network operator whether or not a resource change
request originated within the domain.
It is yet a further object of the invention to provide a mechanism that
allows determination as to whether or not to continue performing a maintenance
l0 procedure.
Summary of Invention
Briefly stated, the invention resides in an ATM network which is
composed of a plurality of domains. According to one aspect, the invention is
directed to a method of managing the resource demand of an active connection
which spans one or more domains. The method comprises steps of performing a
maintenance action at a maintenance node in one domain, receiving a resource
change message at the maintenance node, the message indicating a resource
change request; and deciding to continue performing the maintenance action in
response to the resource change request based upon whether or not the resource
change message originated outside the domain of the maintenance node.
Brief Description of Drawings
Figure 1 shows a known rerouting operation within a domain.
Figure 2 shows an operation model of a known edge-based rerouting.
Figure 3 is an overview of a bandwidth change indication message in an
ATM environment.
Figure 4 shows a format of a dynamic bandwidth management option IE.
Detailed Description of the Preferred Embodiments of Invention
Figure 3 is an example of the bandwidth change indication operation in an
ATM network. In the Figure, an ATM network 40 contains a variety of nodes 42,
44, 46 and 48, each having a variety of capabilities. As an example, nodes 42
and
44 are shown to be holding an IMA virtual link. Different interfaces link
different
pair of nodes, one being defined by ATM Forum under PNNI (Public Network
CA 02233395 1998-10-29
Network Interface). Interfaces between a customer and an ATM node are defined
in UNI (User Network Interface). Therefore a calling party 50 and a called
party
52 are linked with respective nodes through UNI. For an illustration purpose,
a
path has been established between the calling party and the called party
through
5 nodes 48, 44, 42, and 46. The link between node 42 and 46 is shown as being
of
any kind. It should be emphasized that the links shown in the Figure are
examples
only. There are many different interfaces available in the field that can be
used in
this invention. Each node is able to initiate a "bandwidth change indication"
message, when conditions warrant it.
l0 In order to support this dynamic bandwidth change capability, the
connection owner must include dynamic bandwidth management option
information element in the "setup" request.
The existing "setup" message is modified to include the-new information
element (IE for short) to specify dynamic bandwidth management options that
the
network and the called party are allowed to call for. This IE is specified by
the
connection owner and is sent to the network or the called party in the "setup"
message during the initial connection establishment phase. The IE informs them
of the connection owner's desired dynamic bandwidth management options for
point-to-point connections and for the first user of point-to-multipoint
connections. Many options are possible but some typical options would allow
the
network or the called party to:
( 1 ) take no action;
(2) clear connection, if insufficient bandwidth resource to support the
connection;
(3) inform the connection owner of the new bandwidth requirements which
are specified in the "bandwidth change indication" message, set timer and wait
for
the maintenance action from the connection owner.
Based on the management option given by the connection owner, the
network and the called party for that connection can determine the type of
3o management action to perform when they encounter circumstances that require
modification in resources on the connection. If the resources to be altered
are the
bandwidth requirement, it may be accomplished by the connection bandwidth
modify procedures or rerouting. The "bandwidth change indication" message
permits these procedures be initiated by not only the connection owner but the
network and the called party. If dynamic bandwidth management option IE is
CA 02233395 1998-10-29
6
absent in the "setup" message, it implies that no specific management option
is
expected by the connection owner from the network or the called party.
However,
it does not imply that the network cannot perform its own desired maintenance.
Any one or more of network elements located at any of the nodes shown in
Figure 3 can initiate bandwidth change indication procedure as shown by
numeral
54. It is done by sending to the connection owner a "bandwidth change
indication" message. The connection owner then initiates connection modify
procedures as shown by numeral 56.
The "bandwidth change indication" message may contain one of the
i0 following IEs:
( 1 ) the alternative ATM traffic descriptor IE to indicate the overall
changes
to the connection cell rate for a CBR or VBR connection.
(2) the minimum acceptable ATM traffic descriptor IE to indicate the
changes for the peak cell rate parameter for a CBR, VBR, ABR or UBR
15 co~ection.
According to an embodiment of the invention, in addition to above IEs, a
"bandwidth change indication" message contains another IE. This IE is an
"external bandwidth change indicator". This IE allows the dynamic bandwidth
adjustment feature to interact with the edge-based rerouting feature more
2o effectively.
The "external bandwidth change indicator" IE is to indicate whether or not
the "bandwidth change indication" message originated outside the network
domain. It contains a single parameter called "external flag". Currently, only
a
single value is defined for the external flag, "outside scope of edge-based",
which
25 has the value "00000001 ". Of course other values for other circumstances
are
possible.
The flag is set by the first rendezvous node which intercepts the
"bandwidth change indication" message and supports the edge-based rerouting.
Depending upon options chosen, a bandwidth change indication message calls for
3o reduction or increase of bandwidth for the connection. How this message is
handled by variety of node along the connection path will be described below.
(a) If a network node is the rendezvous node which receives the
"bandwidth change indication" message from the direction of the called party,
when it is in the process of performing the "soft reroute" operation, one of
the
35 following actions takes place:
CA 02233395 1998-10-29
7
1. The bandwidth change request is to reduce the bandwidth.
In this case, the rendezvous node shall abort the "soft reroute" operation,
and
forward the "bandwidth change indication" message to upstream towards the
calling party.
2. The bandwidth change request is to increase the bandwidth.
In this case, the rendezvous node shall not forward the "bandwidth change
indication" message to upstream towards the calling party until the rerouting
operation is completed. The decision of whether queuing or discarding the
"bandwidth change indication" message is local implementation dependent, and
is
not within the scope of this description.
(b) If the network node is the rendezvous node which receives the
"bandwidth change indication" message from the direction of the called party,
when it is in the process of performing the "hard reroute" operation, it shall
not
forward the "bandwidth change indication" message to upstream towards the
calling party until the connection is recovered. The decision of whether
queuing
or discarding the "bandwidth change indication" message is local
implementation
dependent, and is not within the scope of this description.
(c) If the network node is the rendezvous node which is not performing
any rerouting operation, it shall insert the external bandwidth change
indicator
information element, if not present, with the external flag set to "outside
scope of
edge-based" in the "bandwidth change indication" message.
(d) If the network node is also a rerouting node and receives the
"bandwidth change indication" message when it is in the progress of performing
the "soft reroute" operation, one of the following action follows:
1. If the bandwidth change request is to reduce the bandwidth.
In this case, if the bandwidth change request is within the rerouting domain
(i.e.
the external bandwidth change indicator is not present ), the connection owner
may ignore the bandwidth change request and carry on the rerouting operation.
It
is because that the rerouting may be able to get around the trouble area.
Otherwise, if the bandwidth change request is not within the rerouting domain
(i.e.
the external bandwidth change indicator is present), the network node may
abort
the "soft reroute" operation and forward the "bandwidth change indication"
message towards the calling party.
2. If the bandwidth change request is to increase the bandwidth.
CA 02233395 1998-10-29
8
In this case, the network node may ignore the bandwidth change request and
carry
on the rerouting operation. The decision of whether queuing or discarding the
"bandwidth change indication" message is local implementation dependent, and
is
not within the scope of this description.
When the connection owner receives the "bandwidth change indication"
message and the connection is in an active state, it may perform one of the
following maintenance actions:
1. release the connection if the new bandwidth requirement is not
acceptable to the connection owner.
2. initiate the "modify request" message (i.e. ITU-T Q.2963.2 procedures)
with the cell rate specified in the "bandwidth change indication" message.
3. initiate the edge-based "soft reroute" procedures if the connection owner
is also a rerouting node, and if
- the connection owner realizes that the request is generated within its own
rerouting domain (i.e. within a single private network), and
- a new path is found to maintain the new bandwidth requirement.
If the connection owner is also a rerouting node for the edge-based
rerouting operation, it is possible that it is in the progress of performing
the "soft
reroute" operation when it receives the "bandwidth change indication" message.
When this happens, the following actions can be performed:
1. If the bandwidth change request is to reduce the bandwidth.
In this case, if the bandwidth change request is within the rerouting domain
(i.e.
the absent of the external bandwidth change indicator IE), the connection
owner
may ignore the bandwidth change request and carry on the rerouting operation.
It
is because that the rerouting may be able to get around the trouble area.
Otherwise, if the bandwidth change request is not within the rerouting domain
(i.e.
the present of the external bandwidth change indicator IE) and the new
bandwidth
requirement is acceptable to the connection owner, the connection owner may
abort the "soft reroute" operation and may initiate the "modify request"
message
(i.e. ITU-T Q.2963 procedures). Otherwise, if the bandwidth change request is
not
within the rerouting domain and the new bandwidth requirement is not
acceptable
to the connection owner, the connection owner may clear the connection.
2. If the bandwidth change request is to increase the bandwidth.
In this case, the connection owner may ignore the bandwidth change request and
carry on the rerouting operation.
CA 02233395 1998-10-29
9
It should be noted that it is possible to have multiple "bandwidth change
indication" messages sent from the network and the called party to the calling
party. However, it is a local implementation decision at the connection owner
to
deal with these multiple indications. In ITU-T Q.2963, section 5.1 clearly
states
that one and only one modification can be requested by the connection owner at
one time. Therefore, the connection owner may wish to buffer the indications
in
the sequence of which they arrive; or the connection owner may simply discard
the
subsequent indications until the current modification procedures are
completed.
Figure 4 shows a format of a dynamic bandwidth management option IE
to which will be modified to contain "external bandwidth change indicator as
will be
shown below.
Following are a variety of messages used in connection with dynamic
bandwidth management option and external bandwidth change indication feature,
according to one embodiment of the invention.
Messages
SETUP message
This message is sent by the preceding side to the succeeding side to initiate
connection establishment. See the table below for addition to the message to
support the bandwidth adjustment feature.
Message Type : SETUP
Direction : Preceding to succeeding
Significance : Global
Table 1: "Setup" message additional content
Information elementReferenceDirectionT a Len
h
Dynamic bandwidthT.B.D both O 5
mana ement o dons
CONNECT message
This message is sent by the Succeeding side and delivered to the
Preceding side to indicate connection acceptance by the called party. See
the table below for addition to the message.
Message Type : CONNECT
Direction : Succeeding to preceding
Significance : Global
CA 02233395 1998-10-29
Table 2: "Connect" message additional content
Information elementReference DirectionT a Len
h
Dynamic bandwidthT.B.D both O 5
mana ement o tions
BANDWIDTH CHANGE INDICATION message
5 This message is used by the network or the called party to specify the
required new bandwidth for the connection from the connection owner. The
message is sent from the succeeding side to the preceding side.
Message Type : BANDWIDTH CHANGE INDICATION
Direction : Succeeding to preceding
10 Significance : Global
Table 3: "Bandwidth change indication" message additional content
Information elementReferenceDirectionT a Len
h
Alternative ATM 6.4.5.7 S -> O 4 -
traffic P 30
descri for
Minimum acceptable 6.4.5.26 S -> O 4 -
P 20
ATM traffic descri
for
External bandwidth T.B.D S -> O 5
P
chan a indicator
Information elements
Table 4: Dynamic bandwidth management options
8 7 Octets
6
5
4
3
2
1
D amic 1
bandwidth
mana
ement
o
tions
IE
identifier
Ext Coding lE 2
instruction
field
standard Fla Res'd IE action indicator
Len 3
h
of
d
amic
bandwidth
mana
ement
o
tions
contents
Length 4
of
dynamic
bandwidth
management
options
contents
continued
Mana 5
ement
o
tion
CA 02233395 1998-10-29
11
Table
6:
Codin
standard
octet
2)
BitsMeanin
76
1 ATM Forum s ecific
1
Table 7: Management option (octet 5)
Bits Meanin
87654321
0 0 0 0 Clear connection, if insufficient bandwidth
0 0 0 0
0 0 0 0 form new bandwidth requirement via
0 0 0 1 "bandwidth
change indication" message, set timer
and wait for
maintenance action from the connection
owner
Table 8: External bandwidth change Indicator
8 7 6 5 4 3 2 1 Octets
External 1
bandwidth
char
a
indicator
IE
identifier
Ext Coding IE 2
instruction
field
standard Fla Res'd IE action indicator
Len 3
h
of
external
bandwidth
chan
a
indicator
contents
Len 4
h
of
external
bandwidth
chan
a
indicator
contents
continued
External 5
fla
Table 9: Coding standard (octet 2)
Bits Meanin
76
1 ATM Forum s ecific
1
1o Table fla octet 5
10:
External
Bits Meanin
87654321
0 0 0 0 0 0 Outside sco a of ed
0 1 e-based
