On Mar 14, 2011, at 3:36 AM, Will Yu wrote: > Hello dear Michael, > > Thank you for your reply. There is an additional query about your reply: > In our realization, the remote address is regarded as unreachable until the > Heartbeat Message from TWO different local address(IP1 and IP2) exceed PMR. > It means that IP1 sent 4(PMR value) Heartbeat and IP2 sent 4(PMR value) > Heartbeat as well. In your describing, is this method not accord with RFC? The RFC only talks about an error counter per remote address, not an error counter per local/remote address pair.
However, you should be able to handle a network setup, where no cross routing is possible, so there is only connectivity between IP1 <-> IP3 and IP2 <-> IP4. This is a setup which is often used in SIGTRAN setups. Best regards Michael > > Thanks again. > > Brs, > Will Yu > > 2011/3/12 Michael Tüxen <[email protected]> > > On Mar 11, 2011, at 7:44 AM, Will Yu wrote: > > > Hello, > > > > I have a query on SCTP standard (RFC 4960). In section 8.2 Path Failure > > Detection, it describes the action which end points should take in > > detecting path unavailable. > > > > When its peer endpoint is multi-homed, an endpoint should keep an > > error counter for each of the destination transport addresses of the > > peer endpoint. > > Each time the T3-rtx timer expires on any address, or when a > > HEARTBEAT sent to an idle address is not acknowledged within an RTO, > > the error counter of that destination address will be incremented. > > When the value in the error counter exceeds the protocol parameter > > ’Path.Max.Retrans’ of that destination address, the endpoint should > > mark the destination transport address as inactive, and a > > notification SHOULD be sent to the upper layer. > > > > In my case, I connected two end points through four IP address. EP1 owns > > IP1 and IP2, EP2 owns IP3 and IP4. And IP1 is the primary address for EP1, > > while IP3 is the primary address for EP2. There is no other packet in this > > association except with Heartbeat and Heartbeat_ACK. > > > > IP1--------------------IP3 > > End \ / End > > Point1 * Point2 > > / \ > > IP2--------------------IP4 > > > > When IP4 is unavailable, the heartbeat messages from IP1 and IP2 with the > > destination IP4 cannot received acknowledgement. In this case, PMR in each > > EP is set to 4. I observed that EP1 used IP1 and IP2 as source address to > > send the heartbeat messages to IP4 respectively. When the heartbeat message > > from source address IP2 exceed 4 times, it marked the path(IP2-IP4) is > > unreachable. And then IP1 exceed, it would mark the destination IP4 is > > unavailable. In my opinion, this result is > There is no state for the path IP2-IP4, only for the remote address IP4. > > reasonable with the recognition of IP2-IP4 is a path and IP1-IP4 is another > > path for the association. Consequently, the PMR parameter is for > > determining which PATH could regard as unavailable. > SCTP supervises remote addresses. So EP1 is supervising IP3 and IP4. So there > is one error counter for IP3 > and one for IP4. There is also only a state per remote IP address. So after > the error counter for IP4 > exceeds PMR, the IP address IP4 should be marked as unreachable. > > But in the section 8.2 Path Failure Detection, the increasing counter > > action is based on different destination transport address, not on the > > different source-destination address pair. I think it make me confused that > > counter will impact the result in my case with the assumption RFC regard > > the destination address failure as the critical element for Path Failure > > Detection. > > > > Would you kindly help me clarify the behaviors in Path Failure Detection, > > or figure out if I have any misunderstanding in this case? > As said above, SCTP supervises remote addresses, not paths. > > Best regards > Michael > > PS: It might be better to send SCTP related questions to [email protected] > > > > Brs, > > Will Yu > > _______________________________________________ > > Ietf mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
