RE: RFC 4666 M3UA - Reg Request Message

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.

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.

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.

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