<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.ietf.sigtran">
    <title>gmane.ietf.sigtran</title>
    <link>http://blog.gmane.org/gmane.ietf.sigtran</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9992"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9991"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9990"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9985"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9984"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9981"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9971"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9967"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9966"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9965"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9955"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9952"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9949"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9947"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9942"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9940"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9937"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9934"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9929"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.ietf.sigtran/9923"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9992">
    <title>回复: Sigtran Digest, Vol 101, Issue 1yu</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9992</link>
    <description>&lt;pre&gt;
要,ya4ARyTS
Yas
发送自THTC手机ar

----- Reply message -----
发件RIT人AR： sigtran-request&amp;lt; at &amp;gt;ietf.org
收件人： &amp;lt;sigtran&amp;lt; at &amp;gt;ietf.org&amp;gt;
主题： 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&amp;lt; at &amp;gt;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&amp;lt; at &amp;gt;ietf.org

You can reach the person managing the list at
sigtran-owner&amp;lt; at &amp;gt;ietf.org

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


Today's Topics:

1. Biggest Fake Conference in Computer Science
(hammondjohnson&amp;lt; at &amp;gt;hushmail.com)


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

MessQTRZQTWage: 1
Date: Sat, 27 Apr 2013 14:00:35 -0400
From: hammondjohnson&amp;lt; at &amp;gt;hushmail.com
To: sigtran&amp;lt; at &amp;gt;ietf.org
Subject: [Sigtran] Biggest Fake Conference in Computer Science
Message-ID: &amp;lt;20130427180035.E32E3E6736&amp;lt; at &amp;gt;smtp.hushmail.com&amp;gt;
Content-Type: text/plain; charset="UTF-8"

We ar日e 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 the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 


We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP?s proceedings since 2011 due to its fakeness. See 
http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of
http://sites.google.com/site/dumpconf for comments from well-known researchers 
about WORLDCOMP. 


The status of your WORLDCOMP papers can be changed from scientific
to other (i.e., junk or non-technical) at any time. Better not to have a paper than 
having it in WORLDCOMP and spoil the resume and peace of mind forever!


Our study revealed that WORLDCOMP is a money making business, 
using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing 
out a small chunk of that money (around 20 dollars per paper published 
in WORLDCOMP?s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) 
who publicizes WORLDCOMP and also defends it at various forums, using 
fake/anonymous names. The puppet uses fake names and defames other conferences
to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to 
threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). 
That is, the puppet does all his best to get a maximum number of papers published 
at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia?s) pockets. 


Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has 
refused to provide the venue for WORLDCOMP?13 because of the fears of their image 
being tarnished due to WORLDCOMP?s fraudulent activities. That is why WORLDCOMP?13 
is taking place at a different resort. WORLDCOMP will not be held after 2013. 


The draft paper submission deadline is over but still there are no committee 
members, no reviewers, and there is no conference Chairman. The only contact 
details available on WORLDCOMP?s website is just an email address! 

Let us make a direct request to Prof. Hamid arabnia: publish all reviews for 
all the papers (after blocking identifiable details) since 2000 conference. Reveal 
the names and affiliations of all the reviewers (for each year) and how many 
papers each reviewer had reviewed on average. We also request him to look at 
the Open Challenge (Section 6) at https://sites.google.com/si
_______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>cheng yan</dc:creator>
    <dc:date>2013-05-21T03:06:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9991">
    <title>Abort chunk in SCTP</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9991</link>
    <description>&lt;pre&gt;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
&lt;/pre&gt;</description>
    <dc:creator>Norah Jones</dc:creator>
    <dc:date>2013-05-04T06:50:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9990">
    <title>Biggest Fake Conference in Computer Science</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9990</link>
    <description>&lt;pre&gt;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 the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 


We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 
http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of
http://sites.google.com/site/dumpconf for comments from well-known researchers 
about WORLDCOMP. 


The status of your WORLDCOMP papers can be changed from scientific
to other (i.e., junk or non-technical) at any time. Better not to have a paper than 
having it in WORLDCOMP and spoil the resume and peace of mind forever!


Our study revealed that WORLDCOMP is a money making business, 
using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing 
out a small chunk of that money (around 20 dollars per paper published 
in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) 
who publicizes WORLDCOMP and also defends it at various forums, using 
fake/anonymous names. The puppet uses fake names and defames other conferences
to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to 
threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). 
That is, the puppet does all his best to get a maximum number of papers published 
at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. 


Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has 
refused to provide the venue for WORLDCOMP’13 because of the fears of their image 
being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 
is taking place at a different resort. WORLDCOMP will not be held after 2013. 


The draft paper submission deadline is over but still there are no committee 
members, no reviewers, and there is no conference Chairman. The only contact 
details available on WORLDCOMP’s website is just an email address! 

Let us make a direct request to Prof. Hamid arabnia: publish all reviews for 
all the papers (after blocking identifiable details) since 2000 conference. Reveal 
the names and affiliations of all the reviewers (for each year) and how many 
papers each reviewer had reviewed on average. We also request him to look at 
the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 


Sorry for posting to multiple lists. Spreading the word is the only way to stop 
this bogus conference. Please forward this message to other mailing lists and people. 


We are shocked with Prof. Hamid Arabnia and his puppet’s activities 
http://worldcomp-fake-bogus.blogspot.com   Search Google using the 
keyword worldcomp fake for additional links.

_______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>hammondjohnson&lt; at &gt;hushmail.com</dc:creator>
    <dc:date>2013-04-27T18:00:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9985">
    <title>bnpptxUT7vTg:-akZ3RR7LlF1Ipc3glBlkmCz3bASr7U6lJrNGA</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9985</link>
    <description>&lt;pre&gt;&lt;/pre&gt;</description>
    <dc:creator>lalitha kumari</dc:creator>
    <dc:date>2013-03-12T09:19:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9984">
    <title>(no subject)</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9984</link>
    <description>&lt;pre&gt;http://wattavillage.com/xj/zjzb43ht3e2cq1y9ner2bnv5c=z2i_______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>deddi hp</dc:creator>
    <dc:date>2013-02-10T13:17:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9981">
    <title>Encoding scheme, Number of Digits parameters,GTI in SUA message</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9981</link>
    <description>&lt;pre&gt;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
&amp;lt;snip&amp;gt;
0001 Nature of Address is taken over
&amp;lt;snip&amp;gt;
What does "taken over" mean? (Sorry, I don't mean the English meaning of it but taken over in this sentence : When there is an explicit Nature of Address parameter in SUA messages , I don't understand what is taken over here?)

4) ANSI specs and ITU specs for message format for different GTI values are different
Example :
ANSI GTI 1 : Global title includes translation type, numbering plan and encoding scheme
ITU GTI 1 : global title includes nature of address indicator only
SUA RFC only specifies ITU spec Q.713 reference.
Is it just for an example, and that similar formats should be used from ANSI or other specs wherever possible?
Or is it to say that the format for the particular GTI is now redefined with the SUA spec and this should be used?

Regards,
Satya
&lt;/pre&gt;</description>
    <dc:creator>Nemana, Satya</dc:creator>
    <dc:date>2013-01-14T14:16:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9971">
    <title>M3UA: SCON: congestion condition never abates</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9971</link>
    <description>&lt;pre&gt;
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 (containing direct route and route over SG1)
 
SCON message was received by AS from SG2 with affected PC SG1.
On AS the route set (PC SG1) was inhibited. No traffic was sent to SG1 by AS any more. 
 
Usually the AS would start sending periodic DAUDs messages as a result of the congestion, but because SG1 was got to know as adjacent node, no DAUDs with affected Point Code = Point Code SG1 were sent by any ASP.
No SCON messages were sent by SG2 to AS because no DATA and DAUD messages were received to react.
The congestion condition never abates.
 
Could you please help me with the following questions:
How to solve this situation (timer on AS?)? 
Is it correct not to audit adjacent nodes?
Can (should) SG2 send a SCON message even there are no DATA and DAUD messages to react?  
Where can I find (rfc) the information, that SCON is like TFC and not TFR?
 
Thanks a lot!
 
regards, urte
       _______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>urte plesske</dc:creator>
    <dc:date>2012-10-23T14:58:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9967">
    <title>Need suggestion on the behavior of M3UA on override mode in IPSP single exchange</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9967</link>
    <description>&lt;pre&gt;Hello all,

We need your suggestion on the behavior of M3UA on override mode in IPSP single exchange and IPSP double exchange mode.

Query-1

In the definition of IPSP double exchange model  (RFC section 4.3) it is mentioned that the RKs define the traffic to be directed to the peer as in the AS-SG model. From this we conclude that the traffic to be directed to peer for AS-SG model is analogous to IPSP  double exchange.

Is our understanding correct ?

/Query-1

Query- 2

As per the specifications RFC 4666 section : 4.3.4.3 ( page No : 84, 4th Paragraph) the behavior of Override mode f AS to be as follows:

"In the case of an Override mode AS, receipt of an ASP Active message
at an SGP causes the (re)direction of all traffic for the AS to the
ASP that sent the ASP Active message . Any previously active ASP in
the AS is now considered to be in the state ASP-INACTIVE and SHOULD
no longer receive traffic from the SGP within the AS. The SGP or
IPSP then MUST send a Notify message ("Alternate ASP_Active") to the
previously active ASP in the AS and SHOULD stop traffic to/from that
ASP. The ASP receiving this Notify MUST consider itself now in the
ASP-INACTIVE state, if it is not already aware of this via inter-ASP
communication with the Overriding ASP."

The following behavior is clear from the specifications when SGP  or IPSP receives ASP active message from an ASP.


1.       Previously active ASP SHOULD no longer receive traffic from the SGP within the AS

2.       SGP or  IPSP then MUST send a Notify message ("Alternate ASP_Active") to the previously active ASP in the AS.

3.       SGP or IPSP should stop traffic to/from the previously active ASP.


Please share on inputs on following:

Is the above text in double quotes from specifications(RFC 4666 section : 4.3.4.3 ( page No : 84, 4th Paragraph)), valid for (i.e. is override mode support for which of the following configurations)

ASP-SGP                                        (Supported/Not Supported):
                IPSP-IPSP-Single Exchange    (Supported/Not Supported):
               IPSP-IPSP-Double Exchange   (Supported/Not Supported):

Also, M3UA specifications  do not mention about the traffic sending behavior of previously active ASP.   What is the expected behavior.

Expected behavior-Possibility-1 :   Traffic should not sent from previously active ASP (for following configurations).

           ASP-SGP                                        (Yes/No):
                IPSP-IPSP-Single Exchange               (Yes/No):
               IPSP-IPSP-Double Exchange              (Yes/No):

Expected behavior-Possibility-2 : Traffic should be sent from previously active ASP ( or following configurations).

           ASP-SGP                                        (Yes/No):
                IPSP-IPSP-Single Exchange               (Yes/No):
               IPSP-IPSP-Double Exchange              (Yes/No):

/Query-2


Thanks &amp;amp; Regards,
Lalitha Yerrapaneni
ARICENT Technologies.




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
_______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>Lalitha Kumari Gopi Reddy</dc:creator>
    <dc:date>2012-07-23T11:09:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9966">
    <title>Hi</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9966</link>
    <description>&lt;pre&gt;

Thanks &amp;amp; Regards,
Lalitha Yerrapaneni
ARICENT Technologies.




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
_______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>Lalitha Kumari Gopi Reddy</dc:creator>
    <dc:date>2012-07-23T10:46:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9965">
    <title>Need suggestion on the behavior of M3UA on override modein IPSP</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9965</link>
    <description>&lt;pre&gt;

Thanks &amp;amp; Regards,
Lalitha Yerrapaneni
ARICENT Technologies.




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
_______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>Lalitha Kumari Gopi Reddy</dc:creator>
    <dc:date>2012-07-23T10:35:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9955">
    <title>SIGTRAN: Client-Server model</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9955</link>
    <description>&lt;pre&gt;Hi all,

One very fundamental question:

SIGTRAN uses "Client-Server" model.

Can anyone please tell why?

Regards,
Aditi
_______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>aditi someshwar</dc:creator>
    <dc:date>2012-04-05T05:45:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9952">
    <title>M3UA: IPSP Signalling Point code?</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9952</link>
    <description>&lt;pre&gt;Hi all,

Does the IPSP (in M3UA) need to have a Point Code? Can anyone explain?

Regards,
Aditi
_______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>aditi someshwar</dc:creator>
    <dc:date>2011-12-08T12:22:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9949">
    <title>Routing Context: M3UA</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9949</link>
    <description>&lt;pre&gt;Hi,

Quick short question:

Is it mandatory for the value of "Routing Context" to be the same at both
the ends of M3UA association?

Thanks and Regards,
Aditi
_______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>aditi someshwar</dc:creator>
    <dc:date>2011-12-08T11:33:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9947">
    <title>[SCTP] Multi-Homing Path Failure detection</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9947</link>
    <description>&lt;pre&gt;Dear Experts,
In the SCTP multi-homing scenario, I have certain doubts on the Path failure detection as below.
                        Two end points A and B have two paths between them named Path1 and Path2.

1)       End point A sends some DATA in Path1 to B. But it did not receive SACK in that path from B. Now the RTO expired in A and it incremented the Error counter for the Path1 destination address in B. And A retransmits the old DATA chunks (that were sent to B in Path1 and unacknowledged) in Path2. And also transmits some new DATA chunks. Now B acknowledges with the latest TSN (old and new DATA chunks transmitted by A). Now is it ok to clear the error counter of Path1 in A (as the old DATA chunks destined to Path1 destination address were also acknowledged by SACK received in Path2)? If A clears the error counter of Path1 in this case, I think it may encounter the same cycle of problem again. What is the suggested and desirable approach here?

2)       Also when an endpoint receives a DATA in certain path, Should it reply the SACK in the same path or it can also reply in other paths (in case when this alternative path also destines to the same Source Address back)?

Please clarify on this.

Regards
Santhana
_______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>Santhanakrishnan yayathi</dc:creator>
    <dc:date>2011-11-28T03:53:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9942">
    <title>Question regarding RFC 4960 Out of the Blue packets</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9942</link>
    <description>&lt;pre&gt;Hello

I wonder if you can help me with a question that I have regarding Out of
the Blue packets please?

Section 1.5.6 states that these packets should be silently discarded:-

1.5.6. Packet Validation
A mandatory Verification Tag field and a 32-bit checksum field (see
Appendix B for a description of the CRC32c checksum) are included in
the SCTP common header. The Verification Tag value is chosen by each
end of the association during association startup. Packets received
without the expected Verification Tag value are discarded, as a
protection against blind masquerade attacks and against stale SCTP
packets from a previous association. The CRC32c checksum should be
set by the sender of each SCTP packet to provide additional
protection against data corruption in the network. The receiver of
an SCTP packet with an invalid CRC32c checksum silently discards the
packet.

However Section 8.4 gives an alternative explanation as to how these
packets should be handled:-


8.4.  Handle "Out of the Blue" Packets

   An SCTP packet is called an "out of the blue" (OOTB) packet if it is
   correctly formed (i.e., passed the receiver's CRC32c check; see
   Section 6.8), but the receiver is not able to identify the
   association to which this packet belongs.

   The receiver of an OOTB packet MUST do the following:

   1)  If the OOTB packet is to or from a non-unicast address, a
       receiver SHOULD silently discard the packet.  Otherwise,

   2)  If the OOTB packet contains an ABORT chunk, the receiver MUST
       silently discard the OOTB packet and take no further action.
       Otherwise,

   3)  If the packet contains an INIT chunk with a Verification Tag set
       to '0', process it as described in Section 5.1.  If, for whatever
       reason, the INIT cannot be processed normally and an ABORT has to
       be sent in response, the Verification Tag of the packet
       containing the ABORT chunk MUST be the Initiate Tag of the
       received INIT chunk, and the T bit of the ABORT chunk has to be
       set to 0, indicating that the Verification Tag is NOT reflected.

   4)  If the packet contains a COOKIE ECHO in the first chunk, process
       it as described in Section 5.1.  Otherwise,

   5)  If the packet contains a SHUTDOWN ACK chunk, the receiver should
       respond to the sender of the OOTB packet with a SHUTDOWN
       COMPLETE.  When sending the SHUTDOWN COMPLETE, the receiver of
       the OOTB packet must fill in the Verification Tag field of the
       outbound packet with the Verification Tag received in the
       SHUTDOWN ACK and set the T bit in the Chunk Flags to indicate
       that the Verification Tag is reflected.  Otherwise,

   6)  If the packet contains a SHUTDOWN COMPLETE chunk, the receiver
       should silently discard the packet and take no further action.
       Otherwise,

   7)  If the packet contains a "Stale Cookie" ERROR or a COOKIE ACK,
       the SCTP packet should be silently discarded.  Otherwise,

   8)  The receiver should respond to the sender of the OOTB packet with
       an ABORT.  When sending the ABORT, the receiver of the OOTB
       packet MUST fill in the Verification Tag field of the outbound
       packet with the value found in the Verification Tag field of the
       OOTB packet and set the T bit in the Chunk Flags to indicate that
       the Verification Tag is reflected.  After sending this ABORT, the
       receiver of the OOTB packet shall discard the OOTB packet and
       take no further action.

My initial thoughts were to treat 8.4 as the overriding section as it
suggests different responses for packets containing different types of
chunks and it goes into more detail. However, I can also see that
section 1.5.6 may have a security benefit over section 8.4. 

If you can offer any help on this I will be very grateful.

Many Thanks, and Kind Regards


Ian Horsham
Principal DTC/VO Engineer 
Cable &amp;amp; Wireless Worldwide

Direct Dial: +44 (0) 1344811151
Mobile: +44 (0) 7822813439

This e-mail has been scanned for viruses by the Cable&amp;amp;Wireless Worldwide e-mail security system. For more information on a proactive 
managed e-mail secure service, visit http://www.cw.com/managed-exchange

The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. 
If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you 
have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any 
attachments without retaining any copies.

Cable &amp;amp; Wireless Worldwide plc 
Registered in England and Wales. Company Number 07029206
Registered office: Liberty House, 76 Hammersmith Road, London W14 8UD, England_______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>Horsham, Ian</dc:creator>
    <dc:date>2011-10-12T10:15:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9940">
    <title>NTFY message in IPSP single exchange mode</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9940</link>
    <description>&lt;pre&gt;Hi Brain,

Is it must to send the NTFY message to the peer node after change in the
IPSP state?


*Thanks
**Mahantesh*
_______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>Mahantesh SK</dc:creator>
    <dc:date>2011-10-04T11:42:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9937">
    <title>SCTP Multihoming</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9937</link>
    <description>&lt;pre&gt;Hi

 

I have query on SCTP Multi-homing with respect to primary and secondary
paths.

Assuming two endpoints using multi-homing, 

End-Point-1, EP1 has IP addresses EP1-IP1 and EP1-IP2, 

End-Point-2, EP2 has IP addresses EP2-IP1 and EP2-IP2.

Both of these interfaces are in completely different networks with
different routers, etc connecting them indirectly.

 

Under this scenario would there be 

2 paths between the two end points (EP1-IP1 &amp;lt;-&amp;gt; EP2-IP1 as path #1 and
EP1-IP2 &amp;lt;-&amp;gt; EP2-IP2 as Path#2) or 

4 paths using (EP1-IP1 &amp;lt;-&amp;gt; EP2-IP1 as path #1 and EP1-IP1 &amp;lt;-&amp;gt; EP2-IP2 as
Path#2 , EP1-IP2 &amp;lt;-&amp;gt; EP2-IP1 as path#3 and EP1-IP2 &amp;lt;-&amp;gt; EP2-IP2)

 

If there are 4 paths, how would IP routing take care of such a scenario,
i.e how would the route tables look like on EP1?

How can EP1 have 2 routes to the same EP2-IP1 IP address through 2
different local interfaces on EP1?

 

TIA,

 

Regards,

Satya

_______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>Nemana, Satya</dc:creator>
    <dc:date>2011-09-26T15:44:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9934">
    <title>[SIGTRAN:M3UA] Query regarding the behavior of networkappearance in the DAUD message</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9934</link>
    <description>&lt;pre&gt;Hi,

 

We have a SIGTRAN setup with ITU, ANSI and Chinese variants with network appearance values configured as 1, 2, and 3 respectively as the DUT.

Now, if I send an ITU-DAUD message with network appearance value as 3 from the peer to the DUT. There is no error message sent from the DUT to the peer. Should there be no error message sent to the peer saying “Invalid Network Appearance” ? 

 

According to RFC 4666, we see that Invalid Network Appearance error message is sent for the below scenario:

 

The "Invalid Network Appearance" error is sent by an SGP if an ASP sends a message with an invalid (unconfigured) Network Appearance value. For this error, the invalid (unconfigured) Network Appearance MUST be included in the Network Appearance parameter.

 

So, does that mean “invalid (configured)” means the NA that’s not configured for any variant on the DUT? 

 

Could you please comment on this behavior.

 

 

Thanks &amp;amp; Regards, 
Vishma R Shetty 

 

_______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>Shetty, Vishma (NSN - IN/Bangalore</dc:creator>
    <dc:date>2011-09-09T11:57:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9929">
    <title>Needs clarification on handling of SCON message</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9929</link>
    <description>&lt;pre&gt;Hi,

I have one query regarding the SCON message handling between SG and ASP.

Suppose a SG informs one of the Active ASP serving an AS that one of the point code in MTP3 network has become congested and hence sends the SCON message with congestion level say 1 to ASP.

After receiving the SCON message with congestion level 1, the ASP starts the audit procedure and starts sending the DAUD message for that destination.

Now when the destination point code in MTP3 network become uncongested, can a SGP inform the ASP by sending a DAVA message or it always informs by sending SCON message with congestion level as 0.

And what if say after sending the initial SCON message to ASP with congestion level 1, the SG gets restarted. After restart would it be a DAVA message sent to ASP, on receiving it the ASP clears the congestion level set earlier and marks the destination point available and informs the higher layers.

Regards
Deepak




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
_______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>Deepak Gunjal</dc:creator>
    <dc:date>2011-09-04T19:05:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9923">
    <title>SCON received at ASP from one of SGs</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9923</link>
    <description>&lt;pre&gt;
 
  Normal
  0
  
  
  
  
  false
  false
  false
  
  RU
  X-NONE
  X-NONE
  
   
   
   
   
   
   
   
   
   
   
   
  
  MicrosoftInternetExplorer4
  
   
   
   
   
   
   
   
   
   
   
   
  

 &amp;lt;w:latentstyles deflockedstate="false" defunhidewhenused="true" defsemihidden="true" defqformat="false" defpriority="99" latentstylecount="267"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="0" semihidden="false" unhidewhenused="false" qformat="true" name="Normal"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="9" semihidden="false" unhidewhenused="false" qformat="true" name="heading 1"&amp;gt;
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  &amp;lt;w:lsdexception locked="false" priority="10" semihidden="false" unhidewhenused="false" qformat="true" name="Title"&amp;gt;
  
  &amp;lt;w:lsdexception locked="false" priority="11" semihidden="false" unhidewhenused="false" qformat="true" name="Subtitle"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="22" semihidden="false" unhidewhenused="false" qformat="true" name="Strong"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="20" semihidden="false" unhidewhenused="false" qformat="true" name="Emphasis"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="59" semihidden="false" unhidewhenused="false" name="Table Grid"&amp;gt;
  
  &amp;lt;w:lsdexception locked="false" priority="1" semihidden="false" unhidewhenused="false" qformat="true" name="No Spacing"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="60" semihidden="false" unhidewhenused="false" name="Light Shading"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="61" semihidden="false" unhidewhenused="false" name="Light List"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="62" semihidden="false" unhidewhenused="false" name="Light Grid"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="63" semihidden="false" unhidewhenused="false" name="Medium Shading 1"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="64" semihidden="false" unhidewhenused="false" name="Medium Shading 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="65" semihidden="false" unhidewhenused="false" name="Medium List 1"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="66" semihidden="false" unhidewhenused="false" name="Medium List 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="67" semihidden="false" unhidewhenused="false" name="Medium Grid 1"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="68" semihidden="false" unhidewhenused="false" name="Medium Grid 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="69" semihidden="false" unhidewhenused="false" name="Medium Grid 3"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="70" semihidden="false" unhidewhenused="false" name="Dark List"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="71" semihidden="false" unhidewhenused="false" name="Colorful Shading"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="72" semihidden="false" unhidewhenused="false" name="Colorful List"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="73" semihidden="false" unhidewhenused="false" name="Colorful Grid"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="60" semihidden="false" unhidewhenused="false" name="Light Shading Accent 1"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="61" semihidden="false" unhidewhenused="false" name="Light List Accent 1"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="62" semihidden="false" unhidewhenused="false" name="Light Grid Accent 1"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="63" semihidden="false" unhidewhenused="false" name="Medium Shading 1 Accent 1"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="64" semihidden="false" unhidewhenused="false" name="Medium Shading 2 Accent 1"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="65" semihidden="false" unhidewhenused="false" name="Medium List 1 Accent 1"&amp;gt;
  
  &amp;lt;w:lsdexception locked="false" priority="34" semihidden="false" unhidewhenused="false" qformat="true" name="List Paragraph"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="29" semihidden="false" unhidewhenused="false" qformat="true" name="Quote"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="30" semihidden="false" unhidewhenused="false" qformat="true" name="Intense Quote"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="66" semihidden="false" unhidewhenused="false" name="Medium List 2 Accent 1"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="67" semihidden="false" unhidewhenused="false" name="Medium Grid 1 Accent 1"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="68" semihidden="false" unhidewhenused="false" name="Medium Grid 2 Accent 1"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="69" semihidden="false" unhidewhenused="false" name="Medium Grid 3 Accent 1"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="70" semihidden="false" unhidewhenused="false" name="Dark List Accent 1"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="71" semihidden="false" unhidewhenused="false" name="Colorful Shading Accent 1"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="72" semihidden="false" unhidewhenused="false" name="Colorful List Accent 1"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="73" semihidden="false" unhidewhenused="false" name="Colorful Grid Accent 1"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="60" semihidden="false" unhidewhenused="false" name="Light Shading Accent 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="61" semihidden="false" unhidewhenused="false" name="Light List Accent 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="62" semihidden="false" unhidewhenused="false" name="Light Grid Accent 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="63" semihidden="false" unhidewhenused="false" name="Medium Shading 1 Accent 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="64" semihidden="false" unhidewhenused="false" name="Medium Shading 2 Accent 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="65" semihidden="false" unhidewhenused="false" name="Medium List 1 Accent 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="66" semihidden="false" unhidewhenused="false" name="Medium List 2 Accent 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="67" semihidden="false" unhidewhenused="false" name="Medium Grid 1 Accent 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="68" semihidden="false" unhidewhenused="false" name="Medium Grid 2 Accent 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="69" semihidden="false" unhidewhenused="false" name="Medium Grid 3 Accent 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="70" semihidden="false" unhidewhenused="false" name="Dark List Accent 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="71" semihidden="false" unhidewhenused="false" name="Colorful Shading Accent 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="72" semihidden="false" unhidewhenused="false" name="Colorful List Accent 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="73" semihidden="false" unhidewhenused="false" name="Colorful Grid Accent 2"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="60" semihidden="false" unhidewhenused="false" name="Light Shading Accent 3"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="61" semihidden="false" unhidewhenused="false" name="Light List Accent 3"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="62" semihidden="false" unhidewhenused="false" name="Light Grid Accent 3"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="63" semihidden="false" unhidewhenused="false" name="Medium Shading 1 Accent 3"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="64" semihidden="false" unhidewhenused="false" name="Medium Shading 2 Accent 3"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="65" semihidden="false" unhidewhenused="false" name="Medium List 1 Accent 3"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="66" semihidden="false" unhidewhenused="false" name="Medium List 2 Accent 3"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="67" semihidden="false" unhidewhenused="false" name="Medium Grid 1 Accent 3"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="68" semihidden="false" unhidewhenused="false" name="Medium Grid 2 Accent 3"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="69" semihidden="false" unhidewhenused="false" name="Medium Grid 3 Accent 3"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="70" semihidden="false" unhidewhenused="false" name="Dark List Accent 3"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="71" semihidden="false" unhidewhenused="false" name="Colorful Shading Accent 3"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="72" semihidden="false" unhidewhenused="false" name="Colorful List Accent 3"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="73" semihidden="false" unhidewhenused="false" name="Colorful Grid Accent 3"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="60" semihidden="false" unhidewhenused="false" name="Light Shading Accent 4"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="61" semihidden="false" unhidewhenused="false" name="Light List Accent 4"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="62" semihidden="false" unhidewhenused="false" name="Light Grid Accent 4"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="63" semihidden="false" unhidewhenused="false" name="Medium Shading 1 Accent 4"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="64" semihidden="false" unhidewhenused="false" name="Medium Shading 2 Accent 4"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="65" semihidden="false" unhidewhenused="false" name="Medium List 1 Accent 4"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="66" semihidden="false" unhidewhenused="false" name="Medium List 2 Accent 4"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="67" semihidden="false" unhidewhenused="false" name="Medium Grid 1 Accent 4"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="68" semihidden="false" unhidewhenused="false" name="Medium Grid 2 Accent 4"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="69" semihidden="false" unhidewhenused="false" name="Medium Grid 3 Accent 4"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="70" semihidden="false" unhidewhenused="false" name="Dark List Accent 4"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="71" semihidden="false" unhidewhenused="false" name="Colorful Shading Accent 4"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="72" semihidden="false" unhidewhenused="false" name="Colorful List Accent 4"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="73" semihidden="false" unhidewhenused="false" name="Colorful Grid Accent 4"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="60" semihidden="false" unhidewhenused="false" name="Light Shading Accent 5"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="61" semihidden="false" unhidewhenused="false" name="Light List Accent 5"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="62" semihidden="false" unhidewhenused="false" name="Light Grid Accent 5"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="63" semihidden="false" unhidewhenused="false" name="Medium Shading 1 Accent 5"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="64" semihidden="false" unhidewhenused="false" name="Medium Shading 2 Accent 5"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="65" semihidden="false" unhidewhenused="false" name="Medium List 1 Accent 5"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="66" semihidden="false" unhidewhenused="false" name="Medium List 2 Accent 5"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="67" semihidden="false" unhidewhenused="false" name="Medium Grid 1 Accent 5"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="68" semihidden="false" unhidewhenused="false" name="Medium Grid 2 Accent 5"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="69" semihidden="false" unhidewhenused="false" name="Medium Grid 3 Accent 5"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="70" semihidden="false" unhidewhenused="false" name="Dark List Accent 5"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="71" semihidden="false" unhidewhenused="false" name="Colorful Shading Accent 5"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="72" semihidden="false" unhidewhenused="false" name="Colorful List Accent 5"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="73" semihidden="false" unhidewhenused="false" name="Colorful Grid Accent 5"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="60" semihidden="false" unhidewhenused="false" name="Light Shading Accent 6"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="61" semihidden="false" unhidewhenused="false" name="Light List Accent 6"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="62" semihidden="false" unhidewhenused="false" name="Light Grid Accent 6"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="63" semihidden="false" unhidewhenused="false" name="Medium Shading 1 Accent 6"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="64" semihidden="false" unhidewhenused="false" name="Medium Shading 2 Accent 6"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="65" semihidden="false" unhidewhenused="false" name="Medium List 1 Accent 6"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="66" semihidden="false" unhidewhenused="false" name="Medium List 2 Accent 6"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="67" semihidden="false" unhidewhenused="false" name="Medium Grid 1 Accent 6"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="68" semihidden="false" unhidewhenused="false" name="Medium Grid 2 Accent 6"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="69" semihidden="false" unhidewhenused="false" name="Medium Grid 3 Accent 6"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="70" semihidden="false" unhidewhenused="false" name="Dark List Accent 6"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="71" semihidden="false" unhidewhenused="false" name="Colorful Shading Accent 6"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="72" semihidden="false" unhidewhenused="false" name="Colorful List Accent 6"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="73" semihidden="false" unhidewhenused="false" name="Colorful Grid Accent 6"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="19" semihidden="false" unhidewhenused="false" qformat="true" name="Subtle Emphasis"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="21" semihidden="false" unhidewhenused="false" qformat="true" name="Intense Emphasis"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="31" semihidden="false" unhidewhenused="false" qformat="true" name="Subtle Reference"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="32" semihidden="false" unhidewhenused="false" qformat="true" name="Intense Reference"&amp;gt;
  &amp;lt;w:lsdexception locked="false" priority="33" semihidden="false" unhidewhenused="false" qformat="true" name="Book Title"&amp;gt;
  
  
 


 /* Style Definitions */
 table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}



Hi All,
Hope to get a piece of advise regarding interpretation of sections 1.3.2 and 4.5.2.2 of RFC4666.



ASP has
routes to SS7 destination point through several SGs.

1 . If ASP gets SCON from one of SGs should it immediately send congestion indication
to the user or should we send report to the user if and only if SCON received from both SGs? RFC says that ASP "determines whether or
   not the overall availability or congestion status of the affected
   destination(s) has changed". Does it mean ASP should set for the destination the minimum congestion status among all SGs or the maximum congestion status among all SGs ?


&amp;amp;nbsp;2. In the
same configuration. If we get SCON from one SG should we try to redistribute
the part of traffic from the congested route, that leads to congestion, to the other routes &amp;amp;nbsp;through which this destination is accessible?

If yes,
what measures can be taken to diminish possible negative side effects of such
redistribution? By the way, RFC recommends to handle it "much like an MTP3 layer
   maintains route-set status", but ITU-T Q.704 does not say anything about rerouting caused by congestion in one of the routes.



(Similar questions have been discussed here before, but those were for several ASPs and a single SG)


&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;
 /w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:
 lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:
 lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:lsdexception&amp;gt;&amp;lt;/w:latentstyles&amp;gt;
&lt;/pre&gt;</description>
    <dc:creator>Mikhail Plotkin</dc:creator>
    <dc:date>2011-09-02T10:05:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.ietf.sigtran/9920">
    <title>[M3UA] Handling DUNA about Self Point Code</title>
    <link>http://comments.gmane.org/gmane.ietf.sigtran/9920</link>
    <description>&lt;pre&gt;Hi Brian

          In M3UA can an entity send DUNA(about itself), to convey its
unavailability, for some other Management reasons.  

 

          If such DUNA(about self Point Code) is received from adjacent
Point Code, then how to process it ? Can it be processed like normal DUNA,
and a DAUD procedure be started? 

 

          Or for management reasons the control should be only at the level
of Blocking the ASP?

 

          Pls share your opinion.

 

Regards

Santhana

_______________________________________________
Sigtran mailing list
Sigtran&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
&lt;/pre&gt;</description>
    <dc:creator>Santhana</dc:creator>
    <dc:date>2011-09-02T02:44:14</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.ietf.sigtran">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.ietf.sigtran</link>
  </textinput>
</rdf:RDF>
