Digital Aggregates | Annotated UNI 3.1 Cause Codes

Annotated UNI 3.1 Cause Codes

Annex E

Annotated UNI 3.1 Cause Codes

The annotations in italics are based on my personal experience and that of many others developing and debugging ATM devices, including switches, multiplexers, and end stations, from a variety of vendors including Agile Networks, Ascend, Avaya, Fore, Lannet, Lucent Technologies, Marconi, and Yurie. The non-italicized text is from the ATM UNI Specification 3.1.

Normal class definitions

Cause Number 1: unallocated (unassigned) number

This cause indicates that the called party cannot be reached because, although the number is in a valid format, it is not currently assigned (allocated).

Cause Number 2: no route to specified transit network

This cause indicates that the equipment sending this cause has received a request to route the call through a particular network which it does not recognize. The equipment sending this cause does not recognize the transit network either because the transit network does not exist or because that particular transit network, while it does exist, does not serve the equipment which is sending this cause.

This cause is supported on a network-dependent basis.

· We have only rarely seen this Cause Code.

· We believe it was caused by PNNI misadministration, or

· by PNNI interoperability issues.

Cause Number 3: no route to destination

This cause indicates that the called party cannot be reached because the network through which the call has been routed does not serve the destination desired.

This cause is supported on a network-dependent basis.

· An ATM switch cannot determine how to route an SVC SETUP message to an end station.

· For end stations and edge switches using ILMI, can be caused temporarily by a Loss Of Signal (LOS) or other failure in the physical layer. LOS causes ATM switch to deregister the ILMI End Station Identifier (ESI). This causes the route to the end station to be lost until the physical layer is reestablished and ILMI in the end station reregisters its ESI with the switch. It takes time to recover from LOS.

· Can similarly occur because of LOS between intermediate ATM switches. This can occur due to any disruption in the physical layer, including fiber disruptions or ATM switch resets.

· For systems not using ILMI, can occur because of misadministration of end stations on the edge switch.

· For systems not using PNNI or other routing protocols, for example when using manually administered routes using IISP, can occur because of misadministration of routes on switches.

· For systems using PNNI, it may be administered incorrectly. We have seen switches fail to find routes when PNNI was configured incorrectly, even when PNNI was not being used for inter-switch routing, or even there was only one switch in the ATM network.

Cause Number 10: VPCI/VCI unacceptable

This cause indicates that the virtual channel most recently identified is not acceptable to the sending entity for use in this call.

Cause Number 16: normal call clearing

This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared.

Under normal situations. The source of this cause is not the network.

· This is typically not an error but we have seen end station device complain about it. It occurred because an end station using point-to-multipoint SVCs lost track of the parties it had ADDed and DROPed on the call. When the end station DROPed what was in fact the last party, the ATM network responded with RELEASE, with a Cause Code 16, that from the perspective of the end station was unexpected because it thought there were still parties on the call.

Cause Number 17: user busy

This cause is used to indicate that the called party is unable to accept another call because the user busy condition has been encountered. This cause value may be generated by the called user or by the network.

Cause Number 18: no user responding

This cause is used when a called party does not respond to a call establishment message with a connect indication within the prescribed period of time allocated.

· An ATM switch or end station did not respond to a SETUP, CALL PROCEEDING, ADD PARTY or DROP PARTY within the time out period. Typical timer values, depending on the message ,range from four to fourteen seconds.

· This is usually been associated with a burst of very high SETUP load.

· This is not necessarily associated with a long term high SETUP volume. We have seen it occur when a temporary LOS causes the end station to have to re-SETUP all of the SVCs that it lost.

· We have found that the performance claims for SETUPs per second for most ATM switches to be the absolute maximum that they can handle under the most optimistic of circumstances. Such claimed rates cannot usually be sustained for very long if at all, or cannot be handled except if the interarrival times of the SETUPs are uniformly distributed (no bursts).

Cause Number 21: call rejected

This cause indicates that the equipment sending this cause does not wish to accept this call, although it could have accepted the call because the equipment sending this cause is neither busy nor incompatible.

· The end station or ATM switch suffered an internal failure, typically in software.

· It is often the result of exhaustion, possibly transient, of some internal resource. For example, end stations and switch have some upper limit on the number of simultaneous SVCs. This may or may not be an administrable limit.

· The ATM switch assigned a VPI or VCI which is outside the implemented range of the end station. Not all end stations can support the maximum possible range of VPI and VCI values.

· The end station lost its connection to the ATM network and is rejecting all new SETUP requests from its application.

· The end station or ATM switch received a SETUP that contained an invalid Connection ID. For example, the Connection ID may already be in use by another SVC between the same to end points.

· A SETUP was received for an SVC that was not in the Connecting state.

· The ATM switch cannot handle a burst of SETUPs.

· Typically this Cause Code is generated by an end station, but it can be generated by an ATM switch using IISP for inter-switch routing and administered as the User side of the UNI.

Cause Number 22: number changed

This cause is returned to a calling party when the called party number indicated by the calling user is no longer assigned. The new called party number may optionally be included in the diagnostic field. If a network does not support this capability, cause number #1, “unassigned (unallocated) number”, shall be used.

Cause Number 23: user rejects all calls with calling line identification restriction (CLIR)

This cause is returned by the called party when the call is offered without calling party number information and the called party requires this information.

Cause Number 27: destination out of order

This cause indicates that the destination indicated by the user cannot be reached because the interface to the destination is not functioning correctly. The term “not functioning correctly” indicates that a signaling message was unable to be delivered to the remote user; e.g., a physical layer or SAAL failure at the remote user, user equipment off-line.

· We have seen this occur when the Q.SAAL low level signaling layer somehow fails between ATM switches or between a switch and an end station, and the culprit does not bring the Q.SAAL layer back up within ten seconds. Then this timeout occurs, the ATM network is required to RELEASE all of the SVCs, typically with this Cause Code, and place each end of the Q.SAAL layer into link recovery.

· This is a typical cause code when an end station or ATM switch is reset or suffers LOS while it has SVCs up.

Cause Number 28: invalid number format (address incomplete)

This cause indicates that the called user cannot be reached because the called party number is not in a valid format or is not complete.

Cause Number 30: response to STATUS ENQUIRY

This cause is included in the STATUS message when the reason for generating the STATUS message was the prior receipt of a STATUS ENQUIRY message.

Cause Number 31: normal, unspecified

This cause is used to report a normal event only when no other cause in the normal class applies.

· We have seen this cause code as a result of an ADD PARTY failure. In this scenario, a DROP PARTY and ADD PARTY are issued in quick succession. The DROP PARTY completes but the ADD PARTY fails. If this leaves only a single party on the call, the ATM network RELEASEs the SVC with this Cause Code. This scenario can occur during a call transfer or when temporarily adding voice resources (for example, touch tone receivers, voice mail, or voice messages) to a call.

Resource unavailable class definitions.

Cause Number 35: requested VPCI/VCI not available

This cause indicates that the requested VPCI/VCI is not available.

· We have seen this occur when the ATM switch and end station, or second ATM switch when using IISP, do not agree on the VPI or VCI range that can be used. Not all end stations or even ATM switches can use the maximum possible range of VPI or VCI values. This is typically due to incorrect administration, but can also be due to bugs in ILMI.

· This can also occur when the ATM switch processes RELEASE messages asynchronously. Most ATM switches issue a RELEASE COMPLETE in response to a RELEASE even though they have not completed processing the RELEASE by releasing all of the internal resources associated with the SVC. This is done to increase the rate of SETUPs that they claim to support. After generating the RELEASE COMPLETE but before completing the processing of the RELEASE, the switch may receive a SETUP using they same VPCI/VCI as the RELEASEd SVC, which some portion of the switch software believes is still in use. The ATM standard requires that all switch resources associated with an SVC be released before a RELEASE COMPLETE is generated for just this reason but many switches violate this.

· We have seen this asynchronous RELEASE processing exacerbated when ATM switches, typically from different vendors, allocated VPCI and VCI values in different orders, for example from high to low values versus from low to high values. Vendors play tricks with this to make it less likely that a VPCI or VCI will be reused before RELEASE processing is complete.

· We also have seen this asynchronous RELEASE processing exacerbated when ATM switches, even from the same vendor, are using IISP and the switch on the Network side (which allocates VPCIs and VCIs) has a much faster processor than the switch on the User side. Try reversing the roles of the switches.

· We have seen ATM switches under high call load drop SETUP and ADD PARTY requests internally. This leads to confusion about what VPCI and VCIs are in use.

Cause Number 38: network out of order

This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time; e.g., immediately re-attempting the call is not likely to be successful.

· Our experience is that this occurs when an ATM switch is using IISP and an adjacent ATM switch is not responding to signaling. Typical reasons are the adjacent switch is in the processing of being reset.

Cause Number 41: temporary failure

This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time; e.g., the user may wish to try another call attempt immediately.

· We have seen this occur due to a failure in an ATM switch or end station to respond in time to signaling messages. The network generates STATUS INQUIRY messages to interrogate the end station or adjacent ATM switch. When no response is forthcoming, typically within four seconds, all SVCs are RELEASEd with this Cause Code.

· This can be due to very high call load, lost messages, or even race conditions.

Cause Number 43: access information discarded

This cause indicates that the network could not deliver access information to the remote user as requested: i.e., ATM adaptation layer parameters, Broadband low layer information, Broadband high layer information, or sub-address as indicated in the diagnostic.

Cause Number 45: no VPCI/VCI available

This cause indicates that there is no appropriate VPCI/VCI presently available to handle the call.

· We have never actually seen this Cause Code occur.

· In the ATM devices for which we have personally written software, it can occur if all available VPCI/VCIs have been used. Recall that this may be a subset of the actually maximum range of possible VPCI/VCI values.

Cause Number 47: resource unavailable, unspecified

This cause is used to report a resource unavailable event only when no other cause in the resource unavailable class applies.

· An ATM switch or end station ran out of some resource other than bandwidth or VPCI/VCIs.

· We have seen this occur when an ATM switch ran out of internal point-to-multipoint resources. Because point-to-multipoint applications are somewhat rare, ATM switches frequently have a limited number of resources, such as internal table sizes, to support them. This is frequently an administrable limit.

· It can be generally interpreted as the exhaustion of any internal resource in the switch or end station, including even CPU utilization.

· It can also be due to a transient dynamic condition related to instantaneous call load, such as a temporary exhaustion of internal memory buffers or a request queue filling up.

· We have seen this occur due to a memory leak in the ATM switch or end station software. This bug usually requires a reset of the culprit to correct.

Service or option not available class definitions

Cause Number 49: Quality of Service unavailable

This cause is used to report that the requested Quality of Service cannot be provided.

· An ATM switch or end station denied a SETUP or an ADD PARTY because it could not guarantee the requested Quality of Service or bandwidth. (The text would suggest the former but our experience is that this is not always the case.)

· When ATM switches are using IISP for inter-switch routing, this indicates a Connection Admission Control (CAC) rejection of a SETUP or ADD PARTY. The ATM switch cannot satisfy the traffic contract or Quality of Service of the request based on its current SVC load. In our experience this is typically a bandwidth issue.

· When ATM switches are using PNNI for inter-switch routing, this may indicate a CAC rejection, but can also be a simple routing issue. PNNI has a feature called Crank Back in which the ATM network searches for a usable route that can satisfy the traffic contract and quality of service of the request. The PNNI Crank Back algorithm cannot always distinguish between lack of bandwidth and lack of a route to the destination end station. All routing failures are considered to be CAC rejections. In our experience this is typically a routing issue.

Cause Number 51: User cell rate not available

This cause is used to report that the requested ATM Traffic Descriptor is unobtainable.

· An ATM switch or end station denied a SETUP or an ADD PARTY because it could not guarantee the requested Quality of Service or bandwidth. (The text would suggest the latter but our experience is that this is not always the case.)

Cause Number 57: bearer capability not authorized

This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but the user is not authorized to use.

Cause Number 58: bearer capability not presently available

This cause indicates that the user requested a bearer capability which is implemented by the equipment which generated the cause but which is not available at this time.

Cause Number 63: Service or option not available, unspecified

This cause is used to report a service or option not available event only when no other cause in the service or option not available class applies.

· We have seen this Cause Code generated when the ATM switch could not guarantee the requested Quality of Service or even bandwidth requested by the SETUP or ADD PARTY request.

· When a single ATM switch is involved, this typically means there is a configuration or administration issue. For example, we have seen this occur when manually administered PVCs are using most of the bandwidth on a particular UNI.

· In multi-switch configurations, it has typically pointed to network congestion, a traffic engineering issue. We have seen DS-3 WAN channels legitimately run out of bandwidth when aggregating one or more OC-3 LAN channels.

· Connection Admission Control algorithms are highly proprietary. Different switches, even from the same vendor, use different CAC algorithms, and make different guesses as to the available allocable bandwidth. Hence, different ATM switches may be able to support more or less of the same call mix.

Service or option not implemented class definitions

Cause Number 65: bearer capability not implemented

This cause indicates that the equipment sending this cause does not support the bearer capability requested.

Cause Number 73: unsupported combination of traffic parameters

This cause indicates that the combination of traffic parameters contained in the ATM traffic descriptor information element is not supported.

Invalid message (e.g., parameter out of range) class definitions

Cause Number 81: invalid call reference value

This cause indicates that the equipment sending this cause has received a message with a call reference which is not currently in use on the user-network interface.

· We have seen this due to a bug in the software of either the end station software or the ATM switch.

· We have also seen this as a result of a race condition due to asynchronous processing of SETUP and RELEASE requests in the ATM switch.

Cause Number 82: identified channel does not exist

This cause indicates that the equipment sending this cause has received a request to use a channel not activated on the interface for a call.

Cause Number 88: incompatible destination

This cause indicates that the equipment sending this cause has received a request to establish a call which has Broadband low layer information, Broadband high layer information, or other compatibility attributes which cannot be accommodated.

Cause Number 89: invalid endpoint reference value

This cause indicates that the equipment sending this cause has received a message with an endpoint reference which is currently not in use on the user-network interface.

Cause Number 91: invalid transit network selection

This cause indicates that a transit network identification was received which is of an incorrect format as defined in Annex D.

Cause Number 92: too many pending add party requests

This cause indicates a temporary condition when the calling party sends an add party message but the network is unable to accept another add party message because its queues are full.

Cause Number 93: AAL parameters can not be supported

This cause indicates that the equipment sending this cause has received a request to establish a call which has ATM adaptation layer parameters which cannot be accommodated.

Protocol Error (e.g., unknown message) class definitions

Cause Number 96: mandatory information element is missing

This cause indicates that the equipment sending this cause has received a message which is missing an information element which must be present in the message before the message can be processed.

· This can occur because of two adjacent ATM switches, one was administered for PNNI and the other for IISP. A SETUP sent from the IISP switch to the PNNI switch lacked a PNNI-specific information element. This is an administration mistake.

· We have seen ATM switches used by service providers administered to require an optional information element, in our case it was the “Calling Party Number, and reject all of our SETUPs with this Cause Code. The Bellcore GR-1110-CORE standard does allow service providers to require optional IEs, typically for purposes of billing. (We fixed our end station software.)

· The RELEASE and RELEASE COMPLETE messages containing this Cause Code should also contain an indication of which IE is missing.

Cause Number 97: message type non-existent or not implemented

This cause indicates that the equipment sending this cause has received a message with a message type it does not recognize either because this is a message not defined or defined but not implemented by the equipment sending this cause.

Cause Number 99: information element non-existent or not implemented

This cause indicates that the equipment sending this cause has received a message which includes information element(s) not recognized because the information element identifier(s) are not defined or are defined but not implemented by the equipment sending the cause. This cause indicates that the information element(s) were discarded. However, the information element is not required to be present in the message in order for the equipment sending this cause to process the message.

Cause Number 100: invalid information element contents

This cause indicates that the equipment sending this cause has received an information element which it has implemented; however, one or more of the fields in the information element are coded in such a way which has not been implemented by the equipment ending this cause.

· To my knowledge, we have seen this Cause Code exactly once. It was in a customer network of single vendor ATM switches. The invalid IE being rejected by our end station software was the Connection Identifier in a SETUP received from the network. The VP Associated Signaling subfield contained the Any VPCI code rather than the expected Explicit Indication of VPCI code. While the ITU-T Q.2931 standard allows either code for the subfield, the ATM Forum UNI 3.1 specification only allows the latter. An upgrade of the ATM network equipment addressed this.

· More generally, the ATM device generating this cause code is complaining about the contents of the Information Element, but not the presence of the Information Element itself. The RELEASE and RELEASE COMPLETE messages containing this Cause Code should also contain an indication of which IE is at fault.

Cause Number 101: message not compatible with call state

This cause indicates that a message has been received which is incompatible with the call state.

· We have seen this when an ADD PARTY request is followed very closely by a DROP PARTY for the same party without waiting for the ADD PARTY ACK. The ATM Forum and ITU-T specifications do not appear to prohibit this. But once the DROP PARTY is generated, the party is in the DROP PARTY INITIATED state and both specifications state that once in that state receiving an ADD PARTY ACK is unexpected. The end station responds with a STATUS message indicating that the ADD PARTY ACK is incompatible with the current call state of the party.

· As near as we can tell, this does not cause any user-perceivable failures, but I personally believe it is a bug in the UNI state machine.

Cause Number 102: recovery on timer expiry

This cause indicates that a procedure has been initiated by the expiry of a timer in association with error handling procedures.

· An ATM switch or end station did not respond to a SETUP, CALL PROCEEDING, or RELEASE within the time out period. Typical timer values, depending on the message ,range from four to thirty seconds.

· This is usually been associated with a burst of very high SETUP load.

· This is not necessarily associated with a long term high SETUP volume. We have seen it occur when a temporary LOS causes the end station to have to re-SETUP all of the SVCs that it lost.

Cause Number 111: protocol error, unspecified

This cause is used to report a protocol error event only when no other cause in the protocol error class applies.

· We have seen this Cause Code occur when an ATM device received an unexpected RELEASE COMPLETE or DROP PARTY ACK without a Cause Code information element.

· The messages were unexpected in the sense that they were not in response to a RELEASE or a DROP PARTY message respectively.

References

ATM User-Network Interface Specification Version 3.1, Annex E, ATM Forum, af-uni-0010.0002, September 1994

Broadband Integrated Services Digital Network (B-ISDN) - Digital Subscriber Signaling System No. 2 (DSS 2) - User-Network Interface (UNI) Layer 3 Specification for Basic Call/Connection Control, ITU-T, Recommendation Q.2931, February 1995

Broadband Switching System (BSS) Generic Requirements, Bellcore, GR-1110-CORE, Issue 4, December 2000

Author

J. L. Sloan jsloan@diag.com 2005-08-16

The author would like the acknowledge the dozens of engineers, with ATM equipment vendors, service providers, and customers, who contributed to this base of knowledge.