Re: Sigtran Digest, Vol 46, Issue 5

Hello, Brain

Please see my comments on your statement in the former emails. 


brain wrote:                                     (Fri, 22 Feb 2008 04:56:15)

>In M3UA ASP-SG model, the virtual SEP resides at the SG, not at the ASP.  By
>choosing a point-code based RK you simply deprive your ASP of the ability to
>signal the unavailability of a user part (and are largely going against the
>MTP-SAP functional model of MTP).  Configure your RKs properly (DPC/SI) and
>you won't have a problem.

[lxy] 
1//  Firstly, Point-code based RK is a most popular configuration in the living network, 
and I think it will be in the real future network. You can not deprive of the choosing of PC based RK.
We must face and solve the problem we met not slider over.  

2// Secondly, configuring RKs with DPC+SI, is a more complex task to manage onsite 
say nothing of the compliance of different vendor's products.
Operator doesn't want to push RKs with DPC+SI in all scenarios, even for our vendors,  
we don't want to configure such unnecessary complex configurations onsite. 
In most of the cases, you must admit it's not necessary to configure RK with DPC+SI, 
while PC based RK is enough.

3// Thirdly, even with what you said to configure RKs with DPC+SI, it cann't solve the problem.
DUNA cann't replace DUPU.
   "The DUNA message is sent from an SGP in an SG to all concerned ASPs
   to indicate that the SG has determined that one or more SS7
   destinations are unreachable.  It is also sent by an SGP in response
   to a message from the ASP to an unreachable SS7 destination.  "
It indicates the unreachable situation of SS7 destinations.

If like what you said to change, not only DUNA, but also other messages' definitions need to change.

It's not expected to change most of the concepts in M3UA RFC(such as DUNA) 
because it has been accepted by all the vendors.

4// By using DUNA with DPC+SI as RK to solve user part's problem, is also strange to me.
Because if AS represents user part granularity, when AS has problem, 
AS inactive shall apply, not DUNA from IPSEP to SG.

5// The fact is there is a bug in the initial RFC with DUPU, we must fix it.


I haven't received the inital email with CT4 CR to 3GPP, when I receive, I will comment more.


Best Regards
Li Xinyan

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: 2008年2月23日 4:00
To: [email protected]
Subject: Sigtran Digest, Vol 46, Issue 5

Send Sigtran mailing list submissions to
	[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
	http://www.ietf.org/mailman/listinfo/sigtran
or, via email, send a message with subject or body 'help' to
	[email protected]

You can reach the person managing the list at
	[email protected]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Sigtran digest..."


Today's Topics:

   1. Re: your mail (Brian F. G. Bidulock)
   2. Re: FW: LS on Clarification of M3UA usage in 3GPP networks
      (Brian F. G. Bidulock)
   3. Re: FW: LS on Clarification of M3UA usage in 3GPPnetworks
      (Brian F. G. Bidulock)
   4. Re: FW: LS on Clarification of M3UA usage in 3GPP networks
      (Asveren, Tolga)

------------------------------
Message: 3
Date: Fri, 22 Feb 2008 04:56:15 -0700
From: "Brian F. G. Bidulock" <[email protected]>
Subject: Re: [Sigtran] FW: LS on Clarification of M3UA usage in
	3GPPnetworks
To: chenxu <[email protected]>
Cc: "Ong, Lyndon" <[email protected]>, "[email protected]"
	<[email protected]>,	Jon Peterson <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1

chenxu,

chenxu wrote:                                     (Fri, 22 Feb 2008 16:39:37)
> 
> This scenario isn't the same one that we want to discuss.What we want to
> discuss is the scenario that one of the user parts of an AS with an RK=DPC
> is unavailable,while DPC is still available??The ASPs and AS are in
> service.??.

Then your scenario is mis-configured for what you wish to achieve.


> UPU can sent from a SEP in SS7 network in that scenario according to
> MTP3,and we hope it does the same in the IP based signalling network.And we
> hope IPSTP can transfer DUPU,too.

In M3UA ASP-SG model, the virtual SEP resides at the SG, not at the ASP.  By
choosing a point-code based RK you simply deprive your ASP of the ability to
signal the unavailability of a user part (and are largely going against the
MTP-SAP functional model of MTP).  Configure your RKs properly (DPC/SI) and
you won't have a problem.

--brian

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


------------------------------

Message: 4
Date: Fri, 22 Feb 2008 10:39:55 -0500
From: "Asveren, Tolga" <[email protected]>
Subject: Re: [Sigtran] FW: LS on Clarification of M3UA usage in 3GPP
	networks
To: "Ong, Lyndon" <[email protected]>, <[email protected]>
Cc: Jon Peterson <[email protected]>
Message-ID:
	<[email protected]>
Content-Type: text/plain;	charset="iso-8859-1"

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






------------------------------

_______________________________________________
Sigtran mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/sigtran


End of Sigtran Digest, Vol 46, Issue 5
**************************************
_______________________________________________
Sigtran mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/sigtran