Subject: [SUA issue 3] SCCP Message Priority - CLOSED

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

Hi all,

I have added this to the QoS parameter.  Does anyone think explanatory text
is needed?  Shall I add it to the parameter text?

John

Priority

Priority value ranges from 0 to 3.  The SG MAY take the priority into
account for determining the MTP message priority. In the all-IP case, this
parameter is ignored.

> -----Original Message-----
> From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 14 August, 2001 19:24
> To: sigtran
> Subject: Re: [SUA issue 3] SCCP Message Priority
> 
> 
> Gery,
> 
> That would be fine.  I agree with your reasoning behind the "MAY".
> 
> --brian
> 
> Verwimp Gery wrote:                                       
> (Tue, 14 Aug 2001 17:39:54)
> > Hi,
> > 
> > See also issue 6 : splitting up of Flags parameter in QOS 
> and hop counter
> > parameters.
> > 
> > No objection, but with following note :
> > 
> > The SG MAY take the priority into account for determining 
> the MTP message
> > priority. In the all-IP case, this parameter is ignored.
> > 
> > 
> > I put MAY, because there can be certain limitations to 
> maximum allowable
> > message priority based on message type (e.g. highest 
> priority "3" reserved
> > for MTP management messages TFC etc.) in the SS7 network.
> > 
> > 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 8:28
> > To: sigtran
> > Subject: [SUA issue 3] SCCP Message Priority
> > 
> > 
> > -----Original Message-----
> > From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: 06 August, 2001 22:40
> > To: Loughney John (NRC/Helsinki); Lyndon Ong
> > Subject: Fwd: SUA: SCCP Message Priority
> > 
> > 
> > This is an issue for SUA Last Call.
> > 
> > SUA must include Message Priority in all CO and CL messages.
> > 
> > --brian
> > 
> > --=20
> > ------_=_NextPart_000_01C12488.23F75549
> > 
> > From: [email-masked]
> > Reply-To: [email-masked]
> > To: [email-masked]
> > Subject: SUA: SCCP Message Priority
> > Date: Mon, 23 Jul 2001 21:01:56 +0300
> > MIME-Version: 1.0
> > X-Mailer: Internet Mail Service (5.5.2652.78)
> > List-Unsubscribe: 
> <mailto:[email-masked]>
> > Content-Type: text/plain
> > 
> > Hi,
> > 
> > Could someone please clarify whether SUA would allow ANSI 
> message priority
> > values to be conveyed between peer SUA/SUA Users.
> > 
> > Thanks
> > Ray
> > 
> > 
> > 
> > ---
> > You are currently subscribed to sigtran as: [email-masked]
> > To unsubscribe send a blank email to
> > [email-masked]
> > 
> > ------_=_NextPart_000_01C12488.23F75549--
> > 
> > 
> > 
> > ---
> > 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]
> 
> -- 
> 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]
> 

---
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:05:42 -0500

John,

Why ignore this parameter in the all IP case?  That should be
up to the implementation.  If the implementation wants to use
MP under a discard policy why would it not be able to use it?

--brian

John Loughney wrote:                                         (Tue, 28 Aug 2001 15:08:43)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

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

Brian,

 
> > > > for MTP management messages TFC etc.) in the SS7 network.

I can remove the 'all IP clause' and replace it to 'implementations'.

---

---

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

John,

How about:

	In the all-IP case, this parameter MAY be ignored.

--brian

John Loughney wrote:                                  (Wed, 29 Aug 2001 12:32:45)

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

---

---

From: [email-masked]
Date: Wed, 29 Aug 2001 14:22:56 +0300

Hi Brian,

> 	In the all-IP case, this parameter MAY be ignored.

Sounds like a winner to me.

John

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 29 Aug 2001 07:55:55 -0700

Are you saying that congestion will never be an issue in an IP network?

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2001 6:16 AM
> To: sigtran
> Subject: Re: [SUA issue 3] SCCP Message Priority - CLOSED
> 
> 
> John,
> 
> How about:
> 
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 15:24:28 -0500

John,

No.  Quite the opposite.  I requested the MUST be downgraded
to a MAY to permit the all-IP implementation to not ignore
the parameter if desired.

--brian

John Schantz wrote:                                          (Wed, 29 Aug 2001 07:55:55)

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

---

---

From: [email-masked]
Date: Thu, 30 Aug 2001 08:41:38 +0300

Brian,

> the parameter if desired.

So, would you like this better?

	In the all-IP case, this parameter MAY be used.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 Aug 2001 00:50:51 -0500

John,

John Loughney wrote:                                  (Thu, 30 Aug 2001 08:41:38)
> 	In the all-IP case, this parameter MAY be used.

I would.

--brian

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

---

---

From: [email-masked]
Date: Thu, 30 Aug 2001 08:56:32 +0300

Hi Brian,

> > 	In the all-IP case, this parameter MAY be used.

Consider it changed.

Also, I will review all mails about the flags parameter & seperating them
out.  My general comment earlier is when I proposed a split up, I recieved
no support.  When I proposed the new SS7 QoS parameter based upon the
existing flags parameter, only you objected.  

I will make a dual proposal & we can see what everyone things.

best regards,
John

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 30 Aug 2001 10:24:29 +0200

Hi,

That's what I was afraid of. We actually have 2 parameters for congestion
control : priority & importance.

In my view priority is utterly useless, but there seemed to be support
having it in SUA. It's only use is to populate the MP bits of the SIO in
some MTP networks, but already it's causing problems at the SG (what if it
conflicts etc. etc.)

My reasoning that the SG (SCCP) determines the MP bits based on SCCP message
type and possibly importance, fell on deaf ears.

Also, importance can be made a mandatory QoS field in SUA's new QoS
parameter, without any interworking problems. If it's not present in the
SCCP message, the SG can easily populate it based on message type or MP bits
(if present).

The only thing SUA needs is a value (importance or whatever), to enable
congestion control, backhaul or all-IP case. Now it seems like there's 2
independent congestion controls at work in the SUA.

Thanks for letting me spill my guts ...

=> As a compromise : let's separate out the QoS parameter in 4 separate
ones, as follows

1) priority parameter : optional in every CL and CO message, with the
purpose of filling the MP bits, for congestion control on the SS7 MTP level.
If the SG doesn't like them, it overwrites them as per T1.111/GR-246 or
national standard.

2) importance parameter : optional in CLDT, CLDR, CORE, COAK, COREF, RELRE,
with the purpose of congestion control on SUA/SCCP level. The SCCP-user (in
the SS7 and IP endpoints) sets this value.

3) protocol class : mandatory in CLDT, CLDR, CORE, COAK, COIT.

4) sequence control : optional in every CL and CO message.

Is everybody happy with this ?

Gery Verwimp
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212

-----Original Message-----
From: Schantz, John [mailto:[email-masked]]
Sent: woensdag 29 augustus 2001 16:56
To: sigtran
Subject: RE: [SUA issue 3] SCCP Message Priority - CLOSED

> [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: Thu, 30 Aug 2001 04:12:25 -0500

Verwimp,

Verwimp Gery wrote:                                (Thu, 30 Aug 2001 10:24:29)
> control: priority & importance.
> 

They *are* two different parameters.

> SCCP message, the SG can easily populate it based on message type or MP bits

For the international network MP bits are not present and Importance can
be preset or not.  How does Importance get populated when neither MP nor
Importance appear in the message?  Message type?  I don't think so: there
is no recommendation mapping message types to importance parameter.

> independent congestion controls at work in the SUA.

No, there are two controls in the SS7 network: congestion control based
on MP at MTP3 and congestion control at SCCP based on Importance.  In the
all IP case, John was suggesting that MP be ignored.  In the IP case it
is permissible for the SUA to ignore MP and there is no requirement for
it to consider Importance.  In the all IP network, there can be 0 congestion
controls a work (except at SCTP).

> If the SG doesn't like them, it overwrites them as per T1.111/GR-246 or

The SG should also be permitted to reject messages in case of conflict.
Existing error codes and messages will suffice.

Also consider making MP required for those message where the SG cannot
determine MP based on the MP tables of the appropriate variant.

> the SS7 and IP endpoints) sets this value.

SCCP-User MAY set this value.

> 3) protocol class : mandatory in CLDT, CLDR, CORE, COAK, COIT.

Ok.

> 4) sequence control : optional in every CL and CO message.

Mandatory in CLDT, CLDR, CORE, COAK. COIT.  Optional but required
for decoupled operation in other messages.

> Is everybody happy with this ?

I support making these separate parameters (<-- take note, John ;)
per John's original proposal.  John already has full text consistent
with what you propose here.

--brian

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

---