RE: RFC 4666 M3UA - Reg Request Message

Jitin,

What is the difference between an unknown CIC and a CIC with no ACTIVE
AS?

Regards,
Lincoln 

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


Lincoln,

Just to complete the discussion on our first point, I am referring to
ISUP specs (ITU or any other variant). You cannot send UPU but as ISUP
treats unknown CICs with UCIC (for us at sigtran, if you get IAM for an
unknown CIC at Routing Key) or locally blocked cics with either Group
blocking or BLO (for us at sigtran, If you get an IAM with AS being
down). Again, I am avoiding this discussion as this is ISUP variant
specific and can get into very detailed analysis message by message. But
every ISUP variant defines such scenarios. 

Also, I don't think that once we regain connectivity, we need to sync up
with SG for CIC states because if you look at various ISUP procedures,
after AS regains connectivity with SGP, it should kick-in its standard
ISUP procedure at ISUP level to broadcast local and remote CIC status.

On ETS specs, we know that both Dynamic registration and Routing Key at
CIC level is not considered (even though then provided by RFC-3332).

Thanks,
-Jitin

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

Jitin,

I agree with most of your points below except for the first.

You still have not clarified exactly how the SG would act in the case
that we loose connectivity to the ISUP application that is processing a
certain range of CICs.  You can not say is is well defined because
typically, in the SS7 specs, MTP3 does not loose connectivity to just a
portion of the ISUP application.  We can't send a "ISUP User Part
Unavailable" because other ISUP applications (read AS) are still
available.  

So are you saying the SG would block those circuits, or send UCIC?  Or
what?  I disagree that with you that this handling is well defined as
the SS7 specs (at least the ones that I'm aware of) do not consider this
case.  

Clearly the SIGTRAN community could decide to put CIC back in the spec.
But I would believe that this would be a broken solution without dealing
with all the CIC management issues.  Any third party trying to interface
to several different vendors SGs using this technogoly would run in to
major interop issues.

If my SG sends UCIC and yours sends BLO and another sends GRS, how can
anybody write an AS that can interface to all the various SGs in the
network and expect them to work.

If you want to pursue the CIC issue, I think it would be practical to
write an extension draft that deals specifically with ISUP.  We see this
as a very practical use of M3UA and were planning on implementing a
proprietary protocol to deal with this as it is internal to our
networks.  But I'd be happy to help a wider effort.

Regards,
Lincoln

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

Lincoln,

I don't think anyone is saying that we do nothing in such scenarios.
Here are my three points:

1. I don't think there is any standardization required for resource
outage and their treatment at ISUP level as it is well defined in ISUP
specs. We are just relocating that functionality at SG and that is
implementation dependant. Though SG MUST take care of this functionality
when using CICs as routing key.

2. When I mentioned un-usability of Dynamic Registration in RFC-4666 in
the current form, I meant it that it is not giving us anything on &
beyond static registration. Point codes and network topologies for Point
code is usually known way before hand and any such changes (i.e.
changing point codes) in the networks are always service affecting and
hence can easily be handled by Static Routing procedures. 
As I said in all my earlier emails, Dynamic registration was all about
Flow through provisioning and CIC being such one resource.  Having
dependant on Static routing for CIC based routing and performing
provisioning at two levels (SG & MGC) is just way too much data for
large networks. 
Dynamic Registration (Flow through provisioning) was just facilitating
this functionality in previous RFC.

3. Again, I re-iterate whatever the Problem is with having CIC at
Routing Key level still exists with RFC-4666 as static routing can have
CIC ranges. By getting rid of CIC ranges at Dynamic Registration we did
NOT solve any problem.

4. However, we liked the way RFC introduced "Routing Context" as a
parameter for Reg-Req message which allows us to re-use routing context
and redefine routing keys. This is more of a practical use of Reg-Req.
The only thing missing now is CIC ranges for Dynamic registration.

Thanks,
-Jitin
-----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