Re: FW: LS on Clarification of M3UA usage in 3GPP networks

Lyndon,

Here are some comments on the document:

First off, both scenarios have been discussed in great detail on
this list in the (albeit distant) past.

Overall, it is not helpful to think of the ASPs as SPs.  The
management of SPs toward the SS7 network (converged or not) is
clearly the responsibiliy of the SG in the RFC.

In scenario 1:

Yes, SG1 must send DUNA when SP2 is unavailable to it (the
routeset to SP2 is unavailable), as SP2 is a destination in the
SS7 network regardless of whether it is served by the SS7 or IP
domains (cf. RFC4666/1.3.2.3 and RFC4666/3.4.1).

Kindly advise CT4 that all SS7 signalling point code are
"SS7 Destinations" regardless of whether they happen to be
served by the SS7 or IP domains.

IMHO no document or protocol modifications are necessary.

In scenario 2: 

This was discussed many times on the list.

If one defines an AS with an RK at the granularity of a
Signalling Point Code, all user parts must live and die
together.  When the ASP signals ASP-INACTIVE for such an RC, the
entire signalling point becomes unavailable (and the SG would be
expected to mark the point code as unavailable if there are no
other ASPs serving the AS and no other routes to the signalling
point, and potentially send TFP toward the SS7 network and DUNA
toward ASPs serving SPs with a route set toward the affected SP).

If one defines an AS with an RK at the granularity of a single
Signalling Point Code/Service Indicator (DPC/SI) combination,
the user part can live and die independent of other user parts
for the same signalling point code.  When the ASP signals
ASP-INACTIVE for such an RC, the single user part becomes
unavailable (and the SG would be expected to mark the user part
unavailable if there are no other ASP serving the AS and no
other routes to an "Alias" SP serving the same single user
part, and potentially send UPU toward the SS7 network and DUPU
toward ASPs serving the SPs sending traffic to the user part.)

There are some minor compications with using multiple STP/SGs
with user part granularity RKs: one STP/SG cannot reroute
traffic for a user part unavailable due to uavailability of a
directly attached ASP to its mate unless each SG has STP circular
route detection logic incorporated into its M3UA layer and
user part available logic.  That is, unless the SG can detect
that it should not send a message out on the same C-link set
upon which it was received and also that the circular route
attempt was based on the unavailability of a user part
associated with a locally attached ASP and send a UPU in
response, it must send the UPU before attempting to route the
message to its mate.  (Circular route detection is explained in
ANSI T1.111.4/2000.)  Without this logic, remote sending SPs can
be alternately sent UPUs and then responses to (say, UPT or SST)
in rapid succession depending only on the SLS of the messages
sent.  Another policy can be taken up by the ASP attached to
both SGs serving such an AS by performing an ASP-INACTIVE
procedure to the remaining SG when communications is lost with
the first SG.

It is a protocol error for the ASP to send DUPU messages to
the SG (cf. RFC4666/3.4.5).

Kindly advise CT4 that SNMM messages are sent only from an
SG to an ASP.  Traffic management messages sent from an ASP
to an SG are ASP-TM messages.  When user parts need to be
independently available or unavailable, they must use separate
RKs.  (Note that ETSI TS 102 142-V1.1.1 (2003-05) forbids use
of an RK at granularity less than a point code; cf. 4.7.)

IMHO no document or protocol modifications are necessary.

Perhaps a BCP document would be a good idea, but I think that
the RFC would have to proceed to DS instead of PS.

By the way, are these protocols ever going to be advanced to
DS?

--brian

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