Subject: Re: [SUA issues 3,6,7] text

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Sep 2001 18:49:43 -0500

John,

In some of these parameters you refer to excess bits as "unused" and
in others you refer to them as "spare".  Is there any difference
between "spare" and "unused"?

Many parameters which do not use a full 8 bits have excess bits
within the defined field that are neither referred to as "unused" or
"spare" but are clearly excess bits.  What is the difference between
"unused", "spare", and these excess bits in the defined field?

There is no description on any restrictions of how "spare", "unused"
and excess field bits are to be coded.  For example, can they be coded
to random values?

Please see comments below...

On Mon, 03 Sep 2001, John Loughney wrote:

> Hi all,
> 
> Here is my (final) proposal for these issues.  Please check if they
> are sufficient.
> 
> John
> 
> 3.10.1 SS7 Hop counter 
> 
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |         Tag = 0x0101          |             Length = 8        |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                unused                         | SS7 Hop Count |  
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> SS7 Hop Counter (3.18/Q.713)
> 
> The value of the SS7 Hop Counter is decremented with each global title
> translation and should be in the range 15 to 1.
> 
> Optional in CLDT, CLDR, CORE.
> 
> ========================================================================
> 
> 3.10. Importance  
> 
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |         Tag = 0x0113          |             Length = 8        |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                  unused                       |   Importance  |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Importance (3.19/Q.713)
> 
> Possible values of the Importance Parameter are between 0 and 7, where the
> value of 0 indicates the least important and 7 indicates the most important.
> 
> Optional in CLDT, CLDR, CORE, COAK, COREF, RELRE, RELCO.
> 
> ========================================================================
> 
> 3.10.c Message Priority (or Priority) 
> 
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |         Tag = 0x0114          |             Length = 8        |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                 spare                         |  Msg Priority |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Priority
> 
> Priority value ranges from 0 to 3.  If the Priority value has not been
> specified by the SCCP user, it should be set to 0xFF. The SG MAY take the
> priority into account for determining the MTP message priority.  In the
> all-IP case, this parameter MAY be used.
> 
> The Message Priority parameter is optional in the CLDT, CLDR, CORE, COAK,
> CODT messages.  However, for networks which support Message Priority message
> priorities (e.g, ANSI), this parameter MUST be included but it is not
> required for those which don't (e.g., International).  
> 
> 
> Optional in CLDT, CLDR, CORE, COAK
> ========================================================================
> 
> 3.10.d Protocol Class
> 
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |         Tag = 0x0115          |             Length = 8        |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                  spare                        |  Protocol Cl. |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Protocol class (3.6/Q.713)
> 
> Bits 1-2 indicate the protocol class.
> 
> 		Value	Description 
>       	  0       Class 0 (connectionless service) 
>       	  1       Class 1 (connectionless service) 
>       	  2       Class 2 (connection-oriented service) 
>       	  3       Class 3 (connection-oriented service)
> 
> Bit 8 indicates the use of the return on error procedure.
> 
> 		Value	Description 
>       	 0x0		No special options
>       	 0x1		Return message on error
> 
> 		Bits 3-7 are spare and should be coded zero.
> 
> Mandatory in CR, CC, IT, UDT, XUDT, LUDT

Should read:

  Mandatory in CORE, COAK, COIT, CLDT

> Optional in CODT

Why is this optional in CODT?  Connections cannot change protocol
classes mid connection...  Also, it has been clearly laid out that
protocol class can be derived from the presence or absence of the
sequence parameter in CODT messages.

Strike the Optional.

> 
> ========================================================================
> 
> 3.10.e Sequence Control
> 
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |         Tag = 0x010e         |             Length = 8         |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                                               | Seq  Control  |  
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Sequence Control (1.1.2/Q.714)
> 
> The field is coded with the value of the sequence control parameter
> associated with a group of messages and are chosen so as to ensure  proper
> loadsharing of message groups over SLS values while ensuring that sequence
> control values within message groups have the sequence control value coded
> with the same value as the initial message of the message group.
> 
> 
> Mandatory in CLDT, CORE, COAK, COIT.

For decoupled operation, sequence control needs to be

  Optional in all other CL and CO messages.

To support non-final GTT, sequence control must be provided in a all
CL and CO messages which do not terminate at the peer.

> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]