Subject: [SUA Issue 6] Flags Parameter - closed

From: [email-masked]
Date: Tue, 28 Aug 2001 16:47:45 +0300

Hi all,

This is closed.  I have added the SS7 QOS parameter to the following
messages:

Optional
RELRE
RELCO
RESRE
RESCO

Mandatory
CLDT
CLDR
COAR
COAK
COREF
CODT
CODA
COERR
COIT

John

> -----Original Message-----
> From: ext Verwimp Gery [mailto:[email-masked]]
> Sent: 28 August, 2001 16:25
> To: sigtran
> Subject: RE: [SUA Issue 6] Flags Parameter
> 
> 
> John,
> 
> It's probably a good idea to have QoS as optional parameter 
> for the other CO
> messages as well for the decoupled approach.
> 
> -Gery
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: dinsdag 28 augustus 2001 14:07
> To: sigtran
> Subject: RE: [SUA Issue 6] Flags Parameter
> 
> 
> Hi all,
> 
> The FLAGS parameter has now mutated to QoS.  Priority has 
> been added as a
> field.  Hop Counter has 'hopped' to a new parameter, see 
> follow-on mail.
> 
> QoS is manditory for:
> 	CLDT, CLDR, CORE, COAK, COIT
> 
> Optional for:
> 	RELRE
> 
> Does that cover it?
> 
> Below is the text.  
> 
> Can I consider this to be closed?
> 
> John
> 
> 3.10.1 Quality of Service 
> 
> The Quality of Service (QoS) parameter is a conglomerate of following
> parameters, described in ITU-T Recommendation Q.713:
> 
>    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        |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |   Priority    |  Importance   |  Seq. Control |  Protocol Cl. |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Priority
> 
> Priority value ranges from 0 to 3.
> 
> 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.
> 
> Sequence Control (1.1.2/Q.714)
> 
> Bits 1-5 are 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.
> 
> Bits 6-8 are spare bits and should be coded zero.
> 
> 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.
> 
> 
> 
> > -----Original Message-----
> > From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: 14 August, 2001 19:21
> > To: sigtran
> > Subject: Re: [SUA Issue 6] Flags Parameter
> > 
> > 
> > Gery,
> > 
> > That sounds ok to me.  Let's see the text.
> > 
> > --brian
> > 
> > Verwimp Gery wrote:                                       
> > (Tue, 14 Aug 2001 17:50:43)
> > > Hi,
> > > 
> > > I guess this is about the addition of a sequence control 
> parameter ?
> > > 
> > > Proposal for layout (hop counter split out as separate 
> > parameter, which is
> > > optional for CL msgs and CORE) :
> > > 
> > > +--------+--------+--------+--------+
> > > |  Tag = QOS      |  Length = 8     |
> > > +--------+--------+--------+--------+
> > > | prio.  | impor. | seqctr.| prot.  |
> > > +--------+--------+--------+--------+
> > > 
> > > priority = range (0..3)
> > > importance = range (0..7)
> > > sequence control parameter = range (0..255)
> > > protocol class as already defined.
> > > 
> > > Proposal to keep routing context separate because of use in 
> > other messages
> > > than SUA-CL or CO, and it may be optional in cases where no 
> > confusion
> > > between routing contexts is possible.
> > > 
> > > Regards,
> > > 
> > > ____________________________
> > > 
> > > Gery Verwimp
> > > > SIEMENS ATEA
> > > > ICN D CS D5
> > > > 
> > > > Tel. : +32 14 25 3424
> > > Fax: +32 14 25 3212
> > > mailto:[email-masked]
> > > ____________________________________
> > > 
> > > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: dinsdag 14 augustus 2001 10:27
> > > To: sigtran
> > > Cc: [email-masked]
> > > Subject: [SUA Issue 6] Flags Parameter
> > > 
> > > 
> > > Resend
> > > 
> > > -----Original Message-----
> > > From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: 06 August, 2001 22:46
> > > To: Loughney John (NRC/Helsinki); Lyndon Ong
> > > Subject: Fwd: SUAv7: Flags Parameter
> > > 
> > > 
> > > Attached is an issue for SUA Last Call.
> > > 
> > > It is included in the addition of optional parameters
> > > for decoupled operation.
> > > 
> > > --brian
> > > ------_=_
> > > From: [email-masked]
> > > Reply-To: [email-masked]
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: SUAv7: Flags Parameter
> > > Date: Thu, 26 Jul 2001 17:48:14 +0300
> > > MIME-Version: 1.0
> > > X-Mailer: Internet Mail Service (5.5.2652.78)
> > > List-Unsubscribe: 
> > <mailto:[email-masked]>
> > > Content-Type: text/plain
> > > 
> > > John,
> > > 
> > > Actually, because a decoupled SG cannot keep state concerning
> > > the SLS value to use towards the SS7 network, the Flags parameter
> > > should be mandatory on all CONS and CLNS messages.  Given that
> > > Flags and Routing Context will then be mandatory on all CONS
> > > CLNS messages, would it not be a good idea just to make them
> > > a permanent header like the IID in M2UA?
> 
> 
> ---
> You are currently subscribed to sigtran as: 
> [email-masked]
> To unsubscribe send a blank email to
> [email-masked]
> 
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 14:35:29 -0500

John,

Not quite closed...  You need to provide codepoints for each parameter
for which the value of the parameter is not populated because it is
optional for the message in which it is included.

--brian

John Loughney wrote: (Tue, 28 Aug 2001 16:47:45)

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

---

---

From: [email-masked]
Date: Wed, 29 Aug 2001 12:44:24 +0300

Hi Brian,

> optional for the message in which it is included.

Sorry, having a little bit of trouble parsing your comment.

Do you mean that the SS7 QoS paramter in the following messages 

> > RESCO

Or are you saying that certain messages need additional info?

John

---