Re: RFC 4666 M3UA - Reg Request Message

Lincoln,

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

It becomes even worse then.

Regards

/Ilie

On 11/6/06, Haresign Lincoln <[email protected]> wrote:
> 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 protected]]
> Sent: Monday, November 06, 2006 1:43 PM
> To: [email protected]
> 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 protected]]
> Sent: Monday, November 06, 2006 1:20 PM
> To: Ilie Glib; Bhandari, Jitin (Jitin)
> Cc: Tolga Asveren; Barry Nagelberg; [email protected]
> Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
>
>
> 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 protected]]
> Sent: Monday, November 06, 2006 12:49 PM
> To: Bhandari, Jitin (Jitin)
> Cc: Haresign Lincoln; Tolga Asveren; Barry Nagelberg; [email protected]
> Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message
>
> 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
>
>
>
> On 11/6/06, Bhandari, Jitin (Jitin) <[email protected]> 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.
> >
> > Thanks,
> > Jitin
> >
> > -----Original Message-----
> > From: Haresign Lincoln [mailto:[email protected]]
> > Sent: Monday, November 06, 2006 11:21 AM
> > To: Bhandari, Jitin (Jitin); Tolga Asveren; Barry Nagelberg;
> > [email protected]
> > 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 protected]]
> > Sent: Monday, November 06, 2006 11:09 AM
> > To: Haresign Lincoln; Tolga Asveren; Barry Nagelberg; [email protected]
> > 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 protected]]
> > Sent: Monday, November 06, 2006 10:37 AM
> > To: Bhandari, Jitin (Jitin); Tolga Asveren; Barry Nagelberg;
> > [email protected]
> > 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 protected]]
> > Sent: Monday, November 06, 2006 10:34 AM
> > To: 'Tolga Asveren'; Haresign Lincoln; Barry Nagelberg;
> > [email protected]
> > 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 protected]]
> > Sent: Thursday, November 02, 2006 4:06 PM
> > To: Haresign Lincoln; Bhandari, Jitin (Jitin); Barry Nagelberg;
> > [email protected]
> > 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 protected]]
> > > Sent: Thursday, November 02, 2006 4:02 PM
> > > To: Tolga Asveren; Bhandari, Jitin (Jitin); Barry Nagelberg;
> > > [email protected]
> > > 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 protected]]
> > > Sent: Thursday, November 02, 2006 3:54 PM
> > > To: Haresign Lincoln; Bhandari, Jitin (Jitin); Barry Nagelberg;
> > > [email protected]
> > > 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 protected]]
> > > > Sent: Thursday, November 02, 2006 3:48 PM
> > > > To: Tolga Asveren; Bhandari, Jitin (Jitin); Barry Nagelberg;
> > > > [email protected]
> > > > 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 protected]]
> > > > Sent: Thursday, November 02, 2006 3:30 PM
> > > > To: Bhandari, Jitin (Jitin); Haresign Lincoln; Barry Nagelberg;
> > > > [email protected]
> > > > 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 protected]]
> > > > > Sent: Thursday, November 02, 2006 3:14 PM
> > > > > To: 'Haresign Lincoln'; Barry Nagelberg; [email protected]
> > > > > 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 protected]]
> > > > > Sent: Thursday, November 02, 2006 2:29 PM
> > > > > To: Barry Nagelberg; [email protected]
> > > > > 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 protected]]
> > > > > Sent: Wednesday, November 01, 2006 4:11 PM
> > > > > To: [email protected]
> > > > > 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 protected]]
> > > > > Sent: Wednesday, November 01, 2006 3:53 PM
> > > > > To: '[email protected]'
> > > > > Cc: '[email protected]'
> > > > > 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 protected]]
> > > > > Sent: Wednesday, November 01, 2006 3:11 PM
> > > > > To: Bhandari, Jitin (Jitin)
> > > > > Cc: '[email protected]'
> > > > > 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 protected]
> > > > > http://www.openss7.org/
> > > > >
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email protected]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email protected]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email protected]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email protected]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
>
> --
> Ilie
>
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>


-- 
Ilie