Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

From: "Bhandari, Jitin (Jitin)" <[email-masked]>
Date: Tue, 7 Nov 2006 14:25:57 -0500

Thanks Brian for the responses. I did read the summary section and it is just that I was trying to confirm couple of thoughts being exchanged in this email chain.

Anyhow, I agree with Ilie that either by re-introducing CIC Ranges for Reg-Req or defining LOADSEL draft as an extension could be a viable path.

However, I still think that LOADSEL is not solving any issues of un-handled CICs when AS is unavailable so if CICs are re-introduced in Reg-Req message for ISUP traffic, re-introducing CIC ranges in Reg-Req is the simplest way to solve handling of ISUP traffic. 
Having a default ASP handling un-available CICs is same as having an implementation dependant solution at SG. I think Notify procedures between ASPs also don't solve this issue.

Talking about requirements, If CIC handling (Note ONLY CIC Handling between ASPs) is the only issue to be solved, then for a simplest solution I see re-introduction of CIC ranges is the best way. Though for now I see CIC handling amongst ASP as a bigger issue given provisioning nature of CICs at MGC.

-Jitin

-----Original Message-----
From: Ilie Glib [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 1:33 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email-masked]
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-masked]> 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-masked]]
> Sent: Tuesday, November 07, 2006 12:51 PM
> To: [email-masked]
> Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
>
> Why the limitation?
>
> -----Original Message-----
> From: Haresign Lincoln [mailto:[email-masked]]
> Sent: Tuesday, November 07, 2006 12:45 PM
> To: Barry Nagelberg; [email-masked]
> 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-masked]]
> Sent: Tuesday, November 07, 2006 12:26 PM
> To: [email-masked]
> 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-masked]]
> Sent: Tuesday, November 07, 2006 12:16 PM
> To: Ilie Glib
> Cc: [email-masked]; [email-masked]
> 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-masked]]
> Sent: Tuesday, November 07, 2006 11:47 AM
> To: Haresign Lincoln
> Cc: [email-masked]; [email-masked]
> 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-masked]> 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-masked]]
> > Sent: Monday, November 06, 2006 7:00 PM
> > To: [email-masked]; Haresign Lincoln; [email-masked]
> > 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-masked]> 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-masked]
> > > http://www.openss7.org/
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> >
> >
> > --
> > Ilie
> >
>
>
> --
> Ilie
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>

-- 
Ilie

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Nov 2006 12:35:11 -0700

Jitin,

Bhandari, Jitin (Jitin) wrote:                     (Tue, 07 Nov 2006 14:25:57)
> Thanks Brian for the responses. I did read the summary section and it is
> just that I was trying to confirm couple of thoughts being exchanged in this
> email chain.
> 
> Anyhow, I agree with Ilie that either by re-introducing CIC Ranges for
> Reg-Req or defining LOADSEL draft as an extension could be a viable path.
> 
> However, I still think that LOADSEL is not solving any issues of un-handled
> CICs when AS is unavailable so if CICs are re-introduced in Reg-Req message
> for ISUP traffic, re-introducing CIC ranges in Reg-Req is the simplest way
> to solve handling of ISUP traffic. 

I disagree.  Routing on CIC introduces more problems, LOADSEL less.

> Having a default ASP handling un-available CICs is same as having an
> implementation dependant solution at SG. I think Notify procedures between
> ASPs also don't solve this issue.

It is a far better situation with LOADSEL where ASPs are informed that a
CIC range is unserved.

> Talking about requirements, If CIC handling (Note ONLY CIC Handling between
> ASPs) is the only issue to be solved, then for a simplest solution I see
> re-introduction of CIC ranges is the best way. Though for now I see CIC
> handling amongst ASP as a bigger issue given provisioning nature of CICs at
> MGC.

It is certainly not the simplest approach and it does not address the three
other issues addressed by LOADSEL.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/