RE: 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