RE: CIC as a RK

Brian,

What I said was just to explore the idea to re-introduce CIC as a RK
parameter.

   Thanks,
   Tolga

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Thursday, November 09, 2006 2:06 PM
> To: Tolga Asveren
> Cc: Ong, Lyndon; Haresign Lincoln; Ilie Glib; [email protected]
> Subject: Re: [Sigtran] CIC as a RK
>
>
> Tolga,
>
> There are already statements that we placed in RFC 4666 (and 3332
> before it):
>
> This:
>
>    For carrier grade networks, the failure or isolation of a particular
>    signalling process should not cause stable calls or transactions to
>    be lost.  This implies that signalling processes need, in some cases,
>    to share the call/transaction state or be able to pass the call state
>    information between each other.  In the case of ASPs performing call
>    processing, coordination may also be required with the related Media
>    Gateway to transfer the MGC control for a particular trunk
>    termination.  However, this sharing or communication of
>    call/transaction state information is outside the scope of this
>    document.
>
> which clearly scopes out issues within the MGC complex for sharing state
> information between ASPs.
>
> And, this:
>
>    In the process of failover, it is recommended that, in the case of
>    ASPs supporting call processing, stable calls do not fail.  It is
>    possible that calls in "transition" may fail, although measures of
>    communication between the ASPs involved can be used to mitigate this.
>
>    For example, the two ASPs may share call state via shared memory, or
>    may use an ASP to ASP protocol to pass call state information.  Any
>    ASP-to-ASP protocol to support this function is outside the scope of
>    this document.
>
> Which also scopes it out.
>
> For load sharing there is this:
>
>    In the case of a Loadshare mode AS, receipt of an ASP Active message
>    at an SGP or IPSP causes direction of traffic to the ASP sending the
>    ASP Active message, in addition to all the other ASPs that are
>    currently active in the AS.  The algorithm at the SGP for loadsharing
>    traffic within an AS to all the active ASPs is implementation
>    dependent.  The algorithm could, for example, be round-robin or based
>    on information in the Data message (e.g., the SLS, SCCP SSN, or ISUP
>    CIC value).  ...
>
> As the loadsharing algorithm is implementation dependent (at the SGP) and
> there is no protocol mechanism for determining what that algorithm may be,
> the ASP in a loadshare AS must be prepared to handle any range of traffic
> for the AS.
>
> These principles for loadsharing and ASP state sharing have been present
> in M3UA from the start.  Altering them would represent a
> significant change
> to the document (and to loadsharing implementations).  Procedures for
> backward compatibility (such as those provided by LOADSEL) would be
> necessary.
>
> --brian
>
>
> Tolga Asveren wrote:
>    (Thu, 09 Nov 2006 13:18:49)
> > IMO, allowing CIC ranges as RK constructs and explaining how it
> is supposed
> > to be used and addressing any issues related with it (hopefully
> not much) in
> > the M3UA document may be useful.
> >
> >     Thanks,
> >     Tolga
> >
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/