gmane.ietf.sigtran

回复: Sigtran Digest, Vol 101, Issue 1yu

cheng yan — 2013-05-21T03:06:55

要,ya4ARyTS
Yas
发送自THTC手机ar

----- Reply message -----
发件RIT人AR： sigtran-request< at >ietf.org
收件人： <sigtran< at >ietf.org>
主题： Sigtran Digest, Vol 101, Issue 1
日期： 周一, 4 月 29 日, 2013 年 03:00

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/sigtran

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send Sigtran mailing list submissions to
sigtran< at >ietf.org
5RZtZrt
To subATscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/sigtranzs
or, via email, send a message with subject or body 'help' to
sigtran-request< at >ietf.org

You can reach the person managing the list at
sigtran-owner< at >ietf.org

When replying, please edit your Subject line

Abort chunk in SCTP

Norah Jones — 2013-05-04T06:50:12

Hi, 

I am using LKSCTP in my project, one sometime I see that by box receives About chunk from the peer. Now question is what are the possibilities for which we can receive abort chunk from remote.


Thanks,
Norah Jones

Biggest Fake Conference in Computer Science

2013-04-27T18:00:35

We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit t

Re: Clarification regarding the IPSP behavior forASPTMmessages without RC

Brian F. G. Bidulock — 2013-03-13T06:38:53

Vaibhav,

Then I should point out that IPSP-DE is not recommended.  Don't
use it.  It has all manner of problems and race conditions.  It
can activate an AS in one direction and fail to do so in the
opposite direction.  It requires brittle configuration: if
configuration on both sides do no match correctly, two half
activations result instead of one full one or none.

IPSP-SE is recommended.  Use that.

--brian

Vaibhav Banga wrote:                           (Wed, 13 Mar 2013 10:54:42)

Re: Clarification regarding the IPSP behavior for ASPTM messages without RC

Vaibhav Banga — 2013-03-13T05:24:42

Hi Brain,

Thanks for the response.
Please confirm only single exchange of ASPTM messages are sufficient if RC
values are not specified.

Our implementation is allowing only single exchange of ASPTM messages by
not specifying RC, Where as peer implementation is expecting double
exchange even if RC values are not specified which is causing inter-op
issues.

Re: Clarification regarding the IPSP behavior forASPTMmessages without RC

Brian F. G. Bidulock — 2013-03-13T00:05:29

Vaibhav,

In the example RC values are specified and therefore a double
exchange is required.

There is no contradiction.

--brian

Vaibhav Banga wrote:                                     (Tue, 12 Mar 2013 15:06:00)

Clarification regarding the IPSP behavior for ASPTMmessages without RC

Vaibhav Banga — 2013-03-12T09:36:00

Hi All,



I would request you to clarify regarding the IPSP D.E mode behavior for
ASPTM messages without RC.



According to M3UA RFC 4666 section 4.3.1 last paragraph :

“ASPTM messages.  When sending ASPTM messages to activate/deactivate

     all the traffic independently of routing keys by not specifying any

     RC, a single exchange could be sufficient.”



A single exchange of ASPTM messages without RC sufficient to
activate/deactivate the traffic.  Whereas the diagram in section 5.6.2.
double exchange it looks, even if RC is optional, double exchange of ASPAC
messages are required.



               IPSP-A                           IPSP-B

                 |                                |

                 |<-------------ASP Up------------|

                 |-----------ASP Up Ack---------->|

                 |                                |

                 |-------------ASP Up------------>|  (optional)

                 |<----------ASP Up Ack-----------|  (optional)

                 |

bnpptxUT7vTg:-akZ3RR7LlF1Ipc3glBlkmCz3bASr7U6lJrNGA

lalitha kumari — 2013-03-12T09:19:03

(no subject)

deddi hp — 2013-02-10T13:17:55

http://wattavillage.com/xj/zjzb43ht3e2cq1y9ner2bnv5c=z2i_______________________________________________
Sigtran mailing list
Sigtran< at >ietf.org
https://www.ietf.org/mailman/listinfo/sigtran

Re: Encoding scheme, Number of Digits parameters,GTI inSUA message

Nemana, Satya — 2013-01-16T17:06:05

Thanks Brian.
It was helpful indeed.
The GTI mapping is not mentioned in the RFC, it was confusing to only reference to ITU spec and wonder what should happen to ANSI.
I now understand that Encoding scheme is now derived from the "Number of digits" parameter , if there are 5 octets and Number of digits is 9, then it is odd, if number of digits is 10, it is even and there cant be values other than 9/10 for a 5 octet digits parameter.

Regards,
Satya



-----Original Message-----
From: Brian F. G. Bidulock [mailto:bidulock< at >openss7.org] 
Sent: 15 January 2013 21:42
To: Nemana, Satya
Cc: sigtran< at >ietf.org
Subject: Re: [Sigtran] Encoding scheme, Number of Digits parameters, GTI in SUA message

Satya,

Please see comments inline...

Nemana, Satya wrote:                    (Mon, 14 Jan 2013 14:16:06)

They are always encoded as digits (i.e. nibble encoded digits) per RFC 3868/3.10.2.3.


10 digits is not implicitly known unless it can be determined from the translation type.  5 octets of digits can be either 9 or 10

Re: Encoding scheme, Number of Digits parameters,GTI inSUA message

Brian F. G. Bidulock — 2013-01-15T21:42:01

Satya,

Please see comments inline...

Nemana, Satya wrote:                    (Mon, 14 Jan 2013 14:16:06)

They are always encoded as digits (i.e. nibble encoded digits) per
RFC 3868/3.10.2.3.


10 digits is not implicitly known unless it can be determined from the
translation type.  5 octets of digits can be either 9 or 10 digits.  The
odd/even indicator indicates this in SS7.  In SUA we used a full digit
count (we had enough bits) instead of an odd/even indicator.  It avoids
having to interpret fillers and can be directly calculated off of the
odd/even indicator and the length of the digits (in octets).


The no. digits field does not encode a subset of the GT digits.  For
example, 5 octets of digits with a 'no. digits' field of 3 would be an
error: the field would have to be 9 or 10.


It assumes the same value at the corresponding field in the SS7 SCCP
message: that is, it is "taken over" from the SS7 message.


Read the line over the descripton of GTI values:

  "GTI (Global Title Indicator, defined in

Encoding scheme, Number of Digits parameters,GTI in SUA message

Nemana, Satya — 2013-01-14T14:16:06

Hello!

I had two questions trying to understand a problem with GT in SUA.

1) Why is the encoding scheme parameter normally present in the SS7 messages absent in the SUA message as a parameter. In the absence of the encoding scheme in the SUA Called party GT, how does the SUA NIF analyze the digits.

2) The number of digits in the SUA message (called party) is already known depending on the digits included, i.e if I have a GT of 0123456789, then I have 10 digits. In such a situation where the number of digits present is implicitly known, why do we have an other parameter " Number of Digits" to tell the same? What is the significance of this parameter?
In most cases, GT is a phone number, why would we want to use only part of it for processing the message? (there would have been a wildcard GT provisioned for the destination(s) on the SG/STP to handle the case of using a subset of the digits.

3) Also, in section 3.10.2.3, the text
<snip>
0001 Nature of Address is taken over
<snip>
What does "taken over" mean

Re: Routing Context: M3UA

Elnur Atakishiyev — 2012-12-12T10:59:04

Yes sure, it must be the same, because on base of Routing Context other end determine to which AS the traffic is sent.
Let say, you send RC=15 and other side no AS defined with RC=15 then you can not to switch message to correct AS.

From: sigtran-bounces< at >ietf.org [mailto:sigtran-bounces< at >ietf.org] On Behalf Of Saxena, Ravi (CMS)
Sent: Wednesday, December 12, 2012 2:49 PM
To: aditi someshwar
Cc: sigtran< at >ietf.org
Subject: Re: [Sigtran] Routing Context: M3UA

Yes Routing Context has to be unique for each AS and same at both ends.
More details are in RFE 3332 section 1.4.2 Routing Contexts and Routing Keys

Regards,
Ravi Saxena

From: sigtran-bounces< at >ietf.org [mailto:sigtran-bounces< at >ietf.org] On Behalf Of arif khan
Sent: Thursday, December 08, 2011 7:41 PM
To: aditi someshwar
Cc: sigtran< at >ietf.org
Subject: Re: [Sigtran] Routing Context: M3UA

Ah got..
RC value should be unique for each AS and it is advisable to maintain it as same way for peer also.
But It can be different.

Cheers

On Thu, Dec 8, 2011 at 12:20

Re: Routing Context: M3UA

Saxena, Ravi (CMS — 2012-12-12T10:49:21

Yes Routing Context has to be unique for each AS and same at both ends.
More details are in RFE 3332 section 1.4.2 Routing Contexts and Routing Keys

Regards,
Ravi Saxena

From: sigtran-bounces< at >ietf.org [mailto:sigtran-bounces< at >ietf.org] On Behalf Of arif khan
Sent: Thursday, December 08, 2011 7:41 PM
To: aditi someshwar
Cc: sigtran< at >ietf.org
Subject: Re: [Sigtran] Routing Context: M3UA

Ah got..
RC value should be unique for each AS and it is advisable to maintain it as same way for peer also.
But It can be different.

Cheers

On Thu, Dec 8, 2011 at 12:20 PM, aditi someshwar <aditi.someshwar< at >gmail.com<mailto:aditi.someshwar< at >gmail.com>> wrote:
Can not see anything in the specs to that effect though?

On Thu, Dec 8, 2011 at 5:18 PM, arif khan <arif15jan< at >gmail.com<mailto:arif15jan< at >gmail.com>> wrote:
Yes
On Thu, Dec 8, 2011 at 11:33 AM, aditi someshwar <aditi.someshwar< at >gmail.com<mailto:aditi.someshwar< at >gmail.com>> wrote:
Hi,

Quick short question:

Is it mandatory for the value of "Routing Context" to be the same

Re: M3UA: SCON: congestion condition never abates

Brian F. G. Bidulock — 2012-10-23T22:23:37

Satya,

An SG is not always able to notify congestion abatement in the
multiple SG as STP configuration.  In this configuration the
AS is responsible for maintaining the state of routes, route lists
and routesets toward the SS7 network via each SG/STP.

What you way really only applys to the normal case where the
SG "owns" the AS point code (i.e. the SG is an SEP and not an
STP in an STP pair).

--brian

Nemana, Satya wrote:                                     (Tue, 23 Oct 2012 15:13:24)

Re: M3UA: SCON: congestion condition never abates

Brian F. G. Bidulock — 2012-10-23T22:19:57

David,

SCON(0) is a valid message indicating "No congestion" for networks
the implement multiple congestion levels.  SCON messages for
international method do not include a congestion level parameter.

In international networks, congestion abatement is signalled in
response to DAUD with a DAVA not preceded by a SCON.

There is an implementation note undef RFC4666/3.4.4 that indicates
that an M3UA may maintain a timer to control congestion notification
vality that will be useful in cases where the peer node fails to
indicate congestion abatement.

There is also a note undef RFC4666/4.5.3 ASP Auditing that states
that periodic DAUD should not be initiated in response to SCON(0)
(i.e. multiple congestion level network signalling congestion
abatement).

--brian

David Laight wrote:                                        (Tue, 23 Oct 2012 16:21:38)

Re: M3UA: SCON: congestion condition never abates

Brian F. G. Bidulock — 2012-10-23T21:31:19

urte,

I should point out that there is an alternative to auditting congestion.
That is to simply resume sending traffic after a short period (1.4-2.0
seconds).  If the network is still congested, you should get a SCON message
rather immediately.  Otherise, traffic can just continue.

--brian

Brian F. G. Bidulock wrote:                                 (Tue, 23 Oct 2012 15:23:12)

Re: M3UA: SCON: congestion condition never abates

Brian F. G. Bidulock — 2012-10-23T21:28:31

Satya,

No, in the multiple STP as SG configuration there is no basis
under which the SG can send SCON(0) unless the SG sends 
signalling route set congestion test messages on behalf of all
its subtending nodes.  Therefore, the AS in this configuration
should periodically audit.

--brian

Nemana, Satya wrote:                                     (Tue, 23 Oct 2012 15:13:24)

Re: M3UA: SCON: congestion condition never abates

Brian F. G. Bidulock — 2012-10-23T21:23:12

urte,

Please see comments inline...

urte plesske wrote:                                         (Tue, 23 Oct 2012 16:58:27)

This, to begin with, is somewhat peculiar.  The circumstances
under which SG2 would send SCON to the AS concerning SG1's point
code would be:

 - traffic on the association from AS to SG2 is overloading;

 - SG2's SMH function is overloading (in which case it should
   have first attempted a DRST in ANSI-based networks);

 - the C-links between SG2 and SG1 are congested.

Which begs the question, why is the AS sending messages with DPC
of SG1 to SG2?  Is not the direct route between AS and SG1
available and unrestricted?  Perhaps you have already received a
DRST from SG1 concerning its own point-code? (which would not be
correct).

So, that's number 1 problem: Why are you sending M3UA-User
messages from the AS to SG1 via the indirect route through SG2
when there exists a direct route to SG1?


No, that is incorrect.  You should audit even though the
destination is adjacent.  Followin

Re: M3UA: SCON: congestion condition never abates

David Laight — 2012-10-23T15:21:38

I presume this is (supposed to be) M3UA?

M3UA is an abstraction of the interface between MTP3 and its userparts (typically SCCP and ISUP).

This means that the ‘AS’ box isn’t running MTP3, so your descriptions about routing are incorrect.

 

The M3UA SCON indication is telling the userpart that MTP3 received a TFC for the route.

This could be used by the userpart to reduce its traffic.

There is no network message that indicates that congestion has ceased.

IIRC M3UA also doesn’t contain any such message.

The ‘congestion level’ will be 1, 2 or 3 in ansi networks, and always 0 in ITU networks.

 

                David

 

From: sigtran-bounces< at >ietf.org [mailto:sigtran-bounces< at >ietf.org] On Behalf Of urte plesske
Sent: 23 October 2012 15:58
To: sigtran< at >ietf.org
Subject: [Sigtran] M3UA: SCON: congestion condition never abates

 

Hello, I'm faced with a problem based on the following architecture:

AS connected to two SGs
   AS
  /  \
 /    \
SG1---SG2
SCCP: SGs are making GTTs to route to the s

Re: M3UA: SCON: congestion condition never abates

Nemana, Satya — 2012-10-23T15:13:24

Hi Urte

Even if AS does not send DAUD(for SG1 PC) to SG2, SG2 should send an SCON(Level-0) when the congestion clears.
In your case, you don't explain if the AS clears(for SG1) when SG2 sends SCON(Level-0) for SG1 PC.
The DAUD from AS is not as important as the SCON(Level-0) that should be sent by SG2 for clearing congestion towards SG1.
The congestion in your case is not abating because SG2 is never clearing congestion for PC:SG1.
This sounds normal scenario as per protocol.

Regards,
Satya



From: sigtran-bounces< at >ietf.org [mailto:sigtran-bounces< at >ietf.org] On Behalf Of urte plesske
Sent: 23 October 2012 15:58
To: sigtran< at >ietf.org
Subject: [Sigtran] M3UA: SCON: congestion condition never abates

Hello, I'm faced with a problem based on the following architecture:

AS connected to two SGs
   AS
  /  \
 /    \
SG1---SG2
SCCP: SGs are making GTTs to route to the ss7 network.
MTP configurations on AS:
There are two routesets defined on AS, one to SG1 (containing direct route and route over SG2) and to SG2 (con