Re: Alternative to M3UA HeartBeat
Deepak Gunjal <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <DF735188ED91BD458FA0E0C17929339F657B9E69@GUREXMB01.ASIAN.AD.ARICENT.COM> |
What are the cases where I may require to use BEAT over reliable transport viz. SCTP? I can think of a case where remote M3UA is stuck in a loop and unable to process protocol messages but its SCTP layer can still send and acknowledge heartbeats at SCTP level though M3UA as such is not available. Will this case qualify for using BEAT where peer can detect such problem as BEAT ACK will not be received? Are there also other use cases which may suggest for use of BEAT over reliable transport? Regards Deepak ________________________________________ From: [email protected] [[email protected]] On Behalf Of Chris Benson [[email protected]] Sent: Tuesday, May 25, 2010 11:40 PM To: Moloud Mousavi Cc: [email protected] Subject: Re: [Sigtran] Alternative to M3UA HeartBeat Moloud, Although other transports are technically allowed, in practice, M3UA is (always?) implemented over SCTP, which *does* have its own heartbeat mechanism. I thus consider your question moot. As you have probably noted, RFC 4666 only "recommends" that M3UA BEAT be used over transport layers without heartbeats. It is thus true that one could use a different transport layer (without its own hearbeat mechanism) and not be able to determine quickly that an M3UA peer has "disappeared". In certain circumstances, the determination can be made (e.g. waiting for ASPUP Ack), but in other circumstances (normal active, idle), the determination cannot be made by M3UA alone. So it isn't a good idea to implement the combination of "M3UA-no-BEATs" with "transport-no-heartbeats". With thanks, from Chris Benson. On Tue, 25 May 2010, Moloud Mousavi wrote: >> Date: Tue, 25 May 2010 12:03:53 -0400 >> From: Moloud Mousavi <[email protected]> >> To: "[email protected]" <[email protected]> >> Subject: [Sigtran] Alternative to M3UA HeartBeat >> >> Hi, >> >> RFC considers M3UA beat optional; it's needed over transport layers without their own heartbeat mechanism. >> My question is: If M3UA beat is off while running over a transport layer without such a mechanism, what would be the system behavior? Does it stay in a wrong status forever or is there an alternative to prevent such a case? >> >> >> 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 protected] >> https://www.ietf.org/mailman/listinfo/sigtran >> _______________________________________________ Sigtran mailing list [email protected] https://www.ietf.org/mailman/listinfo/sigtran "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."