Download (direct link):
CPS provides a non-assured transfer of user-PDUs with any length that can vary from 1 byte to 65,535 bytes. At the receiving side, CPS can detect erroneous CPS-PDUs and it can indicate that to the higher-level application. However, since it provides a non-assured service, it does not recover erroneous CPS-PDUs by retransmission. This is left to a higher-level protocol, such as TCP. It also delivers user-PDUs in the order in which it received them.
CPS provides both message mode service and streaming mode service. In message mode, it is passed through a single user-PDU, which it transfers in a single CPS-PDU. In streaming mode, it is passed over time through several user-PDUs, which it blocks
together and transports to the destination in a single CPS-PDU.
A user-PDU is encapsulated by CPS into a CPS-PDU by adding a trailer, as shown in Figure 3.21. The following fields in the trailer have been defined:
• Padding (Pad): It can be between 0 and 47 bytes long, and is added so that the entire CPS-PDU including the padding and the remaining fields in the trailer becomes an
User-PDU Pad CPS-UU CPI Length CRC-32
Figure 3.21 Encapsulation of a user-PDU.
integer multiple of 48 bytes. The padding is made up of unused bytes that do not convey any information.
• CPS user-to-user indication (CPS-UU): A 1-byte field used to transfer transparently CPS user-to-user information.
• Common part indicator (CPI): A 1-byte field to support future AAL 5 functions.
• Length: A 2-byte field used to indicate the length in bytes of the CPS-PDU payload,
i.e. the user-PDU. The receiver can refer to this field to detect whether any information has been lost or gained.
• CRC-32: This 4-byte field contains the FCS calculated by the transmitting CPS over the entire contents of the CPS-PDU (i.e., the user-PDU, pad, CPS-UU, CPI, and length). The pattern used is: x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1.
The SAR sublayer fragments a CPS-PDU into a sequence of 48-byte segments, and each segment is carried in the payload of an ATM cell. The ATM cell that carries the last segment of a CPS-PDU is flagged by setting the SDU-type to 1 in its PTI field (see Table 3.2). Specifically, each ATM cell that carries a segment of a CPS-PDU has its SDU type indication set to 0, except the ATM cell that carries the last segment of the CPS-PDU whose PTI field contains the indication SDU type = 1.
The receiving SAR appends the payloads of the ATM cells into a buffer, associated with the VCC over which the ATM cells are being transmitted, until it either encounters an ATM cell with an indication SDU-type = 1 in its PTI field, or the CPS-PDU exceeds the buffer. Upon occurrence of either event, the buffer is passed on to a higher-level application with an indication as to whether the indication SDU-type = 1 was received or not, and in the case it was received, whether the CRC check was correct or not.
3.8 CLASSICAL IP AND ARP OVER ATM
Classical IP and ARP over ATM is a technique standardized by IETF designed to support IP over ATM in a single logical IP subnet (LIS). A LIS is a group of IP hosts that have the same IP network address, say 188.8.131.52, and the same subnet mask (see Figure 3.22(a)). Let us assume that the LANs are replaced by three interconnected ATM switches (see Figure 3.22(b)). Each host can communicate directly with any other host in the subnetwork over an ATM connection. The traditional IP model remains unchanged and the IP router is still used to connect to the outside of the subnet.
The word classical in the classical IP and ARP over ATM scheme refers to the use of ATM in support of the IP protocol stack operating in a LAN environment.
IP packets are encapsulated using the IEEE 802.2 LLC/SNAP encapsulation. The protocol used in the payload, such as IP, ARP, Appletalk, and IPX, is indicated in the LLC/SNAP header. An encapsulated packet becomes the payload of an AAL 5 frame. The maximum transfer unit (MTU) is fixed to 9180 bytes. Adding an 8-byte LLC/SNAP header makes the total at 9188 bytes, which is the defaulted size for an AAL 5 frame.
CLASSICAL IP AND ARP OVER ATM
Figure 3.22 A logical IP subnet (LIS).
Each member of the LIS is configured with an IP address and an ATM address. When communicating with another member in the same LIS over ATM, it is necessary to resolve the IP address of the destination host with its ATM address. IP addresses are resolved to ATM addresses using the ATMARP protocol within the LIS. This protocol is based on ARP, see Section 6.1.3, and it has been extended to operate over a nonbroadcast unicast ATM network. The inverse ATMARP (InATMARP) protocol is used to resolve an ATM address to an IP address. It is based on RARP (see Section 6.1.3), but has been extended to support non-broadcast unicast ATM networks.
The ATMARP protocol uses an ATMARP server which can run on an IP host or an IP router and which must be located within the LIS. The LIS members are clients to the ATMARP server, and are referred to as ATMARP clients. The ATMARP server maintains a table or a cache of IP and ATM address mappings. It learns about the IP and ATM addresses of ATMARP clients through a registration process described below. At least one ATMARP server must be configured with each LIS. The following ATMARP messages have been defined.