Subject: [Sigtran] CIC as a RK

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 8 Nov 2006 16:07:27 -0500

Ilie,

I'm not sure that we have ever answered this basic issue:

Do we want to use CIC as a Routing Key (meaning that I can have separate
AS with all the same RKs except CIC range).  CIC range will be the
determining factor for how the SG routes between AS.

Or, do we want to use CIC for loadsharing.  Meaning that the SG will
choose AS based upon other criteria besides CIC (DPC, OPC, SI), and then
use CIC to distribute within the AS (similar to TID/DRN in SUA).

I think the second is more practical as it avoids issues of CIC
management that are apparent in the first case.  To illustrate, I have
this simple scenario.  We have two different AS.  Each with a single
ASP.  They share the same PC as the SG, but use a CIC range as RK to
differentiate the two.

---------
| AS1   |\
| PC=1  | \
| CIC=1 |  \
---------   \ |------|
             \| SG   |
             /| PC=1 |<====SS7 Network===>
---------   / |------|
| AS2   |  /
| PC=1  | /
| CIC=2 |/
---------

When AS1 loses the association to SG, how does it handle an incoming IAM
for CIC=1?  

Or if there is a call in progress, how does it handle an incoming REL
for CIC=1?

These are real scenarios that, if not handled, either affect billing or
use of network resources.  No network provider will be happy if these
problems are not solved.  If you expect your SG to interface to somebody
else's AS, they must be solved in an agreed upon manner.  If it is your
SG and your AS, no problem.  You can determine some internal solution.

Regards,
Lincoln

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 8 Nov 2006 15:05:19 -0700

Lincoln,

Haresign Lincoln wrote:                       (Wed, 08 Nov 2006 16:07:27)
> I'm not sure that we have ever answered this basic issue:

Yes, we answered this question when the WG removed SSN and CIC.  

> use CIC to distribute within the AS (similar to TID/DRN in SUA).

I believe the answer is neither.  CIC or SSN can conceivably be used
for distribution of traffic (neither routing nor loadsharing) within an
MGC complex.  A principle design obejctive is minimization of state
sharing between multiple nodes in a horizontal distributed architecture,
and minimization of lost calls/transactions during failover within the
MGC complex.  However, the procedures are highly dependent upon
implementation details such as functional placement within the MGC
complex, but are local in nature.

For loadsharing between an M3UA SG and ASPs serving an AS, SLS is both
sufficient and necessary (CIC, due to the nature of its allocation, will
not ensure an equal load distribution).  SLS, coupled with an approach
such as CORID, provides assurance of in-sequence delivery at the ASP
pool.  Once a given message arrives, in sequence, at the ASP pool, which
functional unit within the MGC complex that it is delivered to is the
business of the MGC.

That said, M3UA can be used to distribute messages within the MGC
complex, however, its use within the MGC complex can include whatever
proprietary mechanism the MGC designer sees fit and is not really a
proper subject of standardization within IETF.  I use LOADSEL/LOADGRP.
Another design could use whatever mechanisms it chooses.  Perhaps SCOPE
or CP-TA will eventually standardize something here, but these
organizations are welcome to provide extension drafts and request IANA
assignments to that effect.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 9 Nov 2006 07:46:37 -0500

Lincoln,

I agree with your concerns and as a general strategy I would think one can
follow (for the case where CIC ranges are used to define different RKs):

a)Using Override trafic mode for each AS. The standby instance may actually
take over control of the CIC after a failover or just reply back with the
appropriate answer.

b)Using a default fauilure handling ASP, everything, which is received for
an AS, for which there is no ACTIVE ASP is forwarded there. That ASP
constructs the appropriate answer.

c)The SG constructs the appropriate answer and sends it back.

I believe, as long as ASP/SG agree on which model is followed, there
shouldn't be a problem from interoperability point of view. Probably that
agreement could be provisioned both at SG and ASP.

    Thanks,
    Tolga

> -----Original Message-----
> From: Haresign Lincoln [mailto:[email-masked]]
> Sent: Wednesday, November 08, 2006 4:07 PM
> To: Ilie Glib
> Cc: [email-masked]
> Subject: [Sigtran] CIC as a RK
>
>
> Ilie,
>

---

From: "Ilie Glib" <[email-masked]>
Date: Thu, 9 Nov 2006 16:00:39 +0100

Hello Lincoln,

with the current status of M3UA RFC CIC ranges can be used for
loadsharing, if both SG and ASPs support that at provisioning of
ASPs/ASes and the AS takes care od application level procedures.

M3UA implementors' guide provides the following reason for CIC removal:
"Use of SSN and CIC Routing Keys is inadequately defined in RFC3332
leading to non-interoperable solutions."

Whether we want to use CIC ranges as part of RK and improve the
description to provide for interoperability or use them as loadsharing
"label" like in LOADSEL is still open as far as I can understand.

I do not see the reasons that Brian brought as decisive in favor of
LOADSEL vs RK with CICs.

IMHO from Tolga's list below item a) is the best. The default ASP can
also fail and what then.

In alternative a) distributed AS shall take care of ASP failure
situations. The probability of the event where all ASPs are INACTIVE
and cannot go ACTIVE after a NTFY shall be reduced to a minimum. IMHO
MGC internal architecture shall provide for that. Thus SG shall not
initiate any application level messages to SS7 realm.

Regards

/Ilie

-- 
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 9 Nov 2006 11:50:04 -0500

Ilie,

As I stated in one of my first emails, I have no problem with any
approach that is taken (LOADSEL vs. M3UA RFC vs. something else).  I
just believe we need to better document the approach and outline all the
issues with this.

I'm uncertain how to proceed further on this.  IMHO, if we make it an
extension of the M3UA RFC, it is more likely to be adopted by a broader
range of network equipment providers.  But perhaps I'm wrong.

Lyndon,

As chair of this working group, do you have any advice on this topic in
general?

Regards,
Lincoln 

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 10:01 AM
To: Haresign Lincoln
Cc: [email-masked]; Tolga Asveren
Subject: Re: [Sigtran] CIC as a RK

Hello Lincoln,

In alternative a) distributed AS shall take care of ASP failure
situations. The probability of the event where all ASPs are INACTIVE and
cannot go ACTIVE after a NTFY shall be reduced to a minimum. IMHO MGC
internal architecture shall provide for that. Thus SG shall not initiate
any application level messages to SS7 realm.

Regards

/Ilie

On 11/9/06, Tolga Asveren <[email-masked]> wrote:
> Lincoln,
>
> I agree with your concerns and as a general strategy I would think one

> can follow (for the case where CIC ranges are used to define different
RKs):
>
> a)Using Override trafic mode for each AS. The standby instance may 
> actually take over control of the CIC after a failover or just reply 
> back with the appropriate answer.
>
> b)Using a default fauilure handling ASP, everything, which is received

> for an AS, for which there is no ACTIVE ASP is forwarded there. That 
> ASP constructs the appropriate answer.
>
> shouldn't be a problem from interoperability point of view. Probably 
> that agreement could be provisioned both at SG and ASP.
>
>    Thanks,
>    Tolga
>
> > Do we want to use CIC as a Routing Key (meaning that I can have 
> > separate AS with all the same RKs except CIC range).  CIC range will

> > be the determining factor for how the SG routes between AS.
> >

> > choose AS based upon other criteria besides CIC (DPC, OPC, SI), and 
> > then use CIC to distribute within the AS (similar to TID/DRN in
SUA).
> > management that are apparent in the first case.  To illustrate, I 
> > have this simple scenario.  We have two different AS.  Each with a 
> > single ASP.  They share the same PC as the SG, but use a CIC range 
> > as RK to differentiate the two.
> >
> >
> > ---------
> > | AS1   |\
> > | PC=1  | \
> > | CIC=1 |  \
> > ---------   \ |------|
> >              \| SG   |
> > When AS1 loses the association to SG, how does it handle an incoming

> > IAM for CIC=1?
> >
> > Or if there is a call in progress, how does it handle an incoming 
> > REL for CIC=1?
> >
> > These are real scenarios that, if not handled, either affect billing

> > or use of network resources.  No network provider will be happy if 
> > these problems are not solved.  If you expect your SG to interface 
> > to somebody else's AS, they must be solved in an agreed upon manner.

> > If it is your SG and your AS, no problem.  You can determine some
internal solution.

--
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 9 Nov 2006 11:54:17 -0500

Brian,

Below you say that we could use SLS for loadsharing purposes.  Perhaps
I'm missing something, but these seems quite insuffient because:

1) That limits us to 16 values.
2) The SLS value for a call could change during the length of the call.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, November 08, 2006 5:05 PM
To: Haresign Lincoln
Cc: Ilie Glib; [email-masked]
Subject: Re: [Sigtran] CIC as a RK

Lincoln,

Haresign Lincoln wrote:                       (Wed, 08 Nov 2006
16:07:27)

> then use CIC to distribute within the AS (similar to TID/DRN in SUA).

I believe the answer is neither.  CIC or SSN can conceivably be used for
distribution of traffic (neither routing nor loadsharing) within an MGC
complex.  A principle design obejctive is minimization of state sharing
between multiple nodes in a horizontal distributed architecture, and
minimization of lost calls/transactions during failover within the MGC
complex.  However, the procedures are highly dependent upon
implementation details such as functional placement within the MGC
complex, but are local in nature.

--brian

> these problems are not solved.  If you expect your SG to interface to 
> somebody else's AS, they must be solved in an agreed upon manner.  If 
> it is your SG and your AS, no problem.  You can determine some
internal solution.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Nov 2006 10:13:37 -0700

Haresign,

Haresign Lincoln wrote:                                           (Thu, 09 Nov 2006 11:54:17)
> 1) That limits us to 16 values.

In ITU networks, yes.  But that does not seem to hamper SS7.  If you need
more than 16 ASPs serving an AS, you probably need to design bigger ASPs.

> 2) The SLS value for a call could change during the length of the call.

Yes, but that affects neither sequencing nor equal distribution
for loadsharing.

--brian

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

---

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 9 Nov 2006 12:20:11 -0500

Hi Guys,

I've been watching the discussion with interest, but am not sure if
a consensus is developing (a problem with this group for a while).
Can people state what they think is the best approach?

e.g, work within the current (updated) M3UA, define some extension
to the M3UA, work on Brian's LOADSEL proposal?

Lyndon 

-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 8:50 AM
To: Ilie Glib
Cc: [email-masked]; Tolga Asveren
Subject: RE: [Sigtran] CIC as a RK

Ilie,

Lyndon,

Regards,
Lincoln 

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]]
Sent: Thursday, November 09, 2006 10:01 AM
To: Haresign Lincoln
Cc: [email-masked]; Tolga Asveren
Subject: Re: [Sigtran] CIC as a RK

Hello Lincoln,

Regards

/Ilie

SUA).

internal solution.

--
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Nov 2006 10:42:12 -0700

Lyndon,

I believe that at least Jitin an I agree that distribution of messages
on CIC range is a matter to be dealt with within the MGC complex and
not by the SG (not even SS7 is capable of distributing CIC ranges
across signalling points).  As the MGC is largely a single vendor
environment, I do not believe that interoperability is at issue and
the matter should not be dealt with by the main RFC.

--brian

Lyndon Ong wrote:                        (Thu, 09 Nov 2006 12:20:11)

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

---

From: "Ilie Glib" <[email-masked]>
Date: Thu, 9 Nov 2006 19:07:00 +0100

Brian,

I do agree with your statement below.

Regards

/Ilie

-- 
Ilie

---

From: "Ilie Glib" <[email-masked]>
Date: Thu, 9 Nov 2006 19:17:46 +0100

Brian,

still interoperability between SG and ASPs is an issue here, otherwise
there is no reason to do anything related to CICs.

Regards

/Ilie

-- 
Ilie

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 9 Nov 2006 13:18:49 -0500

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

> From: Ong, Lyndon [mailto:[email-masked]]
> Sent: Thursday, November 09, 2006 12:20 PM
> To: Haresign Lincoln; Ilie Glib

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Nov 2006 11:31:19 -0700

Ilie,

I do not think that interoperability between single-vendor processes
within the MGC complex is an issue.  Distributing CIC is not something
that an SG need do, as SS7 cannot do it and the aim of M3UA is simply
to tranparently transport MTP-User messages with some degree of
reliabilty (approaching that afforded by the SS7 network).

--brian

Ilie Glib wrote:                            (Thu, 09 Nov 2006 19:17:46)

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

---

From: "Ilie Glib" <[email-masked]>
Date: Thu, 9 Nov 2006 19:38:21 +0100

Brian,

see below.

Regards

/Ilie

On 11/9/06, Brian F. G. Bidulock <[email-masked]> wrote:
> within the MGC complex is an issue.

ilie: I agree. I was talking about SG and ASPs

>Distributing CIC is not something

ilie: I agree.

-- 
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Nov 2006 11:40:57 -0700

Tolga,

I think that it is only worth saying that it is not to be used.
SS7 does not do this and M3UA does not need to either.

--brian

Tolga Asveren wrote:                         (Thu, 09 Nov 2006 13:18:49)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Nov 2006 11:43:08 -0700

Ilie,

Ilie Glib wrote:                               (Thu, 09 Nov 2006 19:38:21)
> > reliabilty (approaching that afforded by the SS7 network).

So we have three in agreement that an SG need not distribute CIC.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Thu, 9 Nov 2006 13:44:32 -0500

If I understand this thread,

Ilie and Brain appear to be content with the status quo for RFC 4666.

Tolga would like some clarification regarding CIC use and M3UA.

Jitin, you first brought this issue forward.  Do you have any opinions?

Personally, I think it would be nice if we could find a solution to CIC
load distribution in some common way.  

Did I miscount?

Regards,
Lincoln 

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 1:19 PM
To: Ong, Lyndon; Haresign Lincoln; Ilie Glib
Cc: [email-masked]
Subject: RE: [Sigtran] CIC as a RK

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

> I've been watching the discussion with interest, but am not sure if a 
> consensus is developing (a problem with this group for a while).
> e.g, work within the current (updated) M3UA, define some extension to 
> the M3UA, work on Brian's LOADSEL proposal?
>
> Lyndon
>
> just believe we need to better document the approach and outline all 
> the issues with this.
>
> extension of the M3UA RFC, it is more likely to be adopted by a 
> broader range of network equipment providers.  But perhaps I'm wrong.
>
> Lyndon,
>
> As chair of this working group, do you have any advice on this topic 
> in general?
>
> Regards,
> Lincoln
>

> > > choose AS based upon other criteria besides CIC (DPC, OPC, SI), 
> > > and then use CIC to distribute within the AS (similar to TID/DRN 
> > > in
> SUA).
> > >

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Nov 2006 11:50:18 -0700

Haresign,

I believe that Jitin agreed before Ilie.

--brian

Haresign Lincoln wrote:                                           (Thu, 09 Nov 2006 13:44:32)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Nov 2006 12:06:07 -0700

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

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 9 Nov 2006 14:14:13 -0500

Brian,

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

   Thanks,
   Tolga

> Sent: Thursday, November 09, 2006 2:06 PM
> To: Tolga Asveren
> Cc: Ong, Lyndon; Haresign Lincoln; Ilie Glib; [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Nov 2006 12:36:24 -0700

Tolga,

CIC RK cannot work without changing this fundamental characteristic
of M3UA: that an SG does not coordinate state for ASPs.

As it stands the RFC provides for ASP loadsharing under the adopted
loadsharing scheme using CIC, without the SG taking regard to state
sharing within the ASP, which you agreed (back in Jan. 2003) was
sufficient when we removed CIC RK in the first place.

--brian

Tolga Asveren wrote:                        (Thu, 09 Nov 2006 14:14:13)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Nov 2006 12:46:43 -0700

Liconln,

If you want to limit ASP state sharing while doing load sharing in
ANSI networks with insulation of failures involving a differing number
of STP hops (which effectively never occurs for ISUP, does for TCAP,
but not for ISUP), use the 5 or 8 low order bits of the CIC used to
select the original SLS value instead of the received (rotated) SLS.
The current loadsharing scheme permits this.  One does not need CIC RK
to do this.

--brian

Brian F. G. Bidulock wrote:                                       (Thu, 09 Nov 2006 10:13:37)

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