Re: [Tsvwg] Re: The requiremntsand proposalsforM2PA/M3UA/SCTPExtension from China Mobile
"Brian F. G. Bidulock" <[email protected]>
| Newsgroups | gmane.ietf.sigtran,gmane.ietf.tsvwg |
|---|---|
| Organization | http://www.openss7.org/ |
| Message-ID | <[email protected]> |
Ronnie, That's interesting. I don't actually do that. I send the HEARTBEAT-ACK to the Source IP in the HEARTBEAT, provided that I have a usable route to that address, I have no retransmissions that were originally sent to that address outstanding, and I have not received duplicate TSNs when SACKs were sent to that destination. Otherwise, I send them to the current primary. --brian [email protected] wrote: (Mon, 30 Jul 2007 04:02:25) > Hi, > > Won't this association have a serious problem with Heartbeats if you > cannot send a Heartbeat Ack to the address the Heartbeat came from? > > >From RFC 2960bis > 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5): > > An endpoint should send this chunk to its peer endpoint as a > response to a HEARTBEAT chunk (see Section 8.3). A HEARTBEAT > ACK is always sent to the source IP address of the IP datagram > containing the HEARTBEAT chunk to which this ack is responding. > > We also need to take into account that the source address of duplicate > data may NOT be the source address used for the original data if the > sending end has changed paths when the data wasn't acked. > > If this is a routing problem which has been in place since the > association was started then the sender should never send data to an > unconfirmed address. If the Heartbeat mechanism is broken the address > will never be confirmed. > > Ronnie > --- > Ronnie Sellar Emerson Network Power, Embedded Computing > Tel: +44 131 475 7015 Suite 4, 2 Anderson Place > Fax: +44 131 475 7001 Edinburgh EH6 5NP > mailto:[email protected] http://www.emersonembeddedcomputing.com > -- Brian F. G. Bidulock [email protected] http://www.openss7.org/