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

An additional perspective about possible issues with multiple SGs and sub-PC RK  configurations:
SCTP multihoming provides some solution here as well. If multihoming is used and underlying IP network is engineered properly, loss of SCTP association will indicate that ASP is down. So, both SGs will have the same view of the User Part/PC (there possibly would be a slight difference in time when each SGP detects the ASP as down) (I assume if an ASP wants to inactivate a sub-PC AS, it would do so for all SGPs). Again, this explanation relies on resiliency provided by SCTP multihoming against network/NIC failures (so, no need to go into the debate whether this is the case; just pick your side ;-) )

BTW, it is a pitty/shame we couldn't evaluate M3UA SG-SG/M3PA ideas properly in this WG, as this seems to me exactly what people out there are looking for (and possibly would allow them to use a single protocol throughout their networks, rather than a M3UA/M2PA hybrid).

Thanks,
Tolga


-----Original Message-----
From: [email protected] on behalf of Brian F. G. Bidulock
Sent: Thu 2/21/2008 4:45 PM
To: Ong, Lyndon
Cc: [email protected]; Jon Peterson
Subject: Re: [Sigtran] 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/
_______________________________________________
Sigtran mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/sigtran