Standard ECMA-265 Sep te mb e r 1 9 9 7
Standardizing
Information
and
Communication
Systems
Broadband Private Integrated Services Network (B-PISN) Inter-Exchange Signalling Protocol Signalling ATM Adaptation Layer
P h o n e : + 4 1 2 2 8 4 9 . 6 0 . 0 0 - F a x : + 4 1 2 2 8 4 9 . 6 0 . 0 1 - U R L : h t t p : / / www. e c m a . c h - I n t e r n e t : h e l p d e s k @ e c m a . c h
.
Standard ECMA-265 Sep te mb e r 1 9 9 7
Standardizing
Information
and
Communication
Systems
Broadband Private Integrated Services Network (B-PISN) Inter-Exchange Signalling Protocol Signalling ATM Adaptation Layer (B-QSIG-SAAL)
P h o n e : + 4 1 2 2 8 4 9 . 6 0 . 0 0 - F a x : + 4 1 2 2 8 4 9 . 6 0 . 0 1 - U R L : h t t p : / / www. e c m a . c h - I n t e r n e t : h e l p d e s k @ e c m a . c h IW Ecma-265.doc
03-09-97 17,01
.
Brief History
This Standard is one of a series of ECMA Standards defining services and signalling protocols applicable to Broadband Private Integrated Services Networks (B-PISNs). The series uses B-ISDN concepts as developed by ITU-T and conforms to the framework of International Standards for Open Systems Interconnection as defined by ISO/IEC. It has been produced under ETSI work item DEN/ECMA-00130. This particular Standard specifies the Signalling ATM Adaptation Layer (SAAL) protocol for use at the Q reference point. This Standard is based upon the practical experience of ECMA member companies and the results of their active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. This ECMA Standard is completely aligned with International Standard ISO/IEC 13246 to be published by ISO/IEC.
This ECMA Standard has been adopted by the General Assembly in September 1997.
.
- i -
Table of contents 1 Scope
1
2 Conformance
1
3 References (normative)
1
4 Definitions
1
5 List of acronyms
1
6 Description
2
6.1 Common Part - AAL Type 5
2
6.2 SSCOP
3
6.3 SSCF for Broadband Inter-PINX Signalling
3
7 Operational Requirements
3
7.1 B-QSIG SAAL Connections
3
7.2 Traffic Management Method for B-QSIG SAAL Connections
3
8 B-QSIG SAAL Specification
3
8.1 Basic Structure
3
8.2 AAL Type 5
3
8.3 SSCOP
3
8.4 SSCF for Broadband Inter-PINX Signalling
4
8.4.1 SAAL Services Provided by the SSCF for B-QSIG Signalling
4
8.4.2 Functions of the SSCF and Signalling Protocol Stack
4
8.4.3 Definition of the Boundary of SSCF to B-QSIG-Layer 3 Protocols
4
8.4.4 Definition of the Boundary of SSCF with SSCOP
4
8.4.5 State Transition Table of SSCF for Supporting B-QSIG Signalling
4
8.4.6 Boundary to Layer Management
4
8.4.7 Applicability of SSCOP Parameters and Timers to B-QSIG Signalling
4
8.4.8 PICS Proforma for SSCOP AND SSCOP-SSCF
5
8.4.9 SSCF for Semi-Permanent Connection (SPC) Control Signalling
5
Annex A - Protocol Implementation Conformance Statement (PICS) proforma for B-QSIG SAAL
7
Annex B - Relationship to corresponding ITU-T Recommendations for public B-ISDN UNIs
21
Annex C - Protocol data unit and related primitive sequences for establishment and release of B-QSIG SAAL connections
23
- ii -
.
1
Scope This Standard specifies the signalling ATM adaptation layer (SAAL) protocol used at the interface between Broadband PINXs and between Broadband PISNs within the framework of the B-QSIG signalling system protocol family. The B-QSIG SAAL uses the functions provided by the ATM layer, and provides the services required by the B-QSIG Layer 3 signalling protocols.
2
Conformance In order to conform to this Standard, a PINX shall satisfy requirements identified in the Protocol Implementation Conformance Statement (PICS) in annex A.
3
References (normative) The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below.
4
ISO/IEC 9646-1
Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts (1994)
ISO/IEC 9646-7
Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 7: Implementation Conformance Statements (1995)
ITU-T Rec. I.321
B-ISDN protocol reference model and its application (1991)
ITU-T Rec. I.361
B-ISDN ATM layer specification (1995)
ITU-T Rec. I.362
B-ISDN ATM Adaptation Layer (AAL) functional description (1993)
ITU-T Rec. I.363.5
B-ISDN ATM Adaptation Layer (AAL) specification - Part 5: AAL Type 5 (1996)
ITU-T Rec. I.371
Traffic control and congestion control in B-ISDN (1996)
ITU-T Rec. Q.2100
B-ISDN Signalling ATM Adaptation Layer (SAAL) overview description (1994)
ITU-T Rec. Q.2110
B-ISDN ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP) (1994)
ITU-T Rec. Q.2130
B-ISDN Signalling ATM Adaptation Layer - Service Specific Coordination Function for support of signalling at the User-Network Interface (SSCF at UNI) (1994)
Definitions The definitions of ITU-T Recommendations I.363.5, Q.2110 and Q.2130 apply.
5
List of acronyms AAL
ATM Adaptation Layer
ATM
Asynchronous Transfer Mode
B-ISDN
Broadband ISDN
B-PINX
B-PISN Exchange
B-PISN
Broadband Private Integrated Service Network
B-QSIG
Broadband QSIG
CRC
Cyclic Redundancy Check
IPL
Inter-PINX-Link
PICS
Protocol Implementation Conformance Statement
- 2 -
6
PINX
Private Integrated Services Network Exchange
SAAL
Signalling AAL
SDU
Service Data Unit
SPC
Semi-Permanent Connection
SSCF
Service Specific Convergence Functions
SSCOP
Service Specific Connection Oriented Protocol
UBR
Unspecified Bit Rate
UNI
User Network Interface
Description The SAAL protocol for Broadband Inter-PINX signalling uses the services of the ATM layer and provides the services required by the B-QSIG Layer 3 signalling protocols. It is based on the generic framework outlined by Recommendations I.362 for the functional description of the AAL, and Q.2100 for the signalling AAL specification. The B-QSIG SAAL allows a B-QSIG SAAL user (i.e. a layer 3 signalling protocol) to communicate with its peer entity. In particular, it provides for a reliable transfer of layer 3 signalling messages. The information transfer between the B-QSIG SAAL user and the B-QSIG SAAL uses primitives and is performed in Message Mode. Two peer-to-peer operational procedures are specified: Unassured or Assured operation. The support of the Assured operation is mandatory. The support of Unassured operation is optional. NOTE The use of unassured operation is not required by the B-QSIG layer 3 signalling protocol. The basic structure of the B-QSIG SAAL is contained in figure 1. For the B-QSIG SAAL, 3 sublayers are defined similar to those shown in figure 1 of Rec. Q.2100: – SSCF for B-QSIG – SSCOP – Common Part - AAL Type 5.
SSCF for B-QSIG signalling Q.2110
SSCOP (Service Specific Connection Oriented Protocol)
I.363.5
AAL type 5 Figure 1 - B-QSIG SAAL Structure
6.1
Common Part - AAL Type 5 AAL Type 5 provides transparent transfer and CRC checking (32 Bits) for SSCOP SDUs, segmentation into ATM cells, and reassembly.
- 3 -
6.2
SSCOP SSCOP provides the basic mechanisms for the establishment and release of connections and the reliable exchange of information between B-PINX peer entities.
6.3
SSCF for Broadband Inter-PINX Signalling SSCF maps the particular requirements of the Broadband Inter-PINX layer 3 signalling protocols to the SSCOP services.
7
Operational Requirements B-QSIG SAAL requires that the following configuration information is available at both sides of an IPL (the method for making this information available for both peer entities is outside the scope of this Standard): – which virtual channel acts as the signalling channels for the IPL – which traffic management method is applied on that virtual channel.
7.1
B-QSIG SAAL Connections The B-QSIG SAAL operates in a connection-oriented mode. The B-QSIG SAAL connection(s) shall be established as part of the IPL establishment, and shall reside permanently (except for error cases). NOTE B-QSIG SAAL connections are established between two peer entities at the two ends of an IPL.
7.2
Traffic Management Method for B-QSIG SAAL Connections For the operation of the B-QSIG SAAL protocol, the peer entities at two ends of an IPL shall be pre-configured with the traffic resources allocated to the B-QSIG SAAL connections. For each B-QSIG SAAL connection (or for a set of them together). the following are examples of parameters that can be pre-configured (see also ITU-T Rec. I.371): a)
a peak cell rate indication (only), e.g. 167 cells/sec.
b)
peak cell rate, sustainable cell rate, and maximum burst size (together)
c)
an indication as "unspecified bit rate" (UBR).
The method of configuring the traffic resources allocated to the B-QSIG SAAL connection is outside the scope of this Standard. However, it is essential for the traffic management of B-QSIG SAAL connections that both peer entities at the IPL apply the same allocation of parameters.
8 8.1
B-QSIG SAAL Specification Basic Structure Clause 5 of ITU-T Rec. Q.2100 applies.
8.2
AAL Type 5 ITU-T Rec. I.363.5 applies.
8.3
SSCOP ITU-T Rec. Q.2110 applies. NOTE The SSCOP can be combined with different Service Specific Coordination Functions (SSCFs) to offer different AAL services. As a result, the SSCOP specification defines mandatory functions for a general protocol. Some of these functions are not needed within B-QSIG SAAL. Therefore, it is possible for an implementation not to implement a certain SSCOP function and still meet the mandatory requirements of B-QSIG SAAL (e.g. the SSCOP local data retrieval function is not needed within B-QSIG SAAL), provided that the SSCOP implementation provides for the services used by the B-QSIG SAAL-SSCF.
- 4 -
A fully compliant SSCOP implementation according to ITU-T Rec. Q.2110 meets the requirements for the SSCOP of this Standard.
8.4 8.4.1
SSCF for Broadband Inter-PINX Signalling SAAL Services Provided by the SSCF for B-QSIG Signalling The following services shall be provided. Unless specified differently, they shall be provided as specified in clause 5 of ITU-T Rec. Q.2130: – assured transfer of data. – transparency of transferred information. NOTE The SSCF does not interpret the structure or meaning of SDUs; as a default, it supports the transfer of octetaligned SDUs up to a maximum of 4 096 octets. – establishment and release of B-QSIG SAAL connections for assured transfer of data. B-QSIG SAAL connections are established during IPL establishment, and reside permanently. However, in certain error scenarios, the SSCF may release B-QSIG SAAL connections to recover from error situations. The following SAAL services may optionally be provided: – unacknowledged transfer of data. The use of this service is not specified by the B-QSIG layer 3 signalling protocol.
8.4.2
Functions of the SSCF and Signalling Protocol Stack Clause 6 of ITU-T Rec. Q.2130 applies with the following exception: – only point-to-point B-QSIG SAAL connections shall be supported. In particular, B-QSIG SAAL shall not provide the broadcast capability described in clause 6/Q.2130.
8.4.3
Definition of the Boundary of SSCF to B-QSIG-Layer 3 Protocols Clause 7 of ITU-T Rec. Q.2130 applies with the following exceptions: – The support of the AAL-UNITDATA primitive is not mandatory. The use of this primitive is not specified by B-QSIG layer 3 signalling protocol. – The support of layer 3 peer-to-peer messages in the AAL-ESTABLISH and AAL-RELEASE primitives is not mandatory. The use of those parameter data in these primitives is not specified by the B-QSIG layer 3 signalling protocol.
8.4.4
Definition of the Boundary of SSCF with SSCOP Clause 8 of ITU-T Rec. Q.2130 applies with the following exception: – The support of the AA-UNITDATA primitive is not mandatory.
8.4.5
State Transition Table of SSCF for Supporting B-QSIG Signalling Clause 9 of ITU-T Rec. Q.2130 applies with the exceptions specified in sections 8.4.3 and 8.4.4 above.
8.4.6
Boundary to Layer Management No requirements have been identified.
8.4.7
Applicability of SSCOP Parameters and Timers to B-QSIG Signalling The values specified in table 4 of ITU-T Rec. Q.2130 are used as default parameters. However, parameter and timer values at the B-QSIG-IPL shall be configurable, in order to be able to select a proper set of parameter and timer values depending on the use, condition, IPL link rate, round-trip delay, and receiver resequencing buffer size. As a general guide, Timer_POLL should be set to as large a value as possible that still maintains throughput efficiency and satisfies the average and maximum delivery of data. For the signalling channels at the Q reference point, no restrictions to operating at below 10 kbit/s applies.
- 5 -
8.4.8
PICS Proforma for SSCOP AND SSCOP-SSCF Annex A applies.
8.4.9
SSCF for Semi-Permanent Connection (SPC) Control Signalling Functions for the support of semi-permanent connections are outside the scope of this Standard.
- 6 -
- 7 -
Annex A (normative)
Protocol Implementation Conformance Statement (PICS) proforma for B-QSIG SAAL
A.1 A.1.1
Introduction Basic reference documents for PICS proforma specifications General rules for the specification of PICS proforma are provided by ISO/IEC 9646-1. Detailed guidance for the specification of PICS proforma is provided by ISO/IEC 9646-7; in particular the structure of a PICS proforma, the questions to be asked, the syntax and notation to be used and the semantics of the questions and expected answers. For a PICS proforma, specific acronyms and terms are used as defined in ISO/IEC 9646-1 or ISO/IEC 9646-7, e.g.:
A.1.2
− ICS
Implementation Conformance Statement
− ICS proforma
Implementation Conformance Statement proforma
− ICS (proforma) item
A row in an ICS (proforma) table
− PICS
Protocol ICS
− PICS proforma
Protocol ICS proforma
− status (value)
An allowed entry in the status column for an item in an ICS proforma table
− (support) answer
An allowed entry in the support or supported values columns for an item in an ICS question
Copyright Information Users of this specification may freely reproduce the PICS proforma of this annex A so that it can be used for its intended purpose and may further publish the completed PICS.
A.1.3
Structure of this PICS proforma This PICS proforma is subdivided into (sub-)clauses as follows: − Instructions (A.2) − Purpose of a PICS proforma (A.2.1) − Instructions for completing the PICS proforma (A.2.2) − Additional Information (A.2.3) − Exception Information (A.2.4) − Legend for the columns of the PICS proforma tables (A.2.5) − Legend for further indications of the PICS proforma tables (A.2.6) − Identification of the implementation (A.3), including: − Identification of the protocol for which this PICS applies (A.3.7) − Global statement of conformance (A.4) − SSCOP (A.5) − SSCOP-SSCF B-QSIG Protocol Capabilities (A.6)
- 8 -
A.2 A.2.1
Instructions Purpose of a PICS proforma 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 OSI specification. Such a statement is called an Implementation Conformance Statement (ICS). For protocol specifications, this statement is called "Protocol Implementation Conformance Statement" (PICS). For the provision of this statement, a fixed format questionnaire called PICS proforma has to be used. A completed PICS proforma is the PICS for the implementation in question. It is an ICS (as defined in ISO/IEC 9646-7) for an implementation or system which claims to conform to a given specification. The PICS can have a number of uses, including: − by the protocol implementor, as a check list for implementations to reduce the risk of unintended nonconformance, e.g. through oversight; − by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the capabilities of the implementation, stated relative to the common basis for understanding provided by the Standard's PICS proforma; − by the user or potential user of the implementation, as a basis for initially checking the possibility of interworking with another implementation - while interworking can never be guaranteed, failure to interwork can often be predicted from incompatible PICS; − by a protocol tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the implementation. The PICS proforma of this annex therefore reflect a compromise between these different requirements.
A.2.2
Instructions for completing the PICS proforma The supplier of a protocol implementation which is claimed to conform to this Standard shall complete the following Protocol Implementation Conformance Statement (PICS) proforma. The PICS proforma is a fixed format questionnaire. The supplier of the implementation shall complete this questionnaire, in particular identify the implementation, complete the global statement of conformance, and providing the answers in the rows of the tables in clauses A.5 - A.6. The structure of the tables is explained in subclauses A.2.5 and A.2.6. For each row in each table, the supplier shall enter an explicit answer (i.e. by ticking the appropriate "yes", "no", or "N/A" in each of the support column boxes provided. Where a support column box is left blank, or where it is marked "N/A" without any tick box, no answer is required. If a "prerequisite line" (see A.2.6 below) is used after a subclause heading or table title, and its predicate is false, no answer is required for the whole subclause or table, respectively. A supplier may also provide - or be required to provide - further information, categorized as either Additional Information or Exception Information. When present, each kind of further information is to be provided in a further subclause of items labelled "a.<i>"
for additional information,
"x.<i>"
for exceptional information
for cross-referencing purposes, where <i> is any unambiguous identification for the item (e.g., simply a numeral); there are no other restrictions on its format and presentation.
A.2.3
Additional Information Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of the PICS. It is not intended or expected that a large quantity will be supplied, and a PICS can be considered complete without any such information. Examples might be an outline of the ways in which a (single) implementation can be set up to operate in a variety of environments and configurations. References to items of Additional Information may be entered next to any answer in the questionnaire, and may be included in items of Exception information.
- 9 -
A.2.4
Exception Information It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any conditions have been applied) in a way that conflicts with the indicated requirement. No pre-printed answer will be found in the Support column for this. Instead, the supplier is required to write into the support column an x.<i> reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. An implementation for which an Exception item is required in this way does not conform to this Standard; and the answer to the global statement of conformance (see A.4) cannot be "yes". A possible reason for the situation described above is that a defect in the Standards has been reported, a correction for which is expected to change the requirement not met by the implementation.
A.2.5
Legend for the columns of the PICS proforma tables The questionnaire in clauses A.5-A.6 is structured as a set of tables in accordance with the guidelines presented in ISO/IEC 9646-7. The columns of the tables shall be interpreted as follows: "Item" The item column contains a unique reference (a mnemonic plus a number) for each item within the PICS proforma. Items need not always be numbered sequentially. "Item Description" The item description column contains a brief summary of the static requirement for which a support answer is required. This may be done by a question or a reference to a specific feature. "Conditions for Status" The conditions for status column contains a specification, if appropriate, of the predicate upon which a conditional status is based. The indication of an item reference in this column indicates a simple-predicate condition (support of this item is dependent on the support marked for the referenced item). Within the "conditions for status" column, the logical symbol "]" is used to indicate a logical negation ("NOT"). "Status" The following notations, as defined in ISO/IEC 9646-7, are used for the status column: I
Irrelevant or out-of-scope - this capability is outside the scope of the Standard to which this PICS proforma applies and is not subject to conformance testing in this context.
M
Mandatory - the support of this capability is required for conformance to the Standard.
N/A
Not Applicable - in the given context, it is impossible to use the capability. No answer in the support column is required.
O
Optional - the capability is not required for conformance to the protocol and may be supported or not. However, if the capability is implemented, it is required to conform to the protocol specifications.
O.<n>
Qualified optional - in this case, <n> is an integer that identifies a unique group of related optional items. If no additional qualification is indicated, the support of at least one of the optional items is required for conformance to the Standard. Otherwise, the qualification and logic of the selection among the optional items is defined below the table explicitly.
X
eXcluded or prohibited - there is a requirement not to use this capability in a given context.
"Reference" Except where explicitly stated, the reference column refers to the appropriate subclause(s) of this Standard describing the particular item. The reference merely indicates the place(s) where the core of a description of an item can be found; additional information on this item may be contained in other parts of this Standard, and has to be taken into account when making a statement about the conformance to that particular item.
- 10 -
"Support " In the support column, the supplier of the implementation shall enter an explicit answer. The following notation is used: [ ] Yes
[No]
[ ] N/A
Tick "yes", if item is supported; tick "No", if item is not supported. Tick "N/A", if the item is "not applicable".
In specific cases, the indication of explicit values may be requested. Where a support column box is left blank, or where it is marked "N/A" without any tick box, no answer is required.
A.2.6
Legend for further indications of the PICS proforma tables In addition to the columns of a table, the following information may be indicated: "Prerequisite line" A prerequisite line after a subclause heading or table title indicates that the whole subclause or the whole table is not required to be completed if the predicate is false. The prerequisite line takes the form: Prerequisite:<predicate>. "Qualification" At the end of a table, a detailed qualification for a group of optional items may be indicated, as specified in the description of the status "qualified optional" in subclause A.2.5. "Comments" This box at the end of a table allows a supplier to enter any comments to that table. Comments may also be provided separately (without using this box).
A.3
Identification of the implementation Identification of the implementation and the system in which it resides should be filled in to provide as much detail as possible regarding version numbers and configuration options. The implementation about which this PICS proforma asks questions corresponds to a B-QSIG BC implementation at the Q reference point. Configuration options outlined in B-QSIG BC have been incorporated into this PICS proforma. They are referred to by qualified options or prerequisite lines, in order to reflect that an implementation only needs to provide the addressed functions at an interface, if it is configured accordingly (e.g. an implementation only needs to provide gateway call handling functions, if it is configured to act as gateway PINX at an interface). The contact person indicated (see A.3.6) should be able to answer queries regarding information supplied in the PICS. As specified in clause 5 of ISO/IEC 9646-7, it is required for all implementations to at least provide the identification of the implementation (A.3.2), product supplier information (A.3.4), identification of a contact person (A.3.6), and detailed identification of the protocol for which the PICS applies (A.3.7). Identification of the system in which the implementation resides (A.3.3) is recommended in order to facilitate full identification of the system, and avoid possible problems during conformance testing. The client information (A.3.5) only needs to be filled in if it is relevant and different from the product supplier information.
- 11 -
A.3.1
Date of statement ___________________________________________________________________________________
A.3.2
Identification of the implementation The terms "name" and "version" should be interpreted appropriately to correspond with a suppliers terminology (e.g. Type, Series, Model). Name of the implementation: ___________________________________________________________________________________ ___________________________________________________________________________________ Implementation version: ___________________________________________________________________________________ ___________________________________________________________________________________
A.3.3
Identification of the system in which it resides Name of the system: ___________________________________________________________________________________ ___________________________________________________________________________________ Hardware configuration: ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ Operating system: ___________________________________________________________________________________ ___________________________________________________________________________________
A.3.4
Product supplier Name: ___________________________________________________________________________________ Address: ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ Telephone number: ___________________________________________________________________________________ Facsimile number: ___________________________________________________________________________________ E-Mail address: ___________________________________________________________________________________ Additional information: ___________________________________________________________________________________ ___________________________________________________________________________________
- 12 -
A.3.5
Client Name: ___________________________________________________________________________________ Address: ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ Telephone number: ___________________________________________________________________________________ Facsimile number: ___________________________________________________________________________________ E-Mail address: ___________________________________________________________________________________ Additional information: ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________
A.3.6
PICS contact person Name: ___________________________________________________________________________________ Address: ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ Telephone number: ___________________________________________________________________________________ Facsimile number: ___________________________________________________________________________________ E-Mail address: ___________________________________________________________________________________ Additional information: ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________
- 13 -
A.3.7
Protocol for which this PICS applies Protocol: B-QSIG SAAL - B-PISN inter-PINX signalling protocol - Signalling ATM Adaptation Layer Specification Protocol Version - please identify the standards document unambiguously, including e.g. reference number (ECMA-265), edition number (if applicable) and publication date: ___________________________________________________________________________________ ___________________________________________________________________________________ Corrigenda Implemented (if applicable): ___________________________________________________________________________________ ___________________________________________________________________________________ Addenda Implemented (if applicable): ___________________________________________________________________________________ ___________________________________________________________________________________ Amendments Implemented (if applicable): ___________________________________________________________________________________ ___________________________________________________________________________________
A.4
Global Statement of Conformance Does the implementation described in this PICS meet all the mandatory requirements of the referenced standard: [ ]
Yes
[ ]
No
NOTE Answering "No" to this question indicates non-conformance to the protocol specification. In this case, an explanation shall be given of the nature of non-conformance either below or on a separate sheet of paper. Further, the instructions outlined in subclause A.2.4 ("Exception Information") shall be followed when completing the PICS proforma tables. Nature of non-conformance (if applicable): ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________
- 14 -
A.5 A.5.1
SSCOP SSCOP Protocol Capabilities (PC) Each item in table A.1 refers to a capability offered by the SSCOP protocol. Answering "Yes" to a particular question states that the SSCOP implementation supports all the mandatory procedures for that function as defined in the referenced parts of ITU-T Recommendation Q.2110. Answering "No" to a particular question states that the SSCOP implementation does not support that function of the protocol. Items PC2, PC4 (BGREJ, UD, MD), PC5.2, PC5.3 and PC16 are optional, indicating that at Q, SSCF does not invoke this functionality even if it is provided by SSCOP. Item PC9 is optional, indicating a local implementation option of the SSCOP protocol which is not detectable by the peer SSCOP entity.
- 15 -
Table A.1 ITEM #
Protocol feature
References
Status
PC1
Does IUT support Keep Alive function ?
5 e)
M
PC2
Does IUT support the Local Data Retrieve function
5 f)
O
PC3
Does the IUT support SSCOP initiated error recovery due to protocol error ?
5 i)
M
PC4
Does IUT recognize the following messages regardless of state
table 2
BGN
M
BGAK
M
BGREJ
O
END
M
ENDAK
M
ER
M
ERAK
M
POLL
M
STAT
M
USTAT
M
RS
M
RSAK
M
SD
M
UD
O
MD
O
PC5.1
In the absence of protocol error, does the IUT support assured data transfer with sequence integrity?
5 a); 5 h); 7.1 j)
M
PC5.2
Does IUT support the sending of unassured Data PDU ?
5 h); 7.1 n)
O
PC5.3
Does IUT support the sending of the Management Data PDU ?
7.1 o)
O
PC6
Does IUT support user invoked resynchronization procedures ?
5 g)
M
PC7
Does IUT support the establishment procedures for an SSCOP connection ?
5 g)
M
PC8
Does IUT support release procedures for an SSCOP connection ?
5 g)
M
PC9
Does IUT support polling after retransmission ?
SDL
O
PC10
Does IUT support the segmenting of STAT PDUs ?
7.2.5
M
PC11
Can the IUT initiate SSCOP connection
5 g)
M
PC12
Can the IUT reject (BGREJ) the establishment of an SSCOP connection from its peer ?
SDL
N/A
Support
- 16 -
PC13
Does IUT support error reporting to layer management ?
5 d)
M
PC14
Does IUT support the Protocol error detection function?
5 i)
M
PC15
When no SSCOP connection exists, is a connection established only upon receipt of a BGN or a request from the SSCOP user ?
SDL
M
PC16
Does SSCOP permit the conveyance of SCCOP User-toUser Information between users of the SSCOP ?
5 g); 6.1.2 b)
O
Comments
A.5.2
SSCOP PDUs - Protocol data units (PD) Indicating support for an item in table A.2 states that the SSCOP implementation complies with the definition of the basic structure of SSCOP PDU format such as coding conventions and contents of reserved fields. All references are to ITU-T Recommendation Q.2110. Table A.2 ITEM #
Protocol feature
References
Status
7.2.1
M
Support
Order of Octet Transmission PD1
Are octets transmitted in ascending numerical order
Field Mapping Convention PD2
Does the lowest bit number carry the lowest order value?
7.2.1
M
PD3
Are PDU formats 32 bit aligned?
7.2
M
PD4
Are all reserved bits coded as zeroes
7.2.3
M
Comments
A.5.3
SSCOP System parameters (SP) Indicating support for an item in table A.3 states that the implementation has a parameter that operates in accordance with the description in ITU-T Recommendation Q.2110. Specific values for the parameters implemented should be stated here, or, where appropriate, in the PIXIT. All references are to ITU-T Recommendation Q.2110.
- 17 -
Table A.3 ITEM #
Protocol feature
References
Status
SP1
Is the parameters supported which defines the maximum number of transmissions of a BGN, END, ER, or RS PDU (MaxCC) ?
7.7 a)
M
SP2
Is the parameters supported which defines the maximum number of SD PDUs before transmission of a POLL PDU (MaxPD)?
7.7 b)
M
SP3
Is the parameter supported which defines the maximum number of List Elements in a STAT (MaxSTAT) ?
7.7 c)
M
SP4
Is the parameter supported which defines the maximum SSCOP SDU size?
7.2.4
M
SP5
Is Timer_POLL supported ?
7.6 a)
M
SP6
Is Timer_KEEP-ALIVE supported ?
7.6 b)
M
SP7
Is Timer_NO-RESPONSE supported ?
7.6 c)
M
SP8
Is Timer_IDLE supported ?
7.6 c)
M
SP9
Is Timer_CC supported ?
7.6 a)
M
SP10
If PC16 is supported, what is the maximum size of the SSCOP-UU?
6.1.2 b)
M
Support
Supported value
Comments
A.6
SSCOP-SSCF B-QSIG Protocol Capabilities (SUPC) Table A.4 contains questions about the combined SSCOP and SSCF functional block. It is devided into three logical parts, covering the establishment and release of a SSCOP connection, data transfer, and reestablishment of a SSCOP connection. Each is further subdivided depending on the direction of information flow through the combined SSCOP and SSCF functional block. The following terminology is used: − the primitives exchanged between the SSCF and the SSCOP are shown between square brackets "[ ]" in the PICS questions. These primitives do not constrain an implementation; − the SSCOP represents the peer-to-peer messages (e.g., PDUs). Indicating support for an item in table A.4 states that the implementation supports all the mandatory elements of the procedures for that function. Answering "No" to a particular question states that the implementation does not support that function of the protocol. All references are to ITU-T Q.2130 as modified by the present Standard.
- 18 -
Table A.4 ITEM #
Protocol feature
References
Status
ESTABLISHMENT/RELEASE SSCOP -> upper boundary of SSCF SUPC1
Does the receipt of SSCOP PDU BGN [AA-ESTABLISH.indication] generate AAL-ESTABLISH.indication at Q
Table 3/Q.2130
M
SUPC2
In addition to SUPC1, does SSCOP send PDU BGAK [AAESTABLISH.response] to accept the connection request?
Table 3/Q.2130
M
SUPC3
On receipt of SSCOP PDU END [AA-RELEASE.indication], does IUT generate AAL-RELEASE.indication and does the SSCOP send PDU ENDAK [AA-RELEASE.response]?
Table 3/Q.2130
M
Upper boundary of SSCF -> SSCOP SUPC4
Does an AAL-ESTABLISH.requestgenerate an SSCOP PDU BGN [AA-ESTABLISH.request] ?
Table 3/Q.2130
M
SUPC5
Does the receipt of SSCOP PDU BGAK [AA-ESTABLISH.confirm] in response to the sending of an SSCOP PDU BGN generate an AALESTABLISH.confirm?
Table 3/Q.2130
M
SUPC6
Does an AAL-RELEASE request generate an SSCOP PDU END [AARELEASE request]
Table 3/Q.2130
M
SUPC7
Does the receipt of SSCOP PDU ENDAK [AA-RELEASE.confirm] in response to the sending of an SSCOP END PDU generate an AALRELEASE.confirm?
Table 3/Q.2130
M
DATA TRANSFER SSCOP -> upper boundary of SSCF SUPC8
Does receipt of an in-sequence SSCOP PDU SD [AADATA.indication] generate AAL-DATA.indication
Table 3/Q.2130
M
SUPC9
Does receipt of an SSCOP PDU UD [AA-UNITDATA.indication] generate AAL-UNIDATA.indication ?
Table 3/Q.2130
O
Upper boundary of SSCF -> SSCOP SUPC10
Does an AAL-UNITDATA.request generate an SSCOP PDU UD [AA-UNITDATA request]?
Table 3/Q.2130
O
SUPC11
Does an AAL-DATA.request generate an SSCOP PDU SD [AADATA request] while a connection is established and credit is available ?
Table 3/Q.2130
M
RE-ESTABLISHMENT SSCOP -> upper boundary of SSCF SUPC12
Does the receipt of SSCOP PDU RS [AA-RESYNC.indication] generate AAL-ESTABLISH.indication
Table 3/Q.2130
M
SUPC13
In addition to SUPC12, does SSCOP send PDU RSAK [AARESYNC.response] to accept the connection request?
Table 3/Q.2130
M
Support
- 19 -
(continued) SUPC14
On receipt of SSCOP PDU ER [AA-RECOVER.indication], does IUT generate AAL-ESTABLISH.indication and does the SSCOP send PDU ERAK [AA-RECOVER.response]?
Table 3/Q.2130
M
SUPC15
On receipt of SSCOP PDU ERAK [AA-RECOVER.indication], does IUT generate AAL-ESTABLISH.indication?
Table 3/Q.2130
M
Upper boundary of SSCF -> SSCOP SUPC16
Does an AAL-ESTABLISH.request generate an SSCOP PDU RS [AA-RESYNC.request] ?
Table 3/Q.2130
M
SUPC17
Does the receipt of an SSCOP PDU RSAK [AA-RESYNC.confirm] in response to the sending of an SSCOP PDU RS generate an AALESTABLISH.confirm?
Table 3/Q.2130
M
Comments
- 20 -
- 21 -
Annex B (informative)
Relationship to corresponding ITU-T Recommendations for public B-ISDN UNIs
This Standard is based on equivalent protocols specified by ITU-T for public B-ISDN UNIs. The ITU-T specifications are to be found in Rec. Q.2100 (Overview), Rec. I.363.5 (AAL Type 5), Rec. Q.2110 (SSCOP), and Rec. Q.2130 (SSCF for UNI).
The following elements of Q.2110 and Q.2130 are not used in B-QSIG SAAL: -
unacknowledged information transfer
-
broadcast connections.
The following enhancements to procedures exist in B-QSIG SAAL and not in Q.2110 or Q.2130: -
IPL connections are permanently established, except under error conditions
-
operational requirements for signalling virtual channels, B-QSIG SAAL connections, and traffic management.
- 22 -
- 23 -
Annex C (informative)
Protocol data unit and related primitive sequences for establishment and release of B-QSIG SAAL connections
Appendix 1 of ITU-T Rec. Q.2130 applies.
.
.
.
Printed copies can be ordered from: ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland Fax: Internet:
+41 22 849.60.01 [email protected]
Files can be downloaded from our FTP site, ftp.ecma.ch, logging in as anonymous and giving your E-mail address as password. This Standard is available from library ECMA-ST as a compacted, self-expanding file in MSWord 6.0 format (file E265-DOC.EXE) and as an Acrobat PDF file (file E265-PDF.PDF). File E265-EXP.TXT gives a short presentation of the Standard. Our web site, http://www.ecma.ch, gives full information on ECMA, ECMA activities, ECMA Standards and Technical Reports.
ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland This Standard ECMA-265 is available free of charge in printed form and as a file. See inside cover page for instructions