RE: RFC 4666 M3UA - Reg Request Message

Illie,

Certainly there are problems with CIC in the old draft...do you agree?

I'm not proposing a solution at this point, I'd first like to just agree
on what the problems are, or at least outline what scenarios CIC will
work under versus what it won't work under.  Does it seem reasonable at
first to define all the current problems (i.e., the requirements).  And
then perhaps we can address solutions.

Regards,
Lincoln 

-----Original Message-----
From: Ilie Glib [mailto:[email protected]] 
Sent: Tuesday, November 07, 2006 2:46 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email protected]
Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln, Brian

as far as I can understand, the old draft has everything that is needed
to solve CIC problem in a distributed application, that is, an RK can
contain CIC ranges. NTFY procedures will distribute AS/ASP status
changes to ASPs of the AS.

In order to receive a NTFY an ASP has to be inactive for the RK.

The rest is implementation dependent, handling of application level
procedures is the task of the concerned distributed AS.

/Ilie


On 11/7/06, Haresign Lincoln <[email protected]> wrote:
> Ilie,
>
> Personally, I don't see how CICs can work in the old M3UA draft.
>
> And I'm still trying to determine what the actual requirements are.
>
> Do AS share the same PC as the SG when working with CICs or do we 
> require a different PC?
>
> I think the first issue is to define all the requirements.
>
> Regards,
> Lincoln
>
> -----Original Message-----
> From: Ilie Glib [mailto:[email protected]]
> Sent: Tuesday, November 07, 2006 1:33 PM
> To: Haresign Lincoln
> Cc: Barry Nagelberg; [email protected]
> Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message
>
> Lincoln, Barry,
>
> I think  the way forwards with CICs depends on solutions we aim at, 
> and it can either refine the RK as in an old M3UA draft, or define a 
> load distribution scheme as suggested in LOADSEL draft.
>
> I believe both ways are feasible, and the WG has to agree on the 
> preferred option.
>
> /Ilie
>
> On 11/7/06, Haresign Lincoln <[email protected]> wrote:
> > 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
> >
>
>
> --
> Ilie
>


--
Ilie