RE: RFC 4666 M3UA - Reg Request Message

Jitin,

I agree with you, I just tried to answer your question (not that I am
agreeing CIC being removed for dynamic registration):-)

   Thanks,
   Tolga

> -----Original Message-----
> From: Bhandari, Jitin (Jitin) [mailto:[email protected]]
> Sent: Wednesday, November 01, 2006 4:07 PM
> To: 'Tolga Asveren'; [email protected]
> Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
>
>
> Tolga,
>
> I acknowledge that the previous Dynamic Registration procedure
> with CIC & TID had some serious limitation but this is no way to
> follow a path to solve such issues.
>
> To not have support for Flow through Provisioning (Dynamic
> provisioning from MGC to SG) especially for CIC is a serious
> limitation of M3UA with the current RFC. CIC resources are
> configured (added/deleted) dynamically and all we are asking is a
> support from the RFC in that direction. Any previous limitations
> especially in CIC area should have been addressed with latest RFC
> and as you said there are possible ways to solve any open issues.
>
> My concern here again is from Inter-OP conflicts and standards
> are defined to minimize such issues.
>
> I again re-iterate that from the current definition of Dynamic
> Registration in RFC-4666, its practical use is minimal and M3UA
> latest RFC is not solving the issue of Dynamic Provisioning
> between nodes for resources like CICs in SS7 networks.
>
> Thanks,
> -Jitin
>
> -----Original Message-----
> From: Tolga Asveren [mailto:[email protected]]
> Sent: Wednesday, November 01, 2006 3:19 PM
> To: Bhandari, Jitin (Jitin); [email protected]
> Subject: RE: [Sigtran] RFC 4666 M3UA - Reg Request Message
>
> Jitin,
>
> There were some concerns about how to handle ISUP group messages, e.g. how
> to generate a unique answer in the SG etc..., and so CIC-range support in
> dynamic registration was dropped. SSN had a similar fate.
>
> One could argue that generating a unique answer for group
> messages in the SG
> is an implementation dependent feature and does not require support from
> on-the-wire protocol (and I am aware of some products which do exactly
> this), no CIC support in dynamic registration is the current official
> approach.
>
>     Thanks,
>     Tolga
>
> > -----Original Message-----
> > From: Bhandari, Jitin (Jitin) [mailto:[email protected]]
> > Sent: Wednesday, November 01, 2006 2:42 PM
> > To: '[email protected]'
> > Subject: [Sigtran] RFC 4666 M3UA - Reg Request Message
> >
> >
> >
> > Hello,
> >
> > We looked into the RFC-4666 and now we have serious concerns
> > regarding the routing key parameter for Registration Request Message.
> >
> > Can anyone please provide us an explanation/background as why did
> > we drop "Circuit Range List" parameter from the Routing Key
> > Parameter description for RFC-4666?
> >
> > Please refer Section 3.6.1 (RFC-3332) where this parameter was
> > present and Section 3.6.1 for RFC-4666 where this parameter is removed.
> >
> > CIC Resources are allocated dynamically in SS7 networks and
> > provisioning of CIC resources changes quite often. Dynamic
> > Registration procedure at M3UA is facilitating this flow through
> > provisioning changes between MGC & SG.
> >
> > With the omission of this parameter from the Routing Key
> > Definition in RFC-4666, we have limited the scope of Dynamic
> > registration procedure and rather made it un-usable. The current
> > parameters for Routing Key at Registration Request message can
> > very well be defined via Static routing methods (via LM). CIC
> > Range was a key parameter to this message.
> >
> > Please explain the thoughts behind getting rid of this key
> > parameter from "Routing Key" definition.
> >
> > Also, we acknowledge that the Dynamic registration procedure for
> > RFC-3332 had its own limitation but getting rid of CIC Range
> > parameter is only going to make Dynamic registration procedure
> un-usable.
> >
> > Please comment.
> >
> > -Jitin
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran