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

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


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

ilie: Yes.
>
> 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.

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

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

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

>
> Lincoln
>
> -----Original Message-----
> From: Ilie Glib [mailto:[email protected]]
> Sent: Tuesday, November 07, 2006 1:42 PM
> To: Haresign Lincoln
> Cc: Barry Nagelberg; [email protected]
> 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
>
> On 11/7/06, Haresign Lincoln <[email protected]> wrote:
> > 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 protected]]
> > Sent: Tuesday, November 07, 2006 1:20 PM
> > To: [email protected]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> > Maybe I'm loadsharing between multiple ASPs.
> >
> > -----Original Message-----
> > From: Haresign Lincoln [mailto:[email protected]]
> > Sent: Tuesday, November 07, 2006 12:56 PM
> > To: Barry Nagelberg; [email protected]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> >
> > 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 protected]]
> > Sent: Tuesday, November 07, 2006 12:51 PM
> > To: [email protected]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> > Why the limitation?
> >
> > -----Original Message-----
> > From: Haresign Lincoln [mailto:[email protected]]
> > Sent: Tuesday, November 07, 2006 12:45 PM
> > To: Barry Nagelberg; [email protected]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> >
> > So...does that mean you only have one ASP/AS?
> >
> > -----Original Message-----
> > From: Barry Nagelberg [mailto:[email protected]]
> > Sent: Tuesday, November 07, 2006 12:26 PM
> > To: [email protected]
> > 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 protected]]
> > Sent: Tuesday, November 07, 2006 12:16 PM
> > To: Ilie Glib
> > Cc: [email protected]; [email protected]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> >
> > 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 protected]]
> > Sent: Tuesday, November 07, 2006 11:47 AM
> > To: Haresign Lincoln
> > Cc: [email protected]; [email protected]
> > 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 protected]> 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.
> > >
> > > Regards,
> > > Lincoln
> > >
> > > -----Original Message-----
> > > From: Ilie Glib [mailto:[email protected]]
> > > Sent: Monday, November 06, 2006 7:00 PM
> > > To: [email protected]; Haresign Lincoln; [email protected]
> > > 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 protected]> 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).
> > > > 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,
> > > > >
> > > > > 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
> > > > >
> > > >
> > > > --
> > > > Brian F. G. Bidulock
> > > > [email protected]
> > > > http://www.openss7.org/
> > > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email protected]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > >
> > >
> > >
> > > --
> > > Ilie
> > >
> >
> >
> > --
> > 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
> >
> > _______________________________________________
> > 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
>


-- 
Ilie