Re: RFC 4666 M3UA - Reg Request Message

Lincoln

see below

Regards

/Ilie

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

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

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

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.

>
> Regards,
> Lincoln
>
> -----Original Message-----
> From: Ilie Glib [mailto:[email protected]]
> Sent: Tuesday, November 07, 2006 4:06 PM
> To: Haresign Lincoln
> Cc: Barry Nagelberg; [email protected]
> 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.
>
> 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
>


-- 
Ilie