Subject: [Sigtran] M3UA: More redundant RKM error codes

From: "Barry Nagelberg" <[email-masked]>
Date: Wed, 7 Jan 2004 10:47:02 -0500

There is a redundant pair of REG REQ error codes in Section 4.4.1 of RFC
3332, for the case in which a reg req contains a routing key that already
exists at the SGP.

The 1st is from the original RFC:

"  If the SGP determines that a unique Routing Key cannot be created,
   the SGP returns a Registration Response message to the ASP, with a
   Registration Status of "Error - "Cannot Support Unique Routing". An
   incoming signalling message received at an SGP should not match
   against more than one Routing Key. "

The 2nd was added in the IG Rev 05:

"  If the SGP determines that the received RK was already registered,
   the SGP returns a Registration Response message to the ASP,
   containing a Registration Result "Error - Routing Key Already
   Registered". This error applies whether the Routing Key is Active or
   Inactive."

Perhaps the intention of IG Rev 05 was to distinguish between the event
where we have duplicate RKs, one of which was created statically and the
other dynamically (by using the 1st error code), and the event where we have
duplicate RKs, both of which were created dynamically (by using the 2nd
error code)?

If my guess is correct, then the description of the 1st error code must be
updated to reflect this restriction.

As it stands now, the SGP could correctly use either error code to describe
the case in which a reg req contains a routing key that already exists at
the SGP.

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 7 Jan 2004 11:01:19 -0500

Barry,

inline....
-Again as far as I remember ;) -

   Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Barry Nagelberg
> Sent: Wednesday, January 07, 2004 10:47 AM
> To: SIGTRAN Mailing List
> Subject: [Sigtran] M3UA: More redundant RKM error codes
>
>
[TOLGA] This I believe is mainly for the case, where the required RK
overlaps with an already existing one -but they are not the same, just
partially overlapping-.
> duplicate RKs, both of which were created dynamically (by using the 2nd
[TOLGA]I don't know, whether there is a real need to distinguish between
those two cases. But , as it is right know, I also would expect it to work
like you described. Maybe it is a better idea to use the second one, when
there isa full match -regardless dynamic or static- , and to use the first
one for partial overlapping -so, shall Ig be updated to make it work that
way, any ideas?-

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Wed, 7 Jan 2004 12:03:22 -0600 (CST)

Tolga,

 Yes agree with you, Error - "Cannot Support Unique Routing" is used
 when there is a partial match and Error - "Routing Key Already
 Registered" is used when there is a full exact match irrespective of 
 static or dynamic registration.

 But there are some valid reasons for the introdcution of these 2nd
 error code.
 
 Scenario - Before introduction of Error - "Routing Key Already
                                                       Registered "
 -----------------------------------------------------------------
 Intially RFC supported only Error - "Cannot Support Unique Routing".
 Say an ASP1 registers RK1(OPC=*,DPC=x) with SGP1 then SS7 traffic
 is flowing between SGP1 and ASP1. Now same ASP1 further registers
 RK2(OPC=*,DPC=x,SI=ISUP) with same SGP1, but ASP1 receives the 
 Error - "Cannot Support Unique Routing" in the REG RESP message.
 The intention of RK2 is to support only ISUP ss7 traffic with DPC=x.

 But when ASP1 receives Error - "Cannot Support Unique Routing", 50%
 there is a possibility to assume that RK2 was already supported by
 SGP1 and it starts ss7 traffic assuming it is processing only ISUP
 traffic but that is totally false.

 So in order to avoid such confusions Error - "Routing Key Already
 Registered " was introduced which differentiates exact match and 
 partial match.

 This is what i understood.

--Samuel

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 7 Jan 2004 13:11:43 -0500

Samuel,

> From: Samuel Dur D. Jeyaseelan [mailto:[email-masked]]
> Sent: Wednesday, January 07, 2004 1:03 PM
> To: Tolga Asveren
> Cc: SIGTRAN Mailing List
> Subject: RE: [Sigtran] M3UA: More redundant RKM error codes
>
>
>
> Tolga,
>
[TOLGA] I don't propose to remove the second error code, just make it more
clear that it works like you also described above. Currently, IMO, it is not
very clear.
>  Scenario - Before introduction of Error - "Routing Key Already
[TOLGA]I would think, this is not a clever choice in any case. ASP1 does not
know the corresponding RC -REG RSP has RC=0, if the result is error-. So, it
can't activate RK, or can fill RC into DATA properly. So, from protocol
point of view, -at least for now- I can't see a direct use of distinguishing
between those two cases but from administration point of view, it makes
sense to me.
> > > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > > Barry Nagelberg

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Wed, 7 Jan 2004 12:52:11 -0600 (CST)

Tolga,

> between those two cases but from administration point of view, it makes

If ASP1 does not know the RC, How is going to de-register RK1 to
register RK2?

--Samuel

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 7 Jan 2004 13:58:27 -0500

inline....

> Sent: Wednesday, January 07, 2004 1:52 PM
> To: Tolga Asveren
> Cc: SIGTRAN Mailing List
[TOLGA]Yes, for the "already registered case" it should know this. In fact,
"already registered" case does not make sense at all, because it means ASP
already knows that it has registered for this RK, why should it need
asistance from SG?. "Overlap error" makes sense, because some other ASP
might have registered with an overlapping RK.

---

From: "Barry Nagelberg" <[email-masked]>
Date: Wed, 7 Jan 2004 14:05:55 -0500

OK, I now understand the difference, and I agree with Tolga and Samuel.
But the text, as it is now, is confusing. I suggest the following changes:

1st error code:

"  If the SGP determines that the requested RK partially,
   but not exactly, matches an existing RK, and that an
   incoming signalling message received at an SGP could possibly match
   both the requested and the existing RK,
   the SGP returns a Registration Response message to the ASP, with a
   Registration Status of "Error - "Cannot Support Unique Routing"."

2nd error code:

"  If the SGP determines that the requested RK was already registered
   fully and exactly, either statically or dynamically, by the sending ASP,
   the SGP returns a Registration Response message to the ASP,
   containing a Registration Result "Error - Routing Key Already
   Registered ". This error applies whether the Routing Key is Active or
   Inactive."

Barry Nagelberg

> Samuel Dur D. Jeyaseelan

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 7 Jan 2004 15:38:44 -0500

Just one more thought below...

> Sent: Wednesday, January 07, 2004 2:06 PM
> To: SIGTRAN Mailing List
[TOLGA]Although I don't see significant practical use of this error code,
still if we want it then at least let's make it a bit more usefull -or maybe
just discard it?-, by including actual RC in the REG-RESP, so that ASP does
not need to figure it out by itself:
"For this error code, RC field in Registration REsponse message MUST be
populated with the actual value of RC in SGP corresponding to the specified
RK in Registration Request message"

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Jan 2004 13:52:54 -0700

Tolga,

IIRC it was for faulty implementations that lose the REG RESP.

--brian

Tolga Asveren wrote:                                                                 (Wed, 07 Jan 2004 15:38:44)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/