Subject: M3UA v9: Separation of CIC ranges

From: Angermayr Manfred <[email-masked]>
Date: Thu, 11 Oct 2001 14:28:12 +0200

Hello!
I have a question concerning the dynamic registration procedure:
Consider two ASPs connected to an SG.
The first ASP sends a REG REQ with the parameters: 
RK Identifier = 1, NA =7, DPC = 222, Circuit Range List = OPC 33, CIC 1.
The second ASP sends a REG REQ with the parameters: 
RK Identifier = 2, NA=7, DPC = 222, Circuit Range List = OPC 33, CIC 2.
Is this a valid registration?
In my opinion it is not, because the RKs are not unique. As there are no SI values specified, ASP 1 takes all SCCP traffic for DPC 222 and ISUP traffic for OPC 33 and CIC1. But also ASP 2 wants all SCCP traffic for DPC 222, but ISUP traffic for another CIC. Therefore the second registration request should be denied, with the registration status 'Error - Cannot Support Unique Routing'
A separation of CIC ranges is only possible, if ISUP SI is explicitly specified.

What is your opinion? Is this a correct interpretation of the (complicated) dynamig registration procedure?

Another question:
In the example above there is no OPC list in the RK parameter, which means according to the draft, that all OPCs are processed by the ASP. Is ASP 1 getting really the ISUP traffic for all OPCs, although in the CIC list only OPC 33 is mentioned?
I think the OPC list is only valid for users that do not have a CIC. If ISUP for a complete OPC should be processed, the RK the CIC list parameter MUST be used, explicitly specifying all defined CIC values. 

Probably you could find more such examples, where it is not clear what to do. Perhaps some additional explanation about allowed and usefull parameter combinations within an RK would be helpfull.

Thanks a lot for your answers,
Manfred Angermayr

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Greg Sidebottom <[email-masked]>
Date: Thu, 18 Oct 2001 15:20:11 -0400

Greetings Manfred,

I'm not a registration expert but have a response below ...

----- Original Message -----
From: "Angermayr Manfred" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Thursday, October 11, 2001 8:28 AM
Subject: M3UA v9: Separation of CIC ranges

> In my opinion it is not, because the RKs are not unique. As there are no
SI values specified, ASP 1 takes all SCCP traffic for DPC 222 and ISUP
traffic for OPC 33 and CIC1. But also ASP 2 wants all SCCP traffic for DPC
222, but ISUP traffic for another CIC. Therefore the second registration
request should be denied, with the registration status 'Error - Cannot
Support Unique Routing'
> What is your opinion? Is this a correct interpretation of the
(complicated) dynamig registration procedure?

[Greg] Interesting point.  IMO your interpretation is essentially correct.
I can't see how an SG could resolve properly the two RKs taking into account
the current text stating that absence of an SI indicates ANY SI value (Well,
I can think of one way where an SG grants the first request and resolves the
second one by splitting the first key but it seems a little bizarre).  We
could get around this by adding a note to the Circuit Range List section
stating that "If a Circuit Range List is included, a related preceeding SI
value (e.g., ISUP, TUP, BICC) SHOULD be provided".  If one or both of the
ASPs truly wants the SCCP traffic it is possible to do this in the same RK
with a second SI or with another RK.

> Another question:
> In the example above there is no OPC list in the RK parameter, which means
according to the draft, that all OPCs are processed by the ASP. Is ASP 1
getting really the ISUP traffic for all OPCs, although in the CIC list only
OPC 33 is mentioned?
> I think the OPC list is only valid for users that do not have a CIC. If
ISUP for a complete OPC should be processed, the RK the CIC list parameter
MUST be used, explicitly specifying all defined CIC values.

[Greg] I agree in general that if a Circuit Range List is included then a
preceeding OPC list would not also used.  But I think if ISUP for a complete
OPC is to be processed, then the RK used could include the OPC list and not
include a Circuit Range List at all.  I think this still works fine - that
would be better than using a Circuit Range with all circuits in it.

> Probably you could find more such examples, where it is not clear what to
do. Perhaps some additional explanation about allowed and usefull parameter
combinations within an RK would be helpfull.
> Thanks a lot for your answers,

[Greg] Yes, because the RK format is quite open it is quite possible that
there are more examples that don't make sense.  I think Maria-Cruz (?)
suggested we add some RK templates but there wasn't too much support.  We
could do this an M3UA Applicability Statement later though.

Thanks,

   Greg

---