Re: Recommendation for SUA modifications

Lincoln,

The RFC does not say otherwise:

3.10.24.  Congestion Level

    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 = 0x0118          |             Length = 8        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Congestion Level                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Congestion Level field: 8-bits (unsigned integer)

   The Congestion Level field contains the level at which congestion has
   occurred.

   When the Congestion Level parameter is included in a SCON message
   that corresponds to an N-PCSTATE primitive, the Congestion Level
   field indicates the MTP congestion level experienced by the local or
   affected signalling point as indicated by the Affected Point Code(s)
   also in the SCON message.  In this case, valid values for the
   Congestion Level field are as follows:

      0  No Congestion or Undefined
      1  Congestion Level 1
      2  Congestion Level 2
      3  Congestion Level 3


   When the Congestion Level parameter is included in a SCON message
   that corresponds to an N-STATE primitive, the Congestion Level field
   indicates the SCCP restricted importance level experienced by the
   local or affected subsystem as indicated by the Affected Point Code
   and Subsystem Number also in the SCON message. In this case, valid
   values for the Congestion Level field range from 0 to 7, where 0
   indicates the least congested and 7 indicates the most congested
   subsystem.

--brian

Haresign Lincoln wrote:                     (Fri, 14 Oct 2005 08:33:18)
> Brian,
> 
> That's your definition.  The RFC says otherwise.
> 
> An ASP can congest according to the RFC and according to practical
> matters in networks.  We need a mechanism to support ASP congestion.
> The RFC has specified one.  A minor change to the RFC allows the cases
> that the current RFC has not covered.
> 
> And it has no impact on existing SGs since the handling of an SCON is
> optional.  
> 
> Regards,
> Lincoln
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]] 
> Sent: Friday, October 14, 2005 8:28 AM
> To: Haresign Lincoln
> Cc: Valerie Gastaud; [email protected]; [email protected];
> [email protected]
> Subject: Re: [Sigtran] Recommendation for SUA modifications
> 
> Lincoln,
> 
> The congestion level only applies to a single point code.  SCCP
> maintains a independent congestion level for each point code.
> 
> --brian
> 
> Haresign Lincoln wrote:                        (Fri, 14 Oct 2005
> 08:19:02)
> > Valerie,
> > 
> > I think this is a good solution.  Using the RC also addresses the 
> > scenario of the ASP supporting multiple point codes (not something 
> > that we do, but the RFC supports it).  Since the current SCON message 
> > doesn't indicate that multiple point codes can be specified in the 
> > SCON, the RC parameter would handle this scenario also.
> > 
> > Regards,
> > Lincoln
> > 
> 
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
> 
> ______________________________________________________________________
>   This email message has been scanned by PineApp Mail-Secure and has
> been found clean.
> 

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