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