Question 12/XI - Transactions Capabilities

Considering

(a) that signalling networks using Signalling System No. 7 Transactions
Capabilities will become widespread;

(b) that the TC protocol may need enhancing to support a variety of new
applications, basic and supplementary services, OMAP, and the evolving
Telecommunications Management Network (TMN);

(c) that the Quality of Service required by the various applications
needs to be mapped onto the functionality of TC, and that a connection-
based network service may be needed to guarantee the Quality of Service
required by some applications;

(d) that TC will be used in different types of network nodes, e.g.,
exchanges, service control points and OA&M centres, all requiring
standard functions and interfaces to be provided;

(e) that a means may need to be devised to enable the transfer of
information via TC to be charged;

(f) that the requirements of other Recommendations may
impact on TC, e.g.:

- the SCCP, being the primary network service provider for TC,

- other network services used in place of the SCCP, which may provide a
different Quality of Service to Signalling System No. 7,

- the X-Series protocols upon which TC is based,

- transaction oriented protocols used between the subscriber terminal
and network equipment,

- evolving OSI system and layer management conceptsprotocols;

(g) that is is essential to maintain compatibility between different
versions of the TC protocol taking into consideration the issues
identified in Annex 1 to this Question;

(h) that performance requirements of TC need to be specified,

What additional Recommendations and what enhancements to existing
Recommendations are necessary to meet the current and future
requirements of Transaction Capabilities?
ANNEX 1

(to Question 12/XI)

Ensuring compatibility between different versions of TC

1. Introduction

A possible method of ensuring compatibility between different versions
of TC would be to include protocol and version information in the
transaction portion of a message. This annex examines this approach.

In the following analysis, node "A" attempts to initiate a transaction
with node "B".

2. Options

2.1 Include no information

a) no need to specify data or procedures;

b) how should B process a new information element sent by a later
version of A?

c) unable to use common functions for a number of different X.209210
based protocols (no protocol identifier).

2.2Include only a protocol identifier (object identifier) in initial
message - no version information

a) need data and procedure;

b) TC should receive only messages with the protocol identifier = TCAP.
Any other message would be discarded. A reply is not possible, since B
does not understand A's protocol. Report problem to management entry;

c) enables functions to be shared amongst many X.409410 based protocols;

d) gives a "sanity check" on the protocol being used for the
transaction;

2.3 Include protocol identifier and version identifier

a) information contained in first message from A to B (BEGIN);

b) enables B to check protocol and version compatibility with A;

c) if B is same version - continue transaction;

d) if B is a later version but it can "drop back" to A's version, it
should do so. Transaction continues;

e) if B is an earlier version than A, then need to "drop back" at A. B
indicates this by responding to A with an ABORT message, which includes
B's version identity;

f) A should then initiate a new transaction with B by "dropping back" to
B's versions if possible;

2.4As per 2.3, but in the ABORT message indicate all the versions of the
protocol that B supports

a) as in 2.3;

b) as in 2.3;

c) as in 2.3;

d) as in 2.3;

e) if B supports other version(s) then it informs A. B sends an ABORT
message to A which contains a "bit-map" indicating which version(s) of
the protocol B supports;

f) A selects a mutually acceptable version of the protocol (if any) and
initiates a new transaction with A;

3. Issues to be resolved

3.1 Is protocolversion information needed in TC messages to ensure
ongoing compatibility?

If so:

3.2 a) should the version information be contained within the protocol
identifier (i.e. same object identifier) or be contained in another
separate element?

b) what form should the version information have in the ABORT message -
a simple version number, or version indication(s) (i.e. bit map)?

c) what procedures are necessary?

3.3 If this general approach is not used, then what alternative methods
can be used?