RE: RFC 4666 M3UA - Reg Request Message

Tolga,

I still don't understand how you are going to handle the case when you
loose connectivity to an ASP handling a certain range of CICs.  Now you
receive an IAM for that CIC.  What does the SG do?  Drop the message?
This could be a fairly lengthy outage.  Or are you saying we leave it up
to the SG and everybody does it differently?  What if the SG sends a
BLO, then the ASP comes back, how does the ASP know the state of the
CIC?  

I don't think you can just have every SG decide to do things
differently.

Regards,
Lincoln 

-----Original Message-----
From: Tolga Asveren [mailto:[email protected]] 
Sent: Thursday, November 02, 2006 3:54 PM
To: Haresign Lincoln; Bhandari, Jitin (Jitin); Barry Nagelberg;
[email protected]
Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message

Lincoln,

IMHO it may be better to restrict what needs to be standardized to a
simple set of rules -if possible at all- rather than a detailed analysis
of each and every case. That strategy may or may not work.

    Thanks,
    Tolga

> -----Original Message-----
> From: Haresign Lincoln [mailto:[email protected]]
> Sent: Thursday, November 02, 2006 3:48 PM
> To: Tolga Asveren; Bhandari, Jitin (Jitin); Barry Nagelberg; 
> [email protected]
> Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
>
>
> Tolga,
>
> I believe there are all sorts of scenarios that are troublesome 
> relating to the group messages.  Don't you think we would need to 
> define all these in order for an SG to properly interop with an ASP?
>
> Regards,
> Lincoln
>
> -----Original Message-----
> From: Tolga Asveren [mailto:[email protected]]
> Sent: Thursday, November 02, 2006 3:30 PM
> To: Bhandari, Jitin (Jitin); Haresign Lincoln; Barry Nagelberg; 
> [email protected]
> Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
>
> Jitin,
>
> Although I would think introducing CIC-ranges back to dynamic 
> registration may makes sense, I am not sure whether we need to define 
> implementation dependent functionality on SG, e.g ISUP proxy etc...
>
> As long as the issue can be handled locally in SG, IMHO there is no 
> need to define specific behavior in SIGTRAN WG. We maybe just need to 
> say whose responsibility is it to deal with the complexity, e.g. 
> answers messages for group messages need to be aggregated at SG.
>
>
>    Thanks,
>    Tolga
>
> > -----Original Message-----
> > From: Bhandari, Jitin (Jitin) [mailto:[email protected]]
> > Sent: Thursday, November 02, 2006 3:14 PM
> > To: 'Haresign Lincoln'; Barry Nagelberg; [email protected]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> >
> > Lincoln,
> >
> > Your understanding is correct. We all understand and acknowledge 
> > limitations of previous Dynamic registration and issues associated 
> > with it. Not only the Dynamic Registration needs to be re-defined 
> > with
>
> > some basic modifications, along with almost a minor functionality 
> > (ISUP Proxy) need to be defined as a part of M3UA on SG for such 
> > scenarios.
> >
> > I can't stress enough for the need of such functionalities 
> > especially when we have elaborate network in real time domain with 
> > Multiple MGs (at-least 40) being controlled by one MGC and resources

> > are shared all
>
> > across ASPs.
> > If each MG is supporting large number of Trunk resources (e.g.
> > say 60K CICs), we are talking large network provisioning in a real 
> > time network.
> >
> > Static registration is not a method for such networks. Flow through 
> > provisioning (Dynamic Registration) is required between MGC & SG.
> >
> > We have such distributed networks successfully deployed with similar

> > modifications (ISUP Proxy) and enhancement (for dynamic registration
> > procedure) for the same reason.
> >
> > We seriously think that its time that we should consider Dynamic 
> > registration procedure in this direction if we want a better 
> > inter-op world around us.
> >
> > Thanks,
> > Jitin
> >
> >
> > -----Original Message-----
> > From: Haresign Lincoln [mailto:[email protected]]
> > Sent: Thursday, November 02, 2006 2:29 PM
> > To: Barry Nagelberg; [email protected]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> > It certainly would be a nice feature.  But there are a large number 
> > of
>
> > ISUP scenarios that would need to be covered.  For example, if you 
> > loose all ASPs handing a certain CIC range, do you BLO?  Anyway, it 
> > seems to me that this is almost too much for M3UA and almost 
> > requires a new extension specifically for ISUP.
> >
> > Regards,
> > Lincoln
> >
> > -----Original Message-----
> > From: Barry Nagelberg [mailto:[email protected]]
> > Sent: Wednesday, November 01, 2006 4:11 PM
> > To: [email protected]
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> > All,
> >
> > I agree with Jitlin - CIC range functionality should be put back 
> > into Dynamic Registration. After removing it to comply to the spec, 
> > we had to put it back in because one of our customers demanded it.
> >
> > In cases such as these, I suggest that try harder to listen to our 
> > customers - after all, they are the ones who are paying for SIGTRAN 
> > to
>
> > be actually implemented and deployed.
> >
> > Barry Nagelberg
> > Adax, Inc.
> >
> > -----Original Message-----
> > From: Bhandari, Jitin (Jitin) [mailto:[email protected]]
> > Sent: Wednesday, November 01, 2006 3:53 PM
> > To: '[email protected]'
> > Cc: '[email protected]'
> > Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> >
> > Brian,
> >
> > No where in the RFC-3332, I understand the interpretation of CIC 
> > ranges is limited to Load Distribution.
> >
> > When CIC ranges were a part of Routing Key, they can very well be 
> > used
>
> > for routing and be defined as a part of Routing key. Since, 
> > OPC-DPC-CIC values uniquely identify a resource on the ASP and can 
> > very well be treated is unique routing key from RFC definition.
> >
> > I very well understand when you talk about CIC & TID being just an 
> > element from Load Sharing perspective but for the same analogy if 
> > CIC & TID are for Load distribution, OPC can also be viewed as Load 
> > distribution method so as to have multiple ASPs (behind SG) handling

> > parts of SS7 network. It is up-to anyone as how one vision Routing 
> > key
>
> > arbitration at SG for MGC. Limiting the Routing Key definition at 
> > RFC level is not fair especially when it was talked about in
previous RFC.
> >
> > My point here is that by getting rid of such parameters at RFC 
> > level, we would face many inter-op issues with various vendors in 
> > the real work if one has to pick Dynamic Registration Path. We will 
> > only end up
>
> > with many drafts like this one modifying the Registration Request 
> > message for handling of SS7 traffic at SG. Inter-op in real world 
> > would be a serious issue with such procedures then.
> >
> > Also, as I mentioned in my previous email, CIC resources being 
> > dynamic
>
> > in nature at MGC, a flow through dynamic provisioning support (from 
> > MGC to SG) was provided by having such Keys in the dynamic 
> > registration procedure.
> >
> > By getting rid of such parameters at RFC level, we are just making 
> > Dynamic Registration procedure un-usable.
> >
> > -Jitin
> >
> >
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email protected]]
> > Sent: Wednesday, November 01, 2006 3:11 PM
> > To: Bhandari, Jitin (Jitin)
> > Cc: '[email protected]'
> > Subject: Re: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> > Jitin,
> >
> > CIC and TID were only applicable to load distribution and not 
> > routing and were therefore removed from the "routing" key.
> >
> > See
> >
> >
> >
http://www.ietf.org/internet-drafts/draft-bidulock-sigtran-loadsel-04.
> > tx
> > t
> >
> > for a equivalent mechanism for controlling load distribution based 
> > on CIC using a "load" key dynamically registered in the REG REQ.
> >
> > --brian
> >
> > --
> > Brian F. G. Bidulock
> > [email protected]
> > http://www.openss7.org/
> >
> > _______________________________________________
> > 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