Subject: [Sigtran] Query regarding M3UA DAUD message

From: Amit Jain <[email-masked]>
Date: Mon, 5 Apr 2010 10:21:31 +0530

Hi All

 I would like to understand the significance of RC parameter in M3UA DAUD
message.
Consider the case in which there are 2 AS in a single process say P1
connected to a single SG in process say P2 served by a single point code.
Both AS are in active state.

 Query 1: Should there be a single DAUD message from process P1 towards
process P2 or two DAUD messages corresponding to two AS(s) in process P1.

 Query 2: If there is a single DAUD message from process P1 towards process
P2, then what should be the RC value in DAUD message? Should it contain the
RC of both the AS(s)?

 Query 3: What is the significance of RC parameter received in DAUD message
at SG side.
 Regards
Amit Jain

---

From: Moloud Mousavi <[email-masked]>
Date: Wed, 14 Apr 2010 12:05:28 -0400

Hi All,

M3UA terms in RFC confuse me:

IP Server Process (IPSP) - A process instance of an IP-based
application. An IPSP is essentially the same as an ASP, except that
it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does
not use the services of a Signalling Gateway node.

What is this M3UA in a point to point fashion? In fact I took both ASP and ISPS the same concept, different names.

Thanks,
Moloud

________________________________
NOTICE: This e-mail contains information that may be confidential and proprietary. If you are not the intended recipient, any disclosure or other use of this e-mail or the information contained herein or attached hereto may be unlawful and is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail without reading, printing, copying or forwarding it to anyone. Thank you for your kind cooperation.
AVIS : Ce courriel contient des renseignements qui peuvent etre confidentiels ou de propriete industrielle. Si vous n'etes pas le veritable destinataire, la diffusion ou l'usage de ce courriel, des renseignements qu'il contient ou des documents qui lui sont joints pourrait etre illegal. Il est donc strictement interdit de les diffuser ou de les utiliser. Si vous avez recu ce courriel par erreur, veuillez en aviser l'expediteur immediatement et veuillez le supprimer sans le lire, l'imprimer, le sauvegarder ou le diffuser. Merci de votre aimable collaboration.

---

From: "Barry Nagelberg" <[email-masked]>
Date: Wed, 14 Apr 2010 12:16:44 -0400

Moloud,

You are correct. As your excerpt notes, they are conceptually the same thing. The distinction is who they talk to:

An ASP  talks to an SGP
An IPSP talks to an IPSP

Barry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Moloud Mousavi
Sent: Wednesday, April 14, 2010 12:05 PM
To: [email-masked]
Subject: [Sigtran] Query regarding AS and SG/IPSP

Hi All,

 
Thanks,
Moloud

---

From: Moloud Mousavi <[email-masked]>
Date: Wed, 14 Apr 2010 13:23:43 -0400

Barry,

Thanks for the quick reply. One more thing:

What are the differences between figure 1 and 2? Because to me they both are the same.

1)
  -------------                                 --------------
 | SG/IPSP     |                               | AS  DPC = X  |
 | under Test  |                               |  -------     |
 | DPC = Z     |-------------------------------|--| ASP1 |    |
 |             |                               |  -------     |
  -------------                                 --------------

2)
  -------------                                 --------------
 | ASP1        |                               | SG/IPSP      |
 | under Test  |                               | DPC = Z      |
 | DPC = X     |-------------------------------|              |
 |             |                               |              |
  -------------                                 --------------

Thanks,
Moloud

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Nagelberg
Sent: Wednesday, April 14, 2010 12:17 PM
To: [email-masked]
Subject: Re: [Sigtran] Query regarding AS and SG/IPSP

Moloud,

An ASP  talks to an SGP
An IPSP talks to an IPSP

Barry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Moloud Mousavi
Sent: Wednesday, April 14, 2010 12:05 PM
To: [email-masked]
Subject: [Sigtran] Query regarding AS and SG/IPSP

Hi All,

Thanks,
Moloud

_______________________________________________
Sigtran mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sigtran

---

From: "Barry Nagelberg" <[email-masked]>
Date: Wed, 14 Apr 2010 15:47:52 -0400

Moloud,

I would prefer to draw the figures like this:

1)
  -------------                                 --------------
 |    IPSP     |                               |     DPC = X  |
 | under Test  |                               |  -------     |
 | DPC = Z     |-------------------------------|--|IPSP1 |    |
 |             |                               |  -------     |
  -------------                                 --------------

2)
 | ASP1        |                               | SGP          |

In Figure 1, we're testing IPSP-IPSP functionality.
In Figure 2, we're testing ASP-SGP functionality.

Barry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Moloud Mousavi
Sent: Wednesday, April 14, 2010 1:24 PM
To: Barry Nagelberg
Cc: [email-masked]
Subject: Re: [Sigtran] Query regarding AS and SG/IPSP

Barry,

1)

2)

Thanks,
Moloud

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Nagelberg
Sent: Wednesday, April 14, 2010 12:17 PM
To: [email-masked]
Subject: Re: [Sigtran] Query regarding AS and SG/IPSP

Moloud,

An ASP  talks to an SGP
An IPSP talks to an IPSP

Barry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Moloud Mousavi
Sent: Wednesday, April 14, 2010 12:05 PM
To: [email-masked]
Subject: [Sigtran] Query regarding AS and SG/IPSP

Hi All,

Thanks,
Moloud

NOTICE: This e-mail contains information that may be confidential and proprietary. If you are not the intended
recipient, any disclosure or other use of this e-mail or the information contained herein or attached hereto may be
unlawful and is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately and
delete this e-mail without reading, printing, copying or forwarding it to anyone. Thank you for your kind cooperation.
AVIS : Ce courriel contient des renseignements qui peuvent etre confidentiels ou de propriete industrielle. Si vous
n'etes pas le veritable destinataire, la diffusion ou l'usage de ce courriel, des renseignements qu'il contient ou des
documents qui lui sont joints pourrait etre illegal. Il est donc strictement interdit de les diffuser ou de les
utiliser. Si vous avez recu ce courriel par erreur, veuillez en aviser l'expediteur immediatement et veuillez le
supprimer sans le lire, l'imprimer, le sauvegarder ou le diffuser. Merci de votre aimable collaboration.
_______________________________________________
Sigtran mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sigtran

---

From: Moloud Mousavi <[email-masked]>
Date: Tue, 20 Apr 2010 11:21:50 -0400

Hi,

RFC says:

"When the ASP sends an ASP Active message, it starts the timer T(ack).
If the ASP does not receive a response to an ASP Active message
within T(ack), the ASP MAY restart T(ack) and resend ASP Active
messages until it receives an ASP Active Ack message. T(ack) is
provisionable, with a default of 2 seconds. Alternatively,
retransmission of ASP Active messages MAY be put under control of
Layer Management. In this method, expiry of T(ack) results in an MASP_
ACTIVE confirm primitive carrying a negative indication."

how should I interpret "MAY"? Should ASP resends ASPAC or not? Any idea?

Thanks,
Moloud

---

From: "David Laight" <[email-masked]>
Date: Tue, 20 Apr 2010 16:27:47 +0100

> how should I interpret "MAY"? Should ASP resends ASPAC or 

My personal preference is to disbelieve that the far end is
running the relevant protocol, so to disconnect and retry
the whole connection later.

This saves all the problems trying to process unexpected
acks that arrive later because a message that was assumed
to be discarded was just delayed.

Remember this is all over SCTP which is supposed to be a
reliable transport service.

	David

---

From: Ankit Kumar Sharma <[email-masked]>
Date: Tue, 20 Apr 2010 17:35:51 +0100

As per RFC, retransmission of ASP Active is implementation specific.

RFC has suggested two approaches to handle this condition:
  1) M3UA re-transmits ASPAC on the expiry of T(ack)
  2) Layer management is informed about this condition. Now, layer
management could initiate the ASPAC or tear down the connection etc.

Regards

On Tue, Apr 20, 2010 at 4:21 PM, Moloud Mousavi <[email-masked]>wrote:

> NOTICE: This e-mail contains information that may be confidential and
> proprietary. If you are not the intended recipient, any disclosure or other
> use of this e-mail or the information contained herein or attached hereto
> may be unlawful and is strictly prohibited. If you have received this e-mail
> in error, please notify the sender immediately and delete this e-mail
> without reading, printing, copying or forwarding it to anyone. Thank you for
> your kind cooperation.
> AVIS : Ce courriel contient des renseignements qui peuvent etre
> confidentiels ou de propriete industrielle. Si vous n'etes pas le veritable
> destinataire, la diffusion ou l'usage de ce courriel, des renseignements
> qu'il contient ou des documents qui lui sont joints pourrait etre illegal.
> Il est donc strictement interdit de les diffuser ou de les utiliser. Si vous
> avez recu ce courriel par erreur, veuillez en aviser l'expediteur
> immediatement et veuillez le supprimer sans le lire, l'imprimer, le
> sauvegarder ou le diffuser. Merci de votre aimable collaboration.