Multiplex communications – Data flow congestion prevention or control – Flow control of data transmission through a network
Reexamination Certificate
1998-10-23
2004-05-11
Vanderpuye, Kenneth (Department: 2661)
Multiplex communications
Data flow congestion prevention or control
Flow control of data transmission through a network
C370S231000, C370S395100
Reexamination Certificate
active
06735176
ABSTRACT:
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.
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 (?) a, 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 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.
FIG. 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.
FIG. 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 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 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.
FIG. 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 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
FIG. 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.
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 procedure.
SUMMARY OF INTENTION
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.
REFERENCES:
patent: 5241534 (1993-08-01), Omuro et al.
patent: 5280470 (1994-01-01), Buhrke et al.
patent: 5315586 (1994-05-01), Charvillat
patent: 5317562 (1994-05-
Nortel Networks Limited
Phunkulh Bob A.
Vanderpuye Kenneth
LandOfFree
Dynamic bandwidth management and rerouting does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Dynamic bandwidth management and rerouting, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Dynamic bandwidth management and rerouting will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3195854