Multiplex communications – Diagnostic testing – Determination of communication parameters
Reexamination Certificate
1999-06-30
2003-11-04
Cangialosi, Salvatore (Department: 2732)
Multiplex communications
Diagnostic testing
Determination of communication parameters
Reexamination Certificate
active
06643267
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to monitoring operation and maintenance of communication networks. In particular, it is directed to collecting network parameters while tracing the route of a virtual connection between two nodes of a network.
THE BACKGROUND OF THE INVENTION
Connection oriented networks, such as an Asynchronous Transfer Mode (ATM) wide area networks running Switched Virtual Circuit (SVC) services over Private Network-to-Network Interface (PNNI), can route messages through a myriad of possible connections between an originating node and a terminating node using many intermediate nodes. Administration and maintenance of such a network is a significant challenge. It is important to be able to obtain real-time information about message routing and network performance to administer and maintain the network.
FIG. 1
illustrates an exemplary physical structure of an ATM network. An ATM network consists of a set of ATM switches
102
interconnected by point-to-point ATM links
104
or interfaces. ATM networks are fundamentally connection oriented. A virtual circuit
1110
needs to be set up across the ATM network from an originating node
106
to one or more terminating nodes
108
prior to transferring data. ATM circuits are of two types: virtual paths, identified by virtual path identifiers (VPI); and virtual channels, identified by the combination of a VPI and a virtual channel identifier (VCI). A virtual path is a bundle of virtual channels, all of which are switched transparently across the ATM network on the basis of the common VPI. All VCI and VPI, however, have only local significance across a particular link, and are remapped, as appropriate, at each switch. PNNI provides a protocol for exchanging information between switches to establish and maintain ATM circuits.
The PNNI protocol used in ATM networks provides an example of facilities that can be used to provide information for administration and maintenance of a connection oriented network. Data is transmitted in an ATM network in the form of cells made up of 8 bit octets. Each cell has a 5 octet header and a 48 octet data payload. The header provides the routing information for the cell. The header includes a payload type field. Cells can be identified by the payload type field as carrying an Operation, Administration, and Maintenance (OAM) message. This indicates that the data carried by the cell is part a message for the switch. The OAM message is assembled from the cells and processed by the switch.
FIG. 2
illustrates the structure of an OAM message. Each message consists of a list of octets. An embodiment of the present invention is particularly directed to. messages having a message type
206
of SETUP, ADD PARTY, or TRACE CONNECTION. A SETUP message is used to establish a connection from a source node that originates the message to a destination node specified by the endpoint reference octets in the message. An ADD PARTY message adds a destination node to an existing connection. A TRACE CONNECTION message is used to determine the path taken by an existing connection. These three message types will be referred to collectively as request messages. Acknowledge messages are returned to the originating node when a request message is received by the destination node. SETUP is acknowledged by CONNECT if the connection is successfully established, and RELEASE if not. ADD PARTY is acknowledged by ADD PARTY ACKNOWLEDGE if the additional destination is successfully added, and ADD PARTY REJECT if not. TRACE CONNECTION is acknowledged by TRACE CONNECTION ACKNOWLEDGE.
The PNNI facility allows a path of a Switched Virtual Circuit (SVC) to be traced in real time by appending a Trace Transit List (TTL) Information Element (IE) to a request message. The TTL includes various octets which can provide valuable information about the call at every network node. These octets include parameters like Node Id and Port Id, Call Reference Values, and so forth. It will be appreciated that there are many possible ATM circuits between any two nodes in an ATM network if the network is large. An ATM circuit in a large network can include many switches. This makes the task of locating network problems and inefficiencies difficult. TTLs can be used to locate network problems and to optimize performance.
A SETUP or ADD PARTY message may include a TTL
212
. A TRACE CONNECTION message always has a TTL. The TTL
212
records the path traversed by the request message from the source node to the trace destination node.
FIG. 3
shows the structure of the TTL. If a TTL IE is included in the message, the receiving node adds tracing information to the TTL based on the state of the Hierarchy Trace (H), Crankback Trace (C), Clear Call at Destination (X), VPI/VCI Trace (V), and Call Reference Value Trace (A) flags in the TTL flags octet
306
. Each node traversed by the message (including the source node) adds one entry to the TTL IE before forwarding the message to the outgoing interface. The outgoing interface is determined from the local connection table using the call reference and, for a point-to-multipoint connection, the endpoint reference. The source node controls what path information is recorded by setting the H and C flags in the TTL IE. If both the H and C flags are set to 0, only lowest level information of the final path, i.e., not including the failed paths, is recorded. If the H flag is set to 1, higher level information is also recorded. If the C flag is set to 1, all attempted paths including the final one are recorded. The H and C flags are ignored for a TRACE CONNECTION MESSAGE.
Path tracing, which is initiated by a SETUP or ADD PARTY request message, sets up a connection in the forward direction and returns the results in the resulting acknowledge message. The path trace can immediately release the call used to perform the trace or leave it up. Test connections in support of path tracing can be initiated at the source node by a network management action toward a called party number. Alternatively, an administrative action can cause all user initiated calls at a given User-to-Network Interface (UNI) to be traced. In the first case, the trace indicates that the call should be cleared immediately upon reaching the destination node. In the second case, the call is left up. Path tracing is supported for both point-to-point and point-to-multipoint connections. Point-to-point path tracing is used to trace the path of a proposed point-to-point connection from a given source node to a called party number. Point-to-multipoint path tracing is used to trace the path of a branch from a given source node on an existing point-to-multipoint connection to a new party. In both cases, the rules for SETUP and ADD PARTY apply.
If a request message with a TTL is received at a trace destination node, the trace destination node sends the source node an acknowledge message that includes a copy of the received TTL. The destination node acknowledges a connection trace request by copying the content of the trace transit list IE in the request message to the acknowledge message, setting the trace status field to “trace completed normally,” and sending the acknowledge message on the incoming interface. When a node receives an acknowledge message, it forwards it to the incoming link. The incoming interface is determined from the local connection table using the call reference and, for a point-to-multipoint connection, the endpoint reference.
FIG. 3
shows the structure of the TTL IE
212
. The TTL is an ordered list. Interpretation of octet groups within a TTL is position dependent. Every TTL includes a TTL Identifier octet
300
, an octet that includes an Extended flag, a coding standard value, and an IE instruction field
302
, two octets that give the length of the TTL contents
304
, an octet that contains flags
306
, an octet that provides the trace status
308
, and a logical ID group
310
, which is 27 octets that hold a logical node identifier and a logical port identifier. The logical ID. group is identified by hav
Cheng Dean C.
Karia Snehal G.
Blakely , Sokoloff, Taylor & Zafman LLP
Cangialosi Salvatore
Cisco Technology Inc.
LandOfFree
Method and apparatus for tracing a virtual connection does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for tracing a virtual connection, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for tracing a virtual connection will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3170684