RE: RFC 4666 M3UA - Reg Request Message

Ilie,

I'm assuming that you've lost complete connectivity to all your ASPs
with AS1 (i.e, all associations failed).  So:

1) nobody to tell anything behind you.

2) in front of you, you are receiving IAMs for the CIC range from the
connecting switch and since you have other AS handling other CIC ranges,
you can not send UPU. 

Regards,
Lincoln


-----Original Message-----
From: Ilie Glib [mailto:[email protected]] 
Sent: Tuesday, November 07, 2006 5:12 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email protected]
Subject: Re: [Sigtran] 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