The LSA types defined in OSPF are as follows:
The link-state ID of the type 1 LSA is the originating router ID.
Inter-Area-Prefix-LSAs (OSPFv3)
Inter-Area-Router-LSAs (OSPFv3)
At the area border router, selected type-7 LSAs are translated into type 5-LSAs and flooded into the backbone.
Link-local LSAs (OSPFv3)
Intra-Area-Prefix5 (OSPFv3)
The opaque LSAs, types 9, 10, and 11, are designated for upgrades to OSPF for application-specific purposes. For example, OSPF-TE has traffic engineering extensions to be used by RSVP-TE in Multiprotocol Label Switching (MPLS). Opaque LSAs are used to flood link color and bandwidth information. Standard link-state database (LSDB) flooding mechanisms are used for distribution of opaque LSAs. Each of the three types has a different flooding scope.
For all types of LSAs, there are 20-byte LSA headers. One of the fields of the LSA header is the link-state ID.
Each router link is defined as one of four types: type 1, 2, 3, or 4. The LSA includes a link ID field that identifies, by the network number and mask, the object that this link connects to.
Depending on the type, the link ID has different meanings as shown in below table:
As per Appendix-A.3.1 of RFC 2328, all OSPF packets start with a common LSA "24-byte header" as shown below.
For
The Options field is present in:
The option field Indicative the feature supported by the source router. In Hello packet, a mismatch, will result in reject of neighbor. for LSA only packet that matches the destination routes willingness is forward.
Database description messages contain descriptions of the topology of the autonomous system or area. They convey the contents of the link-state database (LSDB) for the area from one router to another. Communicating a large LSDB may require several messages to be sent by having the sending device designated as a master device and sending messages in sequence, with the slave (recipient of the LSDB information) responding with acknowledgments.
Link state request (LSR): Link state request messages are used by one router to request updated information about a portion of the LSDB from another router. The message specifies the link(s) for which the requesting device wants more current information.
Link-state update (LSU) messages contain updated information about the state of certain links on the LSDB. They are sent in response to a link state request message, and also broadcast or multicast by routers on a regular basis. Their contents are used to update the information in the LSDBs of routers that receive them.
Link-state acknowledgment (LSAck)messages provide reliability to the link-state exchange process, by explicitly acknowledging receipt of a Link State Update message. The LSA acknowledgment, explicitly acknowledged, that it have received a LSA, by mirroring it back.
Appendix-A.4.1 of RFC 2328, all LSA packets start with a common LSA "20-byte header" as shown below. Note: These LSA Packet Headers are all preceded by OSPFv2 "24-byte" OSPF Headers.
In 2008, with the introduction of RFC5340 a new standard was set.
As per Appendix A.4.2 of RFC 5340, all LSA packets start with a common LSA "20-byte header" as shown below.
Note: These LSA Packet Headers are all preceded by standard "16-byte" OSPF Headers.
As per Appendix A.4 of RFC 5340 (OSPFv3 for IPv6) depending upon the LS Type, there are nine major LSA Packet formats as follows (actually eight as one has been deprecated):
The nine different formats for each "Type" of LSA packet are listed below (including the deprecated LSA-6):
(Same as Type 5 except for the type number field)
"RFC 5340 – OSPF for IPv6". ietf.org. Retrieved 5 April 2020. http://tools.ietf.org/html/rfc5340 ↩
"RFC 1584 – Multicast Extensions to OSPF". ietf.org. Retrieved 14 August 2015. http://tools.ietf.org/html/rfc1584 ↩
"RFC 5250 – The OSPF Opaque LSA Option". ietf.org. Retrieved 14 August 2015. http://tools.ietf.org/html/rfc5250 ↩