Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
1998-03-23
2001-06-05
Chin, Wellington (Department: 2664)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C709S238000, C370S389000
Reexamination Certificate
active
06243384
ABSTRACT:
BACKGROUND
1. Field of the Invention
The present invention pertains to communications systems, and particularly to communications systems which employ ATM technology.
2. Related Art and other Considerations
Asynchronous Transfer Mode (ATM) is becoming increasingly used in communication networks. ATM is a packet-oriented transfer mode which uses asynchronous time division multiplexing techniques. Packets are called cells and have a fixed size.
An ATM cell consists of 53 octets, five of which form a header and forty eight of which constitute a “payload” or information portion of the cell. The header of the ATM cell includes two quantities which are used to identify a connection in an ATM network over which the cell is to travel, particularly the VPI (Virtual Path Identifier) and VCI (Virtual Channel Identifier). In general, the virtual path is a principal path defined between two switching nodes of the network; the virtual channel is one specific connection on the respective principal path.
Between termination points of an ATM network a plurality of nodes are typically situated, such as switching nodes having ports which are connected together by physical transmission paths or links. The switching nodes each typically have several functional parts, a primary of which is a switch core. The switch core essentially functions like a cross-connect between ports of the switch. Paths internal to the switch core are selectively controlled so that particular ports of the switch are connected together to allow a cells ultimately to travel from an ingress side of the switch to an egress side of the switch.
A particular protocol, known as “PNNI”, has been developed for use between private ATM switches, and between groups of private ATM switches. Consistent with these two potential employments, “PNNI” stands for either Private Network Node Interface, or Private Network-to-Network Interface. Thus, PNNI is a routing information protocol that enables multi-vendor ATM switches to be integrated in the same network. The PNNI protocol is defined e.g., by The ATM Forum's
Private Network
—
Network Interface Specification Version
1.0 (PNNI 1.0), af-pnni-0055.000 (March 1996).
Each private ATM switch can be referred to as a (lowest level) node, each node having particular identifiers. Two nodes are connected together by a physical link, and many such nodes may be connected together. In PNNI parlance, nodes can be grouped together to form “peer groups”. Each node exchanges certain identifying packets (e.g., “Hello” packets) with its immediate neighbors, so that each node can determine certain state information. The state information includes the identity and peer group membership of the node's immediate neighbors, and the status of the node's links to its neighbors. Each node uses the state information to prepare “PNNI Topology State Elements” (PTSEs) [henceforth also referred to as “topology messages”]. Nodes belonging to the same peer group exchange information with one another in a process known as “flooding”, so that all nodes of the peer group have an identical view of the peer group.
Using the topology messages that it receives, each node builds its own topology database. The topology database essentially constitutes the node's view of the universe, e.g., the other nodes in its peer group, connections to other peer groups, and connections to private and public networks. Topology messages are sent in reoccurring fashion from each node, so that on the basis of PNNI information the topology database of each node is frequently updated by the relatively automatic flooding of topology messages. U.S. Pat. No. 4,920,529 to Sasaki et al. discloses e.g., a mode of reconfiguring databases wherein network reconfiguration information is switched from a preparatory side to an operating side for usage.
The concept of peer groups and a hierarchical structuring of node levels obviates requiring that a node's topology database have a comprehensive and detailed mapping of all lower level nodes of the entire system. Rather, in most instances the topology database of a node need only refer to the topology of the peer group to which it belongs, along with information regarding higher level nodes for the rest of the system.
The topology database of a node is important in view of the fact that PNNI uses source routing for all connection setup requests. In this regard, when a user requests a connection setup, an originating node (i.e., the first switching node encountered) chooses a general path to the destination, the general path being specified in accordance with the detail of the hierarchy known to the originating node. The path can be chosen using a path selection algorithm, which may vary from node to node. The path selection algorithm uses the information stored in the topology database in order to choose the general path to the destination, as well as other factors such as the connection's service category, traffic characteristics, and quality of services requirements, for example. The path is encoded as a Designated Transit List (DTL), which is included in the connection setup request. The path specifies every node to be used in transit across the peer group to which the originating node belongs, and refers to higher level nodes which are to be used in reaching the destination. When the connection setup request reaches another node level, e.g., another peer group, the ingress node of the newly reached peer group selects the particular path across the newly reached peer group, consistent with the general path chosen by the originating node (unless a problem occurs).
As indicated above, at each node a path selection algorithm, utilizing the topology database, can choose a path. In addition, it is also possible for an operator, e.g., via manual input, to define the routing [e.g., specify the path(s)] for a user. In the ease of operator definition, the operator-input routing information is stored in a separate table. Thus, heretofore in at least some instances the routing selection function of the node must consult two independent sources of information—the topology database and the separate table in which the operator-input routing information is stored.
BRIEF SUMMARY OF THE INVENTION
An ATM switching node which implements PNNI protocol has a table (known as the consolidated table) which stores plural records, each record associating a connection request input field with corresponding routing information. The node has table maintenance logic which updates the table to consolidate therein both records initiated by operator input and records developed from PNNI updating information. The PNNI updating information is generated by a PNNI protocol unit which consults a topology database of the node. Provision of the consolidate table obviates consultation of multiple tables.
When a connection request is received at the node, a call control unit of the node sends a called party number included in the connection request to a table handling unit. The table handling unit uses the at least a portion of the called party number as the connection request input field for locating the corresponding routing information in the consolidated table.
The consolidated table has an address analysis section; a routing analysis section; and a local look-up section. The consolidated table has an active version and an inactive version copied therefrom. The active version of the consolidated table is utilized in connection setup. Updating is performed on the inactive version of the consolidated table. When updating is completed, the inactive version of the consolidated table becomes the active version of the consolidated table.
The node also includes a static table in which operator input information is stored for use in developing the records initiated by operator input. The operator input information stored in the static table and the PNNI updating information are merged in the inactive version of the consolidated table during table updating.
REFERENCES:
patent: 4920529 (1990-04-01), Sasa
Eriksson Anna
Pettersson Ove
Chin Wellington
Nguyen Steven
Nixon & Vanderhye P.C.
Telefonaktiebolaget LM Ericsson
LandOfFree
Address analysis for asynchronous transfer mode node with... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Address analysis for asynchronous transfer mode node with..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Address analysis for asynchronous transfer mode node with... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2439178