Subject: [Sigtran] Recommendation for SUA modifications

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 12 Oct 2005 11:02:09 -0400

Lode, John, and the SIGTRAN WG,

With regards to the current SUA RFC, it is my humble opinion that there
is some missing functionality that needs to be defined.  I would like to
propose an addition to the current SUA Implementors Guide that you are
maintaining.

The current SUA RFC indicates that the ASP->SG SCON message is a valid
procedure.  However, I believe that in the case of sending an SCON
message from an ASP to an SG, it is not always necessary to include the
affected DPC in the SCON message.  

When the ASP and the SG share the same point code, some architectures
(such as those that use global titles extensively) do not require the
ASP (or the SUA layer in the ASP) to be aware of the point code that is
being used when the SG converts the CL message to an MSU and builds the
L3 MTP routing label.  Therefore, requiring the affected PC in the SCON
message from the ASP to the SG puts and unnecessary burden on the ASP.

There are several ways to solve this problem.  I'm proposing two
possible solutions below.  Personally, I believe the first proposal is a
little cleaner.  I would welcome any and all feedback and/or alternate
solutions.  In the end, I'm no so much concerned with how the problem is
solved.  I would just like a solution that doesn't require the ASP to
have knowledge of the point code being used by the SG if the ASP and SG
share the same point code.

Proposal #1: Use RC

3.4.4.  Signalling Congestion (SCON)

   The SCON message can be sent from the SG or relay node to all
   concerned ASPs to indicate that the congestion level in the SS7
   network to a specified destination has changed.

|  The SCON message can be sent from an ASP to an SG to indicate local 
|  congestion.  The receiving SG MAY trigger the congestion procedures
of 
|  the relevant SCCP standard.

    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 = 0x0006          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                       Routing Context                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0012          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Affected Point Code                    /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x8003          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SSN                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0118          |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Congestion Level                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0112          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SMI                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0004          |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                          Info String                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Routing Context               Optional
|    Affected Point Code           Conditional *1
     SSN                           Optional *1
     Congestion Level              Mandatory
     SMI                           Optional
     Info String                   Optional

|  Note 1:    For an SCON from the SG to an ASP, when the SSN is
included, 
              the SCON message corresponds to the SCCP N-STATE
primitive.  
              When the SSN is not included, the SCON message corresponds

              to the SCCP N-PCSTATE primitive reporting signalling point

              or network congestion status.

|             When the SCON is from the ASP to the SG, the affected
point
|             code is an optional parameter.  The SG, if necessary, can
|             determine the affected PC from the Routing Context.

Proposal #2: Use Source Address

3.4.4.  Signalling Congestion (SCON)

   The SCON message can be sent from the SG or relay node to all
   concerned ASPs to indicate that the congestion level in the SS7
   network to a specified destination has changed.

|  The SCON message can be sent from an ASP to an SG to indicate local 
| congestion.  The receiving SG MAY trigger the congestion procedures of

| the relevant SCCP standard.

    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 = 0x0006          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                       Routing Context                         /
   \                                                               \
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |         Tag = 0x0102          |            Length             |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  /                        Source Address                         /
|  \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0012          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Affected Point Code                    /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x8003          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SSN                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0118          |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Congestion Level                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0112          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SMI                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0004          |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                          Info String                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Routing Context               Optional
|    Source Address                Optional *1
|    Affected Point Code           Conditional *1
|    SSN                           Conditional *1
     Congestion Level              Mandatory
     SMI                           Optional
     Info String                   Optional

|  Note 1:    For an SCON from the SG to an ASP, when the SSN is
included, 
              the SCON message corresponds to the SCCP N-STATE
primitive.  
              When the SSN is not included, the SCON message corresponds

              to the SCCP N-PCSTATE primitive reporting signalling point

              or network congestion status.

|             When the SCON is from the ASP to the SG, the ASP can use
|             the source address parameter instead of the Affected Point
|             Code parameter.  This is used mainly in the case when the 
|             Routing Keys associated with the ASP may not include a
point
|             code and/or an SSN.  The SG should be able to derive the
affected
|             PC from the registration information and take any actions
|             that might be appropriate to for subsystem congestion in 
|             the network.
|
|             If the ASP is sending Source Address, it is not necessary
to 
|             send SSN and/or Affected Point Code as this information is

|             either contained in the source address, or can be derived
at
|             the SG.

Regards,
Lincoln Haresign
Comverse, Inc.

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Oct 2005 11:45:29 -0600

Lincoln,

Please see comments inline.

Haresign Lincoln wrote:                         (Wed, 12 Oct 2005 11:02:09)

--X-snip-X--
> |  Note 1:    For an SCON from the SG to an ASP, when the SSN is included, 
>               the SCON message corresponds to the SCCP N-STATE primitive.  
> |             When the SCON is from the ASP to the SG, the affected point
--X-snip-X--

The SG cannot determine the PC of messages comming from the ASP by
Routing Context.   If you think that it can, please detail one procedure
that the SG can follow to associate a Point Code with this message when
it is received from an ASP.

Please bear in mind that an ASP is not restricted to sending messages
from the source address that it has registered to receive messages.
For example, if ASP A registers AS 1 with Routing key PC 111 and SSN 5,
obtaining RC 1, it is permitted to send messages with source address
PC 333 SSN 7 labelled with RC 1.  There is no restriction in the ASP->SG
direction for SCON either.

So if the SG cannot get the OPC for the outgoing SS7 message from the
SCON, where is it going to get it from?

--X-snip-X--
> |  Note 1:    For an SCON from the SG to an ASP, when the SSN is included, 
>               the SCON message corresponds to the SCCP N-STATE primitive.  
> |             Routing Keys associated with the ASP may not include a point
> |             code and/or an SSN.  The SG should be able to derive the affected
> |             If the ASP is sending Source Address, it is not necessary to 
> |             either contained in the source address, or can be derived at
> |             the SG.
> 

When developing the RFC we considered using Source Address in the SCON;
however, as neither the N-STATE or N-PCSTATE can contain a Global Title,
we rejected using the Source Address.  The situation has not changed.

I strongly disagree with both proposals.  The motiviation behind them
is to modify the SCON message to attempt something that it was never
intended to do: communicate ASP congestion.  SCON is intended for SS7
congestion only.

If you want to develop enhancements for ASP congestion control, please
write an extension draft detailing the new protocol elements required
and their usage.  It might be easier to modify or participate in Kamesh's 
draft.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 12 Oct 2005 14:02:19 -0400

Brian,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Brian F. G. Bidulock
> Sent: Wednesday, October 12, 2005 1:45 PM
> To: Haresign Lincoln
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Sigtran] Recommendation for SUA modifications
>
>
> Lincoln,
>
[TOLGA]I have a different opinion here based on 4.3.4.3 ASP Active
Procedures section.
"The ASP SHOULD NOT send Data or SSNM
messages for the related Routing Context(s) before receiving an ASP
Active Ack message, or it will risk message loss."
I know it is not a "MUST NOT" but still it is nota good thing to do unless
one is aware of consequences and happy with them.
> and their usage.  It might be easier to modify or participate in Kamesh's
[TOLGA]I would think a new draft could be a better approach, if there is
consensus in the WG for it. I personally would like to see something like
ASPCONG etc...OTOH, if we don't define a new message, the need to know about
ASP congestion states does not disappear, and overloading SCON semantics
seem to be a practical approach. What do the others think, does a new draft
have a chance of survival?

---

From: "Barry Nagelberg" <[email-masked]>
Date: Wed, 12 Oct 2005 14:24:31 -0400

All,

Brian is wrong. Of course SCON is intended to communicate ASP congestion. 

Section 1.5.6. (Congestion Management) of the RFC states that:

<snip>
   The SUA layer at an ASP or IPSP MAY indicate local congestion to an
   SUA peer with an SCON message.
<snip>

Barry Nagelberg
Adax, Inc.

-----Original Message-----

Lincoln,

--X-snip-X--
--X-snip-X--

--X-snip-X--

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Oct 2005 12:42:51 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 12 Oct 2005 14:02:19)
> one is aware of consequences and happy with them.

That would be sending messages with RC 1 in them before receiving ASP Active
Ack for RC 1.  That passage does not speak to the addressing of the messages.
Other passages do.  The SG provides uniform connectivity to all ASPs in an AS
and can route any messagew within a Network Appearance.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 12 Oct 2005 14:34:27 -0400

Brian,

> Sent: Wednesday, October 12, 2005 2:43 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA]Here I still think different, i.e. I consider AS state to be honored
in both directions of message flow based on the above passage-.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Oct 2005 17:08:17 -0600

Tolga,

Tolga Asveren wrote:                             (Wed, 12 Oct 2005 14:34:27)
> in both directions of message flow based on the above passage-.

That is true enough for MTP/M3UA, but for SCCP/SUA the
responding address (in a connection response) is not necessarily
the address to which the connection request was sent.  SUA has
the ability for relay internal to the ASP or over the IP
network, that we precluded in the M3UA RFC.

Following your stricter interprentation would require, for
connection oriented operation, when the responding address
differs from the address of the request, of responsding to a
connection request using an RC differennt from that upon which
the connection request arrived.

Nevertheless, Lincoln seems to be avoiding this question,
perhaps you can venture an answer: "How does the SG know what
address to place in the OPC of the message if it receives an SUA
message (SCON or otherwise) from the ASP that does not include a
corresponding point code in the message?"

Remember that Lincoln says that his ASPs register only using GT
(or maybe SSN) with no point code, therefore there is no point
code in the routing key associated with the routing context and
that, if I interpret him correctly, that it is too difficult a
provisioning task for his ASP to provide one at registration.

For arguments sake, assume that the SG supports mutliple point
codes (otherwise the task is trivial).

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Oct 2005 03:13:51 -0600

Tolga,

> > > "The ASP SHOULD NOT send Data or SSNM messages for the related
> > > Routing Context(s) before receiving an ASP Active Ack message, or
> > > it will risk message loss."
> > > I know it is not a "MUST NOT" but still it is nota good thing to
> > > do unless one is aware of consequences and happy with them.
> >
> > That would be sending messages with RC 1 in them before receiving
> > ASP Active Ack for RC 1.  That passage does not speak to the
> > addressing of the messages.  Other passages do.  The SG provides
> > uniform connectivity to all ASPs in an AS and can route any messagew
> > within a Network Appearance.

I know what I meant by that sentence when I wrote it.

One of the possible responses of the SG to an ASP Active request is an
ASP Inactive Ack, or management blocking.  My point was that if an ASP
blindly sends messages to the SG following ASP Active, without waiting
for an ASP Active Ack, that the SG may have to discard them in the case
that it responds with an ASP Inactive Ack or management blocking.

Therefore, if the ASP wishes to avoid risking "message loss", it will
wait for the ASP Active Ack.

If you recall, I was not successful on the argument of symmetrical flows
within a routing context.  RK is only used by an SG for routing messages
to the ASP, not visa versa.

If messages in M3UA could not be sent from ASP to SG with different
addresses than appear in the RK, then the SG would have to compare the
routing labels in DATA messages received from the ASP to police the
arrangement and do something (no procedure exists yet) in event of a
violation.  Currently, the SG can just process the message for M3UA,
because the addresses in it are fully specified and the message is self
contained.  The SG even knows the proper RC value to place in any SSNM
messages sent to the ASP in response to respond to the proper AS,
regardless of the addresses in the message.

In fact there is no procedure in either M3UA or SUA that relies on the
ASP applying a symmetric routing key to that of the SG.

In SUA placing a symmetric requirement on the ASP is not possible,
because not even addresses are symmetric (a transaction query often
includes GT, whereas the response does not).

All that the RC does is identify the AS to an SG and corresponds to
a routing key used by the SG to send messages to the ASP.  It is a false
assertion that missing parts of messages sent from ASP to SG can be
recreated based on RC.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Oct 2005 03:27:27 -0600

Tolga,

You should also note that despite your stance that M3UA only supports
a single DPC in an RK, SUA supports multiple DPCs.  Therefore an RC
does not necessarily identify which of many possible point codes an
AS can register to receive messages for.  Even a symmetrical arrangement
would not help for SUA.

--brian

Brian F. G. Bidulock wrote:                 (Thu, 13 Oct 2005 03:13:51)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 13 Oct 2005 10:21:20 -0400

Brian,
> corresponding point code in the message?"
[TOLGA]For SCON case, my rational was as follows:
If SG has the ability to aggregate availability status of SCCP -which is
attached to a specific PC-  based on ASPAC/ASPAC-ACK -which uses RC for
identification-, it could use similar logic for congestion notification in
ASP=>SG direction as well.

---

From: "Valerie Gastaud" <[email-masked]>
Date: Fri, 14 Oct 2005 10:30:15 +0200

Lincoln, Brian et all,

Lincoln has explained the problem he tries to solve that requires a modification to the SCON and I think it's a valid case: SG and
ASPs share the same Point Code and the ASPs are not provisioned with the PC value.
Let's forget about the usefulness of such architecture. Since I don't think there are any other problem than SCON to solve in this
case, why not trying to solve it.
I propose the following text:
3.4.4.  Signalling Congestion (SCON)
.....
|             When the SCON is from the ASP to the SG, the affected point
|             code is an optional parameter.  If not included, the SG
|             must assume the affected PC is its own (primary) Point Code.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Haresign Lincoln
Sent: mercredi 12 octobre 2005 17:02
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Sigtran] Recommendation for SUA modifications

Proposal #1: Use RC

    0                   1                   2                   3

   Parameters
     Routing Context               Optional

    0                   1                   2                   3

   Parameters
     Routing Context               Optional

Regards,
Lincoln Haresign
Comverse, Inc.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Oct 2005 04:35:18 -0600

Valerie,

How about this:

The following is necessary for an SG to be able to signal toward
the SS7 network in response to SCON from an ASP (as it MAY, or
in ETSI must) without confusing an overloaded use of the message
for an indication of SCCP congestion:

    The SCON message is used to report SCCP or SCCP subsystem
    congestion when a change in Restricted Importance Level
    occurs for an Affected Point Code in accordance with the
    relevant SCCP standard (e.g. Q.714).  It MUST NOT be used by
    an ASP to indicate other forms of congestion.

The following is now necessary for the SG to determine whether
it can discern a point code for any given message:

    The Routing Context is a mandatory parameter.

The following more clearly identifies that the parameter is
mandatory except in Lincoln's corner case:

    The Affected point code is a mandatory parameter unless the
    SCON is from ASP to SG, the ASP and AS are not provisioned
    with any point code, the ASP is connected to one and only
    one SG, the ASP does not perform GTT, the SG supports one
    and only one point code, and the SG is configured to not
    include an originating point code in the Source Address
    field of messages sent to the ASP.

Let's put that in the IG and then some time 3 or 4 years from
now after it goes to RFC and ETSI endorses it Lincoln can go to
the trouble of removing the point codes from his ASPs when
talking to SGs that don't send OPCs in accordance with SCCP
addressing requirements.

Then again, maybe by then we will have an SUA MIB that will
require it again anyway.

I think it is best to just leave it mandatory.

--brian

Valerie Gastaud wrote:                                                             (Fri, 14 Oct 2005 10:30:15)

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