Subject: [SUA Issue 6] Flags Parameter

From: [email-masked]
Date: Tue, 14 Aug 2001 11:26:51 +0300

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?

--Brian

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

------_=_NextPart_000_01C12488.813391E2--

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

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 14 Aug 2001 17:50:43 +0200

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

--brian
------_=_

John,

--Brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 11:21:26 -0500

Gery,

That sounds ok to me.  Let's see the text.

--brian

Verwimp Gery wrote:                                       (Tue, 14 Aug 2001 17:50:43)
> Fax: +32 14 25 3212
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: [email-masked]
Date: Tue, 28 Aug 2001 15:06:41 +0300

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.

> Sent: 14 August, 2001 19:21
> To: sigtran
> Subject: Re: [SUA Issue 6] Flags Parameter
> 
> 
> Gery,
> 
> > List-Unsubscribe: 
> <mailto:[email-masked]>
> > Content-Type: text/plain
> > 
> > John,
> > 

---

---

From: [email-masked]
Date: Tue, 28 Aug 2001 15:40:43 +0300

Hi all,

I also added it to the CODT message as mandatory.

JOhn

> From: ext [email-masked] 
> Sent: 28 August, 2001 15:07
> To: sigtran
> Subject: RE: [SUA Issue 6] Flags Parameter
> 
> 
> Hi all,
> 
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 28 Aug 2001 15:25:00 +0200

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,

QoS is manditory for:

Optional for:
	RELRE

Does that cover it?

Below is the text.  

John

   0                   1                   2                   3

Priority

Importance (3.19/Q.713)

		Value	Description 

		Value	Description 
      	 0x0		No special options

---

---

---

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

John,

I liked your previous proposal with the parameters split out better
and there is one aspect missing from this approach:

All these fields are optional on a different basis.  What value of
Priority is coded when the MP has not been specified by the
SCCP-User?  Must SUA always populate Priority?  When it is not
populated what is its value? 0xff?  The same is true for Importance.
Importance is an optional parameter in all SCCP messages and its
absence indicates a default behavior which is implementation
specific.  No importance parameter could be treated by an
implementation as importance(7).  What value will Importance have
when not populated?  0xff?  The same is true for Sequence Control.
Sequence Control is not required on some messages where MP is
required (e.g, CODT).  The SUA at the ASP should not be required to
populate Sequence Control in each meesage where the flags parameter
occurs.  What value is it when no populated?  0xff?  Protocol class
is more than optional, it cannot even be optionally included in some
messages where the others are required.  What protocol class setting
means unspecified?  0xff?

--brian

John Loughney wrote:                                         (Tue, 28 Aug 2001 15:06:41)

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

---

---

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

Hi Brian,

> messages where the others are required.  What protocol class setting

As I have had requests to keep the SS7 QoS parameter similar to the
previous Flags incarnation, based on people's implementations, I am
going with what I have recently suggested.  However, your points
as far as the value for the fields when not populated are noted &
will be reflected in the text.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 06:31:20 -0500

John,

That's what I meant on the previous note.  It should also be noted
in each messages in which the flags parameter occurs which fields
of the flags parameter must be populated and when (i.e., when is
the field mandatory or optional or not required and when optional
under what conditions it is necessary that each field be populated).
You could use the notes I provided on mandatory and optional for
the previous proposal where these parameters were broken out.

Broken out parameters would be far more consistent with the rest
of the protocol and the formats used for identifying presence,
whether optional or mandatory.  Backwards compatibility between
SUA draft versions should not even be a consideration: anyone who
implements a draft version must be fully congnisant of the risks.

--brian

John Loughney wrote:                                         (Wed, 29 Aug 2001 12:52:01)

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

---

---

From: [email-masked]
Date: Wed, 29 Aug 2001 15:59:26 +0300

Hi Brian,

> the previous proposal where these parameters were broken out.

OK.
 
> implements a draft version must be fully congnisant of the risks.

Yes, but we are ruled by consensus.  When I proposed the broken-out
procedures, even you didn't mail me supporting it.  I did receive
a number of requests that they stay as close to the existing flags
parameter as possible, I have gone with the consensus.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 08:30:49 -0500

John,

John Loughney wrote:                                         (Wed, 29 Aug 2001 15:59:26)
> parameter as possible, I have gone with the consensus.

I mailed corrections to the broken out proposal (would I correct it
it I disagreed with it)?

I didn't know that concensus was judged on the basis of e-mails
which were personally addressed to you.  There has not been a
single objection on this thread (or in this working group) to
broken-out parameters.  In fact, Al Varney gave a good criticism
of the old flags format and why lumping them all together didn't
make much sense on the discussions leading up to SUAv7.  Where
was the support for leaving them together then?  Where is it now?

Could some of those messages be posted to the WG before the matter
is decided (seemingly) behind closed doors?

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 29 Aug 2001 14:03:57 +0200

resend ...

John,

I like this proposal because it groups all QoS parameters. To answer Brian's
questions below :

- priority : this is only required if interworking with an MTP network
variant like ANSI, Japan (?) or other national variants using the national
congestion method exists. This is clear from the RC. In other cases, it is
coded 0 and ignored.

And even whether the priority is populated or not, the SG (SCCP/SUA complex)
finally decides how to populate the message priority bits in the SIO. In
Telcordia GR-246, a table is presented based on MTP/SCCP message type.

- importance : mandatory, value between 0..7.

- sequence control : mandatory, for protocol classes 2 & 3, SUA keeps the
same sequence control parameter for all CO messages of the same connection.

- protocol class : mandatory. 0 or 1 for CL, 2 or 3 for CO messages. Return
option possible for CL messages.

So, except for the priority, when the QoS is there all these fields are
populated.

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: dinsdag 28 augustus 2001 21:32
To: sigtran
Subject: Re: [SUA Issue 6] Flags Parameter

John,

--brian

John Loughney wrote:                                         (Tue, 28 Aug
2001 15:06:41)

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

---

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 29 Aug 2001 10:34:29 +0200

John,

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: dinsdag 28 augustus 2001 21:32
To: sigtran
Subject: Re: [SUA Issue 6] Flags Parameter

John,

--brian

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

---

---

---

From: Lyndon Ong <[email-masked]>
Date: Wed, 29 Aug 2001 09:19:42 -0700 (PDT)

--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> which were personally addressed to you.  > 

Brian is right about this, we need to keep this 
process open/visible as much as we can.

Cheers,

L. Ong

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 14:21:20 -0500

Verwimp,

Verwimp Gery wrote:                                       (Wed, 29 Aug 2001 14:03:57)
> congestion method exists. This is clear from the RC. In other cases, it is

We were agreed that MP was not required as a parameter for all message types
in even an ANSI network.

> Telcordia GR-246, a table is presented based on MTP/SCCP message type.

There is a difference at the SG for the following cases:

	the parameter is populated and is consistent with T1.111/GR-246
	the parameter is populated and conflicts with T1.111/GR-246
	the parameter is not populated

The SG must be permitted to distinguish between these three cases and if
packed parameters are used, each field requires a "non-populated" or
"unspecified" coding to handle the case where the parameter would be optional
and no included for unpacked parameters.

> - importance : mandatory, value between 0..7.

What coding when it is not specified?  The SG needs to distinguish between

	importance is present (to be added) to the message and has
	a value between 0 and 7.

	importance is not to be added to the message.

Importance is an optional parameter in SCCP messages.  SUA messages will
have a hard time representing SCCP PDUs in the IPSP case if the presence
or absence of importance cannot be indicated in the SUA message.

> same sequence control parameter for all CO messages of the same connection.

Are you saying that sequence control can be ignored in some messages?  Then
why should it be mandatory that it be set for those messages?

> option possible for CL messages.

Same as sequence control.  Can this value be ignored in some messages?  If
so, why required the sender to populate it in those cases?

> So, except for the priority, when the QoS is there all these fields are

You missed that importance is optional in SCCP and needs to be optional
in SUA messages to reflect that.  MP needs to distinguish between above
cases and still needs to be optional for some messages and not for others.
Having a code point for "unspecified" on sequence control and protocol
class would increase interoperability for those implementation which do
not care to place redundant information in each message and may rely on
the fact that the receiver ignores values in some messages.

These problems are precisely what makes packing four independent parameters
into one awkward and problematic (to the draft writer).

--brian

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

---