. 98
( 132 .)


the sender that the rate of traf¬c can be increased. The sender will keep decreasing the
rate until it receives an RM cell, indicating no congestion. Again, there is a problem here,
known as the ˜beat down™ problem, where virtual circuits whose paths are longer will
have less chance of increasing their rate. A solution to this is to make the switch decide
whether to set the EFCI bit by considering not only the congestion, but also the current
rate of traf¬c on the virtual circuit. It should be noted that there are more complicated
rate-based schemes which feedback more explicit control information in the RM cell.

For the management of an ATM network, a management architecture is needed. Refer-
ring again to the ATM reference model, the management plane covers all layers of the
protocol architecture. The model for network management is de¬ned by the ATM Forum
and is illustrated in Figure 7.53. Here, each switch has its own network management
system (NMS).
The model provides for a total network management solution. In the upper layers,
management information is sent using the integrated local management interface (ILMI).
This provides for con¬guration and alarm generation of the ATM interfaces, as well as
establishing operations between two different ATM devices. Further down at the ATM
layer, a layer management protocol is used to provide end-to-end circuit management
and checking the circuit throughout the entire network. This management information is
carried by operation administration and maintenance (OAM) cells. The model classi¬es
management functions into ¬ve areas:

• M.1: management of ATM end devices
• M.2: management of private ATM networks

M.3 M.5
Private NMS Operator NMS Operator NMS
M.2 M.4
Private Public Public

ATM end Private Public Public
system ATM Switch ATM Switch ATM Switch

Figure 7.53 Network management model

• M.3: management of links between public and private networks
• M.4: management of public ATM networks
• M.5: management of links between two public networks

7.12.1 Integrated local management interface (ILMI)
ILMI is an implementation which uses the simple network management protocol (SNMP),
the most popular management protocol in use today. It was primarily intended for use
on TCP/IP networks but has been ported across to many other environments. SNMP
allows the monitoring, evaluation and modi¬cation of networks from a single computer,
called the SNMP manager. From here you can make inquiries to other SNMP devices on
your network, such as routers and hosts. The devices questioned will return the requested
information from their management information base (MIB). Figure 7.54 shows the model
of the management structure.

7.12.2 Layer management
Layer management is associated with end-to-end connections and provides lower-level
management functions such as fault detection. Operations and maintenance information



ATM end VPI=0 VCI=16



Descriptions Descriptions
Connections Connections
Statistics Statistics
Network Network
prefix prefix

Manager/agent Manager/agent

Figure 7.54 ILMI model

is transmitted between different network elements. At the physical layer, management
information is carried in the SONET/SDH overhead, termed F1“F3, which cover man-
agement of the transmission path. At the ATM layer, management information is carried
in OAM cells, and operates at two different levels:

• Virtual path level: F4
• Virtual circuit level: F5.

The concept is shown in Figure 7.55. Here it can be seen that the F4 operation termi-
nates at the last switch whereas the F5 continues to the destination system.
To identify the OAM cells, for F4, the cells use the same virtual path as the user data,
but travel on two reserved VCIs, as shown:

VCI = 3: segment OAM F4 cells
VCI = 4: end-to-end OAM F4 cells

For F5 cells, the PTI ¬eld in the cell header is used since the cells are travelling on
the same VPI and VCI as the data:

PTI = 1002 : segment OAM F5 cells
PTI = 1012 : end-to-end OAM F5 cells

Segment OAM cells provide maintenance information between adjacent switches, while
end-to-end OAM cells do the same between source and destination.
The structure of the OAM cell is as shown in Figure 7.56.

system Switch Switch system


F4 F4

Figure 7.55 OAM ¬‚ows

4 bits 4 bits 360 bits 6 bits 10 bits
OAM type Function specific Reserved CRC

48 bytes

Figure 7.56 OAM cell structure

Table 7.19 OAM types
OAM type Value Fault type Value
Fault management 0001 Alarm indication 0000
Far end receive failure 0001
OAM cell loopback 1000
Continuity check 0100
Performance management 0010 Forward monitoring 0000
Backward reporting 0001
Monitoring and reporting 0010
Activation/deactivation 1000 Performance monitoring 0000
Continuity check 0001

The OAM types and their respective function types (value) are outlined in Table 7.19.


Signalling is the process by which ATM users and the network exchange control informa-
tion, such as requesting network resources and establishing connections. The naming and
scope of the standards is different in the de¬nition from the ITU-T and the ATM Forum.
For the ITU-T, the de¬nitions lead on from those de¬ned for narrowband ISDN. The
standard for signalling in an N-ISDN network is Q.931. For B-ISDN, and hence ATM,
the signalling standard is referred to as Q.2931 (formerly Q.93B). Q.2931 is a variant
of signalling system 7 (SS7), the signalling system used in the international telephone
network. The ¬rst signalling protocol devised by the ATM Forum was UNI3.0, which was
unfortunately incompatible with Q.2931. Therefore the ATM Forum upgraded UNI3.0 to
UNI3.1. However, there were still some aspects of Q.2931 not supported by UNI3.1, so
eventually the two bodies worked together and the remaining features of Q.2931 were
incorporated into the current version, UNI4.0. As its name suggests, UNI signalling deals
only with signalling from a user to the network.

7.13.1 ATM signalling protocol stack
ATM provides the following protocol stack to support reliable transport of signalling pro-
tocols. Since the user plane of ATM does not provide for reliable end-to-end connections,
additional layers are needed on top to provide this functionality. The signalling protocol
stack sits on top of AAL5 and is known as the signalling AAL, or SAAL. The stack is
shown in Figure 7.57.
The SAAL consists of the common part, which is the convergence sublayer of AAL5,
and the service-speci¬c part, as shown. It is de¬ned in ITU-T recommendation Q.2100.
AAL5 is used since it supports the transfer of large messages, up to 64 kbytes in size.
However, if MTB3b is being transported, it restricts the message size to 4 kbytes.

Signalling Protocol



AAL5 Common Part

ATM layer

Physical layer

Figure 7.57 ATM signalling protocol stack

7.13.2 Service-speci¬c connection-oriented protocol

Signalling messages generally require assured delivery and this is provided by the SSCOP,
as de¬ned by the ITU-T in the Q.2110 speci¬cation. The rationale for separating the sig-
nalling AAL into two layers, the SSCOP and the Service-Speci¬c Coordination Function
(SSCF), is to allow the SSCOP to operate independently and offer the same service to
a number of different layers above. The SSCF then coordinates the access between the
SSCOP and these upper layers. Considering the UMTS applications alone, the SSCOP pro-
vides service to the transport layer AAL2 signalling and the UMTS application protocols
such as NBAP.
The following key functions are performed by the SSCOP:

• Transfer of user data in-sequence: note that user data here refers to the user of the
SSCOP and not end users. An example user is NBAP.
• Error control: detection of errors and correction through selective retransmission.
• Flow control: the receiver dictates the rate at which the transmitter can send signalling
messages. This is implemented using a window mechanism, the size of which can be
renegotiated once the connection is proceeding.
• Keep alive: a veri¬cation that the receiver and transmitter are still alive even if there
has been little or no data transfer over a long period of time.
• Error and status reporting.

SSCOP has two principal modes of operation: assured and unacknowledged data trans-
fer. In many ways, the SSCOP acknowledged mode can be considered analogous to the
TCP protocol, where reliability is maintained using sequence numbers, ¬‚ow control and
timers. The unacknowledged mode is similar to UDP, where user data is not sequenced
or acknowledged, and no delivery or integrity guarantees are made.

Table 7.20 SSCOP PDU types
Function PDU PDU ¬eld Description
Establishment BGN 0001 Begin connection
BGAK 0010 Begin acknowledge
BGREJ 0111 Begin reject
Release END 0011 End connection
ENDAK 0100 End acknowledge
Assured data transfer SD 1000 Sequenced data
POLL 1010 Information request
STAT 1011 Information reply
USTAT 1100 Unsolicited information
Unacknowledged data transfer UD 1101 Unsequenced data
Resynchronization RS 0101 Resynchronization
RSAK 0110 Resynchronization acknowledge
Recovery ER 1001 Recovery instruction
ERAK 1111 Recovery acknowledge
Management data transfer MD 1110 Management data

0-3 bytes 4 bytes


. 98
( 132 .)