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

From: "Bhandari, Jitin (Jitin)" <[email-masked]>
Date: Tue, 7 Nov 2006 11:20:39 -0500

Brian,

Here are some of the issues/questions I have with LOADSEL, NTFY procedure for handling CIC ranges:

1. Brian in his previous emailed mentioned about defining Single AS for all ASPs handling CIC ranges for same DPC (from Routing Key). This would also mean that all ASPs in this AS are in loadshare mode. Is it true? Can the model of LOADSEL also further support Override mode for CIC ranges? It's very typical to have equipment redundancy in networks at ASPs level and one would need Override mode for redundant ASP pairs where as Loadshare mode is needed to support the LOADSEL scheme at different CIC level. A quick example would be ASP-1 and ASP-2(Override mode) supporting CIC range 1-100 for DPC-X and ASP-3 and ASP-4 (Override mode) supporting CIC range 500-1000 for DPC X. Is this model supported? Please clarify.

2. I see in the email exchange that we have been talking about either:
    a) Sending ISUP messages destined for ASP (which is down) to a Default ASP. What would default ASP do? Keep in mind, CICs are physical resources and are usually mapped to One (or two in override mode) ASP. How do you expect the default ASP to know the Status of CICs which is not assigned to it during provisioning? Are we expecting all resources (CICs) to be assigned to default ASP? Are we expecting General procedures out of this default ASP? If yes, then why send it to this default ASP instead handle it at SG?
    b) The same issue exists with NTFYs where I assume using NTFY messages we are trying to find an "Owner-ASP" for this orphan (now) CIC range who can handle ISUP procedures for it. I have seen loose comments as it is easy to handle ISUP procedures at User Level (ASP) and hence find an ASP who could handle messages for CICs which initially belong to an ASP which is now down. But again we are assuming that ISUP is being assigned such Physical resources by provisioning to these alternate ASPs which is never the case. 
CICs (physical resource) are allocated per ASP (handling ISUP, Call Control states). If with this model, we expect all resources be allocated to all ASPs which defeat the model of Load sharing. 
I think we need clarification as on what basis we define Default ASP or any other ASP handling such "orphan" CICs. Without this, I see this procedure have some serious issues.

Also, to a previous question of handling of ISUP procedures at SG when we had mated STP/SG pairs, Implementation can be defined in a way if an STP/SG has a C link, one could forward ISUP messages for unavailable CICs to the mated Pair and mated Pair can either route to respective ASP(if Active) or define ISUP actions eventually as none of the nodes is able to reach to the ASP. Again, these are very minor implementation notes which can be taken care off.

Thanks,
Jitin

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

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

On 11/6/06, Haresign Lincoln <[email-masked]> wrote:
> 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).
>

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

> Are you saying that the SG should do nothing?  If it should do
> 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.

> 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.

Ilie: Right.

>
> 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,
>
> 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-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.
> >
> > 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
> >
>
>
> --
> Ilie
>

-- 
Ilie

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

---

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

Jitin,

Bhandari, Jitin (Jitin) wrote:                (Tue, 07 Nov 2006 11:20:39)
> 1. Brian in his previous emailed mentioned about defining Single AS for all
> ASPs handling CIC ranges for same DPC (from Routing Key). This would also
> mean that all ASPs in this AS are in loadshare mode. Is it true?

Yes and no.  Please read the summary in section 1.4.2 of the draft.

> Can the
> model of LOADSEL also further support Override mode for CIC ranges?

Yes, please read the summary in section 1.4.2 of the draft.

> It's very typical to have equipment redundancy in networks at ASPs level and
> one would need Override mode for redundant ASP pairs where as Loadshare mode
> is needed to support the LOADSEL scheme at different CIC level. A quick
> example would be ASP-1 and ASP-2(Override mode) supporting CIC range 1-100
> for DPC-X and ASP-3 and ASP-4 (Override mode) supporting CIC range 500-1000
> for DPC X.  Is this model supported? Please clarify.

Yes, this is an Override AS as described in summary section 1.4.2 of the
draft.

Because you seem to have not read the summary section that provides an
overview of the method, it appears that you have not read the draft.

>     a) Sending ISUP messages destined for ASP (which is down) to a Default
>     ASP. What would default ASP do? Keep in mind, CICs are physical
>     resources and are usually mapped to One (or two in override mode) ASP.
>     How do you expect the default ASP to know the Status of CICs which is
>     not assigned to it during provisioning? Are we expecting all resources
>     (CICs) to be assigned to default ASP? Are we expecting General
>     procedures out of this default ASP? If yes, then why send it to this
>     default ASP instead handle it at SG?

This is not new for LOADSEL, I was speaking directly to section 1.4.2.4 of
RFC 4666 which says:

  "Normally, one or more ASPs are active (i.e., currently processing
   traffic) in the AS, but in certain failure and transition cases it is
   possible that there may be no active ASP available.  Broadcast,
   loadsharing, and backup scenarios are supported.

   When there is not matching Routing Key entry fro an incoming SS7
   message, a default treatment MAY be specified.  Possible solutions
   are to provide a default Application Server at the SGP that directs
   all unallocated traffic to a (set of) default ASPs, or to drop the
   message and provide a notification to layer management.  The
   treatment of unallocated traffic is implementation dependent."

The default ASP(s) can also be local (internal) to the SG.

--brian

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