Signaling Transport (sigtran)

headers Santhana | 3 Mar 2010 14:56

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran

Santhana,

Please see comments below:

Santhana wrote:                            (Wed, 03 Mar 2010 19:26:09)

---X--snip--X---
> On section 1.5.4.1  SCTP Stream Management
>    SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP)
>    messages (see Section 3) since stream '0' SHOULD only be used for ASP
>    Management (ASPM) messages (see Section 4.3.3).
> And RFC explains all the ASPSM/ASPTM messages as ASPM messages. So there seems 
> to be a contradiction here in RFC.
> 
>    ===>As per this ASPTM should be sent on stream 0

Yes, ASPM should read ASPSM in section 1.5.4.1 above.

> And for IUA is SCTP stream management aligned(same as) with M2UA ?

No.

The reasons for sending ASPTM and BEAT/ACK on a traffic stream
are primarily to avoid message loss due to deactivation of the
AS (at SGP or ASP) before the last data message has arrived for
the deactivated traffic.  Sending the messages last and
sequenced on the data stream ensures that, once the acknowledge
is received, no messages are in transit to the peer UA.

This is important to meet SS7's stringently low message loss
requirements.

See http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05
for other procedures that can reduce message loss that are in
fitting with this use of ASPTM and BEAT/ACK.

ISDN has far less stringent requirments and, thus, the procedures
are not necessary for IUA and IUA sends all ASPM messages on
stream 0.

Historically, IUA was written first and M2UA came second
borrowing a lot from IUA.  Section 4.2.1 was updated correctly,
but Section 1.5.4.1 still uses the IUA statements, which do
not apply to M2UA.

Please submit an Errata against RFC 3331 for this.

--brian

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

Santhana,

Santhana wrote:                            (Thu, 04 Feb 2010 18:59:43)
> 
> In simple words can an SCTP restart triggered from the SGP side of IUA ?
> 

Not normally, as the SGP is the server and the ASP the client, only
the client would to attempt to reconnect, triggering an SCTP restart.

--brian

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

Dear folks,

We submitted two drafts about the sigtran extension, 
Although the Sigtran WG has been concluded, I still would like to 
talk about these topics in sigtran list before the discussion in tsvwg list.

The drafts may be found by

http://tools.ietf.org/id/draft-cui-tsvwg-snm-ps-00.txt
Abstract: 
   Sigtran is widely applied in the telecommunication network but there 
   are still some issues. This document briefly describes some concerned 
   scenarios and presents the association changeover and Sigtran routing 
   management problems. The goal of this document is to analyse the 
   existing shortage of Sigtran and discuss the desirable improvements. 

http://tools.ietf.org/id/draft-cui-tsvwg-assoc-changeover-00.txt
Abstract:
   Sigtran specifies association-level reliable transport for signaling 
   using SCTP, but in some scenarios a single association failure's 
   reliability mechanism is not sufficient to achieve telco reliability. 
   This document specifies procedures for an SCTP association changeover 
   solution which will enable applications to meet a higher degree of 
   availability. Two generic changeover solutions are presented in this 
   document. One is implemented inside the SCTP protocol stack and the 
   other requires SCTP and ULP to work in collaboration. 

These extensions are expected to improve the performance of sigtran 
network, especially for telecommunication network, what do you think
about them?

Any comments are appreciated!

Thanks and best regards
Xiangsong

Re-posted mail, sorry for the duplication.
=========================================

Dear folks,

We submitted two drafts about the sigtran extension, 
Although the Sigtran WG has been concluded, I still would like to 
talk about these topics in sigtran list before the discussion in tsvwg list.

The drafts may be found by

http://tools.ietf.org/id/draft-cui-tsvwg-snm-ps-00.txt
Abstract: 
   Sigtran is widely applied in the telecommunication network but there 
   are still some issues. This document briefly describes some concerned 
   scenarios and presents the association changeover and Sigtran routing 
   management problems. The goal of this document is to analyse the 
   existing shortage of Sigtran and discuss the desirable improvements. 

http://tools.ietf.org/id/draft-cui-tsvwg-assoc-changeover-00.txt
Abstract:
   Sigtran specifies association-level reliable transport for signaling 
   using SCTP, but in some scenarios a single association failure's 
   reliability mechanism is not sufficient to achieve telco reliability. 
   This document specifies procedures for an SCTP association changeover 
   solution which will enable applications to meet a higher degree of 
   availability. Two generic changeover solutions are presented in this 
   document. One is implemented inside the SCTP protocol stack and the 
   other requires SCTP and ULP to work in collaboration. 

These extensions are expected to improve the performance of sigtran 
network, especially for telecommunication network, what do you think
about them?

Any comments are appreciated!

Thanks and best regards
Xiangsong

Xiangsong,

Xiangsong Cui wrote:                      (Thu, 04 Mar 2010 11:48:15)
> 
> http://tools.ietf.org/id/draft-cui-tsvwg-snm-ps-00.txt
> Abstract: 
>   Sigtran is widely applied in the telecommunication network but there 
>   are still some issues. This document briefly describes some concerned 
>   scenarios and presents the association changeover and Sigtran routing 
>   management problems. The goal of this document is to analyse the 
>   existing shortage of Sigtran and discuss the desirable improvements. 

I believe these issues were already addressed in the 3GPP Liaison
statement of April 2008.  Note that 3GPP (which you cite in the
document) does not permit M3UA RK's at granularity of less than
a signalling point code.

> 
> http://tools.ietf.org/id/draft-cui-tsvwg-assoc-changeover-00.txt
> Abstract:
>   Sigtran specifies association-level reliable transport for signaling 
>   using SCTP, but in some scenarios a single association failure's 
>   reliability mechanism is not sufficient to achieve telco reliability. 
>   This document specifies procedures for an SCTP association changeover 
>   solution which will enable applications to meet a higher degree of 
>   availability. Two generic changeover solutions are presented in this 
>   document. One is implemented inside the SCTP protocol stack and the 
>   other requires SCTP and ULP to work in collaboration. 

http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05 provides
several mechanisms that are completely local and accomplish this
without protocol changes: neither in SCTP nor the UA.  UAs, such as
M3UA, provide CorrelationId/Ack, BEAT/Ack, and ASPTM on data streams
that already accommodate these procedures.

--brian

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

Dear Brian,

Thanks for your attention, please see inline.

Regards
Xiangsong

----- Original Message ----- 
From: "Brian F. G. Bidulock" <bidulock <at> openss7.org>
To: "Xiangsong Cui" <Xiangsong.Cui <at> huawei.com>
Cc: <sigtran <at> ietf.org>
Sent: Thursday, March 04, 2010 4:08 PM
Subject: Re: [Sigtran] Sigtran extension for network management and association changeover.

> Xiangsong,
> 
> Xiangsong Cui wrote:                      (Thu, 04 Mar 2010 11:48:15)
>> 
>> http://tools.ietf.org/id/draft-cui-tsvwg-snm-ps-00.txt
>> Abstract: 
>>   Sigtran is widely applied in the telecommunication network but there 
>>   are still some issues. This document briefly describes some concerned 
>>   scenarios and presents the association changeover and Sigtran routing 
>>   management problems. The goal of this document is to analyse the 
>>   existing shortage of Sigtran and discuss the desirable improvements. 
> 
> I believe these issues were already addressed in the 3GPP Liaison
> statement of April 2008.  Note that 3GPP (which you cite in the
> document) does not permit M3UA RK's at granularity of less than
> a signalling point code.

If you mean https://datatracker.ietf.org/documents/LIAISON/file552.txt,
I think the issues are not all resolved.
Changeover issue (I guess you agree this is a problem after I see your draft) 
is not mentioned in this liaison and the routing management issue is not 
resolved as you said.
The liaison says "However, this approach has some drawbacks, 
expecially if multiple SGs are used." and "There was some discussion within
the Working Group about potential extensions to overcome these drawbacks,
but no consensus was reached." Do I miss any important information?

In addition, in some practical scenario, even one SG, we also met some troubles.
For example, in the basic case of GSM + softswitch, some BSC devices
can not support multiple adjacent SP, unfortunately the BSCs can't be updated 
too. So the MGW has to share the SP code with the MSC Server, but we need
install SCCP in both MGW (for SGW/STP purpose) and MSC Server (for 
MAP purpose). The duplicated combinations of "SP Code + SCCP User Part" 
bring problems for the network. If we use M2UA for GSM access, the complexity
increases explicitly. Is this also a drawback?

> 
>> 
>> http://tools.ietf.org/id/draft-cui-tsvwg-assoc-changeover-00.txt
>> Abstract:
>>   Sigtran specifies association-level reliable transport for signaling 
>>   using SCTP, but in some scenarios a single association failure's 
>>   reliability mechanism is not sufficient to achieve telco reliability. 
>>   This document specifies procedures for an SCTP association changeover 
>>   solution which will enable applications to meet a higher degree of 
>>   availability. Two generic changeover solutions are presented in this 
>>   document. One is implemented inside the SCTP protocol stack and the 
>>   other requires SCTP and ULP to work in collaboration. 
> 
> http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05 provides
> several mechanisms that are completely local and accomplish this
> without protocol changes: neither in SCTP nor the UA.  UAs, such as
> M3UA, provide CorrelationId/Ack, BEAT/Ack, and ASPTM on data streams
> that already accommodate these procedures.
> 
I am glad to see this draft, but I need some time to read through it.
We can discuss this item later.

Thanks, Xiangsong

> --brian
> 
> -- 
> Brian F. G. Bidulock
> bidulock <at> openss7.org
> http://www.openss7.org/

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran

Amir,

RC should likely be marked "conditional" instead of "optional".

--brian

Amir.Khan <at> Emerson.com wrote:              (Thu, 04 Mar 2010 21:42:20)
> 
>    Hi All,
> 
> 
> 
>    Does it become mandatory for SG to send Notify message ("Alternate ASP
>    Active") with Routing Context, when the concerned ASP is a part of
>    multiple AS. So that the concerned ASP can use this RC to become
>    INACTIVE for the related AS.
> 
> 
> 
>    E.g. If  ASP1 is Actively processing traffic for both AS1(Override)
>    and AS2(Loadshare) and another ASP2 of AS1 becomes ACTIVE, Do SG then
>    needs to send Notify message ("Alternate ASP Active") with AS1 Routing
>    Context, which ASP1 will use to become INACTIVE for AS1.
> 
> 
> 
> 
> 
>    Please comment.
> 
> 
> 
>    Thanks
> 
>    aamir

> _______________________________________________
> Sigtran mailing list
> Sigtran <at> ietf.org
> https://www.ietf.org/mailman/listinfo/sigtran

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

Dear Brian,

I have read the corid draft and have some thought.

> http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05 provides
> several mechanisms that are completely local and accomplish this
> without protocol changes: neither in SCTP nor the UA.  UAs, such as
> M3UA, provide CorrelationId/Ack, BEAT/Ack, and ASPTM on data streams
> that already accommodate these procedures.
> 
> --brian

In my understanding, the corid draft and my association-changeover draft are for
the same goal, the main difference is corid draft works in UA (or SPP) layer 
while my association-changeover draft focuses on SCTP layer.

The detailed differences include:
1, Corid draft modifies UA protocols (section 3 Protocol Elements), such as 
    M2UA, M3UA, SUA, ISUA.....
    Association-changeover draft only changes SCTP protocol.
2, Corid draft brings many transport functionalities into UA layer, such as corid 
    (section 4.1.2.1), flow id (section 4.1.2.2), tagging (section 4.1.3) and buffering
    (section 4.1.4). These features bring complex and repeated job into UA layer 
    and would make UA hard to work.
    Association-changeover draft incorporates SS7 changeover functionality in Sigtran,
    the peers exchange sequence information, and the sender resends the 
    unacknowledged messages.
3, Determining which messages have already been acknowledged?
    Corid draft accomplishes it in UA layer (<5>  IMPLEMENTATION NOTE of 
    corid draft), it is out of the scope of corid draft but that is really difficult.
    Association-changeover draft accomplishes it in SCTP layer by TSN, it is very easy.
4. Corid draft requires all traffic packets to include id information (section 4.1.3), 
    which would waste bandwidth of the network.
    Association-changeover draft takes normal traffic transport procedure.
5. Corid resends all undetermined messages (including the acknowledged messages) 
    to the peer, and the messages are determined by the peer node.
    Association-changeover resends only the unacknowledged messages to the peer.

Are those right?

Thanks and regards
Xiangsong

Mon	Tue	Wed	Thu	Fri	Sat	Sun

1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

2	May 2013
1	April 2013
5	March 2013
1	February 2013
3	January 2013
2	December 2012
8	October 2012
6	July 2012
9	April 2012
6	December 2011
2	November 2011
8	October 2011
21	September 2011
16	August 2011
19	July 2011
6	June 2011
2	May 2011
38	April 2011
25	March 2011
20	February 2011
29	January 2011
25	November 2010
28	October 2010
29	September 2010
2	August 2010
2	July 2010
11	June 2010
11	May 2010
16	April 2010
63	March 2010
7	February 2010
6	January 2010
27	December 2009
20	November 2009
27	October 2009
4	September 2009
3	August 2009
55	July 2009
18	June 2009
5	May 2009
9	April 2009
39	March 2009
31	February 2009
8	January 2009
24	December 2008
7	November 2008
21	October 2008
24	September 2008
5	August 2008
30	July 2008
18	June 2008
19	May 2008
16	April 2008
30	March 2008
33	February 2008
16	January 2008
38	December 2007
48	November 2007
26	October 2007
22	September 2007
37	August 2007
81	July 2007
76	June 2007
76	May 2007
85	April 2007
43	March 2007
51	February 2007
72	January 2007
70	December 2006
173	November 2006
168	October 2006
107	September 2006
43	August 2006
64	July 2006
120	June 2006
99	May 2006
6	April 2006
38	March 2006
266	February 2006
201	January 2006
205	December 2005
169	November 2005
303	October 2005
69	September 2005
13	August 2005
53	July 2005
42	June 2005
10	May 2005
48	April 2005
54	March 2005
38	February 2005
18	January 2005
46	December 2004
12	November 2004
38	October 2004
65	September 2004
95	August 2004
60	July 2004
83	June 2004
118	May 2004
43	April 2004
44	March 2004
105	February 2004
77	January 2004
54	December 2003
15	November 2003
76	October 2003
207	September 2003
112	August 2003
336	July 2003
192	June 2003
182	May 2003
168	April 2003
330	March 2003
453	February 2003
551	January 2003
355	December 2002
186	November 2002
218	October 2002
245	September 2002
127	August 2002
223	July 2002
371	June 2002
453	May 2002
373	April 2002

[M2UA, IUA] Stream to be used for ASPTM messages

Re: [M2UA, IUA] Stream to be used for ASPTM messages

Re: [IUA] SCTP RI missing in IUA FSM

Sigtran extension for network management and association changeover.

Sigtran extension for network management and association changeover.

Re: Sigtran extension for network management and association changeover.

Re: Sigtran extension for network management and association changeover.

M3UA Notification and Routing Context

Re: M3UA Notification and Routing Context

Re: Sigtran extension for network management and association changeover.