Title:                             Extension Capability of Mobile SNDCF Header
PDR Reference:                     99090002
SARPs Document Reference:          ICS SARPs, Section 5.7.6.2.1 and 5.7.6.2.2
Status:                            PROPOSED
Impact:                            C (Clarrification)
PDR Revision Date:                 SUBMITTED --> ACCEPTED (28/09/99)
                                   ACCEPTED --> PROPOSED (10/11/99)
PDR Submission Date:               14 September 1999
Submitting State/Organisation:     Germany/DFS
Submitting Author Name:            Klaus-Peter Graf
Submitting Author E-mail Address:  klaus.graf@unibw-muenchen.de
Submitting Author Supplemental
Contact Information:
SARPs Date:                        SV 5 Edition 1
SARPs Language:                    English

Summary of Defect:
The current specification of the mobile SNDCF does not allow for octet extensions in the
SNDCF header in a backwards compatible way. Such extensions will be required to signal new
capabilities (e.g. maintenance of DEFLATE history window) which may be added to future
versions of the ATN SARPs.

To accommodate additional mobile SNDCF options in future editions of Sub-Volume 5 in a
backwards compatible way, the capability of extending the mobile SNDCF header is proposed
in the following SARPs amendment.

Assigned SME: Sub-Volume V SME (K.-P. Graf)

Discussion:
The approach to provide for an extension capability to the Mobile SNDCF header has been
agreed by IDG/2. A PDR has been chosen as method of promulgating this intended change in
order to inform implementors early about the direction in which Sub-Volume 5 is intended
to be progressed to provide backwards-compatible extensibility in the long term.

The proposed solution extends the parameter block of the Call Request and Call Accept User
Data and has been specified along the following outline:

1) Format of the Call Request User Data:
a) The SNDCF Parameter block remains as specified in Editions 1 and 2. In particular the
definition of the length indicator field is unchanged and continues to indicate the number
of octets in the SNDCF parameter  block, from the version number field up to and including
(if present)  the maximum number of directory entries field.

b) The version number of the SNDCF Parameter  block is used to indicate the presence or
absence  of an additional SNDCF Parameter Extension Block. Version Number = 1 indicates
that no SNDCF Parameter Extension Block is present and the format of the Call Request User
Data remains as specified in Editions 1 and 2. Version Number = 2 indicates that an
additional SNDCF Parameter Extension Block is following the existing SNDCF Parameter
Block.

c) The SNDCF Parameter Extension Block consists of a (second) Length Indicator followed by
a sequence of TLV (Type-Length-Value)  encoded optional parameters.

d) The (second) Length Indicator is one octet-long, and indicates the total length of the
SNDCF Parameter Extension Block.

e) The SNDCF Parameter Extension Block may be followed by a "user data field", that can be
used to convey an ISH PDU.

When establishing a call, a Package 2 router may select to use Version 1 or Version 2 of
the SNDCF protocol. In the case, additional compression parameters have to be conveyed, it
will use Version 2. A Package 1 compliant  router that is called by a Package 2 compliant
router, will process  the SNDCF Parameter Block and will not accept the call, if the
Version Number is 2; it will respond with a Call Clear packet indicating "Version number
not supported" in the diagnostic code. This will allow  the calling Package 2 router to
re-establish the call with Version Number set to one, but without the additional
compression parameters.

2) Format of the Call Accept User Data:
a) One of the spare bits in octet 1 of the Call Accept user  data is used to indicate the
presence (if the bit set) or absence (if the bit is not set) of a subsequent SNDCF
Parameter Extension Block in the Call Accept user data

b) An SNDCF Parameter Extension Block will be present in the Call Accept User Data only if
a Call Requst packet with Version Number = 2 has been received. This insures backwards
compatibility between a calling Package 1 router and a called Package 2 router.

c) When present, the SNDCF Parameter Extension Block consists of a Length Indicator
followed by a sequence of TLV  (Type-Length-Value) encoded optional parameters.

d) The Length Indicator is one octet long and indicates the total length of the SNDCF
Parameter Extension Block.

e) The SNDCF Parameter Extension Block may be followed by a "user data field", that can be
used to convey an ISH PDU.

This approach allows for the extension of the SNDCF header to convey additional parameters
in a backwards compatible way, but at the cost of a second call establishment sequence, if
the calling router uses Version 2 of the SNDCF protocol and the calling router complies to

Edition 1 or 2 of the ICS SARPs.


Proposed SARPs Amendment:
See attached WordPerfect (Version 7) file 99090002.zip

Impact on Interoperability:
The SARPs amendment proposed in this PDR will provide for the necessary long-term
backwards compatibility mechanism when introducing new SNDCF capabilities in future SARPs
versions. The SARPs amendment is specified in a way that it will be backwards compatible
with implementations based on Edition 1 and 2 of Doc 9705. This backwards compatibility is

achieved by a mechanism which requires routers implementing this PDR to fall back to
version 1 of the SNDCF protocol (specified in Edition 1 and 2 of Doc 9705), when
recognising (from the diagnostic code of a received call clear packet) that the peer
router has not implemented this PDR.

SME Recommendation to CCB:

CCB Decision:  PDR Accepted (CCB-10)