# Link state packet > Mediated Wiki article. Canonical URL: https://mediated.wiki/source/Link_state_packet > Markdown URL: https://mediated.wiki/source/Link_state_packet.md > Source: https://en.wikipedia.org/wiki/Link_state_packet > Source revision: 1326577938 > License: Creative Commons Attribution-ShareAlike 4.0 International (https://creativecommons.org/licenses/by-sa/4.0/) **Link State Packet** (**LSP**) is a packet of information generated by a [network router](/source/Network_router) in a [link state](/source/Link_state) [routing protocol](/source/Routing_protocol) that lists the router's neighbors. Link state packets can be further defined as special datagrams that determine the names of and the cost or distance to any neighboring [routers](/source/Router_(computing)) and associated [networks](/source/Computer_network). They are used to efficiently determine what the new neighbor is, if a link failure occurs, and the cost of changing a link if the need arises. LSPs are queued for transmission, and must time out at about the same time. They must be acknowledged, and can be distributed throughout the network, but cannot use the routing database. ## Developing Link State Packets When Information needed for exchange is collected, a [router](/source/Router_(computing)) then builds a [packet](/source/Packet_(information_technology)) containing all the data. The [packet](/source/Packet_(information_technology)) starts with the identity of the sender, followed by a [sequence number](/source/Sequence_number) and age, and a list of neighbors. For each neighbor, the delay to that neighbor is given. Building a link state packet is usually easy, the complex part is determining when to build them. One way to reduce this problem is to build them periodically, that is, at regular intervals, or when some significant event occurs, such as a line or neighbor going down or coming back up again, or changing its properties appreciatively. A major procedure called [flooding](/source/Flooding_(computer_networking)) which is used for distributing link state algorithms throughout the routing domain can be implemented with link state packets. However, ordinary flooding may result in problems, because it generates exponential behavior. Smart flooding, on the other hand, recognizes link state packets appropriately. ## Types of Link State packets Link state packets are usually implemented with [Open Shortest Path First](/source/Open_Shortest_Path_First) (OSPF) protocol. OSPF's reliable flooding mechanism is implemented by Link State Update and Link State Acknowledgment packets. ### Link state update packet Link State Update packets are [OSPF](/source/OSPF) packet type 4.[1] These packets implement the flooding of link state advertisements. Each Link State Update packet carries a collection of link state advertisements one hop further from its origin. Several [link-state advertisement](/source/Link-state_advertisement) may be included in a single packet. Link State Update packets are [multicast](/source/Multicast) on those physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded advertisements are acknowledged in Link State Acknowledgment packets. If retransmission of certain advertisements is necessary, the retransmitted advertisements are always carried by [unicast](/source/Unicast) Link State Update packets. ### Link state acknowledgment packet Link State Acknowledgment Packets are [OSPF](/source/OSPF) packet type 5.[2] To make the flooding of link state advertisements reliable, flooded advertisements are explicitly acknowledged. This acknowledgment is accomplished through the sending and receiving of Link State Acknowledgment packets. Multiple link state advertisements can be acknowledged in a single Link State Acknowledgment packet. Depending on the state of the sending interface and the source of the advertisements being acknowledged, a Link State Acknowledgment packet is sent either to the [multicast](/source/Multicast) address AllSPFRouters, to the [multicast](/source/Multicast) address AllDRouters, or as a [unicast](/source/Unicast). ## See also - [Link-state routing protocol](/source/Link-state_routing_protocol) - [Flooding algorithm](/source/Flooding_algorithm) - [Computer network](/source/Computer_network) - [Open Shortest Path First](/source/Open_Shortest_Path_First) ## References 1. Moy, John. ["RFC 2328 OSPF Version 2"](https://tools.ietf.org/html/rfc2328). *IETF Request for Comments*. IETF. Retrieved 13 April 2015. 1. Moy, John. ["RFC 2328 OSPF Version 2"](https://tools.ietf.org/html/rfc2328). *IETF Request for Comments*. IETF. Retrieved 13 April 2015. - FireWire system architecture : IEEE 1394a / MindShare, Inc.; Don Anderson Anderson, Don, 1953- Reading, Mass. : Addison-Wesley, c1999 - Routing in communications networks / editor, Martha Steenstrup Englewood Cliffs, NJ : Prentice Hall, 1995 - Radia Perlman “Rbridges: Transparent Routing”, Infocom 2004. --- Adapted from the Wikipedia article [Link state packet](https://en.wikipedia.org/wiki/Link_state_packet) by Wikipedia contributors ([contributor history](https://en.wikipedia.org/wiki/Link_state_packet?action=history)). Available under [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/). Changes may have been made.