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

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