Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

From: "Bhandari, Jitin (Jitin)" <[email-masked]>
Date: Mon, 6 Nov 2006 12:16:20 -0500

Lincoln,

I understand that we need to resolve such issues of CIC handling at SG but I see putting back CIC ranges in Dynamic registration message as a separate issue. 

Note that the current RFC does not define clearly the Routing Key for Static Registration methods and anyone is free to choose any key (i.e. including CIC ranges). If at SG, we are provisioning CIC ranges against routing Keys and across AS(s), the same problem exists. 

By getting rid of CIC ranges at Dynamic Registration, We haven't yet solved that issue as it still exists (with static routing key definition) but I am not sure if we need to address this issue in SIGTRAN forums.

I think someone else in this discussion thread did already mention that this is issue is essentially with SG and Signaling networks and not between MGC & SG though it is important that any SG implementation which supports CIC ranges are Routing key should address this issue. Also, I agree with you that this problem needs to be solved but I am not sure if this is in the domain of SIGTRAN. 

Also, the handling of such ISUP message should be not proprietary as should adhere to all specs defined for various variants of ISUP.

Again, this problem has nothing to do with having CIC ranges in Dynamic registration request. My point is that as in my earlier emails, that by getting rid of CIC Ranges for Dynamic registration we have limited or somewhat made Dynamic Registration procedure un-usable.

That's why we strongly feel that CIC ranges should be put back in Dynamic registration procedure for Routing Key definitions.

Thanks,
Jitin

-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 11:21 AM
To: Bhandari, Jitin (Jitin); Tolga Asveren; Barry Nagelberg; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Jitin,

So you are saying that the SG might send a BLO or Group Block message?  

I'm not sure I'm understanding.  I think if the SG is going to handling
CIC routing, then there is an implication that it needs to do some level
of CIC management.  I don't think you can just put CIC routing back in
to the RFC w/o addressing this issue.

Are you saying we should put CIC routing back in the RFC and not address
all the issues that are associated with doing this?

Regards,
Lincoln

-----Original Message-----
From: Bhandari, Jitin (Jitin) [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 11:09 AM
To: Haresign Lincoln; Tolga Asveren; Barry Nagelberg; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln, 

The way I perceive, outages of certain "range of CICs" at SG should be
perceived as ISUP would handle incoming messages with a particular CIC
resource face an outage at MG.
These procedures are clearly defined by ISUP standards and vary variant
to variant. So the handling of each such ISUP message would be network &
variant dependant.

We are just talking about relocation of such functionality in such
scenarios at SG. 
Clearly understood that the scope of such functionality is required at
SG only when SG is including CIC as arbitration method across AS(s)
along with DPC/OPC as routing key.

Thanks,
Jitin

-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]]
Sent: Monday, November 06, 2006 10:37 AM
To: Bhandari, Jitin (Jitin); Tolga Asveren; Barry Nagelberg;
[email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Jitin,

I don't believe anybody answered my question.  How can you have CIC
management at the SG if you are not going to say how to handle CIC
outages towards the network.

This is no different than what we are doing for SSNs in an SUA SG or
User parts (or point codes) in an M3UA SG.  

Regards,
Lincoln

-----Original Message-----
From: Bhandari, Jitin (Jitin) [mailto:[email-masked]]
Sent: Monday, November 06, 2006 10:34 AM
To: 'Tolga Asveren'; Haresign Lincoln; Barry Nagelberg; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

I think that is true. Handling of ISUP messages as per ISUP standards
(various depending upon ISUP variant) when CIC ranges face an outage
(per AS) is a different issue at SG and probably does not require
Sigtran attention given that this only exists between Signaling networks
and SG. 

However, we need to bring back CIC ranges in Dynamic Registration
message like the way we had in previous RFC and then implementation at
Signaling Gateway use various ISUP recommendations (again variant
dependant) to handle unavailability of certain ranges of CIC. 

So, my question would be that if we all agree that what should we do to
get back CIC Ranges in Dynamic Registration messages?

Thanks,
-Jitin

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]]
Sent: Thursday, November 02, 2006 4:06 PM
To: Haresign Lincoln; Bhandari, Jitin (Jitin); Barry Nagelberg;
[email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

IMO, things which effect SS7 side of the world do not need to be
standardized in SIGTRAN WG. I would say, for such issues, every SG can
decide itself what to do (and of course there are ISUP specifications).

Things which require coordination between SG and ASP need to be
standardization though.

   Thanks,
   Tolga

> -----Original Message-----
> From: Haresign Lincoln [mailto:[email-masked]]
> Sent: Thursday, November 02, 2006 4:02 PM
> To: Tolga Asveren; Bhandari, Jitin (Jitin); Barry Nagelberg; 
> [email-masked]
> Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
>
>
> Tolga,
>
> I still don't understand how you are going to handle the case when you

> loose connectivity to an ASP handling a certain range of CICs.  Now 
> you receive an IAM for that CIC.  What does the SG do?  Drop the
message?
> This could be a fairly lengthy outage.  Or are you saying we leave it 
> up to the SG and everybody does it differently?  What if the SG sends 
> a BLO, then the ASP comes back, how does the ASP know the state of the

> CIC?
>
> I don't think you can just have every SG decide to do things 
> differently.
>
> Regards,
> Lincoln
>
> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Thursday, November 02, 2006 3:54 PM
> To: Haresign Lincoln; Bhandari, Jitin (Jitin); Barry Nagelberg; 
> [email-masked]
> Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
>
> Lincoln,
>
> IMHO it may be better to restrict what needs to be standardized to a 
> simple set of rules -if possible at all- rather than a detailed 
> analysis of each and every case. That strategy may or may not work.
>
>     Thanks,
>     Tolga
>
> > -----Original Message-----
> > From: Haresign Lincoln [mailto:[email-masked]]
> > Sent: Thursday, November 02, 2006 3:48 PM
> > To: Tolga Asveren; Bhandari, Jitin (Jitin); Barry Nagelberg; 
> > [email-masked]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> >
> > Tolga,
> >
> > I believe there are all sorts of scenarios that are troublesome 
> > relating to the group messages.  Don't you think we would need to 
> > define all these in order for an SG to properly interop with an ASP?
> >
> > Regards,
> > Lincoln
> >
> > -----Original Message-----
> > From: Tolga Asveren [mailto:[email-masked]]
> > Sent: Thursday, November 02, 2006 3:30 PM
> > To: Bhandari, Jitin (Jitin); Haresign Lincoln; Barry Nagelberg; 
> > [email-masked]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> > Jitin,
> >
> > Although I would think introducing CIC-ranges back to dynamic 
> > registration may makes sense, I am not sure whether we need to 
> > define implementation dependent functionality on SG, e.g ISUP proxy
etc...
> >
> > As long as the issue can be handled locally in SG, IMHO there is no 
> > need to define specific behavior in SIGTRAN WG. We maybe just need 
> > to say whose responsibility is it to deal with the complexity, e.g.
> > answers messages for group messages need to be aggregated at SG.
> >
> >
> >    Thanks,
> >    Tolga
> >
> > > -----Original Message-----
> > > From: Bhandari, Jitin (Jitin) [mailto:[email-masked]]
> > > Sent: Thursday, November 02, 2006 3:14 PM
> > > To: 'Haresign Lincoln'; Barry Nagelberg; [email-masked]
> > > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> > >
> > >
> > > Lincoln,
> > >
> > > Your understanding is correct. We all understand and acknowledge 
> > > limitations of previous Dynamic registration and issues associated

> > > with it. Not only the Dynamic Registration needs to be re-defined 
> > > with
> >
> > > some basic modifications, along with almost a minor functionality 
> > > (ISUP Proxy) need to be defined as a part of M3UA on SG for such 
> > > scenarios.
> > >
> > > I can't stress enough for the need of such functionalities 
> > > especially when we have elaborate network in real time domain with

> > > Multiple MGs (at-least 40) being controlled by one MGC and 
> > > resources
>
> > > are shared all
> >
> > > across ASPs.
> > > If each MG is supporting large number of Trunk resources (e.g.
> > > say 60K CICs), we are talking large network provisioning in a real

> > > time network.
> > >
> > > Static registration is not a method for such networks. Flow 
> > > through provisioning (Dynamic Registration) is required between
MGC & SG.
> > >
> > > We have such distributed networks successfully deployed with 
> > > similar
>
> > > modifications (ISUP Proxy) and enhancement (for dynamic 
> > > registration
> > > procedure) for the same reason.
> > >
> > > We seriously think that its time that we should consider Dynamic 
> > > registration procedure in this direction if we want a better 
> > > inter-op world around us.
> > >
> > > Thanks,
> > > Jitin
> > >
> > >
> > > -----Original Message-----
> > > From: Haresign Lincoln [mailto:[email-masked]]
> > > Sent: Thursday, November 02, 2006 2:29 PM
> > > To: Barry Nagelberg; [email-masked]
> > > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> > >
> > > It certainly would be a nice feature.  But there are a large 
> > > number of
> >
> > > ISUP scenarios that would need to be covered.  For example, if you

> > > loose all ASPs handing a certain CIC range, do you BLO?  Anyway, 
> > > it seems to me that this is almost too much for M3UA and almost 
> > > requires a new extension specifically for ISUP.
> > >
> > > Regards,
> > > Lincoln
> > >
> > > -----Original Message-----
> > > From: Barry Nagelberg [mailto:[email-masked]]
> > > Sent: Wednesday, November 01, 2006 4:11 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> > >
> > > All,
> > >
> > > I agree with Jitlin - CIC range functionality should be put back 
> > > into Dynamic Registration. After removing it to comply to the 
> > > spec, we had to put it back in because one of our customers
demanded it.
> > >
> > > In cases such as these, I suggest that try harder to listen to our

> > > customers - after all, they are the ones who are paying for 
> > > SIGTRAN to
> >
> > > be actually implemented and deployed.
> > >
> > > Barry Nagelberg
> > > Adax, Inc.
> > >
> > > -----Original Message-----
> > > From: Bhandari, Jitin (Jitin) [mailto:[email-masked]]
> > > Sent: Wednesday, November 01, 2006 3:53 PM
> > > To: [email-masked]'
> > > Cc: [email-masked]'
> > > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> > >
> > >
> > > Brian,
> > >
> > > No where in the RFC-3332, I understand the interpretation of CIC 
> > > ranges is limited to Load Distribution.
> > >
> > > When CIC ranges were a part of Routing Key, they can very well be 
> > > used
> >
> > > for routing and be defined as a part of Routing key. Since, 
> > > OPC-DPC-CIC values uniquely identify a resource on the ASP and can

> > > very well be treated is unique routing key from RFC definition.
> > >
> > > I very well understand when you talk about CIC & TID being just an

> > > element from Load Sharing perspective but for the same analogy if 
> > > CIC & TID are for Load distribution, OPC can also be viewed as 
> > > Load distribution method so as to have multiple ASPs (behind SG) 
> > > handling
>
> > > parts of SS7 network. It is up-to anyone as how one vision Routing

> > > key
> >
> > > arbitration at SG for MGC. Limiting the Routing Key definition at 
> > > RFC level is not fair especially when it was talked about in
> previous RFC.
> > >
> > > My point here is that by getting rid of such parameters at RFC 
> > > level, we would face many inter-op issues with various vendors in 
> > > the real work if one has to pick Dynamic Registration Path. We 
> > > will only end up
> >
> > > with many drafts like this one modifying the Registration Request 
> > > message for handling of SS7 traffic at SG. Inter-op in real world 
> > > would be a serious issue with such procedures then.
> > >
> > > Also, as I mentioned in my previous email, CIC resources being 
> > > dynamic
> >
> > > in nature at MGC, a flow through dynamic provisioning support 
> > > (from MGC to SG) was provided by having such Keys in the dynamic 
> > > registration procedure.
> > >
> > > By getting rid of such parameters at RFC level, we are just making

> > > Dynamic Registration procedure un-usable.
> > >
> > > -Jitin
> > >
> > >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Wednesday, November 01, 2006 3:11 PM
> > > To: Bhandari, Jitin (Jitin)
> > > Cc: [email-masked]'
> > > Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message
> > >
> > > Jitin,
> > >
> > > CIC and TID were only applicable to load distribution and not 
> > > routing and were therefore removed from the "routing" key.
> > >
> > > See
> > >
> > >
> > >
> http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-loadsel-04.
> > > tx
> > > t
> > >
> > > for a equivalent mechanism for controlling load distribution based

> > > on CIC using a "load" key dynamically registered in the REG REQ.
> > >
> > > --brian
> > >
> > > --
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran

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

---

From: "Ilie Glib" <[email-masked]>
Date: Mon, 6 Nov 2006 18:48:31 +0100

Hello Folks,

M3UA does not define any handling of application level messages that
have to be generated based on AS state.

Under the assumption that CICs are supported as part of the routing
key M3UA SG will distribute ISUP messages to ASPs based on the CIC in
the MTP RL.

In the opposite direction it is the responsibility of the ASPs and AS
to send ISUP messages, for instance when some circuits become
unavailable they have to be blocked by ISUP application residing in
the ASPs. The SG cannot take this burden.

Regards

/Ilie

-- 
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Mon, 6 Nov 2006 13:19:46 -0500

Ilie,

Let's assume that we have AS1 responsible for CICs 1-31 and AS2
responsible for CICs 32-63.  Two separate Application Servers.

The SG looses connectivity to AS1.  Now the switch in the SS7 network is
sending IAMs to the SG to be routed back to AS1, but AS1 can not respond
as it is no longer there.  This situation could persist for hours with
the SS7 switch uselessly sending IAMs delaying call setup time.
Normally, a switch in this case would send a group block message to the
network or individual BLOs if Group Blocking is not supported (I'm not
aware of any country that indicated otherwise...perhaps there is
something here I'm not aware of).

Are you saying that the SG should do nothing?  If it should do
something, don't you think we should attempt to standardize it?

I agree that M3UA does not define the handling of application level
messages.  I think that's why CICs was pulled from M3UA.  I don't think
pulling CICs out of dynamic registration makes it useless.  After all,
you can register for DPC or SI.  These are both very useful features.

Again, I'm not saying that CIC should be permanently pulled.  I just
don't think you can put it back in without adressing all the failure
scenarios.

Regards,
Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 12:49 PM
To: Bhandari, Jitin (Jitin)
Cc: Haresign Lincoln; Tolga Asveren; Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Hello Folks,

Under the assumption that CICs are supported as part of the routing key
M3UA SG will distribute ISUP messages to ASPs based on the CIC in the
MTP RL.

In the opposite direction it is the responsibility of the ASPs and AS to
send ISUP messages, for instance when some circuits become unavailable
they have to be blocked by ISUP application residing in the ASPs. The SG
cannot take this burden.

Regards

/Ilie

On 11/6/06, Bhandari, Jitin (Jitin) <[email-masked]> wrote:
> Lincoln,
>
> I understand that we need to resolve such issues of CIC handling at SG
but I see putting back CIC ranges in Dynamic registration message as a
separate issue.
>
> Note that the current RFC does not define clearly the Routing Key for
Static Registration methods and anyone is free to choose any key (i.e.
including CIC ranges). If at SG, we are provisioning CIC ranges against
routing Keys and across AS(s), the same problem exists.
>
> By getting rid of CIC ranges at Dynamic Registration, We haven't yet
solved that issue as it still exists (with static routing key
definition) but I am not sure if we need to address this issue in
SIGTRAN forums.
>
> I think someone else in this discussion thread did already mention
that this is issue is essentially with SG and Signaling networks and not
between MGC & SG though it is important that any SG implementation which
supports CIC ranges are Routing key should address this issue. Also, I
agree with you that this problem needs to be solved but I am not sure if
this is in the domain of SIGTRAN.
>
> Also, the handling of such ISUP message should be not proprietary as
should adhere to all specs defined for various variants of ISUP.
>
> Again, this problem has nothing to do with having CIC ranges in
Dynamic registration request. My point is that as in my earlier emails,
that by getting rid of CIC Ranges for Dynamic registration we have
limited or somewhat made Dynamic Registration procedure un-usable.
>
> That's why we strongly feel that CIC ranges should be put back in
Dynamic registration procedure for Routing Key definitions.
> I'm not sure I'm understanding.  I think if the SG is going to 
> handling CIC routing, then there is an implication that it needs to do

> some level of CIC management.  I don't think you can just put CIC 
> routing back in to the RFC w/o addressing this issue.
>
> Are you saying we should put CIC routing back in the RFC and not 
> address all the issues that are associated with doing this?
>
> Regards,
> Lincoln
>

> These procedures are clearly defined by ISUP standards and vary 
> variant to variant. So the handling of each such ISUP message would be

> network & variant dependant.
>

> Sigtran attention given that this only exists between Signaling 
> networks and SG.
>

> So, my question would be that if we all agree that what should we do 
> to get back CIC Ranges in Dynamic Registration messages?
>
> Thanks,
> -Jitin
>

> > This could be a fairly lengthy outage.  Or are you saying we leave 
> > it up to the SG and everybody does it differently?  What if the SG 
> > sends a BLO, then the ASP comes back, how does the ASP know the 
> > state of the
>
> > CIC?
> >

> > > As long as the issue can be handled locally in SG, IMHO there is 
> > > no need to define specific behavior in SIGTRAN WG. We maybe just 
> > > need to say whose responsibility is it to deal with the
complexity, e.g.

> > > > with it. Not only the Dynamic Registration needs to be 
> > > > re-defined with
> > >
> > > > some basic modifications, along with almost a minor 
> > > > functionality (ISUP Proxy) need to be defined as a part of M3UA 
> > > > on SG for such scenarios.
> > > >

> > > > When CIC ranges were a part of Routing Key, they can very well 
> > > > be used
> > >
> > > > element from Load Sharing perspective but for the same analogy 
> > > > if CIC & TID are for Load distribution, OPC can also be viewed 
> > > > as Load distribution method so as to have multiple ASPs (behind 
> > > > SG) handling
> >
> > > > arbitration at SG for MGC. Limiting the Routing Key definition 
> > > > at RFC level is not fair especially when it was talked about in
> > previous RFC.
> > > >
> > > > level, we would face many inter-op issues with various vendors 
> > > > in the real work if one has to pick Dynamic Registration Path. 
> > > > We will only end up
> > >
> > > > with many drafts like this one modifying the Registration 
> > > > Request message for handling of SS7 traffic at SG. Inter-op in 
> > > > real world would be a serious issue with such procedures then.
> > > >

--
Ilie

---

From: "Barry Nagelberg" <[email-masked]>
Date: Mon, 6 Nov 2006 13:42:57 -0500

Lincoln,

I disagree that the RFC must define the proper handling of any CIC failure scenarios - this handling is implementation
dependent.

The main purpose of the RFC is to define the xUA-over-IP message formatting. All we are suggesting is to rectify the
"dumbing down" of the Reg Req msg that occurred when CIC range registration was removed.

Barry Nagelberg

-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]]
Sent: Monday, November 06, 2006 1:20 PM
To: Ilie Glib; Bhandari, Jitin (Jitin)
Cc: Tolga Asveren; Barry Nagelberg; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Ilie,

Regards,
Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]]
Sent: Monday, November 06, 2006 12:49 PM
To: Bhandari, Jitin (Jitin)
Cc: Haresign Lincoln; Tolga Asveren; Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Hello Folks,

Regards

/Ilie

complexity, e.g.

--
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Mon, 6 Nov 2006 13:52:32 -0500

Barry,

If you say this is implementation dependent, and the one SG vendor does
different things with the CICs than another in this scenario, and I'm
implementing an AS to interface to various SGs, how can I expect to know
what the state of the CIC is after this failure scenario?

For example, I temporarily loose connectivity to the SG.  As an AS,
should I assume anything about the management state of the CIC?  Perhaps
I might want to do a group reset...but wait..maybe the SG, in their
implementation, did that for me.  Maybe I should try to query the state
of what the SG thinks the CIC state is since it has sent out a BLO.  But
there's no definition for a query in SIGTRAN...

Again, I don't understand....are you saying that everyone who implements
an SG that does load distribution based upon CIC can take it upon them
selves to make up their own actions in the case of failure of an AS.

OR

Are you saying the SG does nothing in the case of AS failure.

OR

Are you saying something else and I'm just not catching it.

Regards,
Lincoln 

-----Original Message-----
From: Barry Nagelberg [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 1:43 PM
To: [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

I disagree that the RFC must define the proper handling of any CIC
failure scenarios - this handling is implementation dependent.

The main purpose of the RFC is to define the xUA-over-IP message
formatting. All we are suggesting is to rectify the "dumbing down" of
the Reg Req msg that occurred when CIC range registration was removed.

Barry Nagelberg

-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]]
Sent: Monday, November 06, 2006 1:20 PM
To: Ilie Glib; Bhandari, Jitin (Jitin)
Cc: Tolga Asveren; Barry Nagelberg; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Ilie,

Regards,
Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]]
Sent: Monday, November 06, 2006 12:49 PM
To: Bhandari, Jitin (Jitin)
Cc: Haresign Lincoln; Tolga Asveren; Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Hello Folks,

Regards

/Ilie

complexity, e.g.

--
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Nov 2006 12:41:25 -0700

Jitin,

Look at ETSI TS 102 142 clause 5.3:

 "The Routing Key to enable messages to be distributed to the appropriate
  AS shall have a granularity no smaller than [a] Point Code."

--brian

Bhandari, Jitin (Jitin) wrote:                   (Mon, 06 Nov 2006 12:16:20)
> 
> Note that the current RFC does not define clearly the Routing Key for Static
> Registration methods and anyone is free to choose any key (i.e. including
> CIC ranges). If at SG, we are provisioning CIC ranges against routing Keys
> and across AS(s), the same problem exists. 
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Nov 2006 12:52:11 -0700

Lincoln,

The LOADSEL draft provides just such a failover mechanism.

The SS7 network does not route on CIC, it performs load sharing of
messages over SS7 links based on SLS (which is part of the CIC).

ETSI TS 102 142 properly asserts that RKs should be no less than
a Point Code (with the exception that in ANSI networks where Alias
point codes are used per ANSI T1.113/2000 for the GTT function,
distribution on SI value is suitable).

In fact, all such CIC schemes are load sharing and not routing.
What is lacking in the M3UA RFCs (both of them) is the ASPs inability
to control the load selection algorithm to effect efficient call
state sharing and management.  The LOADSEL draft provides just such
a mechanism for CIC and the LOADGRP draft provide another level of
sophistication on the same load selector.

In your failover scenario, under LOADGRP it is even possible for
the ASPs to specify to which alternate ASP a given load selection
fails over to.  For both LOADSEL and LOADGRP, the SG does not need
to understand ISUP to perform its function, yet the ASPs have
complete control over management of call state by specifying to
which ASPs the SG sends which messages.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Mon, 6 Nov 2006 15:07:17 -0500

Brian,

Let me see if I understand correctly.  You are saying that we can
distribute load within an AS using LOADSEL.  Does this imply that all
CICs are covered.

For example, if the SG is receiving messages from OPC1 for CICs 1-3200
and OPC2 for CICs 1-3200, then there must be an AS that handles all of
these incoming IAMs.  Or, are you saying the SG has no ISUP knowledge,
and it is just looking at the CIC value and perhaps distributing load to
the AS that is registered to receive traffic from OPC1 for example.

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 2:52 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

ETSI TS 102 142 properly asserts that RKs should be no less than a Point
Code (with the exception that in ANSI networks where Alias point codes
are used per ANSI T1.113/2000 for the GTT function, distribution on SI
value is suitable).

In fact, all such CIC schemes are load sharing and not routing.
What is lacking in the M3UA RFCs (both of them) is the ASPs inability to
control the load selection algorithm to effect efficient call state
sharing and management.  The LOADSEL draft provides just such a
mechanism for CIC and the LOADGRP draft provide another level of
sophistication on the same load selector.

In your failover scenario, under LOADGRP it is even possible for the
ASPs to specify to which alternate ASP a given load selection fails over
to.  For both LOADSEL and LOADGRP, the SG does not need to understand
ISUP to perform its function, yet the ASPs have complete control over
management of call state by specifying to which ASPs the SG sends which
messages.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Nov 2006 14:01:56 -0700

Lincoln,

This simplest approach, and that taken by LOADSEL, is that, if a message
does not correspond to a registered/configured load selection range, it
is load shared over the active ASPs for the AS using the normal
loadsharing mechanism (i.e, SLS, round-robin, dedicated default ASP).
Thus, the selected ASP can apply the appropriate unequipped CIC
treatment and the SG does not require knowledge of ISUP.

The same is true for SSN and TID for SUA.  If you recall our recent
discussion regarding TID and DRN labels, the same principles apply.
LOADSEL is a more workable replacement for the broken TID/DRN label
mechanism.

LOADGRP is even more sophisticated.  It is possible for the ASPs to
specify that a given Load Selection (CIC 1-3200) is Active/Standby
within a load group and the SG can fail this specific load selection
from one ASP to its alternate, again without knowledge of the upper
layer protocol (beyond syntactically extracting the load key from the
message).

--brian

Haresign Lincoln wrote:                       (Mon, 06 Nov 2006 15:07:17)

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Mon, 6 Nov 2006 16:10:12 -0500

Brian,

Is it possible using LOADSEL (or LOADGRP) to have two different
Application Servers (not ASPs) handling different CIC ranges?  Both AS
would share the same PC as the SG.  

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 4:02 PM
To: Haresign Lincoln
Cc: [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

--brian

Haresign Lincoln wrote:                       (Mon, 06 Nov 2006
15:07:17)

> and it is just looking at the CIC value and perhaps distributing load 
> to the AS that is registered to receive traffic from OPC1 for example.
> 
> Regards,
> Lincoln
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Nov 2006 14:17:30 -0700

Haresign,

Yes, that is how it works.  Load selections are defined within an AS.
Therefore, the AS is on the basis of Point Code (and possibly SI=5).
CIC ranges are defined as load selectors and load selections are assigned
to ASPs serving the loadshare AS.  So, all ASPs in this example AS
would serve the same Point Code, but would be given traffic for different
CIC ranges.  Did you look at the draft?

--brian

Haresign Lincoln wrote:                      (Mon, 06 Nov 2006 16:10:12)

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Mon, 6 Nov 2006 16:26:03 -0500

Brian,

"did you look at the spec" 

Yes.

You say AS is on the basis of PC.  Do you mean OPC?  Or DPC?  

Again, the way I understand this is that each AS must have a routing
criteria based upon either OPC or DPC and then you can use LOADSEL for
loadsharing the CIC ranges within the AS.  Is that correct, or have I
misunderstood?

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 4:18 PM
To: Haresign Lincoln
Cc: [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Haresign,

Yes, that is how it works.  Load selections are defined within an AS.
Therefore, the AS is on the basis of Point Code (and possibly SI=5).
CIC ranges are defined as load selectors and load selections are
assigned to ASPs serving the loadshare AS.  So, all ASPs in this example
AS would serve the same Point Code, but would be given traffic for
different CIC ranges.  Did you look at the draft?

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Nov 2006 14:38:19 -0700

Lincoln,

Well, I usually assign ISUP routing keys based on OPC/DPC pairings.
That way the CIC is significant, otherwise is certainly would not
be.  Note that OPC/DPC pairings still meets the TS 102 142
requirement.

--brian

Haresign Lincoln wrote:                      (Mon, 06 Nov 2006 16:26:03)

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Mon, 6 Nov 2006 16:45:16 -0500

Brian,

So in the case that we loose completely connectivity to an AS, what
would the SG do?  

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 4:38 PM
To: Haresign Lincoln
Cc: [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

Well, I usually assign ISUP routing keys based on OPC/DPC pairings.
That way the CIC is significant, otherwise is certainly would not be.
Note that OPC/DPC pairings still meets the TS 102 142 requirement.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Nov 2006 14:58:57 -0700

Lincoln,

Well, to begin with, an SG does not lose connectivity to an AS, it loses
connectivity to one or more ASPs.  In the case where an SG loses
connectivity to all ASPs serving an AS, the SG does what it normally
does: the AS moves to state AS-PENDING and a notification is sent to any
ASPs in the ASP-INACTIVE state for the AS (maybe none) and informs
management.  Eventually the SG moves the AS to the AS-INACTIVE state and
takes action with regard to the SS7 network.  Because there is no AS in
the AS-ACTIVE or AS-PENDING state corresponding to messages received
from the SS7 network, the SG performs implementation dependent treatment
toward the SS7 network.

This, according to the RFC, can include sending the messages to a
default ASP (possibly and internal one), rerouting messages to the
alternate STP in an STP pair using C-links if the route toward the
alternate STP is not prohibited, or sending UPU Inaccessible toward the
originating SP (in the case that the SG is an SEP and "owns" the point
code), or sending TFP (if the SG is an STP and the route to the paired
STP is prohibited).

In the non-STP case, sending UPU Inaccessible is appropriate and is
properly interpreted by ISUP at the originating SEP.

--brian

Haresign Lincoln wrote:                       (Mon, 06 Nov 2006 16:45:16)

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

---

From: "Ilie Glib" <[email-masked]>
Date: Tue, 7 Nov 2006 00:41:04 +0100

Lincoln,

if it is an M3UA SG it shall not send any MTP3 user messages on its
own to SS7 peers.
What the SG can do is to have a kind of NTFY procedure to inform other
ASPs, for instance ASPs serving the same point code, about
unavailability of the range of CICs.

I believe it is application responsibility to deal with this kind of
problems. Therefore, the distributed application that resides in
SIGTRAN realm has to take care and inform SS7 peers about such an
event.

The distributed AS may rely on notifications from the SGs, in that
case we need to extend NTFY or use loadsel draft. NTFY of loadsel
works here perfectly. The only problem for the ASPs is to decide which
one has to block the CIC range, but this one can be left to the ASPs
to solve, and it is rather easy to solve it.

I think that CIC ranges belong more to load distribution mechanism
rather than to an RK.

Regards

/Ilie

> something here I'm not aware of).

Ilie: This problem has to be solved by applications (ISUP in that case)

> something, don't you think we should attempt to standardize it?

Ilie: Yes, it shall be standardized. However, the M3UA SG shall not
send ISUP group blocking messages to SS7 peers.

> don't think you can put it back in without adressing all the failure

Ilie: Right.

-- 
Ilie

---

From: "Ilie Glib" <[email-masked]>
Date: Tue, 7 Nov 2006 00:45:08 +0100

Lincoln,

what SG would do in case of multiple M3UA SG scenario?

It becomes even worse then.

Regards

/Ilie

-- 
Ilie

---

From: "Ilie Glib" <[email-masked]>
Date: Tue, 7 Nov 2006 00:59:38 +0100

Brian,

I do not agree that TID and DRN is a broken loadsharing scheme.
It works perfectly, although it cannot use TID and DRN ranges dynamically.
Even that is possible with AS internal communication.

/Ilie

-- 
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Nov 2006 17:19:50 -0700

Ilie,

It is broken in a similar sense to CIC: what is lacking is a
notification procedure for notifying ASPs when a DRN/TID label range is
not being served by any ASP within the AS.  The SUA RFC describes the SG
as sending these messages to any active ASP and the problem ensues
again.  Coupled with the multiple SG as STP scenario, lack of a
notification procedure is further aggravated.  LOADSEL/LOADGRP provide a
superior mechanism for load distribution and activation of DRN/TID label
ranges.  Also, they provide a sensible notification procedure and
specified fail over procedures that allows ASPs to determine what
happens to ranges that are not being served.

All in all, I do not see much difference between managing call state
(CIC) and managing transaction/connection state (TID/DRN).  That is why
all three are included in the LOADSEL/LOADGRP drafts.

--brian

Ilie Glib wrote:                            (Tue, 07 Nov 2006 00:59:38)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Nov 2006 17:26:20 -0700

Ilie,

Ilie Glib wrote:                        (Tue, 07 Nov 2006 00:41:04)
> I think that CIC ranges belong more to load distribution mechanism

That is precisely what the WG agreed upon when CIC was removed from
the routing key in the M3UA IG -03.

What didn't happen (although it was supposed to be addressed in an
"extension draft") was adoption of a load distribution mechanism similar
to LOADSEL or LOADGRP to provide a usable replacement mechanism
supporting dynamic registration.

--brian

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

---

From: "Ilie Glib" <[email-masked]>
Date: Tue, 7 Nov 2006 12:21:11 +0100

Hello Brian,

multiple SG as STP scenario in SUA is a dead end, at least with the
current SUA status.

I think the difference between CIC and DRN or destination TID is
essential. CIC is a "resource" owned by both peers of the signalling
relation, while TID/DRN is owned only by one side of the signalling
relation.
More over DRNs and TIDs are software resources, while CICs are
physical resources.

For the reasons above, static handling of DRN/TID labels is
acceptable, whereas CICs require a rather dynamic handling. That is
why I find loadsel or similar way as something mandatory for M3UA to
support ISUP, while it is rather nice to have for SUA.

Regards

/Ilie

-- 
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Nov 2006 05:27:03 -0700

Ilie,

It does not alter the fact that DRN/TID labels have no notification
procedures and cannot support fail-over.  It is in this regard that
DRN/TID labels are fundamentally broken.

The fact that DRN/TID labels in RFC 3868 are not registered means that
errors occurring at activation time, as dictated by 4.7.2.1, can cripple
an entire AS.  Registering the load selection as described in LOADSEL
has the advantage that errors are detected at registration time instead
of at activation time.

The inability of multiple ASPs to activate for the same DRN/TID label
range makes it impossible to fail-over or smoothly transition from one to
another as is possible for the non-label model.  For example, if an ASP
registered for a label range fails and this is detected by another ASP,
the other ASP cannot activate for the label range for the duration of
time that the SG considers the failed ASP still active.

None of these problems or issues exist for the LOADSEL approach.
LOADSEL provides a notification procedure for fail-over; it detects load
selection errors at registration (or configuration) time instead of at
activation time; and it permits multiple ASPs to serve the same load
selection, even in Override mode, permitting smooth ASP-controlled
fail-over.

No, DRN/TID labels were rushed in at the end, did not receive sufficient
inspection or review, and are largely impractical when compared even to
LOADSEL.

--brian

Ilie Glib wrote:                          (Tue, 07 Nov 2006 12:21:11)

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 7 Nov 2006 11:33:26 -0500

Ilie,

Why couldn't you use TID/DRN ranges dynamically?  If the ASPs within the
AS have knowledge of each other, and each ASP receives a NOTIFY upon ASP
inactive, another ASP could become ACTIVE.  Not sure what you mean by
this.

Regards,
Lincoln 

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 7:00 PM
To: [email-masked]; Haresign Lincoln; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Brian,

I do not agree that TID and DRN is a broken loadsharing scheme.
It works perfectly, although it cannot use TID and DRN ranges
dynamically.
Even that is possible with AS internal communication.

/Ilie

On 11/6/06, Brian F. G. Bidulock <[email-masked]> wrote:
> Lincoln,
>
> This simplest approach, and that taken by LOADSEL, is that, if a 
> message does not correspond to a registered/configured load selection 
> range, it is load shared over the active ASPs for the AS using the 
> normal loadsharing mechanism (i.e, SLS, round-robin, dedicated default
ASP).
15:07:17)
> > distribute load within an AS using LOADSEL.  Does this imply that 
> > all CICs are covered.
> >
> > For example, if the SG is receiving messages from OPC1 for CICs 
> > 1-3200 and OPC2 for CICs 1-3200, then there must be an AS that 
> > handles all of these incoming IAMs.  Or, are you saying the SG has 
> > no ISUP knowledge, and it is just looking at the CIC value and 
> > perhaps distributing load to the AS that is registered to receive
traffic from OPC1 for example.

--
Ilie

---

From: "Ilie Glib" <[email-masked]>
Date: Tue, 7 Nov 2006 17:47:17 +0100

Lincoln,

the format of the TID/DRN labels is not prepared for dynamic handling.
An ASP cannot serve two TID/DRN labels. Moreover, it is not possible
to combine several labels in one.

Regards

/Ilie

-- 
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 7 Nov 2006 12:16:00 -0500

Ilie,

You're right.  The problem of TIDs/DRNs is different than CICs as loss
of an ASP will only result in loss of calls in progess.  The SG will
reshuffle new BEGINs to the remaining ASPs.   With CICs it's a little
more of a problem as CICs are being assigned by the network as it
initiates a call and not by the ASP.

I'm unclear what the proposal is for CICs.  Is it to be used as an RK
which implies routing decisions on an AS level, or is it more like the
TID which implies routing decisions on an ASP level.

Regards,
Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 11:47 AM
To: Haresign Lincoln
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

the format of the TID/DRN labels is not prepared for dynamic handling.
An ASP cannot serve two TID/DRN labels. Moreover, it is not possible to
combine several labels in one.

Regards

/Ilie

On 11/7/06, Haresign Lincoln <[email-masked]> wrote:
> Ilie,
>
> Why couldn't you use TID/DRN ranges dynamically?  If the ASPs within 
> the AS have knowledge of each other, and each ASP receives a NOTIFY 
> upon ASP inactive, another ASP could become ACTIVE.  Not sure what you

> mean by this.
> > message does not correspond to a registered/configured load 
> > selection range, it is load shared over the active ASPs for the AS 
> > using the normal loadsharing mechanism (i.e, SLS, round-robin, 
> > dedicated default
> ASP).

> > layer protocol (beyond syntactically extracting the load key from 
> > the message).
> >
> > --brian
> >

--
Ilie

---

From: "Barry Nagelberg" <[email-masked]>
Date: Tue, 7 Nov 2006 12:25:44 -0500

It is to be used as an RK, which implies routing decisions on an AS level.

-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 12:16 PM
To: Ilie Glib
Cc: [email-masked]; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Ilie,

Regards,
Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 11:47 AM
To: Haresign Lincoln
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

Regards

/Ilie

--
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 7 Nov 2006 12:45:26 -0500

So...does that mean you only have one ASP/AS? 

-----Original Message-----
From: Barry Nagelberg [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 12:26 PM
To: [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

It is to be used as an RK, which implies routing decisions on an AS
level.

-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 12:16 PM
To: Ilie Glib
Cc: [email-masked]; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Ilie,

Regards,
Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 11:47 AM
To: Haresign Lincoln
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

Regards

/Ilie

--
Ilie

---

From: "Barry Nagelberg" <[email-masked]>
Date: Tue, 7 Nov 2006 12:50:40 -0500

Why the limitation?

-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 12:16 PM
To: Ilie Glib
Cc: [email-masked]; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Ilie,

Regards,
Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 11:47 AM
To: Haresign Lincoln
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

Regards

/Ilie

--
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 7 Nov 2006 12:55:51 -0500

Well if you are specifing a CIC range as a RK, then for other ASP to be
within the same AS, they also must specify the same CIC range..yes? 

-----Original Message-----
From: Barry Nagelberg [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 12:51 PM
To: [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Why the limitation?

-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 12:16 PM
To: Ilie Glib
Cc: [email-masked]; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Ilie,

Regards,
Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 11:47 AM
To: Haresign Lincoln
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

Regards

/Ilie

--
Ilie

---

From: "Barry Nagelberg" <[email-masked]>
Date: Tue, 7 Nov 2006 13:20:03 -0500

Maybe I'm loadsharing between multiple ASPs.

-----Original Message-----
From: Barry Nagelberg [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 12:51 PM
To: [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Why the limitation?

-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 12:16 PM
To: Ilie Glib
Cc: [email-masked]; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Ilie,

Regards,
Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 11:47 AM
To: Haresign Lincoln
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

Regards

/Ilie

--
Ilie

---

From: "Ilie Glib" <[email-masked]>
Date: Tue, 7 Nov 2006 19:19:56 +0100

Lincoln,

instead of
> An ASP cannot serve two TID/DRN labels.
I wanted to say "An ASP cannot serve two TID/DRN labels PER AS".

/Ilie

-- 
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 7 Nov 2006 13:23:43 -0500

OK..so an IAM comes in for CIC 1 and you send to ASP1, then later the
REL comes in for CIC 1 and you send to ASP2? 

-----Original Message-----
From: Barry Nagelberg [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 12:51 PM
To: [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Why the limitation?

-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 12:16 PM
To: Ilie Glib
Cc: [email-masked]; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Ilie,

Regards,
Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 11:47 AM
To: Haresign Lincoln
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

Regards

/Ilie

--
Ilie

---

From: "Barry Nagelberg" <[email-masked]>
Date: Tue, 7 Nov 2006 13:32:17 -0500

For ISUP, ASP mapping is performed based on SLS.

-----Original Message-----
From: Barry Nagelberg [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 12:51 PM
To: [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Why the limitation?

-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 12:16 PM
To: Ilie Glib
Cc: [email-masked]; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Ilie,

Regards,
Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 11:47 AM
To: Haresign Lincoln
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

Regards

/Ilie

--
Ilie

---

From: "Ilie Glib" <[email-masked]>
Date: Tue, 7 Nov 2006 19:33:20 +0100

Lincoln, Barry,

I think  the way forwards with CICs depends on solutions we aim at,
and it can either refine the RK as in an old M3UA draft, or define a
load distribution scheme as suggested in LOADSEL draft.

I believe both ways are feasible, and the WG has to agree on the
preferred option.

/Ilie

-- 
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 7 Nov 2006 13:36:30 -0500

That implies that you can only have 16 ASPs?

Besides, that doesn't really work in an ANSI network.  In an ANSI
network, the SLS is rotated as it passes through the network.  So the
incoming IAM may have one SLS value, but due to a failure in the network
and a longer path, the REL may have a different SLS value.

-----Original Message-----
From: Barry Nagelberg [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 12:51 PM
To: [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Why the limitation?

-----Original Message-----
From: Haresign Lincoln [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 12:16 PM
To: Ilie Glib
Cc: [email-masked]; [email-masked]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Ilie,

Regards,
Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 11:47 AM
To: Haresign Lincoln
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

Regards

/Ilie

--
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Nov 2006 11:39:45 -0700

Lincoln,

Haresign Lincoln wrote:                                           (Tue, 07 Nov 2006 11:42:43)
> Brian,
> 
> I'm just trying to clarify one issue based upon this chain and also some
> previous ones.  Do you believe that this is a valid scenario:
> 
> SG: DPC=1
> 
> AS1 - RK: DPC=1, OPC=2
> AS2 - RK: DPC=1, OPC=3
>
> The AS share the same point code with the SG.  AS1 receives all messages
> from PC=2.  AS2 receives all messages from PC=3.

Yes, this is the scenario of which I was speaking.

> If this is valid, I guess this shares the same problem whether or not
> you are using CIC loadsharing.  If AS1 completely goes away (all ASP
> wihtin AS1 become INACTIVE), there is little the SG can do but drop the
> messages.  

It can send UPU Inaccessible to PC=2.  At PC=2, ISUP, on receipt of UPU
for PC=1 will start User Part Test procedures, sending periodic UPT messages
to PC=1 until a UPA is returned instead of a UPU.  During the User Part Test
it will send no further ISUP messages to PC=1 and will perform proper
treatment of circuits for the isolated signalling relation.

> 
> The ETSI spec seems to imply the perhaps this is not valid since is has
> a finer granularity that PC.

The routing key is not of finer granularity than a PC.  SI is the first
element of finer granularity than a PC.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 7 Nov 2006 13:41:13 -0500

Ilie,

Personally, I don't see how CICs can work in the old M3UA draft.

And I'm still trying to determine what the actual requirements are.  

Do AS share the same PC as the SG when working with CICs or do we
require a different PC?

I think the first issue is to define all the requirements.

Regards,
Lincoln 

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 1:33 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln, Barry,

I think  the way forwards with CICs depends on solutions we aim at, and
it can either refine the RK as in an old M3UA draft, or define a load
distribution scheme as suggested in LOADSEL draft.

/Ilie

On 11/7/06, Haresign Lincoln <[email-masked]> wrote:
> Well if you are specifing a CIC range as a RK, then for other ASP to 
> be within the same AS, they also must specify the same CIC range..yes?
>

> > > The same is true for SSN and TID for SUA.  If you recall our 
> > > recent discussion regarding TID and DRN labels, the same
principles apply.
> > > LOADSEL is a more workable replacement for the broken TID/DRN 
> > > label mechanism.
> > >
> > > LOADGRP is even more sophisticated.  It is possible for the ASPs 
> > > to specify that a given Load Selection (CIC 1-3200) is 
> > > Active/Standby within a load group and the SG can fail this 
> > > specific load selection
>
> > > from one ASP to its alternate, again without knowledge of the 
> > > upper layer protocol (beyond syntactically extracting the load key

> > > from the message).
> > > > Let me see if I understand correctly.  You are saying that we 
> > > > can distribute load within an AS using LOADSEL.  Does this imply

> > > > that all CICs are covered.
> > > >

--
Ilie

---

From: "Ilie Glib" <[email-masked]>
Date: Tue, 7 Nov 2006 19:41:32 +0100

Lincoln,

even when the RK contains a range of CICs the SG has to loadshare in
SLS persistent way. So the SG will send ISUP message to the same ASP
for the same CIC.

/ilie

-- 
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 7 Nov 2006 13:24:14 -0500

Agreed. 

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 1:20 PM
To: Haresign Lincoln
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

instead of

/Ilie

principles apply.

--
Ilie

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Nov 2006 12:30:37 -0700

Lincoln,

The deficiency addressed by LOADSEL, as described in the Overview
section 1.4., is that existing approaches are not amenable in the
following situations:

  a) Connection- or Transaction-Oriented traffic flows which group
     the message corresponding to a connection or transaction.

  b) Large scale ssytems that need to adapt to dynamic traffic
     loading.

  c) Systems that need dynamic reconfiguration under ASP control
     for maintenance or fail-over purposes.

  d) Systems that require ASP control over load-sharing (such as
     those that attempt to minimize state sharing while maximizing
     reliability).

But that is contained in the overview of the draft...

--brian

Haresign Lincoln wrote:                 (Tue, 07 Nov 2006 13:41:13)

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

---

From: "Ilie Glib" <[email-masked]>
Date: Tue, 7 Nov 2006 20:46:05 +0100

Lincoln, Brian

as far as I can understand, the old draft has everything that is
needed to solve CIC problem in a distributed application, that is, an
RK can contain CIC ranges. NTFY procedures will distribute AS/ASP
status changes to ASPs of the AS.

In order to receive a NTFY an ASP has to be inactive for the RK.

The rest is implementation dependent, handling of application level
procedures is the task of the concerned distributed AS.

/Ilie

-- 
Ilie

---

From: "Ilie Glib" <[email-masked]>
Date: Tue, 7 Nov 2006 20:47:53 +0100

Brian,

Please can you give an ISUP related example where LOADSEL draft does
better than RKs with CICs.

Thank you in advance

/Ilie

-- 
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 7 Nov 2006 14:54:18 -0500

Brian,

You're right, that will work.  

I'm in agreement with you that adding CIC to the list of RK won't work
and we either need to further modify M3UA, or try to get your
LOADSEL/LOADGRP drafts in alignment with all the requirements that might
exist for all users (if they are not already).

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 1:40 PM
To: Haresign Lincoln
Cc: [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

Haresign Lincoln wrote:                                           (Tue,
07 Nov 2006 11:42:43)
> Brian,
> 
> I'm just trying to clarify one issue based upon this chain and also 
> some previous ones.  Do you believe that this is a valid scenario:
> 
> SG: DPC=1
> 
> AS1 - RK: DPC=1, OPC=2
> AS2 - RK: DPC=1, OPC=3
>
> The AS share the same point code with the SG.  AS1 receives all 
> messages from PC=2.  AS2 receives all messages from PC=3.

> wihtin AS1 become INACTIVE), there is little the SG can do but drop 
> the messages.

It can send UPU Inaccessible to PC=2.  At PC=2, ISUP, on receipt of UPU
for PC=1 will start User Part Test procedures, sending periodic UPT
messages to PC=1 until a UPA is returned instead of a UPU.  During the
User Part Test it will send no further ISUP messages to PC=1 and will
perform proper treatment of circuits for the isolated signalling
relation.

> 
> The ETSI spec seems to imply the perhaps this is not valid since is 
> has a finer granularity that PC.

--brian

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

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 7 Nov 2006 15:05:53 -0500

Ilie,

Certainly.  So you are saying that one ASP takes on all CICs of a
certain value.

Perhaps I'm mistaken, if CIC ranges is part of a "routing key", than it
has a one-to-one correspondence with a Routing Context.  And all ASPs
within an AS share the same RC.

Therefore, I think the CIC range needs to be treated more like in the
ASP-ACTIVE message (similar to TID) except that perhaps the SG needs to
be able to handle receiving this with modified ranges when other ASPs
come up/down.

Unless you are saying that two ASPs send the same range in the RK (where
the SG is loadsharing evenly among the CIC range with a consistent
algorithm).  Then, there is no simple way to add a third ASP to the AS
dynamically unless the SG is somehow maintaining CIC state which would
never work.

Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 1:42 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

even when the RK contains a range of CICs the SG has to loadshare in SLS
persistent way. So the SG will send ISUP message to the same ASP for the
same CIC.

/ilie

principles apply.

--
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 7 Nov 2006 15:12:38 -0500

Illie,

Certainly there are problems with CIC in the old draft...do you agree?

I'm not proposing a solution at this point, I'd first like to just agree
on what the problems are, or at least outline what scenarios CIC will
work under versus what it won't work under.  Does it seem reasonable at
first to define all the current problems (i.e., the requirements).  And
then perhaps we can address solutions.

Regards,
Lincoln 

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 2:46 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln, Brian

as far as I can understand, the old draft has everything that is needed
to solve CIC problem in a distributed application, that is, an RK can
contain CIC ranges. NTFY procedures will distribute AS/ASP status
changes to ASPs of the AS.

/Ilie

> > I'm unclear what the proposal is for CICs.  Is it to be used as an 
> > RK which implies routing decisions on an AS level, or is it more 
> > like the
>

> > > the AS have knowledge of each other, and each ASP receives a 
> > > NOTIFY upon ASP inactive, another ASP could become ACTIVE.  Not 
> > > sure what you
> >
> > > mean by this.
> > >
> > > Regards,
> > > Lincoln
> > >

> > > > > For example, if the SG is receiving messages from OPC1 for 
> > > > > CICs 1-3200 and OPC2 for CICs 1-3200, then there must be an AS

> > > > > that handles all of these incoming IAMs.  Or, are you saying 
> > > > > the SG has
> >

--
Ilie

---

From: "Ilie Glib" <[email-masked]>
Date: Tue, 7 Nov 2006 21:46:08 +0100

Lincoln,

 Agreed.

/ilie

-- 
Ilie

---

From: "Ilie Glib" <[email-masked]>
Date: Tue, 7 Nov 2006 22:06:18 +0100

Lincoln,

I agree that in case there are problems we have to list them and try
to solve. At the same time I want to understand what are those
problems in case of RKs with CICs.

There are 3 TMTs to handle traffic for the RKs with CICs.
I do not see any problems with override and broadcast, there can be
any number of ASPs then.
I think that in case of loadshare TMT the SG shall distribute traffic
to ASPs in CIC persistent way, that is, as long as an ASP is active it
shall get all messages related to one particular CIC. In that sense
your example with ANSI SLSs is significant.
Thus, the number of the ASPs serving ISUP traffic for a particular CIC
range is limited by the number of CICs in the range, this is a
marginal example of course.

So far looking from AS/ASP perspective I cannot see any essential
differences between LOADSEL and RK with CICs.
I would appreciate it a lot if you can point to an explicit example
where ASP logic would be different for LOADSEL and RKs with CICs

See below in line.

Regards

/Ilie

> within an AS share the same RC.

ilie: Yes.
> be able to handle receiving this with modified ranges when other ASPs

ilie: No, other ASPs have to go active for the PENDING AS based on NTFY.

> dynamically unless the SG is somehow maintaining CIC state which would

Ilie: No, the SG shall not keep any CIC states.

-- 
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 7 Nov 2006 16:39:05 -0500

Ilie,

I'll leave it up to Brian to answer for LOADSEL.

Here are two problems:

1) First, with regards to CIC in general, I don't believe that you can
have the following AS definitions:

AS1 - RK: DPC=5, CIC=1-3200
AS2 - RK: DCP=5, CIC=3201-6400

I believe that you must either specify different DPCs, or you must
specifiy OPC in addition to DPC.  Otherwise, the SG will have to get in
to CIC management, which I believe we are all trying to avoid.  If it is
not clear why this is problematic, I can go in to more detail.
 
2) With regards to LoadShare within an AS, I'm not sure how you handle
the following dynamic case:

AS1 - RK: DPC=5, CIC=1-3200

2 ASPs are active.  ASP1 is receiving all messages for CIC 1-1600.  ASP2
is receiving all messages for CIC=1601-3200.  

Then ASP3 becomes ACTIVE in the same AS.  How can the SG redistribute
load while calls are in progress.  Or are you saying that the ASPs need
to just handle it?

Regards,
Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 4:06 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

I agree that in case there are problems we have to list them and try to
solve. At the same time I want to understand what are those problems in
case of RKs with CICs.

There are 3 TMTs to handle traffic for the RKs with CICs.
I do not see any problems with override and broadcast, there can be any
number of ASPs then.
I think that in case of loadshare TMT the SG shall distribute traffic to
ASPs in CIC persistent way, that is, as long as an ASP is active it
shall get all messages related to one particular CIC. In that sense your
example with ANSI SLSs is significant.
Thus, the number of the ASPs serving ISUP traffic for a particular CIC
range is limited by the number of CICs in the range, this is a marginal
example of course.

See below in line.

Regards

/Ilie

On 11/7/06, Haresign Lincoln <[email-masked]> wrote:
> Perhaps I'm mistaken, if CIC ranges is part of a "routing key", than 
> it has a one-to-one correspondence with a Routing Context.  And all 
> ASPs within an AS share the same RC.

ilie: Yes.
> ASP-ACTIVE message (similar to TID) except that perhaps the SG needs 
> to be able to handle receiving this with modified ranges when other 
> ASPs come up/down.

>
> Unless you are saying that two ASPs send the same range in the RK 
> (where the SG is loadsharing evenly among the CIC range with a 
> consistent algorithm).  Then, there is no simple way to add a third 
> ASP to the AS dynamically unless the SG is somehow maintaining CIC 
> state which would never work.

> > OK..so an IAM comes in for CIC 1 and you send to ASP1, then later 
> > the REL comes in for CIC 1 and you send to ASP2?
> >

--
Ilie

---

From: "Ilie Glib" <[email-masked]>
Date: Tue, 7 Nov 2006 23:00:17 +0100

Lincoln

see below

Regards

/Ilie

> not clear why this is problematic, I can go in to more detail.

Ilie: as long as MTP RL is part of the message, I cannot see a problem here.

> load while calls are in progress.  Or are you saying that the ASPs need

Ilie: Yes. M3UA has n+k redundancy scheme to deal with that problem.
Here, when you need more that k active ASPs, it is not possible to
avoid AS internal communication between involved ASPs.
To have a graceful handover from one ASP to another there can be ISUP
level procedures or better use override TMT.
Another option may be to use finer RK granularity, with smaller CIC
ranges, and perform coordinated ASPIA/ASPAC procedures from ASPs based
on NTFYs.

-- 
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 7 Nov 2006 17:06:25 -0500

Ilie,

OK, in order to keep this thread simple, I'll address issues one at a
time.

> specifiy OPC in addition to DPC.  Otherwise, the SG will have to get 
> in to CIC management, which I believe we are all trying to avoid.  If 
> it is not clear why this is problematic, I can go in to more detail.

Ilie: as long as MTP RL is part of the message, I cannot see a problem
here.

The problem is that when all the ASPs in AS1 become inactive, what
action should the SG take (if any)?

Regards,
Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 5:00 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln

see below

Regards

/Ilie

> specifiy OPC in addition to DPC.  Otherwise, the SG will have to get 
> in to CIC management, which I believe we are all trying to avoid.  If 
> it is not clear why this is problematic, I can go in to more detail.

Ilie: as long as MTP RL is part of the message, I cannot see a problem
here.

> 2 ASPs are active.  ASP1 is receiving all messages for CIC 1-1600.  
> ASP2 is receiving all messages for CIC=1601-3200.
>
> load while calls are in progress.  Or are you saying that the ASPs 
> need to just handle it?

Ilie: Yes. M3UA has n+k redundancy scheme to deal with that problem.
Here, when you need more that k active ASPs, it is not possible to avoid
AS internal communication between involved ASPs.
To have a graceful handover from one ASP to another there can be ISUP
level procedures or better use override TMT.
Another option may be to use finer RK granularity, with smaller CIC
ranges, and perform coordinated ASPIA/ASPAC procedures from ASPs based
on NTFYs.

> > Therefore, I think the CIC range needs to be treated more like in 
> > the ASP-ACTIVE message (similar to TID) except that perhaps the SG 
> > needs to be able to handle receiving this with modified ranges when 
> > other ASPs come up/down.
>

> > > > > This simplest approach, and that taken by LOADSEL, is that, if

> > > > > a

> > > > > dedicated default
> > > > ASP).
> > > > > Thus, the selected ASP can apply the appropriate unequipped 
> > > > > CIC treatment and the SG does not require knowledge of ISUP.
> > > > >
> > > > > upper layer protocol (beyond syntactically extracting the load

> > > > > > Let me see if I understand correctly.  You are saying that 
> > > > > > we can distribute load within an AS using LOADSEL.  Does 
> > > > > > this imply
> >

--
Ilie

---

From: "Ilie Glib" <[email-masked]>
Date: Tue, 7 Nov 2006 23:12:26 +0100

Lincoln,

the SG shall NTFY ASPs in ACTIVE/INACTIVE state of the AS.

/Ilie

-- 
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 7 Nov 2006 17:42:14 -0500

Ilie,

I'm assuming that you've lost complete connectivity to all your ASPs
with AS1 (i.e, all associations failed).  So:

1) nobody to tell anything behind you.

2) in front of you, you are receiving IAMs for the CIC range from the
connecting switch and since you have other AS handling other CIC ranges,
you can not send UPU. 

Regards,
Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 5:12 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

/Ilie

> > in to CIC management, which I believe we are all trying to avoid.  
> > If it is not clear why this is problematic, I can go in to more
detail.

> > in to CIC management, which I believe we are all trying to avoid.  
> > If it is not clear why this is problematic, I can go in to more
detail.

> > Then ASP3 becomes ACTIVE in the same AS.  How can the SG 
> > redistribute load while calls are in progress.  Or are you saying 
> > that the ASPs need to just handle it?
>

> > I think that in case of loadshare TMT the SG shall distribute 
> > traffic to ASPs in CIC persistent way, that is, as long as an ASP is

> > active it
> > > it has a one-to-one correspondence with a Routing Context.  And 
> > > all ASPs within an AS share the same RC.
> >
> > ilie: Yes.
> > >

> > > needs to be able to handle receiving this with modified ranges 
> > > when other ASPs come up/down.
> >
> > > consistent algorithm).  Then, there is no simple way to add a 
> > > third ASP to the AS dynamically unless the SG is somehow 
> > > maintaining CIC state which would never work.
> >
> > > > OK..so an IAM comes in for CIC 1 and you send to ASP1, then 
> > > > later the REL comes in for CIC 1 and you send to ASP2?
> > > >
> > > > It is to be used as an RK, which implies routing decisions on an

> > > > AS level.
> > > > more of a problem as CICs are being assigned by the network as 
> > > > it initiates a call and not by the ASP.
> > > >

> > > > > NOTIFY upon ASP inactive, another ASP could become ACTIVE.  
> > > > > Not sure what you
> > > >
> > > > > mean by this.
> > > > >
> > > > > Regards,
> > > > > Lincoln
> > > > >

> > > > > > LOADSEL is a more workable replacement for the broken 
> > > > > > TID/DRN label mechanism.
> > > > > >
> > > > > > from one ASP to its alternate, again without knowledge of 
> > > > > > the upper layer protocol (beyond syntactically extracting 
> > > > > > the load
>
> > > > > > key
> > >
> > > > > > from the message).
> > > > > >
> > > > > > --brian
> > > > > >

> > > > > > > no ISUP knowledge, and it is just looking at the CIC value

> > > > > > > and

--
Ilie

---

From: "Haresign Lincoln" <[email-masked]>
Date: Tue, 7 Nov 2006 11:42:43 -0500

Brian,

SG: DPC=1

AS1 - RK: DPC=1, OPC=2
AS2 - RK: DPC=1, OPC=3

Regards,
Lincoln

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 4:59 PM
To: Haresign Lincoln
Cc: [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

--brian

16:45:16)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Nov 2006 23:19:47 -0700

Ilie,

Ilie Glib wrote:                           (Tue, 07 Nov 2006 20:47:53)
> better than RKs with CICs.

The difficulty with routing verses load sharing is that with routing, for each
CIC range, you need a different RK/RC/AS and all of the difficulties that
entails.

Consider the following example:

ANSI 32k CICs broken into 24 channel circuit management groups for a total of
1366 CIC ranges between two point codes (PCA (local) and PCB (remote)).

OLD RFC Routing Keys would look like:

RK0001: DPC=PCA OPC=PCB TM=OVERRIDE CIC=00000-00023 => RC0001
RK0002: DPC=PCA OPC=PCB TM=OVERRIDE CIC=00024-00047 => RC0002
RK0003: DPC=PCA OPC=PCB TM=OVERRIDE CIC=00048-00071 => RC0003
...
RK1365: DPC=PCA OPC=PCB TM=OVERRIDE CIC=32736-32759 => RC1365
RK1366: DPC=PCA OPC=PCB TM=OVERRIDE CIC=32760-32768 => RC1366

The size of a single registration request message necessary to register all of
these keys at once would be:

 8 (msg hdr) + 1366 * ( 4 (rk phdr) + 8 (rk id) + 8 (tmode) + 8 (dpc) + 8 (opc
 list) + 12 (cic range) ) = 65576 bytes

The successful response would contain 1366 results with 1366 RC values.

Also, because the registering ASP is not ASP Inactive in 1366 separate AS,
each with an independent state,  1366 Notify(AS-INACTIVE) messages need to be
sent to each ASP when it registers.

LOADSEL Load Keys would look like:

LK0001: CIC=00000-00023 => LS0001
LK0002: CIC=00024-00047 => LS0002
LK0003: CIC=00048-00071 => LS0003
...
LK1365: CIC=32736-32759 => LS1365
LK1366: CIC=32760-32768 => LS1365

The size of a single registration request message necessary to register
all of these load keys would be:

 8 (msg hdr) + 4 (rk phdr) + 8 (rk id) + 8 (tmode) + 8 (dpc) + 8 (opc list) +
 1366 * ( 4 (ls phdr) + 12 (cic range) ) = 21900 bytes

The successful response would contain 1 result with 1 RC value and 1366 LS
values.

When each ASP registers, one Notify(AS-INACTIVE) is sent for the entire AS.

Now, assume that ASP1 activates for half of the RC values and ASP2 activates
for the other half (exactly which half is not important) in the RK case, and
ASP1 activates for half of the LS values and ASP2 the other half in the
LOADSEL case.  Each ASP is the standby for the half for which it is not
active.

In the RK case, when ASP1 activates, 683 AS transition from the AS-INACTIVE
state to the AS-ACTIVE state requiring sending 683 Notify(AS-ACTIVE) messages
to ASP1 and 683 Notify(AS-ACTIVE) messages to ASP2.  Again in the RK case,
when ASP2 activates, the other 683 AS transition from AS-INACTIVE to AS-ACTIVE
requiring sending 683 Notify(AS-ACTIVE) messages to ASP1 and 683
Notify(AS-ACTIVE) message to ASP2.

In the LOADSEL case, when ASP1 activates 1 AS transition occurs and 1
Notify(AS-ACTIVE) is sent to ASP1 and another to ASP2.  When ASP2 activates, 1
AS transition occurs and 1 Notify(AS-ACTIVE) is sent to ASP1 and another to
ASP2.

Now, assume that in comes time to send an SNMM for PCB (SCON[1] for example).

In the RK case, the SG will need to send 683 SCON[1] messages (one for each RC
value) to ASP1 and 638 SCON[1] messages (one for each RC value) to ASP2.

In the LOADSEL case, the SG sends one SCON[1] message to each of ASP1 and ASP2
(the same message twice rather than two messages).

Now, assume that ASP2 fails.  In the RK case, 683 AS's transition to the
AS-PENDING state (with 683 pending timers set) and the SG MUST send 683
Notify(AS-PENDING) messages to ASP1.  As the timers fire, 683
Notify(AS-INACTIVE) messages are sent to ASP1. In the LOADSEL case, 683 load
groups transition to AS-PENDING and the SG sends 1 Notify(AS-PENDING) with 683
load selectors in it, one timer can be set.  When the timer expires 1
Notify(AS-INACTIVE) message can be sent to ASP1.

I could go on, but I think that anyone can see from this example that fudging
the RK to include CIC range is an abuse of the AS mechanism that simply does
not scale, and requires that the SG juggle many more states and timers than
the better suited LOADSEL procedures.

When the mapping between AS and manageable SS7 MTP entities (Point Codes, User
Parts) is direct, a more workable approach to SS7 management of the SPMC
results.  Splitting a manageable SS7 MTP entity (ISUP User Part) into hundreds
or thousands of AS requires the SG to juggle (and notify for, and return
status for) all the independent parts that is simply not necessary with
LOADSEL.  LOADSEL allow the AS to represent the ISUP User Part and provides a
more apt management of Load Selections within that AS used only for message
distribution and communications concerning message distribution, with ASPs.

I hope that answers your question.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Nov 2006 23:23:21 -0700

Ilie,

I think that you will find from my previous note that forcing an RK approach
on something that is fundamentally a load sharing algorithm has inherent
disadvantages that make it unworkable in any system of significant scale
(10,000 - 50,000 trunks).

--brian

Ilie Glib wrote:                            (Tue, 07 Nov 2006 20:46:05)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Nov 2006 23:57:33 -0700

Lincoln,

It is even worse when one must examine the state of hundreds or thousands of
AS to determine whether it is possible to send UPU.  With LOADSEL, only one
AS state needs to be examined.

--brian

Haresign Lincoln wrote:                       (Tue, 07 Nov 2006 17:42:14)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Nov 2006 23:46:15 -0700

Lincoln,

All comments on any of the extension drafts is always welcomed.  The
LOADSEL and LOADGRP drafts are certainly not cast in concrete and can be
augmented or changed to meet whatever requirements the WG sees fit.  I
urge the WG to review the LOADSEL/LOADGRP drafts and consider whether
they can act as a basis for moving forward.

If we proceed with an extension draft approach, I urge the WG to
consider the procedures described in the ASPEXT draft which describes a
mechanism that allows an ASP to identify in the ASP Up (and SGP in the
ASP Up Ack) message which extensions they support.

 http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-aspext-04.txt

However, I do agree that the requirements really need to be established.

<rant>
For example, I really believe that any perceived need for CIC ranges is
really just bad or lazy MGC engineering: hoping that the SG will solve
all the state sharing and redundancy issues for the MGC instead of
dealing with those things inside the MGC architecture.  That is, once
messages are delivered to a pair of redundant ASPs at the MGC, those
ASPs can distribute the messages across MGC blades, processors, nodes,
as the MGC designer sees fit without having to involve the SG at all.  A
couple of blades acting as ASPs with a hardware cost less than my
daughter's MP3 player could easily distribute the traffic for most of
the West Coast of the Americas.  Also, I don't believe that it was ever
anyone's intentions to distribute a single MGC along the 49th parallel,
CIC range by CIC range.  All the nodes serving the CIC ranges are at the
same location, likely in the same bay or shelf.  It is foolish in such
an arrangement to expect the loosely coupled arrangement between SG and
ASPs to be able to match the fail-over capabilities of a system that can
be tightly-coupled blade-to-blade, shelf-to-shelf and crate-to-crate.
News Flash: SIGTRAN will not make the redundant distributed system
design of your MGC unnecessary, and will not turn dumb ASPs into a
carrier grade system.
</rant>

--brian

Haresign Lincoln wrote:                      (Tue, 07 Nov 2006 14:54:18)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Nov 2006 23:54:11 -0700

Ilie,

Ilie Glib wrote:                             (Tue, 07 Nov 2006 22:06:18)
> where ASP logic would be different for LOADSEL and RKs with CICs

Please see my previous note on this topic.

--brian

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

---

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

Lincoln,

see below.

/Ilie
> 1) nobody to tell anything behind you.

ilie: This can happen in case MGC has wrong architecture, or in case
of a real disaster. In the former case there is little that can help;
the only thing that can help in the latter case is geographical
redundancy of the MGC. Then item 1) above shall not become true.

> connecting switch and since you have other AS handling other CIC ranges,

ilie: I would assume that MGC owning the SPC is from one vendor and
has good internal architecture so that ASPs that serve some CIC ranges
could stay inactive for other ranges, and for instance when the last
dedicated ASP serving a CIC range goes inactive another ASP can go
active and take over the traffic for the CIC range or block CIC group
to avoid loss of new calls.

-- 
Ilie

---

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

Ilie,

OK, so you're saying that you are relying on the system architects to do
a good job and hope that we never get a catastrophic failure.

And if we fail in either of those cases, the SG just drops incoming
IAMs.

Did I understand correctly?

This is not a completely ideal solution, but I guess it is not
unreasonable.  It has been our experience that the network providers do
not always do a good job building their networks, and catastrophic
failures do occasionally occur.  But I guess then it is up to the
equipment providers to educate the network providers and help them build
better architectures.

Regards,
Lincoln

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 10:32 AM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

see below.

/Ilie
> 1) nobody to tell anything behind you.

ilie: This can happen in case MGC has wrong architecture, or in case of
a real disaster. In the former case there is little that can help; the
only thing that can help in the latter case is geographical redundancy
of the MGC. Then item 1) above shall not become true.

> connecting switch and since you have other AS handling other CIC 
> ranges, you can not send UPU.
>

ilie: I would assume that MGC owning the SPC is from one vendor and has
good internal architecture so that ASPs that serve some CIC ranges could
stay inactive for other ranges, and for instance when the last dedicated
ASP serving a CIC range goes inactive another ASP can go active and take
over the traffic for the CIC range or block CIC group to avoid loss of
new calls.

> > OK, in order to keep this thread simple, I'll address issues one at 
> > a time.
> >
> > > 1) First, with regards to CIC in general, I don't believe that you

> > > can

> > > 1) First, with regards to CIC in general, I don't believe that you

> > > can

> > To have a graceful handover from one ASP to another there can be 
> > ISUP level procedures or better use override TMT.
> > > I do not see any problems with override and broadcast, there can 
> > > be any number of ASPs then.
> > > shall get all messages related to one particular CIC. In that 
> > > sense your example with ANSI SLSs is significant.
> > > Thus, the number of the ASPs serving ISUP traffic for a particular

> > > CIC
> > > I would appreciate it a lot if you can point to an explicit 
> > > example where ASP logic would be different for LOADSEL and RKs 
> > > with CICs
> > >
> > > See below in line.
> > >
> > > Regards
> > >
> > > /Ilie
> > >
> > >
> > > > Certainly.  So you are saying that one ASP takes on all CICs of 
> > > > a certain value.
> > > >
> > > > Therefore, I think the CIC range needs to be treated more like 
> > > > in the ASP-ACTIVE message (similar to TID) except that perhaps 
> > > > the SG
>
> > > > Unless you are saying that two ASPs send the same range in the 
> > > > RK (where the SG is loadsharing evenly among the CIC range with 
> > > > a consistent algorithm).  Then, there is no simple way to add a 
> > > > SLS persistent way. So the SG will send ISUP message to the same

> > > > ASP
> > > > > You're right.  The problem of TIDs/DRNs is different than CICs

> > > > > as loss
> > > >
> > > > > of an ASP will only result in loss of calls in progess.  The 
> > > > > SG
> > will

> > > > > > > message does not correspond to a registered/configured 
> > > > > > > load selection range, it is load shared over the active 
> > > > > > > ASPs for the AS
> > > >
> > > > > > > Thus, the selected ASP can apply the appropriate 
> > > > > > > unequipped CIC treatment and the SG does not require
knowledge of ISUP.
> > > > > > > Active/Standby within a load group and the SG can fail 
> > > > > > > this specific load selection
> > > > >

> > > > > > > > CICs 1-3200 and OPC2 for CICs 1-3200, then there must be

> > > > > > > > an AS

--
Ilie

---

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

Lincoln,

if AS PENDING state changes to INACTIVE, and there are still ASes
serving the same SPC and SI, the SG can do nothing but discard
buffered messages.
This is currently suggested by the SIGTRAN RFCs, I think it is
reasonable (there is also the default AS concept, but IMHO it does not
work for CICs since there is a need to coordinate CIC states at the
ASPs serving the AS).

Regards

/Ilie

-- 
Ilie

---

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

Ilie,

Discarding messages is the wrong thing to do.  It appears that you have not had
much recent experience with designing and fielding ISUP systems.

ISUP systems that distribute call handling capacity by CIC ranges must still
share circuit group supervision state across the architecture.  Otherwise,
circuit management would not be possible if a call processors for a CIC range
failed.  Therefore, regardless of the failure of a call processor, the system
must still maintain circuit supervision state.  Poorly defined systems that
fail to do so result in an annoying circuit leakage.  Therefore, at least an
administrative processor must be capable of obtaining and maintaining circuit
management state for every circuit.

An ASP in the system is in the best position to obtain this circuit management
state for any given circuit.

Therefore, if an SG (albeit one within the MGC complex) pends on a CIC range
and is forced to moved to the LG-INACTIVE state for the load group,
LOADSEL/LOADGRP allows it to select an ASP (or ASPs) from the available ASPs
serving the AS an distribute messages related according to the traffic mode
defined for the AS.  If that traffic mode is load sharing, it will distribute
these unserved CICs across the ASPs that are available for the AS, regardless
of which Load Selection for which they are active.

An ASP serving the AS is thus able to institute appropriate software failure
blocking procedures for circuits for assigned circuits for which it receives
messages and is also able to properly complete blocking procedures because the
SG will also deliver subsequent messages related to the same CIC to the same
ASP.  Each ASP needs to be capable of accessing the centralized circuit
management state for each circuit, but for proper circuit management as
outlined above, this is necessary for a properly functioning system anyway.

Thus, by delivering unserved load selection messages to the ASPs, the remote
switch responsible for the same circuit range will block call to the circuits
and take appropriate action with regard to alarms, network management controls
(call rerouting), etc.  This is far preferable to throwing messages on the
floor and waiting for call processing related timers to expire, just to have
the remote switch reselect the circuit when they do.

--brian

Ilie Glib wrote:                        (Thu, 09 Nov 2006 16:57:10)

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