RE: Recommendation for SUA modifications

Brian,

You state:

[brian] 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.

The SUA RFC states:

   The SUA layer at an ASP or IPSP MAY indicate local congestion to an
   SUA peer with an SCON message.  When an SG receives a congestion
   message (SCON) from an ASP, and the SG determines that an endpoint is
   now encountering congestion, it MAY trigger congestion procedures of
   the relevant SCCP standard.

So...either you are wrong, or the RFC is wrong. For now, I'm going on
the premise that the SCON from ASP to SG is a valid procedure since the
RFC is no longer draft.  I'm not even going to try to argue that one.
The only issue I'm trying to resolve is what is required in the SCON
message from the ASP to the SG.  I'm not trying to resolve any other
issues.

If you don't agree with the way that I'm trying to fix the problem, I am
certainly open to other solutions and if you want to propose one and it
meets my requirements (problem outlined below), I'm happy to support
your solution.  I'm very flexible and I'm just looking for solution that
is agreed to (for the most part) by the Sigtran community.

With regards to what you indicated below and the RC.  What I proposed is
"the affected PC is optional".  Meaning if the ASP knows the affected
PC, it can send it in the SCON (sending SCON is optional).  But in the
case that the ASP does not know it's PC (e.g., it is sharing the same PC
as the SG), then the SG can infer the PC based upon RC.  In the example
you gave below, the ASP is sending messages with a particular (and
known) PC.  The problem that I'm trying to solve (which I've already
outlined extensively as a valid scenario) is that the ASP does not know
it's PC.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Wednesday, October 12, 2005 1:45 PM
To: Haresign Lincoln
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [Sigtran] Recommendation for SUA modifications

Lincoln,

Please see comments inline.

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

--X-snip-X--
> 
>    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.
> 
--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--
> 
>    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.
> 


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 protected]
http://www.openss7.org/