This preview shows page 1. Sign up to view the full content.
Unformatted text preview: s question:
how does a node determine its current set of neighbors? The HELLO protocol solves this
The HELLO protocol is simple and is named for the kind of message it uses. Each
node sends a HELLO packet along all its links periodically. The purpose of the HELLO is
to let the nodes at the other end of the links know that the sending node is still alive. As
long as the link is working, these packets will reach. As long as a node hears another’s
HELLO, it presumes that the sending node is still operating correctly. The messages are
periodic because failures could occur at any time, so we need to monitor our neighbors
When should a node remove a node at the other end of a link from its list of neighbors?
If we knew how often the HELLO messages were being sent, then we could wait for a certain amount of time, and remove the node if we don’t hear even one HELLO packet from it
in that time. Of course, because packet losses could prevent a HELLO packet from reaching, the absence of just one (or even a small number) of HELLO packets may not be a sign
that the link or node has failed. Hence, it is best to wait for enough time before deciding
that a node whose HELLO packets we haven’t heard should no longer be a neighbor.
For this approach to work, HELLO packets must be sent at some regularity, such that
the expected number of HELLO packets within the chosen timeout is more or less the
same. We call the mean time between HELLO packet transmissions the HELLO INTERVAL.
In practice, the actual time between these transmissions has small variance; for instance,
one might pick a time drawn randomly from [HELLO INTERVAL - δ , HELLO INTERVAL +
δ ], where δ < HELLO INTERVAL.
When a node doesn’t hear a HELLO packet from a node at the other end of a direct link
for some duration, k · HELLO INTERVAL, it removes that node from its list of neighbors
and considers that link “failed” (the node could have failed, or the link could just be experienced high packet loss, but we assume that it is unusable until we start hearing HELLO
packets once more).
The choice of k is a trade-off between the time it takes to determine a failed link and the
odds of falsely ﬂagging a working link as “failed” by confusing packet loss for a failure (of
course, persistent packet losses that last a long period of time should indeed be considered
a link failure, but the risk here in picking a small k is that if that many successive HELLO
packets are lost, we will consider the link to have failed). In practice, designers pick k
by evaluating the latency before detecting a failure (k · HELLO INTERVAL) with the probability of falsely ﬂagging a link as failed. This probability is k , where is the packet loss
probability on the link, assuming—and this is a big assumption in some networks—that
packet losses are independent and identically distributed. SECTION 19.4. PERIODIC ADVERTISEMENTS 19.4 5 Periodic Advertisements The key idea that al...
View Full Document
- Fall '13