Re: RFC 4666 M3UA - Reg Request Message

Lincoln,

the SG shall NTFY ASPs in ACTIVE/INACTIVE state of the AS.

/Ilie

On 11/7/06, Haresign Lincoln <[email protected]> wrote:
> Ilie,
>
> OK, in order to keep this thread simple, I'll address issues one at a
> time.
>
> > 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.
>
>
> The problem is that when all the ASPs in AS1 become inactive, what
> action should the SG take (if any)?
>
>
>
> Regards,
> Lincoln
>
> -----Original Message-----
> From: Ilie Glib [mailto:[email protected]]
> Sent: Tuesday, November 07, 2006 5:00 PM
> To: Haresign Lincoln
> Cc: Barry Nagelberg; [email protected]
> Subject: Re: [Sigtran] 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
>


-- 
Ilie