Subject: [Sigtran] Plugtest Issue - repost

From: Ken Morneault <[email-masked]>
Date: Mon, 02 Dec 2002 10:32:55 -0500

There have been no comments on the following issue.    The RFC
implies "that each received SS7 signalling message 
SHOULD have a full or partial match to a single 
routing result".

This could be interpreted to imply that hierarchical Routing Keys are
not allowed.  

-----------------------------------issue--------------------------------------------

3.  Does a message have to match one Routing Key?  This question
arose from the following scenario:

      REG REQ (RK1, DPC X)
      REG REQ (RK2, DPC X, SI ISUP)

One SG treats this as an overlapping RK and sends an Error for the
second REG REQ.  Another SG treats it as an overlapping RK, but
allows the configuration because it supports hierarchical RKs.  
With hierarchical RKs, a message can match more than one RK, but
the best match is taken.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 2 Dec 2002 09:29:38 -0700

Ken,

This was discussed somewhat during development of the RFC, particularly
with regards to "default" routing keys and "default" ASPs.  That is,

    "When there is no matching Routing Key entry for an incoming SS7
     message, a default treatment MAY be specified.  Possible solutions
     are to provide a default Application Sever at the SGP that directs
     all unallocated traffic to a (set of) default ASP(s), or to drop the
     message and provide notification to layer management.  The
     treatment of unallocated traffic is implementation dependent."
     -- Section 1.4.2.4

As for overlapping routing keys, the RFC is clear: they should not occur:

    "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." - Section 4.4.1.

It is clear that the SG that sends the Error follows the RFC; the SG that
does not, does not follow the RFC.

Clearly interoperable ASPs that follow the RFC will register with:

    REG REQ (RK1, DPC X, SI = ever SI but ISUP)
    REG REQ (RK2, DPC X, SI = ISUP)

Otherwise receiving an "Error -- Cannot Support Unique Routing" is to be
expected.

--brian

Ken Morneault wrote:                             (Mon, 02 Dec 2002 10:32:55)

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

---

From: "Valerie Gastaud" <[email-masked]>
Date: Mon, 2 Dec 2002 19:33:29 +0100

Brian,

Do you mean that the dynamic registration of overlapping Routing Keys is not
authorized but a static configuration can allow it? Otherwise, how can you
provide a default AS at the SGP that would direct unallocated traffic to a
set of ASPs?

To me, we should allow overlapping at different granularity level, i.e.
RK=CIC range and RK=SI ISUP and use the best matching RK but forbid
overlapping at the same granularity level, i.e. RK=CIC 1-10 and RK=CIC 5-15.
I don't think this goes against the RFC.

Valerie
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: lundi 2 decembre 2002 17:30
To: Ken Morneault
Cc: [email-masked]
Subject: Re: [Sigtran] Plugtest Issue - repost

Ken,

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 2 Dec 2002 11:16:37 -0700

Valerie,

Valerie Gastaud wrote:                               (Mon, 02 Dec 2002 19:33:29)
> provide a default AS at the SGP that would direct unallocated traffic to a

This was the only reason for saying "should" in section 4.4.1.  That is why
I cited 1.4.2.4.

> I don't think this goes against the RFC.

Yes it does.  We restricted routing keys to being unique for good purpose.
Otherwise, notifications, activations, deactivations, sending of SNMM,
switching over traffic, pending ASs and every procedure associated with
an AS gets blurred.  If you would like to see overlapping RKs, please write
an extension draft proposing how all of the AS procedures will be handled
in the case of overlap.

The only overlap permitted by the RFC is the "default" RK for the "default"
ASP(s) to be used in the case that there is no other match to a unique routing
key.

--brian