Standard ECMA-245 2nd E dition - S e ptember 1997
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol PINX Clock Synchronization
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-245 2nd E dition - S e ptember 1997
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol PINX Clock Synchronization (SYNC-SIG)
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-245.doc
02-09-97 12,12
.
Brief History
This Standard is one of a series of ECMA Standards defining services and signalling protocols applicable to Private Integrated Services Networks (PISNs). The series uses 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 DE/ECMA-00115. This particular Standard specifies the signalling protocol for the support of PINX clock synchronization. The protocol defined in this Standard forms part of the PSS1 protocol (informally known as QSIG). 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. Compared to the 1st Edition of Standard ECMA-245 (published by ECMA in June 1996), this 2nd Edition incorporates changes in order to achieve complete alignment with International Standard ISO/IEC 15507 to be published by ISO/IEC.
Adopted as 2nd Edition of Standard ECMA-245 by the General Assembly in September 1997.
.
- i -
Table of contents 1 Scope
1
2 Conformance
1
3 References (normative)
1
4 Definitions
1
4.1 External definitions
1
4.2 Other definitions
2
4.2.1 Adjacent PINX
2
4.2.2 Requesting PINX
2
4.2.3 Destination PINX
2
4.2.4 Synchronization Entity
2
5 List of acronyms
2
6 Signalling protocol for the support of the protocol
2
6.1 Description
2
6.2 Operational requirements
2
6.3 Coding requirements
3
6.3.1 Operations
3
6.3.2 Information elements
4
6.3.3 Messages
4
6.4 State definitions
4
6.4.1 States at the Requesting PINX
4
6.4.2 States at the Destination PINX
4
6.5 Signalling procedures
4
6.5.1 Actions at the Requesting PINX
4
6.5.2 Actions at the Destination PINX
5
6.6 Impact of interworking with public ISDNs
5
6.7 Impact of interworking with non-ISDNs
5
6.8 Protocol interactions between Synchronization and supplementary services and ANFs
6
6.9 Parameter values (timers)
6
6.9.1 Timer T1
6
Annex A - Protocol Implementation Conformance Statement (PICS) Proforma
7
Annex B - Examples of Message Sequences
11
Annex C - Specification and Description Language (SDL) Representation of Procedures
15
- ii -
.
1
Scope This Standard specifies the signalling protocol for the support of clock synchronization (SYNC-SIG) between Private Integrated Services Network Exchanges (PINXs) connected together within a Private Integrated Services Network (PISN). This protocol supports the synchronization of a PISN using the different sources of clocks available to each PINX. The protocol is based on the method of synchronization described in annex F of the International Standard ISO/IEC 11573. This Standard is applicable to PINXs which can be interconnected to form a PISN.
2
Conformance In order to conform to this Standard, a PINX shall satisfy the requirements identified in the Protocol Implementation Conformance Statement (PICS) proforma 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. In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the appropriate ISO/IEC International Standard is given in brackets after the ECMA reference.
4
ECMA-165
Private Integrated Services Network - Generic Functional Protocol for the Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol (International Standard ISO/IEC 11582)
ISO/IEC 11573
Information technology - Telecommunications and information exchange between systems Synchronization methods and technical requirements for Private Integrated Services Networks
ISO/IEC 11579-1
Information technology - Telecommunications and information exchange between systems Private Integrated Services Network - Part 1: Reference configuration for PISN Exchanges (PINX)
ITU-T Rec. I.112
Vocabulary of terms for ISDNs (1993)
ITU-T Rec. Z.100
Specification and description language (1993)
Definitions For the purposes of this Standard, the following definitions apply.
4.1
External definitions This Standard uses the following terms defined in other documents: − Application Protocol Data Unit
(ECMA-165)
− End PINX
(ECMA-165)
− Interpretation APDU
(ECMA-165)
− Private Integrated Services Network (PISN)
(ISO/IEC 11579-1)
− Private Integrated Services Network Exchange (PINX)
(ISO/IEC 11579-1)
− Signalling
(ITU-T Rec. I.112)
− Originating PINX
(ECMA-165)
− Terminating PINX
(ECMA-165)
- 2 -
4.2
Other definitions
4.2.1
Adjacent PINX One of two PINXs that are directly connected by means of an inter-PINX link.
4.2.2
Requesting PINX PINX that initiates a confirmed or unconfirmed transaction.
4.2.3
Destination PINX PINX which is the target of a confirmed or unconfirmed transaction.
4.2.4
Synchronization Entity Entity which is in charge of the synchronization in a PINX. NOTE The functions of the Synchronization Entity are described in ISO/IEC 11573.
5
6 6.1
List of acronyms APDU
Application Protocol Data Unit
ASN.1
Abstract Syntax Notation One
ISDN
Integrated Services Digital Network
NFE
Network Facility Extension
PICS
Protocol Implementation Conformance Statement
PINX
Private Integrated Network Exchange
PISN
Private Integrated Service Network
SDL
Specification and Description Language
Signalling protocol for the support of the protocol Description When two or more PINXs are connected to each other, it is required by ISO/IEC 11573 that these PINXs shall work for transmission with the same clock value: in that case PINXs are ”synchronized”. Without such synchronization, information can be lost from one PINX to another. ISO/IEC 11573 describes the “clock synchronization” in detail and defines a method to use for a network synchronization. The signalling protocol for this method is defined in this Standard. The protocol involves the exchange of APDUs between adjacent PINXs using the call-independent signalling connection (connectionoriented) transport mechanism specified in ECMA-165.
6.2
Operational requirements Generic procedures for the call-independent control (connection-oriented), as specified in ECMA-165 for an Originating PINX and Terminating PINX, shall apply. A Synchronization Entity which can be called by a predetermined called party number shall exist in each PINX.
- 3 -
6.3 6.3.1
Coding requirements Operations To convey information defined by the method of synchronization in messages, the operations defined in Abstract Syntax Notation number 1 (ASN.1) in table 1 shall apply. Table 1 - Operations in support of clock synchronization
Synchronization-Operations { iso (1) standard (0) pinx-clock-synchronization (15507) synchronization-operations (0) } DEFINITIONS EXPLICIT TAGS
::=
BEGIN IMPORTS
OPERATION, ERROR FROM Remote-Operation-Notation { joint-iso-ccitt (2) remote-operations (4) notation (0) } Extension FROM Manufacturer-specific-service-extension-definition {iso (1) standard (0) pss1-generic-procedures (11582) msi-definition (0)};
-- The following two operations shall apply to SYNC-SIG SynchronizationRequest
SynchronizationInfo
::=
::=
SynchronizationReqArg
SynchronizationReqRes
SynchronizationInfoArg
::=
::=
::=
OPERATION ARGUMENT RESULT ERRORS
SynchronizationReqArg SynchronizationReqRes {unspecified}
OPERATION ARGUMENT
SynchronizationInfoArg
SEQUENCE { action argExtension
Action, ArgExtension OPTIONAL}
SEQUENCE { action response argExtension
Action, BOOLEAN, -- TRUE = yes, FALSE = no ArgExtension OPTIONAL}
SEQUENCE { stateinfo argExtension
INTEGER { freerunning (0), idle (1)}, ArgExtension OPTIONAL}
Action
::= INTEGER
{ enslavement (0), holdon (1)}
ArgExtension
::= CHOICE
{
extension sequOfExtn
synchronizationRequest synchronizationInfo
SynchronizationRequest SynchronizationInfo
unspecified Unspecified
Unspecified ERROR
::=
END -- of Synchronization-Operations
[1] IMPLICIT Extension, [2] IMPLICIT SEQUENCE OF Extension } ::= 78 ::= 79
::= 1008 PARAMETER Extension
- 4 -
6.3.2
Information elements
6.3.2.1
Facility information element The operations defined in 6.3.1 shall be coded in the Facility information element in accordance with ECMA-165. When conveying the invoke APDU of the operations defined in 6.3.1, the destinationEntity data element of the NFE shall contain value endPINX and the interpretation APDU shall either be omitted or be included with the value rejectAnyUnrecognisedInvokePdu.
6.3.2.2
Other information elements Any other information element (e.g. Called party number) shall be coded in accordance with ECMA-165.
6.3.3
Messages The transport mechanism is based on call-independent signalling connection (connection-oriented).The Facility information element shall be conveyed in the FACILITY message as specified in clause 10 of ECMA-165.
6.4
State definitions The procedures for each PINX in the network are written in terms of the following conceptual states existing within the SYNC-SIG control entity in that PINX.
6.4.1
States at the Requesting PINX
6.4.1.1
SYNC-Idle This state exists when the connection for synchronization is not established (exchange of information is not possible).
6.4.1.2
SYNC-Active This state exists when the connection for synchronization is established (exchange of information is possible).
6.4.1.3
SYNC-Wait This state exists when the connection is established and a synchronizationRequest invoke APDU is sent to the Destination PINX and the response is not yet received.
6.4.2
States at the Destination PINX
6.4.2.1
SYNC-Idle This state exists when the connection for synchronization is not established (exchange of information is not possible).
6.4.2.2
SYNC-Active This state exists when the connection for synchronization is established (exchange of information is possible).
6.5
Signalling procedures Annex B contains examples of message sequences of the signalling procedures.
6.5.1
Actions at the Requesting PINX The SDL representation of procedures of the Requesting PINX is shown in C.1 of annex C. NOTE Choice of information to request by the Requesting PINX and actions in the Synchronization Entity on receipt or absence of response from the Destination PINX are to be made in conformance with ISO/IEC 11573 and are outside the scope of this Standard.
6.5.1.1
Normal procedures In state SYNC-Idle, on request of the Synchronization Entity the SYNC-SIG Control entity shall invoke SYNC-SIG towards an adjacent PINX. The Requesting PINX shall act as an Originating PINX and establish a call-independent signalling connection (connection-oriented) towards the Terminating PINX using the specific called party number given by the Synchronization entity. The SYNC-SIG Control entity shall inform the Synchronization Entity when the connection is established and enter state SYNC-Active. Only the call reference of this call-independent signalling connection shall be used to transport SYNC-SIG operations. On
- 5 -
request of the Synchronization Entity, the SYNC-SIG Control entity releases the connection towards the adjacent PINX and SYNC-SIG enters state SYNC-Idle. In states SYNC-Wait and SYNC-Idle, requests from the Synchronization Entity for sending information to the adjacent PINX are ignored. In SYNC-Active state, if the Synchronization Entity requests for sending information not requiring a response (free-running, idle), the Requesting PINX shall send a synchronizationInfo invoke APDU, and remain in state SYNC-Active. In state SYNC-Active, if the Synchronization Entity requests for sending information requiring a response from the Destination PINX (enslavement or holdon request), the Requesting PINX shall send a synchronizationRequest invoke APDU, start timer T1, and enter state SYNC-Wait. In state SYNC-Wait, on receipt of the synchronizationRequest return result APDU from the Destination PINX, the Requesting PINX shall convey the result to the Synchronization Entity, stop timer T1, and enter state SYNC-Active. In state SYNC-Wait, if the connection is released, the Requesting PINX shall inform its Synchronization Entity, stop timer T1, and enter state SYNC-Idle. In state SYNC-Active, if the connection is released by the adjacent PINX, the Requesting PINX shall inform Synchronization Entity and enter state SYNC-Idle. 6.5.1.2
Exceptional procedures In state SYNC-Wait, on receipt of the synchronizationRequest return error or reject APDU from the Destination PINX, the Requesting PINX shall inform the Synchronization Entity, stop timer T1, and enter state SYNC-Active. If timer T1 expires in state SYNC-Wait, the Requesting PINX shall inform the Synchronization Entity, and enter state SYNC-Active.
6.5.2
Actions at the Destination PINX The SDL representation of procedures of the Destination PINX is shown in C.2 of annex C. NOTE Choice of response to send by the Destination PINX and actions in the Synchronization Entity on receipt of requests from the Requesting PINX are to be made in conformance with ISO/IEC 11573 and are outside the scope of this Standard.
6.5.2.1
Normal procedures The call reference of the call-independent signalling connection that was established by the Requesting PINX shall be used to transport SYNC-SIG operations. The SYNC-SIG Control entity shall inform the Synchronization Entity when the connection is established and enter state SYNC-Active. In state SYNC-Active, on receipt of the synchronizationRequest invoke APDU or synchronizationInfo invoke APDU from the Requesting PINX, the Destination PINX shall convey the information to the Synchronization Entity and remain in state SYNC-Active. In state SYNC-Active, if the Synchronization Entity requests sending a response to a synchronizationRequest invoke APDU, the Destination PINX shall send a synchronizationRequest return result APDU to the Requesting PINX and remain in state SYNC-Active. On request of the Synchronization Entity, the Destination PINX shall release the connection towards the Requesting PINX and enter state SYNC-Idle. In state SYNC-Active, if the connection is released by the adjacent PINX, the Destination PINX shall inform the Synchronization Entity and enter state SYNC-Idle.
6.5.2.2
Exceptional procedures If a synchronizationRequest invoke APDU cannot be accepted a synchronizationRequest return error APDU shall be returned.
6.6
Impact of interworking with public ISDNs Not applicable.
6.7
Impact of interworking with non-ISDNs Not applicable.
- 6 -
6.8
Protocol interactions between Synchronization and supplementary services and ANFs Not applicable.
6.9 6.9.1
Parameter values (timers) Timer T1 Timer T1 operates at the Requesting PINX in state SYNC-Wait. Its purpose is to protect against the absence of a response to the synchronizationRequest invoke APDU. Timer T1 shall have a value not less than 15 s.
- 7 -
Annex A (normative)
Protocol Implementation Conformance Statement (PICS) Proforma
A.1
Introduction The supplier of a protocol implementation which is claimed to conform to this Standard shall complete the Protocol Implementation Conformance Statement (PICS) proforma. A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of which capabilities and options of the protocol have been implemented. The PICS can have a number of uses, including use:
A.2 A.2.1
-
by a protocol implementer, as a check-list to reduce the risk of failure to conform to the standard 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 PICS proforma;
-
by the user (or potential user) of the implementation, as a basis for initially checking the possibility of interworking with another implementation (note that, while interworking cannot 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 asses the claim for conformance of the implementation.
Instructions for completing the PICS proforma General structure of the PICS proforma The PICS proforma is a fixed-format questionnaire divided into subclauses each containing a group of individual items. Each item is identified by an item number, the name of the item (question to be answered) and the reference(s) to the clause(s) that specifies (specify) the item in the main body of this Standard. The “Status” column indicates whether an item is applicable and, if so, whether support is mandatory or optional. The following terms are used: m
mandatory (the capability is required for conformance to the protocol);
o
optional (the capability is not required for conformance to the protocol, but if the capability is implemented it is required to conform to the protocol specifications);
o.<n>
optional, but support of at least one of the group of options labelled by the same numeral <n> is required;
x
prohibited;
c.<cond>
conditional requirement, depending on support for the item or items listed in condition <cond>;
<item>:m
simple conditional requirement, the capability being mandatory if item number <item> is supported, otherwise not applicable;
<item>:o
simple conditional requirement, the capability being optional if item number <item> is supported, otherwise not applicable.
Answers to the questionnaire items are to be provided either in the “Support” column, by simply marking an answer to indicate a restricted choice (Yes or No) or in the “Not Applicable” column (N/A).
- 8 -
A.2.2
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.
A.2.3
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 requirements. 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. A possible reason for the situation described above is that a defect in the Standard has been reported, a correction for which is expected to change the requirement not met by the implementation.
- 9 -
A.3
PICS proforma for ECMA-245
A.3.1
Implementation identification
Supplier Contact point for queries about the PICS Implementation name(s) and version(s) Other information necessary for full identification, e.g. name(s) and version(s) for machines and/or operating systems; system name(s)
Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirement for full identification. The terms name and version should be interpreted appropriately to correspond with a supplier’s terminology (e.g. type, series, model).
A.3.2
Protocol summary
Protocol version
1.0
Addenda implemented (if applicable) Amendments implemented Have any exception items been required (see A.2.3)?
Date of Statement
No [ ] Yes [ ] (The answer Yes means that the implementation does not conform to this Standard)
- 10 -
A.3.3
Procedures
Item
Question/feature
Reference
Status
A1
Support of ECMA-165 procedures at Requesting PINX
6.2
m
Yes [ ]
A2
Support of ECMA-165 procedures at Destination PINX
6.2
m
Yes [ ]
A3
Signalling procedures at Requesting PINX
6.5
m
Yes [ ]
A4
Signalling procedures at Destination PINX
6.5
m
Yes [ ]
A.3.4
N/A
Support
Coding
Item
Question/feature
Reference
Status
B1
Receipt of synchronizationRequest invoke APDU and sending of return result and return error APDUs
6.3
m
Yes [ ]
B2
Sending of synchronizationRequest invoke APDU and receipt of return result and return error APDUs
6.3
m
Yes [ ]
B3
Receipt of synchronizationInfo invoke APDU
6.3
m
Yes [ ]
B4
Sending of synchronizationInfo invoke APDU
6.3
m
Yes [ ]
Reference
Status
6.9
m
A.3.5 Item C1
N/A
Support
Timers Question/feature Support of timer T1
N/A
Support Yes [ ] Value [.....]
- 11 -
Annex B (informative)
Examples of Message Sequences
This annex describes some typical message flows of Synchronization. The following conventions are used in the figures of this annex.
xxx.inv
:
Invoke APDU for operation xxx
xxx.res
:
Return result APDU for operation xxx
1. The figures show messages exchanged via Protocol Control between PINXs involved in Synchronization. 2. Only the relevant information content (i.e. remote operation APDUs) is listed below each message name. The Facility information elements containing remote operation APDUs are not explicitly shown. Information with no impact on Synchronization is not shown.
- 12 -
B.1
Message sequences for Synchronization Figures B.1, B.2 and B.3 show examples of messages sequences for clock synchronization.
Figure B.1 - Establishment and release of call-independent signalling connection for Synchronization between two adjacent PINXs
- 13 -
Figure B.2 - Successful clock enslavement of PINX A to adjacent PINX B
Figure B.3 - End of enslavement - PINX A informs PINX B that it is now in free-running state (it is running with its own clock source)
- 14 -
- 15 -
Annex C (informative)
Specification and Description Language (SDL) Representation of Procedures
The diagrams in this annex use the Specification and Description Language defined in ITU-T Rec. Z.100 (1993). Each diagram represents the behavior of a Synchronization Control entity at a particular type of PINX. In accordance with the protocol model described in ECMA-165, the Control entity uses, via the Coordination Function, the services of Generic Functional Procedures Control. Where an output symbol represents a primitive to the Coordination Function, and that primitive results in a message being sent, the output bears the name of the message and any remote operations APDU(s) or notification(s) contained in that message. Where an input symbol represents a primitive from the Coordination Function and that primitive is the result of a message being received, the input signal bears the name of the message and any remote operation APDU(s) or notification(s) contained in that message. The following abbreviations are used: xxx.inv
:
Invoke APDU for operation xxx
xxx.res
:
Return result APDU for operation xxx
xxx.err
:
Return error APDU for operation xxx
xxx.rej
:
Reject APDU for operation xxx
NOTE All operations are in the Facility information element and carried in the FACILITY message. This is not shown in the boxes of the diagram.
- 16 -
C.1
SDL representation of SYNC-SIG at the Requesting PINX Figure C.1 shows the behaviour of a SYNC-SIG Control entity within the Requesting PINX. Input signals from the right and output signals to the right represent primitives from and to the Coordination Function in respect of messages being received and sent. Input signals from the left and outputs signals to the left represent primitives between the Synchronization Control entity and the entity which controls synchronization in the PINX.
Figure C.1 - SDL representation of SYNC-SIG at the Requesting PINX
- 17 -
C.2
SDL representation of SYNC-SIG at the Destination PINX Figure C.2 shows the behaviour of a SYNC-SIG Control entity within the Destination PINX. Input signals from the right and output signals to the right represent primitives from and to the Coordination Function in respect of messages being received and sent. Input signals from the left and outputs signals to the left represent primitives between the Synchronization Control entity and the entity which controls synchronization in the PINX.
Figure C.2 - SDL representation of SYNC-SIG at the Destination PINX
.
.
.
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 E245-DOC.EXE) and as an Acrobat PDF file (file E245-PDF.PDF). File E245-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-245 is available free of charge in printed form and as a file. See inside cover page for instructions