Download (direct link):
The window granted by the SSCOP receiver allows the peer SSCOP transmitter to transmit new SD PDUs. The process by which the receiver determines how many new SD PDUs the transmitter can transmit is not part of the standard. Typically, it should be a function of buffer availability at the receiver and of the bandwidth-delay product. The SSCOP receiver allocates a buffer to support each connection. In principle, this buffer should match or exceed the window granted by the receiver, in order to avoid discarding of successfully transmitted data.
If the receiver detects a missing or erroneous SD PDU, it sends a USTAT immediately, instead of having to wait for a POLL. A USTAT PDU is identical to a STAT PDU except that it is not associated with a POLL. A USTAT PDU is not sent by the receiver, if the same SD PDU is found missing for the second time.
SSCOP does not have the means to check for erroneously received SD PDUs. SSCOP runs on top of AAL 5, and the payload of each AAL 5 CPS-PDU contains an SD PDU. Upon receipt of an AAL 5 CPS-PDU, the CPS checks for errors using the CRC check. If it finds that the received CPS-PDU is in error, it still passes its payload to SSCOP with a notification that it is in error. SSCOP checks for invalid PDUs. A PDU is invalid if its PDU type is unknown, or it is not 32-bit aligned, or it does not have the proper length for a PDU of the stated type. Invalid PDUs are discarded.
Lost SD PDUs are detected by SSCOP by checking whether there is a missing SD PDU sequence number. An SD PDU might be lost for a variety of reasons; it might have
THE SIGNALING ATM ADAPTATION LAYER (SAAL)
arrived when the SSCOP receiver buffer was full, or it might have been invalid, in which case, the SSCOP discarded it. It will also be lost in the unlikely case where all of the ATM cells carrying the SD PDU are lost.
In the OSI model, the functions of a layer n provide a set of services which can be used by the next higher layer n + 1. The function of a layer n are built on services it requires from the next lower layer n — 1. The services in each layer are provided through a set of primitives. Each primitive might have one or more parameters that convey information required to provide the service. There are four basic types of primitives: request, indication, response, and confirm. A request type primitive is passed from a layer n to a lower layer n — 1 to request a service to be initiated. An indication type primitive is passed from a layer n — 1 to a higher layer n to indicate an event or condition significant to layer n. A response type primitive is passed from a layer n to a lower layer n — 1 to complete a procedure previously invoked by an indication primitive. Finally, a confirm type primitive is used by a layer n — 1 to pass results from one or more previously invoked request primitives to an upper layer n. These primitive types are also used between a signaling protocol and SAAL (see Figure 5.4).
SAAL functions are accessed by a signaling protocol through the AAL-SAP, using the primitives: AAL-ESTABLISH, AAL-RELEASE, AAL-DATA, and AAL-UNIT-DATA.
The AAL-ESTABLISH is issued by a signaling protocol to SAAL in order to request the establishment of a connection over the UNI to its peer protocol. This is necessary, in order for the two peer signaling protocol to exchange signaling messages. This is a reliable connection that is managed by the SSCOP as described above.
The AAL-RELEASE primitive is a request by a signaling protocol to SAAL to terminate a connection established earlier on using the AAL-ESTABLISH primitive.
The AAL-DATA primitive is used by a signaling protocol to request the transfer of a signaling message to its peer signaling protocol. Signaling messages have a specific structure, and will be discussed below in detail. Finally the AAL-UNIT-DATA is used to request a data transfer over an unreliable connection.
An example of how these primitives are used to establish a new connection over the UNI between two peer signaling protocols is shown in Figure 5.5. The primitive AAL-ESTABLISH.request is used to request SAAL to establish a connection. (In order to simplify the presentation, we do not present the signals exchanged between the SSCF and the SSCOP). In response to this request, SSCOP sends a BEGIN frame to its peer SSCOP.
ATM end-station ATM switch
Figure 5.4 The four primitive types.
SIGNALING IN ATM NETWORKS
Figure 5.5 Establishment of a connection between two peer signaling protocols.
The peer SAAL generates an AAL-ESTABLISH.indication to the peer signaling protocol, and its SSCOP returns a BEGIN ACKNOWLEDGE frame, upon receipt of which, the SAAL issues a AAL-ESTABLISH.confirm to the signaling protocol.