EUROPEAN ETS TELECOMMUNICATION August 1995 STANDARD

Transcription

1 EUROPEAN ETS TELECOMMUNICATION August 1995 STANDARD Source: ETSI TC-NA Reference: DE/NA ICS: Key words: B-ISDN, ATM Broadband Integrated Services Digital Network (B-ISDN); Asynchronous Transfer Mode (ATM) Adaptation Layer (AAL) specification - type 5 ETSI European Telecounications Standards Institute ETSI Secretariat New presentation - see History box Postal address: F Sophia Antipolis CEDEX - FRANCE Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: secretariat@etsi.fr Tel.: Fax: Copyright Notification: No part ay be reproduced except as authorized by written perission. The copyright and the foregoing restriction extend to reproduction in all edia. European Telecounications Standards Institute All rights reserved.

2 Page 2 Whilst every care has been taken in the preparation and publication of this docuent, errors in content, typographical or otherwise, ay occur. If you have coents concerning its accuracy, please write to "ETSI Editing and Standards Approval Dept." at the address shown on the title page.

3 Page 3 Contents Foreword...5 Introduction Scope Norative references Definitions Abbreviations AAL type Fraework of AAL type Inforation flow across the AAL-ATM boundary Service provided by the AAL type Description of AAL type 5 connections Priitives for the AAL type The coon part of the AAL type Services provided by the coon part of the AAL type Priitives Priitives for the CPCS of the AAL type Priitives for the data transfer service Priitives for the abort service Service provided by the SAR sublayer Priitives for the SAR sublayer of the AAL type Priitives for the data transfer service Interaction with the anageent and control plane Functions, structure, and coding of the AAL type Segentation And Reassebly (SAR) sublayer Functions of the SAR sublayer SAR-PDU structure and coding Convergence Sublayer (CS) Functions, structure, and coding for the CPCS Functions of the CPCS CPCS structure and coding Procedures Procedures of the SAR sublayer State variables of the SAR sublayer at the sender side Procedures of the SAR sublayer at the sender side State variables of the SAR sublayer at the receiver side Procedures of the SAR sublayer at the receiver side Procedures of the CPCS for the Message Mode service State variables of the CPCS at the sender side Procedures of the CPCS at the sender side State variables of the CPCS at the receiver side Procedures of the CPCS at the receiver side Suary of paraeters and values for an AAL type 5 connection...25 Annex A (inforative): Details of the data unit naing convention...26 Annex B (inforative): General fraework of the AAL type B.1 Message segentation and reassebly...28 B.2 PDU Headers, trailers and terinology...29

4 Page 4 B.3 Exaples of the segentation and reassebly process Annex C (inforative): Functional odel for the AAL type Annex D (inforative): Specification and Description Language (SDL) diagras for the SAR and the CPCS of the AAL type D.1 SDL for the SAR sublayer D.1.1 The SAR sender D.1.2 The SAR receiver D.2 SDL for the CPCS procedures D.2.1 The CPCS sender D.2.2 The CPCS receiver Annex E (inforative): Exaple CPCS-PDUs for the AAL type Annex F (norative): Protocol Ipleentation Conforance Stateent (PICS) profora F.1 Identification of the ipleentation F.2 Identification of the protocol F.3 Global stateent of conforance F.4 Capabilities F.4.1 Initiator/responder capability F.4.2 Major capabilities F Transission capabilities F Protocol paraeters for transission F PDUs for transission F Data CPCS-PDU paraeters for transission F Abort CPCS-PDU paraeters for transission F AUU-0 SAR-PDU paraeters for F transission AUU-1 SAR-PDU paraeters for transission F Receipt capabilities F Receipt tiers/ protocol paraeters for reception F Support of PDUs received F F F F Data CPCS-PDU paraeters at receipt Abort CPCS-PDU paraeters at receipt AUU 0 SAR-PDU paraeters at receipt AUU 1 SAR-PDU paraeters at receipt F Protocol error handling F.4.3 Negotiation capabilities F.4.4 Multi-layer dependencies F.4.5 Other conditions Annex G (inforative): Bibliography History... 47

5 Page 5 Foreword This European Telecounication Standard (ETS) has been prepared by the Network Aspects (NA) Technical Coittee of the European Telecounications Standards Institute (ETSI). The content of this ETS is derived fro ITU-T Recoendation I.363 [2]. This ETS constitutes one of a set of ETSs describing different Asynchronous Transfer Mode (ATM) Adaptation Layer (AAL) types. Transposition dates Date of adoption of this ETS: 28 July 1995 Date of latest announceent of this ETS (doa): 30 Noveber 1995 Date of latest publication of new National Standard or endorseent of this ETS (dop/e): 31 May 1996 Date of withdrawal of any conflicting National Standard (dow): 31 May 1996 Introduction The AAL type 5 enhances the service provided by the ATM layer to support functions required by the next higher layer. The AAL type 5 perfors functions required by the user, control and anageent planes and supports the adaptation between the ATM layer and the next higher layer. The functions perfored in the AAL type 5 depend upon the higher layer requireents. The AAL supports ultiple protocols (AAL types) to suit the needs of the different AAL service users. The service provided by the AAL type 5 to the higher layer and the functions perfored are specified in this ETS.

6 Page 6 Blank page

7 Page 7 1 Scope This European Telecounication Standard (ETS) specifies the interactions between the Asynchronous Transfer Mode (ATM) Adaptation Layer (AAL) type 5 and the next higher layer, and the AAL type 5 and the ATM layer, as well as AAL type 5 peer-to-peer operations. This ETS is applicable to variable bitrate sources where there exists no tiing relation between the source and the destination of the data. This ETS defines the coon part of AAL type 5 and can be copleented with standards for the service specific part of the convergence sublayer. 2 Norative references This ETS incorporates by dated or undated reference provisions fro other publications. These norative references are cited at the appropriate places in the text and the publications are listed hereafter. For dated references, subsequent aendents to or revisions of any of these publications apply to this ETS only when incorporated in it by aendent or revision. For undated references, the latest edition of the publication referred to applies. [1] ITU-T Recoendation I.361 (1993): "B-ISDN ATM layer specification". [2] ITU-T Recoendation I.363 (1993): "B-ISDN ATM adaptation layer specification". 3 Definitions Illustration of the data unit naing convention used in this ETS can be found in annex A. In addition, for the purposes of this ETS, the following definitions apply: essage ode: A Service Data Unit (SDU) is passed across the (sub)layer interface in exactly one Interface Data Unit (IDU) (see note). streaing ode: A SDU is passed across the (sub)layer interface in one or ore IDUs. The transfer of the IDUs across the (sub)layer ay occur separated in tie (see note). pipelining: The sending peer entity initiates the data transfer to the receiving peer entity before the coplete SDU is available (see note). NOTE: The ipleentation of these concepts is not always externally visible.

8 Page 8 4 Abbreviations For the purposes of this ETS, the following abbreviations apply: AAL AAL-IDU AAL-SAP AAL-SDU ATM ATM-SDU AUU CLP CPCS CPCS-CI CPCS-IDU CPCS-LP CPCS-PDU CPCS-SDU CPCS-UU CPI CRC CS ID IDU LP M MM Pad PICS PT QoS RS SAP SAR SAR-CI SAR-IDU SAR-LP SAR-PDU SAR-SDU SDU SDL SM SSCS SSCS-PDU ATM Adaptation Layer AAL type 5 IDU AAL Service Access Point AAL type 5 Service Data Unit Asynchronous Transfer Mode ATM Service Data Unit ATM-layer-User to ATM-layer-User indication Cell Loss Priority Coon Part Convergence Sublayer CPCS-Congestion Indication CPCS Interface Data Unit CPCS-Loss Priority CPCS Protocol Data Unit CPCS Service Data Unit CPCS-User to User indication Coon Part Indicator Cyclic Redundancy Check Convergence Sublayer Interface Data Interface Data Unit Loss Priority More Message Mode Padding Protocol Ipleentation Conforance Stateent Payload Type Quality of Service Reception Status Service Access Point Segentation And Reassebly SAR-Congestion Indication SAR IDU SAR-Loss Priority SAR Protocol Data Unit SAR Service Data Unit Service Data Unit Specification and Description Language Streaing Mode Service Specific CS SSCS Protocol Data Unit

9 Page 9 5 AAL type Fraework of AAL type 5 The Convergence Sublayer (CS) has been subdivided into the Coon Part CS (CPCS) and the Service Specific CS (SSCS) as shown in figure 1 (further clarification can be found in annex C). Different SSCS protocols, to support specific AAL type 5 user services, or groups of services, ay be defined. The SSCS ay also be null, in the sense that it only provides for the apping of the equivalent priitives of the AAL type 5 to CPCS and vice-versa. SSCS protocols are specified in separate ETSs. The description contained in this ETS defines the functional behaviour of the AAL type 5 coon part and does not preclude any ipleentation as long as the external behaviour of the ipleentation follows this ETS. The separation of the functionality between SAR and CPCS is arbitrary and is not visible to the outside. The allocation of functions to the two sublayers has been ade in order to siplify the description. SAP Service Specific CS (ay be Null) SSCS Priitives CS AAL Coon Part CS CPCS Priitives SAR SAR SAP Figure 1: Structure of the AAL type 5

10 Page Inforation flow across the AAL-ATM boundary The AAL type 5 akes use of the ATM layer services as defined in ITU-T Recoendation I.361 [1]. NOTE: The addition of the "Received Loss Priority" paraeter in the ATM-DATA-indication priitive as agreed by CCITT SG XVIII in January 1993 is assued. 5.3 Service provided by the AAL type 5 The AAL type 5 provides the capabilities to transfer the AAL type 5 Service Data Unit (AAL-SDU) fro one AAL type 5 user to another AAL type 5 user through the ATM network. The Message Mode service, Streaing Mode service, and assured and non-assured operations as defined below for AAL type 5 are identical to those defined for AAL type 3/4 (see ETS ). Two odes of service are defined: Message and Streaing: a) Message Mode service: the AAL-SDU is passed across the AAL type 5 interface in exactly one AAL type 5 Interface Data Unit (AAL-IDU). This service provides the transport of fixed size or variable length AAL-SDUs: 1) in case of short fixed size AAL-SDUs an internal blocking/deblocking function in the SSCS ay be applied; it provides the transport of one or ore fixed size AAL-SDUs in one SSCS Protocol Data Unit (SSCS-PDU); 2) in case of variable length AAL-SDUs an internal AAL-SDU essage segentation/reassebling function in the SSCS ay be applied. In this case, a single AAL-SDU is transferred in one or ore SSCS-PDUs; 3) where the above options are not used, a single AAL-SDU is transferred in one SSCS-PDU. When the SSCS is null, the AAL-SDU is apped to one CPCS Service Data Unit (CPCS-SDU); b) Streaing Mode service: the AAL-SDU is passed across the AAL type 5 interface in one or ore AAL-IDU. The transfer of these AAL-IDUs across the AAL type 5 interface ay occur separated in tie. This service provides the transport of variable length AAL-SDUs: 1) an internal AAL-SDU essage segentation/reassebling function in the SSCS ay be applied. In this case all the AAL-IDUs belonging to a single AAL-SDU are transferred in one or ore SSCS-PDU; 2) an internal pipelining function ay be applied. It provides the eans by which the sending AAL type 5 entity initiates the transfer to the receiving AAL type 5 entity before it has the coplete AAL-SDU available; 3) where option 1) is not used, all the AAL-IDUs belonging to a single AAL-SDU are transferred in one SSCS-PDU. When the SSCS is null, the AAL-IDUs belonging to a single AAL-SDU are apped to one CPCS-SDU. The Streaing Mode service includes an abort service by which the discarding of an AAL-SDU partially transferred across the AAL type 5 interface can be requested. Suaries of the service ode and feature options are provided in tables 1 and 2. NOTE: An end-to-end specification of the SDU length in Message Mode with Blocking/Deblocking is needed.

11 Message Option 1 Option 2 Table 1: Cobination of service ode and internal function AAL-SDU Message Segentation/reassebly in the SSCS AAL-SDU Message Blocking/deblocking in the SSCS Page 11 Pipelining O N/A N/A O Streaing O N/A O Option 1: Long variable size SDUs O: Optional Option 2: Short fixed size SDUs N/A: Not Applicable N/A N/A Table 2: Cobination of service ode at the sender and receiver side Receiver Sender MM/Blocking MM/Segentation SM MM/Deblocking A N/A N/A MM/Reassebly N/A A A SM N/A A A MM: Message Mode A: Applicable SM: Streaing Mode N/A: Not Applicable Both odes of service ay offer the following peer-to-peer operational procedures: - assured operations: every assured AAL-SDU is delivered with exactly the data content that the user sent. The assured service is provided by retransission of issing or corrupted SSCS-PDUs. Flow control is provided as a andatory feature. The assured operation ay be restricted to point-to-point AAL type 5 connections; - non-assured operations: integral AAL-SDUs ay be lost or corrupted. Lost and corrupted AAL-SDUs are not corrected by retransission. An optional feature ay be provided to allow corrupted AAL-SDUs to be delivered to the user (i.e. optional delivery of corrupted data). Flow control ay be provided as an option Description of AAL type 5 connections The AAL type 5 provides the capabilities to transfer the AAL-SDU fro one AAL Service Access Point (AAL-SAP) to one other AAL-SAP through the ATM network (see figure 2). The AAL type 5 users have the capability to select a given AAL-SAP associated with the Quality of Service (QoS) required to transport that AAL-SDU (for exaple, delay and loss sensitive QoS). The AAL type 5 akes use of the service provided by the underlying ATM layer (see figure 3). Multiple AAL type 5 connections ay be associated with a single ATM layer connection, allowing ultiplexing at the AAL type 5; however, if ultiplexing is used in the AAL type 5, it occurs in the SSCS. The AAL type 5 user selects the QoS provided by the AAL type 5 through the choice of the AAL-SAP used for data transfer.

12 Page 12 AAL-SAP AAL-SAP AAL-Connection AAL ATM AAL-Entity Point-to-point ATM Layer Connection AAL-Entity Priitives for the AAL type 5 Figure 2: Point-to-Point AAL type 5 connection These priitives are service specific and are contained in separate Standards on SSCS protocols. The SSCS ay be null, in the sense that it only provides for the apping of the equivalent priitives of the AAL type 5 to CPCS and vice-versa. In this case, the priitives for the AAL type 5 are equivalent to those for the CPCS (subclause ) but identified as AAL-UNITDATA-request, AAL-UNITDATAindication, AAL-U-Abort-request, AAL-U-Abort-indication and AAL-P-Abort-indication, consistent with the priitive naing convention at a Service Access Point (SAP). AAL-SAP 1 AAL-SAP 2 AAL-SAP 3 (QOS1) (QOS2) (QOS3) Service provided to the AAL-users (NOTE) ATM-SAP AAL Layer ATM Layer ATM-SAP n Makes use of the underlying ATM Layer service NOTE: If ultiplexing is present at the AAL type 5, it occurs in the SSCS. Figure 3: Relation between AAL-SAP and ATM-SAP

13 Page 13 6 The coon part of the AAL type Services provided by the coon part of the AAL type 5 Two odes of service are defined, essage and streaing: a) Message Mode service: The CPCS Service Data Unit is passed across the CPCS interface in exactly one CPCS-IDU. This service provides the transport of fixed size or variable length CPCS-SDUs. A single CPCS-SDU is transferred in one CPCS Protocol Data Unit (CPCS-PDU); b) Streaing Mode service: The CPCS-SDU is passed across the CPCS interface in one or ore CPCS-IDUs. The transfer of these CPCS-IDUs across the CPCS interface ay occur separated in tie. This service provides the transport of variable length CPCS-SDUs. The Streaing Mode service includes an abort service by which the discarding of an CPCS-SDU partially transferred across the CPCS interface can be requested. An internal pipelining function ay be applied. It provides the eans by which the sending CPCS entity initiates the transfer to the receiving CPCS entity before it has the coplete CPCS-SDU available. All the CPCS-IDUs belonging to a single CPCS-SDU are transferred in one CPCS-PDU. NOTE: Figures A.2.a) and A.2.d) of annex A illustrate the Message Mode and Streaing Mode services. The following peer-to-peer operational procedure is offered: - non-assured operations: integral CPCS-SDUs ay be lost or corrupted. Lost and corrupted CPCS-SDUs will not be corrected by retransission. An optional feature ay be provided to allow corrupted CPCS-SDUs to be delivered to the user (i.e. optional delivery of corrupted data) Priitives The functional odel for the AAL type 5 as contained in annex C shows the interrelation between the Segentation And Reassebly (SAR) sublayer, CPCS and SSCS and the SAR and CPCS priitives. CPCS and SAR connection establishent and release can be done via signalling, anageent or prearrangeent. The CPCS connection and the corresponding SAR connection are established siultaneously. There is no provision for CPCS or SAR connection establishent and release in the CPCS or the SAR protocol Priitives for the CPCS of the AAL type 5 As there exists no SAP between the sublayers of the AAL type 5, the priitives are called "invoke" and "signal" instead of the conventional "request" and "indication" to highlight the absence of the SAP.

14 Page Priitives for the data transfer service CPCS-UNITDATA-invoke and CPCS-UNITDATA-signal. These priitives are used for the data transfer. The following paraeters are defined: - Interface Data (ID). This paraeter specifies the Interface Data Unit (IDU) exchanged between the CPCS and the SSCS entity. The ID is an integral ultiple of one octet. If the CPCS entity is operating in the Message Mode service, the ID represents a coplete CPCS-SDU; when operating in the Streaing Mode service, the ID does not necessarily represent a coplete CPCS-SDU. When the corrupted data delivery option is used, the ID paraeter ay be epty; - More (M). In the Message Mode service, this paraeter is not used. In the Streaing Mode service, this paraeter specifies whether the ID counicated contains a beginning / continuation of a CPCS-SDU or the end of / coplete CPCS-SDU; - CPCS Loss Priority (CPCS-LP). This paraeter indicates the loss priority for the associated CPCS-SDU. It can take only two values, one for high priority and the other for low priority. In Streaing Mode, this paraeter is andatory with the first invoke priitive related to a certain CPCS-SDU; otherwise, it is ignored and ay be absent. At the receiving side, this paraeter is only present with the last signal priitive related to a certain CPCS-SDU. This paraeter is apped to and fro the SAR Loss Priority (SAR-LP) paraeter. In general, this paraeter has no end-to-end significance; - CPCS Congestion Indication (CPCS-CI). This paraeter indicates whether the associated CPCS-SDU has experienced congestion. In Streaing Mode, this paraeter is andatory with the first invoke priitive related to a certain CPCS-SDU; otherwise, it is not present. At the receiving side, this paraeter is only present with the last signal priitive related to a certain CPCS-SDU. This paraeter is apped to and fro the SAR-Congestion Indication (SAR-CI) paraeter; - CPCS User to User indication (CPCS-UU). This paraeter is transparently transported by the CPCS between peer CPCS users. In Streaing Mode, this paraeter is andatory with the last invoke priitive related to a certain CPCS-SDU; otherwise, it is not present. At the receiving side, this paraeter is only present with the last signal priitive related to a certain CPCS-SDU; - Reception Status (RS). This paraeter indicates whether or not the associated CPCS-SDU delivered ay be corrupted. This paraeter is only utilized if the corrupted data delivery option is used. In Streaing Mode, this paraeter is only present with the last signal priitive related to a certain CPCS-SDU. Depending on the service ode (Message Mode or Streaing Mode service, discarding or delivery of errored inforation), not all paraeters are required. This is suarized in table 3.

15 Page 15 Table 3: Paraeters of the CPCS-UNITDATA Paraeter Type MM SM Coents Interface Data (ID) invoke whole or partial CPCS-SDU signal More (M) invoke signal - - M = 0: end of CPCS-SDU M = 1: not end of CPCS-SDU CPCS-Loss priority (CPCS-LP) invoke signal 1 2 apped to and fro the ATM layer's CLP field CPCS-LP = 1: Low priority CPCS-Congestion Indication (CPCS-CI) invoke signal CPCS-User to User Indication (CPCS-UU) invoke signal Reception Status (RS) invoke (note) signal MM: Message Mode service CPCS-LP = 0: High priority apped to and fro the ATM layer's Congestion Indication paraeter CPCS-CI = 1: Congestion experienced CPCS-CI = 0: No congestion experienced transparently transported by the CPCS indication of corrupted data SM: Streaing Mode service. : andatory. -: not present. 1 : 2 : andatory with the first invoke or signal priitive related to a certain CPCS-SDU, otherwise absent. andatory with the last invoke or signal priitive related to a certain CPCS-SDU, otherwise absent. NOTE: Not present if the corrupted data delivery option is not used Priitives for the abort service These priitives are used in the Streaing Mode service: a) CPCS-U-Abort-invoke and CPCS-U-Abort-signal. This priitive is used by the CPCS user to invoke the abort service. It is also used to signal to the CPCS user that a partially delivered CPCS-SDU is to be discarded by instruction fro its peer entity. No paraeters are defined. This priitive is not used in Message Mode; b) CPCS-P-Abort-signal. This priitive is used by the CPCS entity to signal to its user that a partially delivered CPCS-SDU is to be discarded due to the occurrence of soe error in the CPCS or below. No paraeters are defined. This priitive is not used in Message Mode.

16 Page Service provided by the SAR sublayer Two odes of service are defined: essage and streaing: a) Message Mode service: the SAR Service Data Unit (SAR-SDU) is passed across the SAR interface in exactly one SAR-IDU. This service provides the transport of fixed size or variable length SAR-SDUs. A single SAR-SDU is transferred in one or ore SAR Protocol Data Units (SAR-PDUs); b) Streaing Mode service: the SAR-SDU is passed across the SAR interface in one or ore SAR-IDUs. The transfer of these SAR-IDUs across the SAR interface ay occur separated in tie. This service provides the transport of variable length SAR-SDUs. The SAR receiver always operates in Streaing Mode. An internal pipelining function is applied. It provides the eans by which the sending SAR entity initiates the transfer to the receiving SAR entity before it has the coplete SAR-SDU available. Figure A.2.d) of annex A illustrates the Streaing Mode service. The following peer-to-peer operational procedure is offered: - non-assured operations. Integral SAR-SDUs ay be lost or corrupted. Lost and corrupted SAR-SDUs will not be corrected by retransission. An optional feature ay be provided to allow corrupted SAR-SDUs to be delivered to the user (i.e. optional delivery of corrupted data) Priitives for the SAR sublayer of the AAL type 5 These priitives odel the exchange of inforation between the SAR sublayer and the CPCS. As there exists no SAP between the sublayers of the AAL type 5, the priitives are called "invoke" and "signal" instead of the conventional "request" and "indication" to highlight the absence of the SAP Priitives for the data transfer service SAR-UNITDATA-invoke and SAR-UNITDATA-signal. These priitives are used for the data transfer. The following paraeters are defined: NOTE: It is assued that the SAR sender operates in Streaing Mode. - Interface Data (ID). This paraeter specifies the IDU exchanged between the SAR and the CPCS entity. The ID is an integral ultiple of 48 octets. The ID does not necessarily represent a coplete SAR-SDU; - More (M). This paraeter specifies whether the ID counicated contains the end of the SAR-SDU; - SAR-Loss Priority (SAR-LP). This paraeter indicates the loss priority for the associated SAR ID. It can take only two values, one for high priority, and the other for low priority. This paraeter is apped to the ATM layer's Subitted Loss Priority paraeter and fro the ATM layer's Received Loss Priority paraeter; - SAR-Congestion Indication (SAR-CI). This paraeter indicates whether the associated SAR ID has experienced congestion. This paraeter is apped to and fro the ATM layer's Congestion Indication paraeter.

17 Page 17 The usage of the paraeters is suarized in table 4. Table 4: Paraeters of the SAR-UNITDATA Paraeter Type Coents Interface Data (ID) invoke whole or partial SAR-SDU signal More (M) invoke signal M = 0: end of SAR-PDU M = 1: not end of SAR-PDU SAR-Loss Priority (SAR-LP) invoke signal apped to and fro the ATM layer's CLP field SAR-LP = 1: Low priority SAR-Congestion Indication (SAR-CI) : andatory. invoke signal SAR-LP = 0: High priority apped to and fro the ATM layer's Congestion Indication paraeter SAR-CI = 1: Congestion experienced SAR-CI = 0: No congestion experienced 6.2 Interaction with the anageent and control plane Currently, no interactions with the anageent and control plane are standardized. 6.3 Functions, structure, and coding of the AAL type Segentation And Reassebly (SAR) sublayer Functions of the SAR sublayer The SAR sublayer functions are perfored on a SAR-PDU basis. The SAR sublayer accepts variable length SAR-SDUs which are integral ultiples of 48 octets fro the CPCS and generates SAR-PDUs containing 48 octets of SAR-SDU data. a) Preservation of SAR-SDU. This function preserves the SAR-SDU by providing for an "end of SAR-SDU" indication. b) Handling of congestion inforation. This function provides for the passing of congestion inforation between the layers above the SAR sublayer and the one below in both directions. c) Handling of loss priority inforation. This function provides for the passing of cell loss priority inforation between the layers above the SAR sublayer and the one below in both directions. d) SAR-SDU sequence integrity. This function assures that the sequence of SAR-SDUs is aintained within one SAR connection. e) Mapping between SAR connections and ATM connections. This function provides for the one-to-one apping between SAR connections and ATM connections. Neither SAR connection ultiplexing nor splitting is provided.

18 Page SAR-PDU structure and coding The SAR sublayer functions utilize the ATM-layer-user to ATM-layer-user indication (AUU) paraeter of the ATM layer priitives to indicate that a SAR-PDU contains the end of a SAR-SDU. A SAR-PDU where the value of the AUU paraeter is "1" indicates the end of a SAR-SDU; the value of "0" indicates the beginning or continuation of a SAR-SDU. The structure of the SAR-PDU is illustrated in figure 4. Cell Header PT SAR-PDU Payload SAR-PDU PT: NOTE: Payload Type The Payload Type field belongs to the ATM header. It conveys the value of the AUU paraeter end-to-end Convergence Sublayer (CS) Figure 4: SAR-PDU forat for the AAL type Functions, structure, and coding for the CPCS The CPCS has the following service characteristics: - non-assured data transfer of user data fraes with any length easured in octets fro 1 to octets. In addition, an independent octet of user to user inforation per frae is transferred; - the CPCS connection is established by anageent or by the control plane; - error detection and indication (bit error and cell loss or gain); - CPCS-SDU sequence integrity on each CPCS connection Functions of the CPCS The CPCS functions are perfored per CPCS-PDU. The CPCS provides several functions in support of the CPCS service user. The functions provided depend on whether the CPCS service user is operating in Message Mode or Streaing Mode: a) Message Mode service: the CPCS-SDU is passed across the CPCS interface in exactly one CPCS-IDU. This service provides the transport of a single CPCS-SDU in one CPCS-PDU; b) Streaing Mode service: the CPCS-SDU is passed across the CPCS interface in one or ore CPCS-IDUs. The transfer of these CPCS-IDUs across the CPCS interface ay occur separated in tie. - General description: This service provides the transport of all the CPCS-IDUs belonging to a single CPCS-SDU within one CPCS-PDU. - Pipelining function: An internal pipelining function in the CPCS ay be applied which provides the eans by which the sending CPCS entity initiates the transfer to the receiving CPCS entity before it has the coplete CPCS-SDU available. - Abort service: The Streaing Mode service includes an abort service by which the discarding of a CPCS-SDU partially transferred across the interface can be requested. NOTE: At the sending side, parts of the CPCS-PDU ay have to be buffered if the restriction (i.e. that SAR ID are a ultiple of 48 octets, see subclause ) cannot be satisfied.

19 Page 19 The functions ipleented by the CPCS include: 1) preservation of CPCS-SDU. This function provides for the delineation and transparency of CPCS-SDUs; 2) preservation of CPCS user to user inforation. This function provides for the transparent transfer of CPCS user to user inforation; 3) error detection and handling. This function provides for the detection and handling of CPCS-PDU corruption. By default, corrupted CPCS-SDUs are discarded. A CPCS receiver ay provide the local option to deliver corrupted CPCS-SDU to the SSCS (i.e. optional delivery of corrupted data). When the corrupted data delivery option is used, an error status indication is associated with the delivery. Even if the errored delivery service is used, CPCS-SDUs ay be lost without notice. Exaples of detected errors include: received length and CPCS-PDU Length field isatch including buffer overflow, and CPCS Cyclic Redundancy Check (CRC) errors; 4) abort. This function provides for the eans to abort a partially transitted CPCS-SDU. This function is indicated in the Length field; 5) padding. This function provides for the padding of the CPCS-PDUs to an integral ultiple of 48 octets and for the location of the CPCS-PDU trailer in the last 8 octets of the CPCS-PDU; 6) handling of congestion inforation. This function provides for the passing of congestion inforation between the layers above the CPCS and the one below in both directions; 7) handling of loss priority inforation. This function provides for the passing of cell loss priority inforation between the layers above the CPCS and the one below in both directions; 8) CPCS-SDU sequence integrity. This function assures that the sequence of CPCS-SDUs is aintained within one CPCS connection; 9) apping between CPCS connections and SAR connections. This function provides for the one-to-one apping between CPCS connections and SAR connections. Neither CPCS connection ultiplexing nor splitting is provided.

20 Page CPCS structure and coding The CPCS functions require an 8 octet CPCS-PDU Trailer. The CPCS-PDU Trailer is always located in the last 8 octets of the last SAR-PDU of the CPCS-PDU. Therefore, a padding field provides for a 48 octet alignent of the CPCS-PDU. The CPCS-PDU Trailer together with the padding field and the CPCS-PDU payload coprise the CPCS-PDU. The sizes and positions of fields for the CPCS-PDU structure are given in figure 5. CPCS-PDU payload (CPCS-SDU) Pad CPCS-PDU trailer CPCS-UU CPI Length CRC CPCS-PDU Trailer CPCS-PDU Pad: CPCS-UU: CPI: Length: CRC: Padding CPCS User-to-User Indication Coon Part Indicator Length of CPCS-SDU Cyclic Redundancy Check ( ( ( ( ( octets ) octet ) octet ) octets ) octets ) Figure 5: CPCS-PDU forat for the AAL type 5 The coding of the CPCS-PDU confors to the coding conventions specified in ITU-T Recoendation I.361 [1], 2.1: a) CPCS-PDU payload. The CPCS-PDU payload is the CPCS-SDU. The field can be fro 1 to octets in length; b) Padding (Pad) field. Between the end of the CPCS-PDU payload and the CPCS-PDU trailer, there are fro 0 to 47 unused octets. These unused octets are called the Padding (Pad) field; they are strictly used as filler octets and do not convey any inforation. Any coding is acceptable. This padding field copleents the CPCS-PDU (including CPCS-PDU payload, Padding field, and CPCS-PDU Trailer) to an integral ultiple of 48 octets. The function of the Pad field is shown in figure 6.

21 Page 21 ultiple of 48 octets 48 octets CPCS payload CPCS trailer Pad = 1 octet CPCS payload CPCS trailer Pad = 0 octets CPCS payload Pad Pad Pad Pad = 7+40 octets CPCS trailer Pad Padding field Figure 6: Exaples of the Pad field function c) CPCS-UU field. The CPCS-UU field is used to transparently transfer CPCS user to user inforation; d) Coon Part Indicator (CPI) field. The value CPI="0" indicates that the field is only used to align the length of the CPCS-PDU trailer to 64 bits. Possible additional functions and corresponding codings ay include identification of layer anageent essages; e) Length field. The Length field is used to encode the length of the CPCS-PDU payload field. The Length field value is also used by the receiver to detect the loss or gain of inforation. The length is binary encoded as nuber of octets. A Length field coded as zero is used for the abort function; f) CRC field. The CRC-32 is used to detect bit errors in the CPCS-PDU. The CRC field is filled with the value of a CRC calculation which is perfored over the entire contents of the CPCS-PDU, including the CPCS-PDU payload, the Pad field, and the first 4 octets of the CPCS-PDU Trailer. The CRC field shall contain the ones copleent of the su (odulo 2) of: 1) the reainder of x k (x 31 + x x + 1) divided (odulo 2) by the generator polynoial, where k is the nuber of bits of the inforation over which the CRC is calculated; and 2) the reainder of the division (odulo 2) by the generator polynoial of the product of x 32 by the inforation over which the CRC is calculated. The CRC-32 generator polynoial is: G(x) = x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 11 + x 10 + x 8 + x 7 + x 5 + x 4 + x 2 + x + 1 The result of the CRC calculation is placed with the least significant bit right justified in the CRC field.

22 Page 22 As a typical ipleentation at the transitter, the initial content of the register of the device coputing the reainder of the division is pre-set to all "1's" and is then odified by division by the generator polynoial (as described above) of the inforation over which the CRC is to be calculated; the ones copleent of the resulting reainder is put into the CRC field. As a typical ipleentation at the receiver, the initial content of the register of the device coputing the reainder of the division is pre-set to all "1's". The final reainder, after ultiplication by x 32 and then division (odulo 2) by the generator polynoial of the serial incoing CPCS-PDU, will be (in the absence of errors): C(x) = x 31 +x 30 +x 26 +x 25 +x 24 +x 18 +x 15 +x 14 +x 12 +x 11 +x 10 +x 8 +x 6 +x 5 +x 4 +x 3 +x+1 An exaple of the CRC calculation is given in annex E. 6.4 Procedures No procedures describing the delivery of errored inforation are standardized Procedures of the SAR sublayer The structure and coding of the SAR-PDU is defined in subclause State variables of the SAR sublayer at the sender side The SAR sender aintains no state variables Procedures of the SAR sublayer at the sender side The state achine of the SAR sender is shown in figure 7. IDLE SAR-UNITDATA-invoke Table 5 defines the state for the SAR sender. Figure 7: State transition diagra for the SAR Sender Table 5: State definition for the SAR sender State IDLE Definition Waiting to begin or continue to transit a SAR-SDU 1) Upon receiving a SAR-UNITDATA-invoke priitive fro the CPCS, the SAR sender shall start the segenting process. If the ID has a length of ore than 48 octets, the SAR sender generates ore than one SAR-PDU. In all SAR-PDUs, the SAR-PDU payload field shall be filled with 48 octets of CPCS-PDU inforation. 2) If the More paraeter in the SAR-UNITDATA-invoke priitive has the value "0", the SAR sender shall set the AUU paraeter in the ATM-DATA-request priitive for the last SAR-PDU generated fro the ID to "1"; in all other cases (i.e. the More paraeter has the value "1" or the ATM-DATArequest priitive does not contain the last data generated fro the ID), it shall set the AUU paraeter to "0". 3) In all ATM-DATA-request priitives, the Subitted CLP and Congestion Indication paraeters shall be set to the sae value as the SAR-LP and SAR-CI paraeters, respectively, in the received SAR-UNITDATA-invoke priitive.

23 Page State variables of the SAR sublayer at the receiver side The SAR receiver aintains no state variables Procedures of the SAR sublayer at the receiver side The state achine of the SAR receiver is shown in figure 8. IDLE ATM-DATA-indication Table 6 defines the state for the SAR receiver. Figure 8: State transition diagra for the SAR receiver Table 6: State definition for the SAR receiver State IDLE Definition Waiting to begin or continue to receive a SAR-SDU 1) Upon receipt of an ATM-DATA-indication priitive, the 48 octet SAR-PDU payload is sent to the CPCS. If the AUU paraeter in the ATM-DATA-indication priitive is set to "1", the More paraeter is set to "0"; otherwise, the More paraeter is set to "1". 2) In all SAR-UNITDATA-signal priitives, the SAR-CI and the SAR-LP paraeters shall be set to the sae value as the Congestion Indication and the Received Loss Priority paraeters, respectively, in the received ATM-DATA-indication priitive Procedures of the CPCS for the Message Mode service No procedures for the CPCS operating in Streaing Mode are standardized. The structure and coding of the CPCS-PDU is defined in subclause State variables of the CPCS at the sender side The CPCS sender aintains no state variables Procedures of the CPCS at the sender side The state achine of the CPCS sender is shown in figure 9. IDLE CPCS-UNITDATA-DATA-invoke Table 7 defines the state for the CPCS sender. Figure 9: State transition diagra for the CPCS sender Table 7: State definition for the CPCS sender State IDLE Definition Waiting to transit a new CPCS-PDU

24 Page 24 Upon reception of a CPCS-UNITDATA-invoke priitive, the CPCS-PDU is constructed as described in subclause , and the CPCS-PDU is passed to the SAR sublayer in a SAR-UNITDATA-invoke priitive with the More paraeter set to "0". The SAR-LP and the SAR-CI paraeters are set to the value of the CPCS-LP and the CPCS-CI paraeters, respectively, of the CPCS-UNITDATA-invoke priitive. The CPCS-UU field is assigned the value of the CPCS-UU paraeter State variables of the CPCS at the receiver side The CPCS receiver aintains the following state variable: rcv_lp. The rcv_lp variable is initially set to "0" and reinitialized at the beginning of the handling of a CPCS-PDU. If any SAR-LP paraeter is set to "1", this variable is set to "1". It is used to set the CPCS-LP paraeter in the CPCS-UNITDATA-signal priitive Procedures of the CPCS at the receiver side The following procedures are specified for a CPCS receiver that does not deliver errored data to the receiving CPCS user. The CPCS receiver aintains the following paraeter: Max_SDU_Deliver_Length. This paraeter indicates the axiu size SDU (in octets) that ay be delivered to a CPCS user. At a receiver, the value of this paraeter is copared to the length of each CPCS-SDU before it is delivered. Any CPCS-SDU that has a length greater than Max_SDU_Deliver_Length is discarded and the event is reported to layer anageent. This paraeter can take on any integer value fro 1 to 65'535 and is set by the anageent plane. The state achine of the CPCS receiver is shown in figure 10. IDLE SAR-UNITDATA-signal tier expiry Figure 10: State transition diagra for the CPCS receiver Table 8 defines the state for the CPCS receiver. Table 8: State definition for the CPCS receiver State IDLE Definition Waiting to begin or continue to reasseble a CPCS-PDU NOTE: This procedure description ay copy up to 47 octets of the Pad field into the reassebly buffer before processing the CPCS-PDU trailer. 1) When the CPCS receiver receives a SAR-UNITDATA-signal priitive fro the SAR sublayer, it shall copy the ID to the reassebly buffer. If the SAR-LP paraeter is set to "1", the variable rcv_lp is also set to "1". 2) If the More paraeter of the SAR-UNITDATA-signal priitive is "1" and the received nuber of octets in the reassebly buffer of the CPCS-SDU is greater than the value of the paraeter Max_SDU_Deliver_Length + 7, the CPCS receiver shall discard any inforation in the reassebly buffer.

25 Page 25 3) If the More paraeter of the SAR-UNITDATA-signal priitive is "0", the last 8 octets of the ID represent the CPCS-PDU trailer. If the CRC calculation perfored on the coplete CPCS-PDU as specified in subclause and the value in the CRC field indicate the presence of errors, any inforation in the reassebly buffer shall be discarded. 4) If the value in the CPI field is not valid, any inforation in the reassebly buffer shall be discarded. 5) If the Length field of the CPCS-PDU trailer is coded as "0", any inforation in the reassebly buffer shall be discarded. 6) The Length field of the CPCS-PDU trailer is used to deterine the length of the Pad field (length of received CPCS-PDU inus eight and inus the content of the Length field). If the Pad field is longer than 47 octets or not enough data has been received, any inforation in the reassebly buffer shall be discarded. 7) If the CPCS-SDU is longer than Max_SDU_Deliver_Length, any inforation in the reassebly buffer shall be discarded. 8) After the receipt of a SAR-UNITDATA-signal priitive with the More paraeter set to "0" and the data has not been discarded, any CPCS-SDU data in the reassebly buffer shall be delivered to the CPCS user via a CPCS-UNITDATA-signal priitive. The CPCS-LP paraeter shall be set to the value of the variable rcv_lp. The CPCS-CI paraeter shall be set to the value of the SAR-CI paraeter received with the last SAR-UNITDATA-signal priitive. The CPCS-UU paraeter shall be set to the value of the CPCS-UU field of the CPCS-PDU trailer. Data that is delivered is reoved fro the reassebly buffer. 9) Whenever inforation fro the reassebly buffer is delivered or discarded, the variable rcv_lp is reset to "0". A CPCS receiver ay optionally ipleent a reassebly tier. If a reassebly tier is supported, the following procedures apply: 10) When the CPCS receiver receives a SAR-UNITDATA-signal priitive fro the SAR sublayer with the More paraeter set to "1", the reassebly tier shall be (re-)started. 11) When the CPCS receiver receives a SAR-UNITDATA-signal priitive fro the SAR sublayer with the More paraeter set to "0", the reassebly tier shall be stopped. 12) If the tier expires, the CPCS receiver shall discard any inforation in the reassebly buffer. NOTE: The initialization value of a reassebly tier is not indicated to the corresponding CPCS sender(s). Neither an initialization value for the reassebly tier nor a forula to deterine it fro, e.g., ATM layer connection characteristics and/or AAL type 5 user requireents is standardized Suary of paraeters and values for an AAL type 5 connection The inforation in table 9 shall be known at AAL type 5 connection establishent. Table 9: Paraeters and options for the AAL type 5 Significance Option/Paraeter Legal values peer-to-peer Max_SDU_Deliver_Length 1 to 65'535 octets local (receiver) corrupted SDU delivery no / yes use and value of reassebly tier no / yes and value

26 Page 26 Annex A (inforative): Details of the data unit naing convention AAL-SAP AAL-SDU Service Specific Convergence Sublayer (SSCS) SSCS-PDU Header SSCS-PDU payload SSCS-PDU trailer SSCS SSCS-PDU No SAP defined between SSCS and CPCS Coon Part Convergence Sublayer (CPCS) CPCS-SDU CPCS-PDU payload CPCS-PDU trailer CPCS AAL CPCS-PDU No SAP defined between CPCS and SAR Segentation and Reassebly (SAR) Sublayer AUU SAR-PDU payload SAR-PDU SAR ATM-SAP ATM-SDU ATM Layer Cell header AUU Cell inforation field (Cell payload) ATM ATM-PDU = Cell Figure A.1: Data unit naing conventions for the AAL type 5

27 Page 27 AAL-SDU AAL-IDU AAL Interface H T a) Message ode service SSCS-PDU (note) AAL-SDU AAL-SDU AAL-SDU AAL-IDU AAL-IDU AAL-IDU AAL Interface H T SSCS-PDU (note) b) Message ode service plus blocking/deblocking internal function AAL-SDU AAL-IDU AAL Interface H T H T H T SSCS-PDU (note) SSCS-PDU (note) SSCS-PDU (note) c) Message Mode service plus segentation/reassebly internal function AAL-SDU AAL-IDU AAL-IDU AAL-IDU AAL-IDU AAL-IDU AAL Interface H T SSCS-PDU (note) d) Streaing Mode service AAL-SDU AAL-IDU AAL-IDU AAL-IDU AAL-IDU AAL-IDU AAL-IDU AAL Interface H T H T H T SSCS-PDU (note) SSCS-PDU (note) SSCS-PDU (note) e) Streaing Mode service plus segentation/reassebly internal function NOTE: The structure of the SSCS-PDU is for further study. Figure A.2: Message Mode and Streaing Mode of service at the AAL type 5 interface cobined with blocking/deblocking or segentation/reassebly internal function

28 Page 28 Annex B (inforative): General fraework of the AAL type 5 This annex provides a description of the general fraework of the AAL type 5 including SAR and CPCS PDU forats. B.1 Message segentation and reassebly Figure B.1 provides a generic interpretation of the segenting of a SAR-SDU (essage) into SAR-PDUs where the AUU bit in the header of the associated ATM Service Data Unit (ATM-SDU) is set to "0" and the last SAR-PDU where the AUU bit is set to "1". SAR-SDU (Message) AUU=0 "segent" AUU=0 "segent" AUU=0 "segent" AUU=1 "segent" Figure B.1: Message segentation and reassebly

29 Page 29 B.2 PDU Headers, trailers and terinology Figure B.2 builds on the generic view of essage segentation of figure A.1 to incorporate the relevant PDU headers and trailers and appropriate terinology on the basis of the AUU bit being set to "0" or "1". CPCS-SDU CPCS-PDU Payload Pad CPCS-PDU trailer CPCS-PDU AUU 0 SAR-PDU Payload SAR-PDU AUU 0 SAR-PDU Payload SAR-PDU AUU 0 SAR-PDU Payload SAR-PDU AUU 1 SAR-PDU Payload SAR-PDU ATM-SDU Cell Header Cell Inforation Field Pad: Padding ATM-PDU = Cell Figure B.2: PDU headers, trailers and terinology

30 Page 30 B.3 Exaples of the segentation and reassebly process Figure B.3 shows scheatically a successful segentation and reassebly of a CPCS user PDU in Message Mode. CPCS CPCS-UNITDATA-invoke add padding field add CPCS trailer SAR SAR-UNITDATA-invoke set AUU bit AUU=0 SAR-PDU AUU=0 SAR-PDU AUU=0 SAR-PDU AUU=1 SAR-PDU interpret AUU bit CPCS SAR- UNITDATAsignal SAR- UNITDATAsignal SAR- UNITDATAsignal SAR- UNITDATAsignal CPCS-UNITDATA-signal strip padding field strip CPCS trailer Figure B.3: Successful segentation and reassebly of a CPCS user PDU

31 Annex C (inforative): Functional odel for the AAL type 5 Page 31 For the AAL type 5, the functionality of the SSCS ay provide only for the apping of the equivalent priitives of the AAL type 5 to the CPCS an vice versa. On the other hand, the SSCS ay ipleent functions such as assured data transfer. Such functions, however, are not shown in the following figures. The functional odel of the AAL type 5 at the sender side is shown in figure C.1. The odel consists of several blocks that co-operate to provide the AAL type 5 service. The SAR and CPCS blocks that are paired represent the segentation state achine. AAL-CEP AAL-SAP P l a n e L a y e r SSCS CPCS-UNITDATA-invoke CPCS-U-Abort-invoke SSCS M a n a g e e n t M a n a g e e n t ATM-CEP CPCS SAR S e g e n t a t i o n SAR-UNITDATA-invoke ATM-DATA-request ATM-SAP AAL CPCS SAR Figure C.1: Functional odel for the AAL type 5 (sender side)

32 Page 32 The functional odel of the AAL type 5 at the receiver side is shown in figure C.2. The odel consists of several blocks that co-operate to provide the AAL type 5 services. The SAR and CPCS blocks that are paired represent the reassebly state achine. NOTE 1: NOTE 2: Layer anageent interactions require further study. Concerning the SSCS, the functional odel is an exaple only. Possible functions in the SSCS (i.e. ultiplexing) are not shown. The SSCS is specified in other standards and Recoendations. AAL-CEP AAL-SAP P l a n e M a n a g e e n t L a y e r M a n a g e e n t ATM-CEP SSCS CPCS SAR R e a s s e b l y CPCS-UNITDATA-signal CPCS-U-Abort-signal CPCS-P-Abort-signal SAR-UNITDATA-signal ATM-DATA-indication ATM-SAP SSCS CPCS SAR AAL Figure C.2: Functional odel for the AAL type 5 (receiver side)

33 Page 33 Annex D (inforative): Specification and Description Language (SDL) diagras for the SAR and the CPCS of the AAL type 5 D.1 SDL for the SAR sublayer The purpose of this clause is to provide one exaple of an SDL representation of the SAR procedures, to assist in the understanding of this ETS. The SDL representation does not constrain ipleentations fro exploiting the full potential inherent in this highly parallel and fast environent. The text description of the procedures in the ain body of this ETS is definitive. D.1.1 The SAR sender The SAR sender akes use of two variables: a) ptrpdu. This is a teporary variable that points into the (partial) CPCS-PDU received via the SAR-UNITDATA-invoke priitive. As successive parts of the CPCS-PDU are filled into SAR-PDU payloads, this pointer keeps pointing at the first octet within the CPCS-PDU that has not yet been sent within a SAR-PDU; b) count. This teporary variable keeps track of the nuber of octets still awaiting segentation and transission within a SAR-PDU. NOTE: No interactions with layer anageent are shown; these interactions require further study.