Академический Документы
Профессиональный Документы
Культура Документы
ATM Layer
Physical Layer
ATM signalling protocol stack
The UNI signalling protocols within the SAAL are responsible for ATM call and
connection control, including call establishment, call clearing, status enquiry, and point-
to-multipoint control.
UNI 3.x Signalling
ftp://ftp.atmforum.com/pub/approved-specs/
A signalling message uses the Q.931 message format. It is made up of a message header
and a variable number of Information Elements (IEs). This is shown in the following
figure:
Message header
IE
IE
...
IE
ATM signalling message
structure
The message header is shown in the following diagram:
Bit
8 7 6 5 4 3 2 1 Octet
Protocol discriminator (9 for Q.2931 messages) 1
0 0 0 0 Length of call reference 2
value
Flag Call reference value 3
Call reference value (continued) 4
Call reference value (continued) 5
Message type 6
Message type (continued) 7
Message length 8
Message length (continued) 9
Variable length Information Elements as required etc.
ATM signalling message structure
Protocol discriminator
Distinguishes Messages for user-network call control from other messages.
Call reference
Unique number for every ATM connection which serves to link all signalling messages
relating to the same connection. It identifies the call at the local user network interface to
which the particular message applies. The call reference is comprised of the call reference
value and the call reference flag. The call reference flag indicates who allocated the call
reference value.
Message type
The message may be of the following types:
Call establishment messages:
CALL PROCEEDING, sent by the called user to the network or by the network to the
calling user to indicate initiation of the requested call.
CONNECT, sent by the called user to the network and by the network to the calling user
to indicate that the called user accepted the call.
CONNECT ACKNOWLEDGE, sent by the network to the called user to indicate that the
call was awarded and by the calling user to the network.
SETUP, sent by the calling user to the network and by the network to the calling user to
initiate a call.
Call clearing messages:
RELEASE, sent by the user to request that the network clear the connection or sent by
the network to indicate that the connection has cleared.
RELEASE COMPLETE, sent by either the user or the network to indicate that the
originator has released the call reference and virtual channel.
RESTART, sent by the user or the network to restart the indicated virtual channel.
RESTART ACKNOWLEDGE, sent to acknowledge the receipt of the RESTART
message.
Miscellaneous messages:
STATUS, sent by the user or network in response to a STATUS ENQUIRY message.
STATUS ENQUIRY, sent by the user or the network to solicit a STATUS message.
Point-to-Multipoint messages:
ADD PARTY, adds a party to an existing connection.
ADD PARTY ACKNOWLEDGE, acknowledges a successful ADD PARTY.
ADD PARTY REJECT, indicates an unsuccessful ADD PARTY.
DROP PARTY, drops a party from an existing point-to-multipoint connection.
DROP PARTY ACKNOWLEDGE, acknowledges a successful DROP PARTY.
Message length
The length of the contents of a message.
Information Elements
Described below.
Example of UNI signalling decode
Types of Information Elements
There are several types of information elements. Some may appear only once in the
message; others may appear more than once. Depending on the message type, some
information elements are mandatory and some are optional. The order of the information
elements does not matter to the signalling protocol. The information elements in UNI 3.0
are listed in the following table:
IE Description Max.
No.
Cause Gives the reason for certain messages. For example, 2
the Cause IE is part of the release message,
indicating why the call was released.
Call state Indicates the current state of the call. 1
Endpoint Identifies individual endpoints in a point-to- 1
reference multipoint call.
Endpoint state Indicates the state of an endpoint in a point-to- 1
multipoint call.
AAL parameters Includes requested AAL type and other AAL 1
parameters.
ATM user cell Specifies traffic parameters. 1
rate
Connection Identifies the ATM connection and gives the VPI 1
identifier and VCI values.
Quality of Indicates the required Quality of Service class for 1
Service the connection.
parameter
Broadband high- Gives information about the high-layer protocols for1
layer information compatibility purposes.
Broadband Requests a service from the network (such as CBR 1
bearer capacity or VBR link, point-to-point and point-to-multipoint
link).
Broadband low- Checks compatibility with layer 2 and 3 protocols. 3
layer information
Broadband Indicates a new active codeset. -
locking shift
Broadband non- Indicates a temporary codeset shift. -
locking shift
Broadband Indicates the competition of sending the called party 1
sending complete number.
Broadband repeat Indicates how IEs which are repeated in the 1
indicator message should be handled.
Calling party Origin of the call. 1
number
Calling party Subaddress of calling party. 1
subaddress
Called party Destination of the call. 1
number
Called party Subaddress of the called party. 1
subaddress
Transit network Identifies one requested transit network. 1
selection
Restart indicator Identifies which facilities should be restarted (e.g., 1
one VC, all VCs).
Types of IEs
For further reference about the exact structure and parameters of the IEs, refer to the
ATM Forum, ATM User-Network Interface Specifications 3.0 and 3.1.
Interested in more details about testing this protocol?
Q.SAAL
Q. 2110 http://www.itu.int/itudoc/itu-t/rec/q/q1000up/q2110_27521.html
Q.2144 http://www.itu.int/itudoc/itu-t/rec/q/q1000up/q2144_33084.html
Q.2100 http://www.itu.int/itudoc/itu-t/rec/q/q1000up/q2100_27509.html
RFC1953 http://www.cis.ohio-state.edu/htbin/rfc/rfc1953.html
Following is the structure for each Q.SAAL message type.
BGN PDU (Begin)
The BGN PDU is used to initially establish an SSCOP connection or reestablish an
existing SSCOP connection between two peer entities. The BGN requests the clearing of
the peer’s transmitter and receiver buffers, and the initialization of the peer’s transmitter
and receiver state variables.
Bytes
1 2 3 4
1 N(UU)
2 Rsvd S PDU N(MR)
Type
876 5 4321
Begin PDU (BGN PDU)
BGAK PDU (Begin Acknowledge)
The BGAK PDU is used to acknowledge the acceptance of a connection request by the
peer entity.
Bytes
1 2 3 4
1 N(UU)
2 Rsvd PDU N(MR)
Type
8765 4321
Begin Acknowledged PDU (BGAK PDU)
BGREJ PDU (Begin Reject)
The BGREJ PDU is used to reject the connection establishment of the peer SSCOP
entity.
Bytes
1 2 3 4
1 N(UU)
2 Rsvd PDU Reserved
Type
8765 4321
Begin Reject PDU (BGREJ PDU)
END PDU (End)
The END PDU is used to release an SSCOP connection between two peer entities.
Bytes
1 2 3 4
1 N(UU)
2 Rsvd S PDU Reserved
Type
876 5 4321
End PDU (END PDU)
ENDAK PDU (End Acknowledge)
The ENDAK PDU is used to confirm the release of an SSCOP connection that was
initiated by the peer SSCOP entity.
Bytes
1 2 3 4
1 Rsvd PDU Reserved
Type
8765 4321
End Acknowledgement (ENDAK PDU)
RS PDU (Resynchronization Command)
The RS PDU is used to resynchronize the buffers and data transfer state variables in the
transmit direction of an SSCOP connection.
Bytes
1 2 3 4
1 N(UU)
2 Rsvd PDU Reserved
Type
8765 4321
Resynchronization PDU (RS PDU)
RSAK PDU (Resynchronization Acknowledgement)
The RSAK PDU is used to acknowledge the resynchronization of the local receiver
stimulated by the received RS PDU.
Bytes
1 2 3 4
1 Rsvd PDU Reserved
Type
8765 4321
Resynchronization acknowledge PDU (RSAK PDU)
SD PDU (Sequenced Data)
The SD PDU is used to transfer, across an SSCOP connection, sequentially numbered
PDUs containing information fields provided by the SSCOP user.
Bytes
1 2 3 4
1 Information (maximum k bytes)
... PAD (0-3 Bytes)
n PL Rsd PDU Type N(S)
87 65 4321
Sequenced data PDU (SD PDU)
SDP PDU (Sequenced Data with Poll)
The SDP PDU is used to transfer, across an SSCOP connection, sequentially numbered
PDUs containing information fields provided by the SSCOP user. The SDP PDU also
contains a poll request that is used to stimulate the transmission of a STAT PDU.
Therefore, an SDP PDU is the functional concatenation of an SD PDU and a POLL PDU.
POLL PDU (Status Request)
The POLL PDU is used to request, across an SSCOP connection, status information
about the peer
Bytes
1 2 3 4
1 Information (maximum k bytes)
... PAD (0-3 Bytes)
Reserved N(PS)
n PL Rsd PDU Type N(S)
87 65 4321
Sequenced data with poll PDU (SDP PDU)
SSCOP entity. It contains a sequence number for use in the retransmission of lost SD or
SDP PDUs.
Bytes
1 2 3 4
1 Reserved N(PS)
2 Rsvd PDU N(S)
Type
8765 4321
Poll PDU (POLL PDU)
STAT PDU (Solicited Status Response)
The STAT PDU is used to respond to a status request (POLL PDU) received from a peer
SSCOP entity. It contains information regarding the reception status of SD or SDP PDUs,
credit information for the peer transmitter, and the sequence number of the POLL PDU to
which it is in response.
Bytes
1 2 3 4
1 PAD List element 1 (a SD PDU N(S))
2 PAD List element 2
... . .
. .
. .
L PAD List element L
L+1 PAD N(PS)
L+2 PAD N(MR)
L+3 Rsvd PDU Type N(R)
8765 4321
Solicited status PDU (STAT PDU)
USTAT PDU (Unsolicited Status Response)
The USTAT PDU is used to respond to a detection of a new missing SD or SDP PDU,
based on the examination of the sequence number of the SD or SDP PDU. It contains
information regarding the reception status of SD or SDP PDUs and credit information for
the peer transmitter.
Bytes
1 2 3 4
1 PAD List element 1 (a SD PDU N(S))
2 PAD List element 2
3 PAD N(MR)
4 Rsvd PDU N(R)
Type
8765 4321
Unsolicited status PDU (STAT PDU)
IISP
IISP (Interim Interswitch Signalling Protocol) is a protocol that has been devised to
provide signalling between switches from multiple vendors. It has been developed as a
stopgap solution, until the more sophisticated PNNI (Private Network-to-Network
Interface) specification is complete. There is no migration path from IISP to PNNI.
IISP uses UNI 3.1 signalling procedures as does PNNI. However, the switches using IISP
are not peers, i.e., one switch functions as the network node and the other as an end-
station. There is no support for dynamic distribution of routing information.
Interested in more details about testing this protocol?
B-ICI
http://www-comm.itsi.disa.mil/atmf/bici.html#af13.3
B-ICI, a BISDN Inter Carrier Interface, is an interface connecting two different ATM
based public network providers or carriers. This is necessary in order to facilitate end-to-
end national and international ATM/BISDN services. The B-ICI specification also
includes service specific functions above the ATM layer required to transport, operate
and manage a variety of intercarrier services across the B-ICI.
The protocols in this group include: Q.2140 and B-ISUP.
B-ISUP
The structure of the B-ISUP header is shown in the following illustration:
Routing Type Message Compatibility Message
label code length
4 1 2 1 variable
B-ICI header structure
Routing label
This is the same for each message on a specific ATM virtual connection.
Type code
Defines the function and format of each B-ISDN user part message. Examples of
messages are: Address complete, Call progress, Forward transfer, and Release complete.
Message length
Number of octets in the message.
Compatibility
Message compatibility information. Defines the behavior of a switch if a message is not
understood.
Message
Contents of the message.
Interested in more details about testing this protocol?
Q.2140
Q.2140 is part of the ATM adaptation layer which supports signalling at the Network
Node Interface of the B-ISDN. This protocol implements the Service Specific
Coordination Function (SSCF) for signalling at the NNI.
The structure of the Q.2140 header is shown in the following illustration. The Q.2140
contains one field called SSCF status.
Reserved SSCF Status
3 bytes 1 byte
Q.2140 header structure
The SSCF status indicates the status of the sending peer. It can have the following values:
0000 0001 Out of service
0000 0010 Processor Outage
0000 0011 In Service
0000 0100 Normal
0000 0101 Emergency
0000 0111 Alignment Not Successful
0000 1000 Management Initiated
0000 1001 Protocol Error
0000 1010 Proving Not successful
Interested in more details about testing this protocol?
SPANS
SPANS UNI release 2.3, NNI release 3.0, UNI release 3.0
SPANS (Simple Protocol for ATM Network Signalling) is a simple signalling protocol,
developed by FORE systems and used by FORE and other manufacturers working in
cooperation with FORE, for use in ATM networks.
SPANS signalling messages are transferred over a reserved ATM virtual connection,
using AAL type 3/4. Currently this connection uses VPI 0 and VCI 15. This channel must
be predefined in both directions, on all links used by participants in the signalling
protocol.
A null transport layer is used. Retransmission of lost messages and suppression of
duplicate messages are performed by the application when necessary.
The first part of this protocol is SPANS UNI which is used in ATM LANs. The protocol
specifies the signalling messages that are exchanged between hosts and the ATM network
to perform several functions such as opening and closing connections. These functions
allow hosts and routers to use an ATM LAN as a subnet of a larger internet. The two
classes of messages involved in this protocol are status messages and connection
messages.
The second part of the protocol is SPANS NNI, which is a simple signalling protocol for
routing and virtual path support in ATM LANs. This part of the protocol specifies the
signalling messages that are exchanged between ATM network switches to perform
functions such as opening and closing virtual paths. An ATM network switch is a device
which is capable of forwarding data over ATM connections from one or more sources to
one or more destinations. The two classes of messages involved with this protocol are
topology messages and network internal connection messages.
The format of the SPANS header is shown in the following illustration:
8 16 24 32 bits
Major version Minor ver
Message type
Remainder of frame
SPANS header structure
Major version
• The major version of the protocol.
Minor ver(sion)
• The minor version of the protocol.
Message type
• The types of messages are as follows:
• STATUS messages, which transfer information about the state of a signalling
peer. The status messages are as follows:
Indications - Issued by the network.
Responses - Issued in response to the network’s indications.
Requests - Issued by hosts when booting.
• CONNECTION messages are used in order to open new connections or close
existing ones. The connection messages are as follows:
Requests - The originating side, either the source or the destination of the
connection, sends a request message.
Indications - In most cases, the request causes an indication message to be issued
by the network to the target host.
Responses - The target host then returns a response message, in response to the
request which was received.
Confirmations - Finally, the network issues a confirmation message to the
original source.
• TOPOLOGY messages are exchanged between switches within a network.
Through these messages, switches learn of changes in the network topology, e.g.,
new switches coming on line, switches and links going down, and changing node
and link loads.
• NETWORK-INTERNAL CONNECTION messages are exchanged by switches
in the network to set up and manage virtual paths. The originating switch issues a
request, which may be forwarded as a request by intermediate switches until it
reaches the target switch. The target switch produces a reply, which again may be
forwarded by intermediate switches on its way back to the originator.
Interested in more details about testing this protocol?
ViVID MPOA
ViVID is a proprietary protocol of Newbridge which provides bridged LAN Emulation.
and routed LAN Emulation functionality. There are 3 protocols in the ViVID group,
BME, ARM and CCP. They share a common header format. All ViVID protocols are
LLC/SNAP encapsulated. The Newbridge OUI and a PID value of 0x02 identify them as
ViVID.
Interested in more details about testing this protocol?
MPOA
The Multi Protocol Over ATM (MPOA) deals with the efficient transfer of inter-subnet
unicast data in a LANE environment. MPOA integrates LANE and NHRP to preserve the
benefits of LAN Emulation, while allowing inter-subnet, internetwork layer protocol
communication over ATM VCCs without requiring routers in the data path. MPOA
provides a framework for effectively synthesizing bridging and routing with ATM in an
environment of diverse protocols, network technologies, and IEEE 802.1 virtual LANs.
MPOA is capable of using both routing and bridging information to locate the optimal
exit from the ATM cloud.
(Compliant with the ATM Forum Specification STR-MPOA-MPOA-01.00 04-1997.)
The format of the header is shown in the following illustration:
8 16 24 32 bits
ar$afn ar$pro.type
ar$pro.snap
ar$pro.snap ar$hopcnt ar$pkstz
ar$chksum ar$extoff
ar$op.version ar$op.type ar$shtl ar$sstl
MPOA header structure
ar$afn
Defines the type of "link layer" address being carried.
ar$pro.type
This field is a 16 bit unsigned integer.
ar$pro.snap
When ar$pro.type has a value of 0x0080, a snap encoded extension is being used to
encode the protocol type. This snap extension is placed in the ar$pro.snap field;
otherwise this field should be set to 0.
ar$hopcnt
The hop count. This indicates the maximum number of NHSs that an MPOA packet is
allowed to traverse before being discarded.
ar$pktsz
The total length of the MPOA packet in octets.
ar$chksum
The standard IP checksum over the entire MPOA packet.
ar$extoff
This field identifies the existence and location of MPOA extensions.
ar$op.version
This field indicates what version of generic address mapping and management protocol is
represented by this message.
ar$op.type
The MPOA packet type. Possible values for packet types are:
128 MPOA Cache Imposition Request.
129 MPOA Cache Imposition Reply.
130 MPOA Egress Cache Purge Request.
131 MPOA Egress Cache Purge Reply.
132 MPOA Keep-Alive.
133 MPOA Trigger.
134 MPOA Resolution Request.
135 MPOA Resolution Reply.
5 MPOA Data Plane Purge.
6 MPOA Purge Reply.
7 MPOA Error Indication.
ar$shtl
The type and length of the source NBMA address interpreted in the context of the
"address family number".
ar$sstl
The type and length of the source NBMA subaddress interpreted in the context of the
"address family number".