Re: RFC 4666 M3UA - Reg Request Message

Lincoln,

 Agreed.

/ilie

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


-- 
Ilie