The ATM Forum Technical Committee PICS Proforma for the AAL Type 5 af-test-0042.000 August, 1995 Copyright Release for PICS: This PICS Proforma may be freely reproduced, so that it may be used for its intended purpose. PICS Proforma for the AAL Type 5 Version 1.0 August, 1995 (C) 1995 The ATM Forum. All Rights Reserved. The information in this publication is believed to be accurate at its publication date. Such information is subject to change without notice and the ATM Forum is not responsible for any errors. The ATM Forum does not assume any responsibility to update or correct any information in this publication. Notwithstanding anything to the contrary, neither The ATM Forum nor the publisher make any representation or warranty, expressed or implied, concerning the completeness, accuracy, or applicability of any information contained in this publication. No liability of any kind shall be assumed by The ATM Forum or the publisher as a result of reliance upon any information contained in this publication. The receipt or use of this document or its contents does not in any way create by implication or otherwise: o Any express or implied license or right to or under any ATM Forum member company's patent, copyright, trademark or trade secret rights which are or may be associated with the ideas, techniques, concepts or expressions contained herein; nor o Any warranty or representation that any ATM Forum member companies will announce any product(s) and/or service(s) related thereto, or if such announcements are made, that such announced product(s) and/or service(s) embody any or all of the ideas, technologies, or concepts contained herein; o Any form of relationship between any ATM Forum member companies and the recipient or user of this document. Implementation or use of specific ATM recommendations and/or specifications or recommendations of the ATM Forum or any committee of the ATM Forum will be voluntary, and no company shall agree or be obliged to implement them by virtue of participation in the ATM Forum. The ATM Forum is a non-profit international organization accelerating industry cooperation on ATM technology. The ATM Forum does not, expressly or otherwise, endorse or promote any specific products or services. Table of Contents 1. Introduction....................................................... 1 1.1 Scope..................................................... 1 1.2 Normative References...................................... 1 1.3 Definitions............................................... 1 1.4 Symbols and Conventions................................... 2 1.5 Conformance Statement..................................... 2 2. Identification of the Implementation............................... 3 3. PICS Proforma for AAL5............................................. 5 3.1 Global Statement of Conformance........................... 5 3.2 Instructions for completing the PICS Proforma............. 5 3.3 AAL5 Service.............................................. 6 3.3.1 Service Modes and Operations Service............ 6 3.4 Functions, Structure and Coding of AAL5................... 6 3.4.1 Functions of SAR and CPCS ...................... 6 3.4.2 SAR Functions, Structure and Coding ............ 6 3.4.3 CPCS Functions.................................. 7 3.4.4 CPCS Structure and Coding....................... 7 3.4.4.1 CPCS-PDU Structure ................... 7 3.4.4.2 CPCS-PDU Payload...................... 7 3.4.4.3 CPCS-PDU Pad Field ................... 8 3.4.4.4 CPCS User-to-User indication (UU) Field ........................... 8 3.4.4.5 CPCS-PDU Common Part Indicator (CPI) Field .......................... 8 3.4.4.6 CPCS-PDU Length Field ................ 8 3.4.4.7 CPCS-PDU Cyclic Redundancy Code (CRC) Field .......................... 9 3.5 Procedures ............................................... 9 3.5.1 Procedures for the SAR Sublayer at the Sender Side ............................. 9 3.5.2 Procedures of the CPCS for the Message Mode service at the Receiver Side .............. 9 1. Introduction To evaluate conformance of a particular implementation, it is necessary to have a statement of which capabilities and options have been implemented for a given protocol. Such a statement is called a Protocol Implementation Conformance Statement (PICS). 1.1 Scope This document provides the PICS proforma for the ITU-T AAL Type 5 as described in Section 6 of the ITU_T Draft Recommendation I.363. It covers the AAL5 with the SSCS sublayer set to Null. For AAL5 based protocols with SSCS not Null, a separate PICS Proforma should be generated. In this case, the PICS for AAL5 Common Part will be merged together with the one for the SSCS in one document. The proforma, when completed for an implementation, becomes the PICS for the implementation. 1.2 Normative References [1] ISO/IEC 9646-1: 1990, Information technology - Open systems interconnection - Conformance testing methodology and framework - Part1: General concepts. (See also CCITT Recommendation X.290 (1991)) [2] ISO/IEC 9646-2: 1990, Information technology - Open systems interconnection - Conformance testing methodology and framework - Part2: Abstract test suite specification. (See also CCITT Recommendation X.291 (1991)) [3] CCITT Document TD-XVIII/10 (AAL 5), "AAL Type 5, Draft Recommendation text for section 6 of I.363", 29 January 1993, Geneva. 1.3 Definitions This document uses the following terms defined in ISO/IEC 9646-1: IUT: Implementation under test. PICS: Protocol Implementation Conformance Statement. A statement made by the supplier of an implementation or system, stating which capabilities have been implemented for a given protocol. PICS Proforma: A document in the form of a questionnaire, designed by the protocol specifier or conformance test suite specifier, which, when completed for an implementation or system, becomes the PICS. SUT: System under test. This document uses the following terms defined in ITU-T Recommendation I.363: AAL5: ATM Adaption Layer Type 5 ATM : Asynchronous Transfer Mode CLP : Cell Loss Priority CPAAL5: Common Part AAL5 CPCS : AAL5 Common Part CS CPI: Common Part Indicator CRC: bit Cyclic Redundancy Code CS : AAL5 Convergence Sublayer HEC: Header Error Control LSB : Least Significant Bit PDU : Protocol Data Unit SAR : Segmentation And Reassembly sublayer SDU : Service Data Unit SSCS : AAL5 Service Specific CS 1.4 Symbols and Conventions - M Mandatory - O Optional - O. Optional, at least one or only one of the options is required in the group labelled with number n - Yes Supported - No Not supported 1.5 Conformance Statement The supplier of a protocol implementation which is claimed to conform to the AAL5 specification is required to complete a copy of the PICS proforma provided in the following sections of this document and is required to provide the information necessary to identify both the supplier and the implementation (i.e. Sections 2 and 3). 2. Identification of the Implementation IUT Identification IUT Name: ___________________________________________________ IUT Version: ________________________________________________ System Under Test SUT Name: ___________________________________________________ Hardware Configuration: _____________________________________ Operating System: ___________________________________________ Product Supplier Name: _______________________________________________________ Address: ____________________________________________________ _____________________________________________________________ _____________________________________________________________ Telephone Number:___________________ Facsimile Number:___________________ Additional Information: _____________________________________ _____________________________________________________________ _____________________________________________________________ Client Name: _______________________________________________________ Address: ____________________________________________________ _____________________________________________________________ _____________________________________________________________ Telephone Number:___________________ Facsimile Number:___________________ Additional Information: _____________________________________ _____________________________________________________________ _____________________________________________________________ PICS Contact Person Name: _______________________________________________________ Address: ____________________________________________________ _____________________________________________________________ _____________________________________________________________ Telephone Number:___________________ Facsimile Number____________________ Additional Information: _____________________________________ _____________________________________________________________ _____________________________________________________________ 3. PICS Proforma for AAL5 3.1 Global Statement of Conformance The implementation described in this PICS meets all of the mandatory requirements of the reference protocol. [] Yes [] No Note: Answering "No" indicates non-conformance to the specified protocol. Non-supported mandatory capabilities are to be identified in the following tables, with an explanation in the comments section of each table as to why the implementation is non-conforming. 3.2 Instructions for Completing the PICS Proforma Each question in this section refers to a major function of the protocol. Answering "Yes" to a particular question states that the implementation supports all of the mandatory procedures for that function, as defined in the referenced section of ITU-T I363 [3]. Answering "No" to a particular question in this section states that the implementation does not support that function of the protocol. 3.3 AAL5 Service 3.3.1 Service Modes and Operations Service _______________________________________________________________________________ Index Text Status Reference Support _______________________________________________________________________________ 3.3.1.1 Does the IUT support Message Mode? M 6.1 []Yes []No 3.3.1.2 Does the IUT support Streaming Mode? O 6.1 []Yes []No 3.3.1.3 Does the IUT support non-assured M 6.1 []Yes []No operations in any supported service mode? ________________________________________________________________________________ Comment (s) ________________________________________________________________________________ 3.4 Functions, Structure and Coding of AAL5 3.4.1 Functions of SAR and CPCS _______________________________________________________________________________ Index Text Status Reference Support _______________________________________________________________________________ 3.4.1.1 Does the IUT pass congestion M 6.3.2.1.1 []Yes []No information between the layers above and below the CPAAL5 in both directions? 3.4.1.2 Does the IUT pass CLP information M 6.3.2.1.1 []Yes []No between the layers above and below the CPAAL5 in both directions? ________________________________________________________________________________ Comment (s) ________________________________________________________________________________ 3.4.2 SAR Functions, Structure and Coding _______________________________________________________________________________ Index Text Status Reference Support _______________________________________________________________________________ 3.4.2.1 Does the IUT encodes AUU parameter M 6.3.1.1 []Yes []No value=0 to indicate beginning or 6.3.1.2 continuation of SAR-SDU and AUU parameter value=1 to indicate the end of the SAR-SDU? 3.4.2.2 Does the IUT SAR accept variable M 6.3.1.1 []Yes []No length SAR-SDUs which are integral multiples of 48 octets from the CPCS? 3.4.2.3 Does the IUT SAR generate SAR-PDUs M 6.3.1.1 []Yes []No containing 48 octets of SAR-SDU data? _______________________________________________________________________________ Comment (s) _______________________________________________________________________________ 3.4.3 CPCS Functions _______________________________________________________________________________ Index Text Status Reference Support _______________________________________________________________________________ 3.4.3.1 Does the IUT preserve the CPCS-SDU M 6.3.2.1 []Yes []No sequence integrity on each CPCS connection? 3.4.3.2 Does the IUT preserve the CPCS M 6.3.2.1.1 []Yes []No user-to-user information? 3.4.3.3 Is the option of discarding corrupted O 6.3.2.1.1 []Yes []No CPCS-SDUs supported for non-assured (Note 1) operations? 3.4.3.4 Is the option of delivering corrupted O 6.3.2.1.1 []Yes []No CPCS-SDU supported for non-assured (Note 1) operations? 3.4.3.5 Does the IUT provide the means to abort M 6.3.2.1.1 []Yes []No a partially transmitted CPCS-SDU using (Note 2) the Length field? 3.4.3.6 Does the IUT provide for 48 octet M 6.3.2.1.1 []Yes []No alignment of the CPCS-PDU trailer? _______________________________________________________________________________ Comment (s) Note 1: At least one of these capabilities shall be implemented. Note 2: The response is meaningful if only question 3.3.1.2 is given a "yes" answer. _______________________________________________________________________________ 3.4.4 CPCS Structure and Coding 3.4.4.1 CPCS-PDU Structure _______________________________________________________________________________ Index Text Status Reference Support _______________________________________________________________________________ 3.4.4.1.1 Does the IUT support CPCS-PDU structure M 6.3.2.1.2 []Yes []No as presented in figure 6.5 of [3] ? _______________________________________________________________________________ Comment (s) _______________________________________________________________________________ 3.4.4.2 CPCS-PDU Payload _______________________________________________________________________________ Index Text Status Reference Support _______________________________________________________________________________ 3.4.4.2.1 Does the IUT support CPCS-PDU payload M 6.3.2.1.2 []Yes []No field with 1 to 65535 octets in length? 3.4.4.2.2 Does the IUT use the CPCS-PDU payload M 6.3.2.1.2 []Yes []No to carry CPCS-SDU? _______________________________________________________________________________ Comment (s) _______________________________________________________________________________ 3.4.4.3 CPCS-PDU Pad Field _______________________________________________________________________________ Index Text Status Reference Support _______________________________________________________________________________ 3.4.4.3.1 Does the IUT support the padding field M 6.3.2.1.2 []Yes []No with 0 to 47 octets in length? 3.4.4.3.2 Does the IUT use the Padding field to M 6.3.2.1.2 []Yes []No align the CPCS-PDU on a 48 octet boundary? _______________________________________________________________________________ Comment (s) _______________________________________________________________________________ 3.4.4.4 CPCS User-to-User indication (UU) Field _______________________________________________________________________________ Index Text Status Reference Support _______________________________________________________________________________ 3.4.4.4.1 Does the IUT support the 1 octet M 6.3.2.1.2 []Yes []No CPCS-UU field? 3.4.4.4.2 Does the IUT use the CPCS-UU field to M 6.3.2.1.2 []Yes []No carry CPCS user-to-user information? _______________________________________________________________________________ Comment (s) _______________________________________________________________________________ 3.4.4.5 CPCS-PDU Common Part Indicator (CPI) Field _______________________________________________________________________________ Index Text Status Reference Support _______________________________________________________________________________ 3.4.4.5.1 Does the IUT support the 1 octet CPI M 6.3.2.1.2 []Yes []No field? 3.4.4.5.2 Does the IUT encode the CPI field to all M 6.3.2.1.2 []Yes []No zeros? _______________________________________________________________________________ Comment (s) _______________________________________________________________________________ 3.4.4.6 CPCS-PDU Length Field _______________________________________________________________________________ Index Text Status Reference Support _______________________________________________________________________________ 3.4.4.6.1 Does the IUT support the 2 octet M 6.3.2.1.2 []Yes []No Length field? 3.4.4.6.2 Does the IUT binary encode the Length M 6.3.2.1.2 []Yes []No field with the number of octets of the CPCS_PDU payload? 3.4.4.6.3 Does the IUT encode the Length field as M 6.3.2.1.2 []Yes []No zero for the abort function for the (note1) sending side? _______________________________________________________________________________ Comment (s) Note 1: This response is meaningful if only question 3.4.3.5 is given a 'yes' answer. _______________________________________________________________________________ 3.4.4.7 CPCS-PDU Cyclic Redundancy Code (CRC) Field _______________________________________________________________________________ Index Text Status Reference Support _______________________________________________________________________________ 3.4.4.7.1 Does the IUT support the 4 octet CRC M 6.3.2.1.2 []Yes []No field? 3.4.4.7.2 Does the IUT use the specified CRC-32 to M 6.3.2.1.2 []Yes []No calculate the CRC value? 3.4.4.7.3 Does the IUT place the result of the M 6.3.2.1.2 []Yes []No CRC-32 calculation in the CRC field with the LSB right justified? _______________________________________________________________________________ Comment (s) _______________________________________________________________________________ 3.5 Procedures 3.5.1 Procedures for the SAR Sublayer at the Sender Side _______________________________________________________________________________ Index Text Status Reference Support _______________________________________________________________________________ 3.5.1.1 Does the IUT generate more than one M 6.4.1.2 []Yes []No SAR-PDU, if the CPCS-PDU has the length of more than 48 octets? 3.5.1.2 In all the generated SAR-PDUs, does the M 6.4.1.2 []Yes []No IUT fill the SAR-PDU payload field with 48 octets of CPCS-PDU information? _______________________________________________________________________________ Comment (s) _______________________________________________________________________________ 3.5.2 Procedures of the CPCS for the Message Mode Service at the Receiver Side _______________________________________________________________________________ Index Text Status Reference Support _______________________________________________________________________________ 3.5.2.1 Does the IUT maintain the Max_SDU_ M 6.4.2.4 []Yes []No Deliver_Length to indicate the maximum size SDU in octets? 3.5.2.2 Does the IUT allow Max_SDU_Deliver_ M 6.4.2.4 []Yes []No Length to take on any integer value, (Note 1) set by the management plane, from 1 to 65535? 3.5.2.3 Does the IUT discard any CPCS-SDUs that M 6.4.2.4 []Yes []No have a length greater than MAX_SDU_ (Note 1) Deliver_Length and report the event to Layer Management? 3.5.2.4 Does the IUT discard CPCS-PDU when a CRC M 6.4.2.4 []Yes []No error is detected and the delivery option for non-assured operations is not set? 3.5.2.5 Does the IUT discard CPCS-PDU when invalid M 6.4.2.4 []Yes []No CPI is detected? 3.5.2.6 Does the IUT discard CPCS-PDU when the M 6.4.2.4 []Yes []No Length field is coded as zero? 3.5.2.7 Does the IUT discard CPCS-PDU when the M 6.4.2.4 []Yes []No value of the Length field indicates that the PAD field is longer than 47 octets or not enough data has been received? 3.5.2.8 Does the IUT set the CPCS-UU to the M 6.4.2.4 []Yes []No value of the CPCS-UU field of the CPCS-PDU trailer if the CPCS-SDU is delivered? 3.5.2.9 Does the IUT support a reassembly timer? O 6.4.2.4 []Yes []No 3.5.2.10 If reassembly Timer is supported, does M 6.4.2.4 []Yes []No the IUT (re)start the timer when it (Note 2) receives a SAR-UNITDATA signal with More = 1? 3.5.2.11 If reassembly Timer is supported, does M 6.4.2.4 []Yes []No the IUT discard CPCS-PDU when the timer (Note 2) expires? _______________________________________________________________________________ Comment (s) Note 1: Although the management layer interactions are not defined in the standard, they are very important to check, therefore they can be implementation dependent for the time being. Note 2: The response is meaningful if only question 3.5.2.9 is given a "yes" answer. _______________________________________________________________________________