13.5. Sending Link State Acknowledgment packets
Connected: An Internet Encyclopedia
13.5. Sending Link State Acknowledgment packets
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 1583
Up:
13. The Flooding Procedure
Prev: 13.4. Receiving self-originated link state
Next: 13.6. Retransmitting link state advertisements
13.5. Sending Link State Acknowledgment packets
13.5. Sending Link State Acknowledgment packets
Each newly received link state advertisement must be
acknowledged. This is usually done by sending Link State
Acknowledgment packets. However, acknowledgments can also be
accomplished implicitly by sending Link State Update packets
(see step 7a of Section 13).
Many acknowledgments may be grouped together into a single Link
State Acknowledgment packet. Such a packet is sent back out the
interface that has received the advertisements. The packet can
be sent in one of two ways: delayed and sent on an interval
timer, or sent directly (as a unicast) to a particular neighbor.
The particular acknowledgment strategy used depends on the
circumstances surrounding the receipt of the advertisement.
Sending delayed acknowledgments accomplishes several things: it
facilitates the packaging of multiple acknowledgments in a
single Link State Acknowledgment packet; it enables a single
Link State Acknowledgment packet to indicate acknowledgments to
several neighbors at once (through multicasting); and it
randomizes the Link State Acknowledgment packets sent by the
various routers attached to a multi-access network. The fixed
interval between a router's delayed transmissions must be short
(less than RxmtInterval) or needless retransmissions will ensue.
Direct acknowledgments are sent to a particular neighbor in
response to the receipt of duplicate link state advertisements.
These acknowledgments are sent as unicasts, and are sent
immediately when the duplicate is received.
The precise procedure for sending Link State Acknowledgment
packets is described in Table 19. The circumstances surrounding
the receipt of the advertisement are listed in the left column.
The acknowledgment action then taken is listed in one of the two
right columns. This action depends on the state of the
concerned interface; interfaces in state Backup behave
differently from interfaces in all other states. Delayed
acknowledgments must be delivered to all adjacent routers
associated with the interface. On broadcast networks, this is
accomplished by sending the delayed Link State Acknowledgment
packets as multicasts. The Destination IP address used depends
on the state of the interface. If the state is DR or Backup,
the destination AllSPFRouters is used. In other states, the
destination AllDRouters is used. On non-broadcast networks,
delayed Link State Acknowledgment packets must be unicast
separately over each adjacency (i.e., neighbor whose state is >=
Exchange).
The reasoning behind sending the above packets as multicasts is
best explained by an example. Consider the network
configuration depicted in Figure 15. Suppose RT4 has been
elected as Designated Router, and RT3 as Backup Designated
Router for the network N3. When Router RT4 floods a new
advertisement to Network N3, it is received by routers RT1, RT2,
and RT3. These routers will not flood the advertisement back
onto net N3, but they still must ensure that their topological
databases remain synchronized with their adjacent neighbors. So
RT1, RT2, and RT4 are waiting to see an acknowledgment from RT3.
Likewise, RT4 and RT3 are both waiting to see acknowledgments
from RT1 and RT2. This is best achieved by sending the
acknowledgments as multicasts.
The reason that the acknowledgment logic for Backup DRs is
slightly different is because they perform differently during
the flooding of link state advertisements (see Section 13.3,
step 4).
Next: 13.6. Retransmitting link state advertisements
Connected: An Internet Encyclopedia
13.5. Sending Link State Acknowledgment packets
|