headers
Bhandari, Jitin (Jitin | 1 Nov 2006 20:41
Picon
Favicon

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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Brian F. G. Bidulock | 1 Nov 2006 21:10
Favicon

Re: 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
bidulock <at> openss7.org
http://www.openss7.org/
Permalink | Reply | 2 comments |
headers
Tolga Asveren | 1 Nov 2006 21:19
Favicon

RE: 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:jbhandari <at> lucent.com]
> Sent: Wednesday, November 01, 2006 2:42 PM
> To: 'sigtran <at> ietf.org'
> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bhandari, Jitin (Jitin | 1 Nov 2006 21:52
Picon
Favicon

RE: 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:bidulock <at> openss7.org] 
Sent: Wednesday, November 01, 2006 3:11 PM
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bhandari, Jitin (Jitin | 1 Nov 2006 22:06
Picon
Favicon

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:asveren <at> ulticom.com] 
Sent: Wednesday, November 01, 2006 3:19 PM
To: Bhandari, Jitin (Jitin); sigtran <at> ietf.org
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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Barry Nagelberg | 1 Nov 2006 22:11

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:jbhandari <at> lucent.com]
Sent: Wednesday, November 01, 2006 3:53 PM
To: 'bidulock <at> openss7.org'
Cc: 'sigtran <at> ietf.org'
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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tolga Asveren | 1 Nov 2006 22:11
Favicon

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:jbhandari <at> lucent.com]
> Sent: Wednesday, November 01, 2006 4:07 PM
> To: 'Tolga Asveren'; sigtran <at> ietf.org
> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian F. G. Bidulock | 1 Nov 2006 22:22
Favicon

Re: RFC 4666 M3UA - Reg Request Message

Jitin,

There are no procedures for CIC in RFC 3332 either: just the parameter,
leading to non-interoperable implementations.  Although one can conceive
of fashions in which to use it, there are many non-interoperable
interpretations of how that could be done.  I figured that either we
should describe an interoperable solution or remove it.  The WG decided
to remove it and address it in an extension draft.

draft-bidulock-sigtran-loadsel-04.txt is such an extension draft that
describes an interoperable solution and is a good starting point for
providing this functionality and has been avialable for years.  It
seems that implementors have preferred to provide their own proprietary
solutions rather than advancing and contributing to a common standard
solution.

--brian

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/
Permalink | Reply | 0 comments |
headers
Satya Prasad Nemana | 2 Nov 2006 10:57
Picon

Notify messages in M3UA

Hi 

I have a question regarding the notify messages in M3UA.
A lot of clauses are found in the RFC where in all the circumstances in 
which the notify messages
are issued by the SGP are mentioned.
But how should the ASP react to the notify messages is never mentioned 
anywhere which
has caused many implmentations of AS to simply ignore the messages and 
still remain RFC compliant.
Steps to be taken when Notify messages are not received by the ASP are 
also not mentioned.

Can a clarification be solicited in this aspect?

Thanks
Satya Prasad
Permalink | Reply | 1 comment |
headers
Brian F. G. Bidulock | 2 Nov 2006 14:35
Favicon

Re: Notify messages in M3UA

Satya,

All NOTIFY messagse are advisory.  That is, although they must be
issued by the SGP in specific circumstances, but they do not compel
the ASP to take any action whatsoever.  Yes, an ASP that ignores all
NOTIFY messages can be compliant with the specification (but might
not be very useful in practice).  I am not sure what you mean by
"not received by the ASP" as SCTP is a reliable transport protocol.

--brian

Satya Prasad Nemana wrote:                  (Thu, 02 Nov 2006 15:27:46)
> Hi 
> 
> I have a question regarding the notify messages in M3UA.
> A lot of clauses are found in the RFC where in all the circumstances in 
> which the notify messages
> are issued by the SGP are mentioned.
> But how should the ASP react to the notify messages is never mentioned 
> anywhere which
> has caused many implmentations of AS to simply ignore the messages and 
> still remain RFC compliant.
> Steps to be taken when Notify messages are not received by the ASP are 
> also not mentioned.
> 
> Can a clarification be solicited in this aspect?
> 
> Thanks
> Satya Prasad
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane