RE: RFC 4666 M3UA - Reg Request Message

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