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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Aug 2001 23:53:36 -0500

John,

Here was my comments... (Great mail server.)

--brian

Brian F. G. Bidulock wrote:                        (Wed, 22 Aug 2001 18:27:24)
> John,
> 
> Please see comments below...
> 
> John Loughney wrote:                                         (Wed, 22 Aug 2001 14:04:19)
> > Hi all,
> > 
> > There was a suggestion to split up the flags parameter into components.
> > 
> > Please see if these parameters are sufficient.
> > 
> > John
> > 
> > 3.10.x 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 = 0x010x          |             Length = 8        |
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |                unused                         |  Hop Counter  |  
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > Hop Counter (3.18/Q.713)
> > 
> > The value of the hop counter is decremented with each global title
> > translation, and should be in the range 15 to 1.
> > 
> > mandatory in CLDT, CLDR, CORE.
> 
> Because Hop Count is optional in UDT and UDTS and optional in CR for
> SCCP, Hop Counter should be optional in CLDT, CLDR and CORE, not
> mandatory.
> 
> Because Hop Counter appears to have some non-SCCP (e.g. IPSP) uses,
> is there any reason to restrict it to 8 bits?  Why not 32?  We have
> lots of parameters that have less than 15 code-points but which are
> 32-bits.  Might as well make Hop Counter 32 bits.
> 
> > 
> > 3.10.y Importance & 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 = 0x010y          |             Length = 8        |
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |          Importance           |        Message Priority       |
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > Importance (3.19/Q.713)
> > 
> > Bits 1-3 are coded to indicate the importance of the messages. The values
> > are between 0 and 7, where the value of 0 indicates the least important and
> > 7 indicates the most important.
> > 
> > Bits 4-8 are spare bits and should be coded zero.
> > 
> > mandatory in CLDT, CLDR, CORE, COAK, COREF, RELRE.
> 
> Because Importance is optional in ITUT SCCP messages and does not
> exist in ANSI SCCP messages, Importance should be optional in
> CLDT, CLDR, CORE, COAK, COREF, RELRE, and you missed RELCO.
> 
> Message Priority should only be required for users with MTP's
> which support message priorities (e.g, ANSI) but not required
> for those which don't (e.g., International).  Message priority
> should be optional (but required where MTPs support it) on
> at least CLDT, CLDR, CORE, COAK, CODT.
> 
> Because MP has different requirements to Importance and Importance
> is optional on a number of messages where MP may be required, it
> is not possible to tell whether Importance has actually been included
> in the message or is just there because MP was required.  These
> two parameters need to be split or a coding provided to indicate
> that either the Importance or Message Priority are unspecified.
> Might as well bite the bullet and split these last two out as well.
> 
> When they are split, they might as well be 32 bit values.  The text
> referring to "Bits 4-8" is no longer applicable (you have Importance
> as a 16-bit value now, not 8).
> 
> Importance should be optional in CLDT, CLDR, CORE, COAK, COREF, RELRE
> and RELCO.
> 
> Message Priority should be optional (but required in some networks)
> in CLDT, CLDR, CORE, COAK, CODT and COED (<-hint).  Message Priority
> could be made optional for all CL and CO messages.
> 
> > 
> > 3.10.z 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 = 0x010z          |             Length = 8        |
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |                  unused                       |  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.
> 
> Why the unused?  I suggest we make it 32 bits.
> 
> 
> > 
> > 3.10.zz 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 = 0x010zz         |             Length = 8        |
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   |                        Sequence  Control  				|
> >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > Mandatory in CLDT, CORE, COAK, COIT.
> 
> For decoupled operation, sequence control should be optional in all
> CL and CO messages (and required in all messages under decoupled
> operation).
> 
> > 
> > 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.
> > 
> 
> --brian
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

-- 
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]