Subject: M3UA-06 Routing Key/Context issues

From: [email-masked]
Date: Wed, 14 Mar 2001 16:36:00 -0600

Greg et al.:

I have got a few questions/comments regarding the infamous routing
key/context.

1.	1.4.2.1 Overview (nit)
2nd paragraph, 3rd line: delete "other" in "other MTP 3 user ..."

2.	1.4.2.2 Routing Key Limitiations
The first two paragraphs do not make sense to me. 
There is no reason to force restriction of the RK to just one DPC - except
perhaps in the Register msg for format reasons. MTP NM will just have to
send multiple NM msgs if the RK spans more than one DPC. Problems arise only
if the RK covers fractional DPCs which (unfortunately) is allowed. In
addition, we allow one ASP to register for multiple DPCs in the same network
which for MTP NM is indistinguishable from having RKs spanning more than one
DPC.
Same applies to the second paragraph. UPU is no reason whatsoever to
restrict an RK to a single SI. After all, SS7 allows it and UPU still is
supposed to work.

Proposal: let's delete these two paragraphs.

The first sentence of the third paragraph needs some more explanation. What
kind of matching are we talking about? Something like longest matching
"prefix"? The assumption of a "default" RK seems to imply this. On the other
hand, prohibiting "overlapping" might prevent this. The "longest match"
could make registration simpler? Other places in the text might require
clarification of this point also.

3.	1.4.2.3 Managing Routing Contexts and Routing Keys (nit)
First paragraph: what is the special meaning of "statically or dynamically
in full accordance to the M3UA specifications"? If anything, it would be "in
full accordance with", but I find it rather superfluous.

4.	1.4.2.4 Message Distribution the SG
Fourth para: a NO is missing:

Normally, one or more ASPs are active in the AS (i.e., currently 
processing traffic) but in certain failure and transition cases it is 
possible that there may be no active ASP available.  Both load-sharing and
                           ^^ 
backup scenarios are supported.

Fifth para: delete "or only a partial match" it does not add value.

5.	1.4.2.5 Message Distribution at the ASP
The section has nothing to do with RKs/RCs. It should be moved out of 1.4.2.

6.	3.5.5 Registration Request (REG REQ)
There is another section labeled 3.5.5.

We need some more semantics on the REG format. While it is only mentioned
with the SI, if a parameter is not specified it presumably matches all
possible values. This should be made explicit for every parameter. What if
OPC in CIC param is not covered by OPC param, e.g.
DPC=X, OPC=A, CIC=(OPC=B, CIC=1-1023)?
Does 
DPC=X, CIC=(OPC=B, CIC=1-1023) 
match only ISUP from OPC=B with CIC=1-1023 or does it match everything
except ISUP from B with CIC > 1023 

Also, the specification of OPC specific CIC ranges is allowed, but not OPC
specific SIs and SSNs. Why not? 
Why are OPCs not maskable (in OPC and CIC params)?

7.	4.3.4.1 Registration
Need to define whether or not registrations survives ASP DOWN

2nd para, 5th line: replace 1st ASP by SG
The SG examines the contents of the received Routing Key parameter and 
compares it with the currently provisioned Routing Keys.  If the 
received Routing Key matches an existing SG Routing Key entry, and the 
ASP is not currently included in the list of ASPs for the related 
Application Server, the SG MAY authorize the ASP to be added to the
                        ^^ 

Cheers,

Klaus

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