RFC 2642
Cabletron's VLS Protocol Specification
Cabletron's VLS Protocol Specification 🎀
Okay bestie, let's start with the title block 💅 This is RFC 2642, written by L. Kane at Cabletron Systems Incorporated. It's dated August 1999 and it's Informational, so it's sharing info, not setting a standard 🦋 The header doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC.
Status of this Memo 📜
This memo gives info to the Internet community. It is not an Internet standard of any kind. Distribution is unlimited 🌸
Copyright Notice ©️
Copyright (C) The Internet Society (1999). All Rights Reserved. 💜
Abstract ✨
So the Virtual LAN Link State Protocol (VLSP) is part of the InterSwitch Message Protocol (ISMP). It handles interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product 🔥 VLSP figures out and keeps a fully connected mesh topology graph of the switch fabric. Every switch keeps an identical database describing that topology. When a call-originating switch needs to route a call connection, it checks the topology database to pick the path 👑
VLSP also supports equal-cost multipath routing, and it recalculates routes super fast when the topology changes, all while using a minimum of routing protocol traffic 🧚
Table of Contents 📚
1. Introduction............................................ 3
1.1 Acknowledgments..................................... 3
1.2 Data Conventions.................................... 3
1.3 ISMP Overview....................................... 4
2. VLS Protocol Overview................................... 5
2.1 Definitions of Commonly Used Terms.................. 6
2.2 Differences Between VLSP and OSPF................... 7
2.2.1 Operation at the Physical Layer............... 8
2.2.2 All Links Treated as Point-to-Point........... 8
2.2.3 Routing Path Information...................... 9
2.2.4 Configurable Parameters....................... 9
2.2.5 Features Not supported........................ 9
2.3 Functional Summary.................................. 10
2.4 Protocol Packets.................................... 11
2.5 Protocol Data Structures............................ 12
2.6 Basic Implementation Requirements................... 12
2.7 Organization of the Remainder of This Document...... 13
3. Interface Data Structure................................ 14
3.1 Interface States.................................... 16
3.2 Events Causing Interface State Changes.............. 18
3.3 Interface State Machine............................. 21
4. Neighbor Data Structure................................. 23
4.1 Neighbor States..................................... 25
4.2 Events Causing Neighbor State Changes............... 27
4.3 Neighbor State Machine.............................. 29
5. Area Data Structure..................................... 33
5.1 Adding and Deleting Link State Advertisements....... 34
5.2 Accessing Link State Advertisements................. 35
5.3 Best Path Lookup.................................... 35
6. Discovery Process....................................... 35
6.1 Neighbor Discovery.................................. 36
6.2 Bidirectional Communication......................... 37
6.3 Designated Switch................................... 38
6.3.1 Selecting the Designated Switch............... 39
6.4 Adjacencies......................................... 41
7. Synchronizing the Databases............................. 42
7.1 Link State Advertisements........................... 43
7.1.1 Determining Which
Link State Advertisement Is Newer............. 44
7.2 Database Exchange Process........................... 44
7.2.1 Database Description Packets.................. 44
7.2.2 Negotiating the Master/Slave Relationship..... 45
7.2.3 Exchanging Database Description Packets....... 46
7.3 Updating the Database............................... 48
7.4 An Example.......................................... 49
8. Maintaining the Databases............................... 51
8.1 Originating Link State Advertisements............... 52
8.1.1 Switch Link Advertisements.................... 52
8.1.2 Network Link Advertisements................... 55
8.2 Distributing Link State Advertisements.............. 56
8.2.1 Overview...................................... 57
8.2.2 Processing an
Incoming Link State Update Packet............. 58
8.2.3 Forwarding Link State Advertisements.......... 60
8.2.4 Installing Link
State Advertisements in the Database.......... 62
8.2.5 Retransmitting Link State Advertisements...... 63
8.2.6 Acknowledging Link State Advertisements....... 64
8.3 Aging the Link State Database....................... 66
8.3.1 Premature Aging of Advertisements............. 66
9. Calculating the Best Paths.............................. 67
10. Protocol Packets........................................ 67
10.1 ISMP Packet Format................................. 68
10.1.1 Frame Header................................ 69
10.1.2 ISMP Packet Header.......................... 70
10.1.3 ISMP Message Body........................... 71
10.2 VLSP Packet Processing............................. 71
10.3 Network Layer Address Information.................. 72
10.4 VLSP Packet Header................................. 73
10.5 Options Field...................................... 75
10.6 Packet Formats..................................... 76
10.6.1 Hello Packets............................... 76
10.6.2 Database Description Packets................ 78
10.6.3 Link State Request Packets.................. 80
10.6.4 Link State Update Packets................... 82
10.6.5 Link State Acknowledgment Packets........... 83
11. Link State Advertisement Formats........................ 84
11.1 Link State Advertisement Headers................... 84
11.2 Switch Link Advertisements......................... 86
11.3 Network Link Advertisements........................ 89
12. Protocol Parameters..................................... 89
12.1 Architectural Constants............................ 90
12.2 Configurable Parameters............................ 91
13. End Notes............................................... 93
14. Security Considerations................................. 94
15. References.............................................. 94
16. Author's Address........................................ 94
17. Full Copyright Statement................................ 951. Introduction ✨
This memo is going out to the Internet community so people can react to the proposals in it 🫶 The spec here might not be directly relevant to the Internet's research problems, but researchers and implementers might find it interesting 👀
1.1 Acknowledgments 🙏
VLSP is derived from the OSPF link-state routing protocol described in [RFC2328], which was written by John Moy, formerly of Proteon, Inc., in Westborough, Massachusetts. A lot of this memo was drawn from [RFC2328], so the author wants to thank Mr. Moy for his contribution, even though he didn't know he was contributing 💖
1.2 Data Conventions 🔢
The way this memo describes and pictures data follows the Internet Protocol documentation standards in [RFC1700], and there are a few big rules:
- Numbers are written in decimal, and data is pictured in "big-endian" order. So fields go left to right, with the most significant octet on the left and the least significant on the right. Order of transmission is figured out down to the octet level, and when a diagram shows a group of octets, you send them in the normal order you'd read them in English.
- When an octet holds a numeric value, the leftmost bit in the diagram is the high-order (most significant) bit. The bit labeled 0 is the most significant bit 🧠
- Same idea for multi-octet fields: the leftmost bit of the whole field is the most significant bit. When a multi-octet quantity is sent, the most significant octet goes out first 🚀
1.3 ISMP Overview 🌐
The InterSwitch Message Protocol (ISMP) gives you one consistent way to wrap up and send control messages between switches running Cabletron's SecureFast VLAN (SFVLAN) product, as described in [IDsfvlan]. ISMP offers these services:
- Topology services. Each switch keeps a distributed topology of the switch fabric by swapping these interswitch control messages with other switches:
- Interswitch Keepalive messages are sent by each switch to say "hi, I exist" to its neighbors and to build the topology of the switch fabric. (Interswitch Keepalive messages follow Cabletron's VlanHello protocol, described in [IDhello].)
- Interswitch Spanning Tree BPDU messages and Interswitch Remote Blocking messages are used to find and keep a loop-free flood path between all the network switches in the fabric. This flood path is used for all undirected interswitch messages -- that is, messages that are (potentially) sent to all switches in the switch fabric.
- Interswitch Link State messages (VLS protocol) are used to find and keep a fully connected mesh topology graph of the switch fabric. Call-originating switches use that topology graph to pick the path for routing a call connection 🛣️
- Address resolution services. Interswitch Resolve messages resolve a packet destination address when the packet source and destination pair doesn't match a known connection. Interswitch New User messages give end-station address mobility between switches 📱
- Tag-based flooding. A tag-based broadcast method limits the broadcast of unresolved packets to only the ports in the fabric that belong to the same VLAN as the source 🏷️
- Call tapping services. Interswitch Tap messages monitor traffic moving between two end stations. Traffic can be monitored in one direction or both along the connection path 👀
Note: Older versions of VLSP treated all links as broadcast (multi-access). So if VLSP finds out a neighbor switch is running an older version of the protocol software (see Section 6.1), it changes the interface type to broadcast and starts exchanging Hello packets with that single neighbor switch 🦋
2. VLS Protocol Overview ✨
okay bestie, VLSP is a dynamic routing protocol 🦋 It quickly notices when the topology of the switch fabric changes (like when a switch interface fails) and then works out new loop-free routes after a short period of convergence. That convergence period is quick and involves a minimum of routing traffic, so it's giving efficiency 💅
All switches in the fabric run the same algorithm and keep identical databases describing the fabric's topology 🌸 That database holds each switch's local state, including its usable interfaces and reachable neighbors. Each switch shares its local state with everyone by flooding it through the fabric 📣 Then, from that topological database, each switch builds a set of best path trees (with itself as the root) that spell out routes to every other switch in the fabric. iconic, honestly 👑
2.1 Definitions of Commonly Used Terms
this section is a little glossary of terms that have a specific meaning for the protocol and get used all over the text, so let's get them straight 🎀
Switch ID
A 10-octet value that uniquely identifies the switch within the switch fabric. It's made up of the 6-octet base MAC address of the switch, followed by 4 octets of zeroes 🧚
Network link
The physical connection between two switches. A link is associated with a switch interface.
There are two physical types of network links supported by VLSP:
- Point-to-point links that join a single pair of switches. A serial line is an example of a point-to-point network link.
- Multi-access broadcast links that support the attachment of multiple switches, along with the capability to address a single message to all the attached switches. An attached ethernet is an example of a multi-access broadcast network link.
A single topology can contain both types of links 🌈 At startup, all links are assumed to be point-to-point. A link is determined to be multi-access when more than one neighboring switch is discovered on the link. plot twist energy 😭
Interface
The port over which a switch accesses one of its links. Interfaces are identified by their interface ID, a 10-octet value consisting of the 6-octet base MAC address of the switch, followed by the 4-octet local port number of the interface 🍓
Neighboring switches
Two switches attached to a common link. ✨
Adjacency
A relationship formed between selected neighboring switches for the purpose of exchanging routing information. Not every pair of neighboring switches become adjacent. not every pair gets to be besties, and that's okay 🫶
Link state advertisement
Describes the local state of a switch or a link. Each link state advertisement is flooded throughout the switch fabric. The collected link state advertisements of all switches and links form the protocol's topological database 💜
Designated switch
Each multi-access network link has a designated switch. The designated switch generates a link state advertisement for the link and has other special responsibilities in the running of the protocol. main character of the link, ngl 👑
The use of a designated switch permits a reduction in the number of adjacencies required on multi-access links. This in turn reduces the amount of routing protocol traffic and the size of the topological database 💅
The designated switch is selected during the discovery process. A designated switch is not selected for a point-to-point network link.
Backup designated switch
Each multi-access network link has a backup designated switch. The backup designated switch maintains adjacencies with the same switches on the link as the designated switch. This optimizes the failover time when the backup designated switch must take over for the (failed) designated switch. it's the understudy who is always ready to slay the moment someone drops out 🎀
The backup designated switch is selected during the Discovery process. A backup designated switch is not selected for a point-to-point network link.
2.2 Differences Between VLSP and OSPF
okay so the VLS protocol is derived from the OSPF link-state routing protocol described in [RFC2328]. it's like OSPF's cooler sibling who moved to a new neighborhood 🦋
2.2.1 Operation at the Physical Layer
the main differences between VLS and OSPF come from the fact that OSPF runs over the IP layer, while VLSP runs at the physical MAC layer. this has the following repercussions:
- VLSP does not support features (such as fragmentation) that are typically provided by network layer service providers. no fragmentation drama here 💀
- Due to the unrelated nature of MAC address assignments, VLSP provides no summarization of the address space (such as, classical IP subnet information) or level 2 routing (such as, IS-IS Phase V DECnet). Thus, VLSP does not support grouping switches into areas. All switches exist in a single area. Since a single domain exists within any switch fabric, there is no need for VLSP to provide interdomain reachability. one squad, one area, no cliques 🌸
- As mentioned in Section 10.1.1, ISMP uses a single well-known multicast address for all packets. However, parts of the VLS protocol (as derived from OSPF) are dependent on certain network layer addresses -- in particular, the
AllSPFSwitchesandAllDSwitchesmulticast addresses that drive the distribution of link state advertisements throughout the switch fabric. In order to facilitate the implementation of the protocol at the physical MAC layer, network layer address information is encapsulated in the protocol packets (see Section 10.3). This information is unbundled and packets are then processed as if they had been sent or received on that multicast address. it's giving wrapped-up-in-a-bow energy, ngl 🎁
2.2.2 All Links Treated as Point-to-Point
when the switch first comes online, VLSP assumes all network links are point-to-point and that no more than one neighboring switch will be discovered on any one port 🧚 So at startup, VLSP does not send its own Hello packets over its network ports. Instead, it relies on the VlanHello protocol [IDhello] to discover its neighbor switches. If a second neighbor is detected on a link, the link is then deemed multi-access and the interface type is changed to broadcast. At that point, VLSP exchanges its own Hello packets with the switches on the link in order to select a designated switch and designated backup switch for the link 🫶
This method eliminates unnecessary duplication of message traffic and processing, thereby increasing the overall efficiency of the switch fabric. efficiency era, periodt ✨
Note: Previous versions of VLSP treated all links as if they were broadcast (multi-access). Thus, if VLSP determines that a neighbor switch is running an older version of the protocol software (see Section 6.1), it will change the interface type to broadcast and begin exchanging Hello packets with the single neighbor switch. 🙈
2.2.3 Routing Path Information
instead of providing the next hop to a destination, VLSP calculates and maintains complete end-to-end path information. On request, a list of individual port identifiers is generated describing a complete path from the source switch to the destination switch. If multiple equal-cost routes exist to a destination switch, up to three paths are calculated and returned. three paths?! that's a whole lineup 💅🔥
2.2.4 Configurable Parameters
OSPF supports (and requires) configurable parameters. In fact, even the default OSPF configuration requires that IP address assignments be specified. On the other hand, no configuration information is ever required for the VLS protocol. Switches are uniquely identified by their base MAC addresses and ports are uniquely identified by the base MAC address of the switch and a port number. zero setup, full vibes 🌈
While a developer is free to implement configurable parameters for the VLS protocol, the current version of VLSP supports configurable path metrics only. Note that this has the following repercussions:
- All switches are assigned a switch priority of 1. This forces the selection of the designated switch to be based solely on base MAC address. no drama, the MAC address decides 💜
- Authentication is not supported. 💀
2.2.5 Features Not supported
in addition to the features mentioned in the previous sections, the following OSPF features are not supported by the current version of VLSP:
- Periodic refresh of link state advertisements. (This optimizes performance by eliminating unnecessary traffic between the switches.) no spam, just vibes 🦋
- Routing based on non-zero type of service (TOS).
- Use of external routing information for destinations outside the switch fabric. the fabric keeps its own business in its own lane 🎀
2.3 Functional Summary
okay, there are essentially four operational stages of the VLS protocol, and I'm obsessed with how they flow together 🌸
- Discovery Process The discovery process involves two steps:
- Neighboring switches are detected by the VlanHello protocol [IDhello], which then notifies VLSP of the neighbor.
- If more than one neighbor switch is detected on a single port, the link is determined to be multi-access. VLSP then sends its own Hello packets over the link in order to discover the full set of neighbors on the link and select a designated switch and designated backup switch for the link. Note that this selection process is unnecessary on point-to-point links.
The discovery process is described in more detail in Section 6. 🔍
- Synchronizing the Databases
Adjacencies are used to simplify and speed up the process of synchronizing the topological database (also known as the link state database) maintained by each switch in the fabric. Each switch is only required to synchronize its database with those neighbors to which it is adjacent. This reduces the amount of routing protocol traffic across the fabric, particularly for multi-access links with multiple switches. group chats are better when you don't text everyone 💬
The process of synchronizing the databases is described in more detail in Section 7. ✨
- Maintaining the Databases
Each switch advertises its state (also known as its link state) any time its link state changes. Link state advertisements are distributed throughout the switch fabric using a reliable flooding algorithm that ensures that all switches in the fabric are notified of any link state changes. no one gets left on read 🫶
The process of maintaining the databases is described in more detail in Section 8. 🌈
- Calculating the Best Paths
The link state database consists of the collection of link state advertisements received from each switch. Each switch uses its link state database to calculate a set of best paths, using itself as root, to all other switches in the fabric. the grand finale of the whole routing saga 👑
The process of recalculating the set of best paths is described in more detail in Section 9. 💖
2.4 Protocol Packets ✨
okay so bestie, every VLS protocol packet wears the same outfit 👗. On top of the frame header and the ISMP packet header from Section 10.1, they all share a common protocol header, which is in Section 10.4. 💅
The VLSP packet types are in Table 1 below, and their formats are in Section 10.6 🎀
Type Packet Name Protocol Function
1 Hello Select DS and Backup DS
2 Database Description Summarize database contents
3 Link State Request Database download
4 Link State Update Database update
5 Link State Ack Flooding acknowledgment
Table 1: VLSP Packet TypesHello packets pick the designated switch and the backup designated switch on multi-access links 🌸 Database Description and Link State Request packets are the ones that form adjacencies 🤝 and Link State Update and Link State Acknowledgment packets keep the topological database up to date 🦋
Each Link State Update packet carries a set of link state advertisements, and one packet can hold advertisements from several switches at once 📦 There are two types of link state advertisement, shown in Table 2 🌈
LS Advertisement Advertisement Description
Type Name
1 Switch link Originated by all switches. This
advertisements advertisement describes the collected
states of the switch's interfaces.
2 Network link Originated by the designated switch.
advertisements This advertisement contains the list
of switches connected to the network
link.
Table 2: VLSP Link State Advertisements2.5 Protocol Data Structures 🧠
so VLS is described in this spec by how it operates on different protocol data structures 🔥 Table 3 lists the main VLSP ones and tells you which section goes into each in detail 👑
Structure Name Description
Interface Data Structure Section 3
Neighbor Data Structure Section 4
Area Data Structure Section 5
Table 3: VLSP Data Structures2.6 Basic Implementation Requirements 🛠️
to implement VLS, your system needs these pieces of support:
Timers ⏰
we need two kinds of timer 💖 The first is a one-shot timer, which goes off exactly once and triggers an event. The second is an interval timer, which goes off again and again at set intervals, perfect for anything periodic ✨ The granularity of both is one second.
Interval timers should be implemented so they avoid drift. Packet processing can mess with timer execution on some switches, and on a multi-access link with lots of switches, regular broadcasts can lead to really unwanted synchronization of routing packets unless the interval timers avoid drift 😭 If drift-free timers aren't possible, then small random amounts of time should be added to or subtracted from the timer interval each time it fires 🎲
List manipulation primitives 📝
a lot of VLSP is described in terms of working with lists of link state advertisements 🫶 One advertisement can sit on lots of these lists at once. So an implementation of VLSP must be able to manipulate these lists, adding and deleting advertisements whenever it needs to 💅
Tasking support 🧚
some procedures in this spec call other procedures 🌀 Sometimes those other procedures should run in-line, meaning before the current procedure finishes. The text says to "execute" a procedure for that. Other times they should only run after the current procedure is done, and the text says to "schedule" a task for that 📅 An implementation of VLSP must support both kinds of tasking ✨
2.7 Organization of the Remainder of This Document 🗺️
the rest of the doc is laid out like this:
- Section 3 through Section 5 cover the main data structures the protocol uses. The spec explains things in terms of these structures so it's more precise. Implementations must support the functionality described, but they don't need to use the exact data structures that show up in this spec 💜
- Section 6 through Section 9 cover the four operational stages of the protocol: the discovery process, synchronizing the databases, maintaining the databases, and calculating the set of best paths 🌟
- Section 10 covers how VLSP packets are processed and gives detailed descriptions of their formats 📦
- Section 11 gives detailed descriptions of link state advertisements 🦋
- Section 12 sums up the protocol parameters 🎀
3. Interface Data Structure 🔌
okay the port a switch uses to access a network link is called the link interface 🔌 Each switch keeps a separate interface data structure for every network link it has 💕
each interface has these data items associated with it:
Type
this is the type of network the interface is attached to: point-to-point or broadcast (multi-access) 🌈 It gets set to point-to-point when the interface becomes operational. If a second neighbor shows up on the link after the first one was discovered, the interface type flips to broadcast. It stays broadcast until the interface is declared down, and then it goes back to point-to-point 🔄
Note: Previous versions of VLSP treated all links as if they were multi-access. So if VLSP finds out a neighbor switch is running an older version of the protocol software (see Section 6.1), it will change the interface type to broadcast 🙈
State
this is the functional level of the interface 💫 The interface state gets included in every switch link advertisement the switch generates, and it's also used to decide whether full adjacencies are allowed on the interface. See Section 3.1 for the full list of interface states 👑
Interface identifier
this is a 10-octet value that uniquely identifies the interface 🔑 It's made of the 6-octet base MAC address of the neighbor switch, followed by the 4-octet local port number of the interface 🧩
Area ID
this is a 4-octet value that identifies the area 🗺️ VLSP doesn't support multiple areas, so this value is always zero 0️⃣
HelloInterval
this is the interval, in seconds, at which the switch sends VLSP Hello packets over the interface ⏱️ This parameter isn't used on point-to-point links 🚫
SwitchDeadInterval
this is how long, in seconds, neighboring switches will wait before they declare the local switch down 💀
Neighboring switches
this is a list of the neighboring switches attached to this network link 👯 The list gets created during the discovery process. Adjacencies are formed to one or more of these neighbors. You can figure out the set of adjacent neighbors by checking the states of the neighboring switches in their link state advertisements 🕵️♀️
Designated switch
this is the designated switch selected for the multi-access network link 👑 (A designated switch isn't selected for a point-to-point link.) This data item gets set to zero when the switch comes online, which means no designated switch has been chosen for the link yet 🌱
Backup designated switch
this is the backup designated switch selected for the multi-access network link 🥈 (A backup designated switch isn't selected for a point-to-point link.) It also gets set to zero when the switch comes online, meaning no backup designated switch has been picked for the link yet 🌱
Interface output cost(s)
this is the cost of sending a packet over the interface 💸 The link cost is expressed in the link state metric and must be greater than zero 📏
RxmtInterval
this is the number of seconds between link state advertisement retransmissions for adjacencies that belong to this interface 🔁 This value is also used to time the retransmission of Database Description and Link State Request packets ⏳
3.1 Interface States ✨
okay bestie, this section is all about the different states a switch interface can be in 🦋 they're listed in order of progressing functionality, so the inoperative one comes first, then the intermediate states it passes through, and the final fully functional one comes last. the spec actually relies on this ordering with stuff like "those interfaces in state greater than X" 🧚
Figure 1 is the interface state machine, showing how the states change. the arrows are the events that cause each change 💅 those events are in Section 3.2, and the full state machine is described in Section 3.3 🌸
Down
this is the starting state 🌈 the interface is unusable, and no protocol traffic is sent or received on it. the interface parameters get set to their initial values, all interface timers are disabled, and no adjacencies are associated with the interface 💀
+-------+
| any | Interface +----------+ Unloop Ind +----------+
| state | -----------> | Down | <----------- | Loopback |
+-------+ Down +----------+ +----------+
| ^
| Interface Up |
+-------+ [pt-to-pt] | |
| Point |<------------type? Loop Ind |
| to | | |
| Point | | [broadcast] |
+-------+ V +-------+
+-----------+ | any |
| Waiting | | state |
+-----------+ +-------+
|
Backup Seen |
| Wait Timer
|
|
+----------+ Neighbor V Neighbor +----------+
| DS | <------------> [ ] <------------> | DS Other |
+----------+ Change ^ Change +----------+
|
|
Neighbor Change |
|
V
+----------+
| Backup |
+----------+Figure 1: Interface State Machine
Loopback
in this state, the switch interface is looped back, either in hardware or in software 🔁 it's unavailable for regular data traffic, so no main character moments here 🙈
Point-to-Point
this one is giving operational 🔥 the interface is up and connected to a physical point-to-point link. the second it enters this state, the switch tries to form an adjacency with the neighboring switch 🫶
Waiting
in this state the switch is trying to figure out who the backup designated switch is for the link, by watching the Hello packets it receives 👀 it does NOT try to pick a designated switch or a backup designated switch until it leaves this state. that's the whole point, it stops unnecessary changes to the DS and its backup 💖
DS Other
operational again ✨ this time the interface is connected to a multi-access broadcast link where other switches were already picked as the designated switch and the backup designated switch. the moment it enters this state, the switch tries to form adjacencies with both of them 🧚♀️
Backup
in this state, the switch itself is the backup designated switch on the attached multi-access broadcast link 👑 if the current designated switch fails, this switch gets promoted to designated switch. it establishes adjacencies with all the other switches on the link. (See Section 6.3 for more on the functions the backup designated switch performs.) 🌈
DS
this is the big-girl energy state 💅 the switch itself is the designated switch on the attached multi-access broadcast link. it establishes adjacencies with all the other switches on the link, and it's responsible for originating network link advertisements for the link. those advertisements contain link information for every switch attached to the link, including the designated switch itself 🍓 (See Section 6.3 for more on the functions the designated switch performs.)
3.2 Events Causing Interface State Changes 🦋
the state of an interface changes because of an interface event, and this section explains what those events are 🌸
the events show up as arrows in Figure 1, the graphic version of the interface state machine. for more on that state machine, check out Section 3.3 💜
Interface Up
this event gets generated by the VlanHello protocol [IDhello] when it discovers a neighbor switch on the interface ✨ the interface is now operational, and this event kicks the interface out of the Down state. which state it enters next depends on the interface type 🎀 if the interface type is broadcast (multi-access), this event also makes the switch start sending periodic Hello packets out over the interface 📡
Wait Timer
this event gets generated when the one-shot Wait timer goes off 🔔 that means the required waiting period is over, and the switch can finally start picking a designated switch and a backup designated switch on a multi-access link 🫶
Backup Seen
this event gets generated when the switch has figured out whether or not a backup designated switch exists for the link 🕵️♀️ it can find out in one of two ways:
- a Hello packet came in from a neighbor that claims to be the backup designated switch.
- a Hello packet came in from a neighbor that claims to be the designated switch, and that packet said there is no backup.
either way, the interface must have bidirectional communication with its neighbor. that means the local switch has to be listed in the neighbor's Hello packet 🤝
this event signals the end of the Waiting state 🏁
Neighbor change
this event gets generated when one of the following changes happens in the set of bidirectional neighbors tied to the interface 🌊 (See Section 4.1 for info on neighbor states.)
- bidirectional communication has been established with a neighbor, so the neighbor's state went to 2-Way or higher 🥳
- bidirectional communication with a neighbor got lost, so the neighbor's state dropped to Init or lower 💔
- a bidirectional neighbor just declared itself to be the designated switch or the backup designated switch, which the switch can tell from that neighbor's Hello packets 👑
- a bidirectional neighbor stopped declaring itself to be the designated switch or the backup designated switch, again based on its Hello packets 🙃
- the advertised switch priority of a bidirectional neighbor changed, which also shows up in its Hello packets 🎭
when this event happens, the designated switch and the backup designated switch must be reselected 🔄
Loop Ind
this event gets generated when an interface enters the Loopback state 🔁 it can come from either the network management service or the lower-level protocols.
Unloop Ind
this one is the opposite vibe: it gets generated when an interface leaves the Loopback state ✨ again, it can come from either the network management service or the lower-level protocols.
Interface Down
this event gets generated in two situations 💀
- the VlanHello [IDhello] protocol has determined that the interface is no longer functional.
- the neighbor state machine has detected a second neighboring switch on a link that was presumed to be point-to-point. on top of generating the Interface Down event, the neighbor state machine also changes the interface type to broadcast 🌸
in both cases, this event forces the interface state to Down. BUT (and this is the tea 🫖) when the neighbor state machine is the one that generated it, the Interface Up event comes right after it. (See Section 4.3.) 🎀
3.3. Interface State Machine ✨
okay so this section is the full interface state machine, bestie 🫶 Interface states (see Section 3.1) change because of all kinds of events (see Section 3.2), but the same event can do different things depending on what state the interface is already in 🤔 So the machine is organized by current state AND event. For each state/event pair, you get the new state plus the processing you're supposed to do.
Also, when an interface changes state, you may need to originate a new switch link advertisement 📣 see Section 8.1 for that.
Some of the processing here generates events for the neighbor state machine too. For example, when an interface goes inoperative, every neighbor connection tied to it must be destroyed 💀 (more on the neighbor state machine in Section 4.3).
Down + Interface Up 🌸
- New state: Depends on action routine
- Action: If the interface is a point-to-point link, set the interface state to
Point-to-Point. Otherwise, start the Hello interval timer, which enables periodic sending of Hello packets over the interface. If the switch is not eligible to become the designated switch, change the interface state toDS Other. Otherwise, set the interface state toWaitingand start the one-shot wait timer. Then create a new neighbor data structure for the neighbor switch, initialize all neighbor parameters, and set the state of the neighbor toDown🦋
Waiting + Backup Seen 🎀
- New state: Depends on action routine
- Action: Select the designated switch and backup designated switch for the attached link, as described in Section 6.3.1. As a result of that selection, set the new state of the interface to either
DS Other,BackuporDS✨
Waiting + Wait Timer ⏰
- New state: Depends on action routine
- Action: Same vibe as above! Select the designated switch and backup designated switch for the attached link (Section 6.3.1), then set the interface to either
DS Other,BackuporDSbased on that selection 💅
DS Other, Backup or DS + Neighbor Change 🔄
- New state: Depends on action routine
- Action: Reselect the designated switch and backup designated switch for the attached link, as described in Section 6.3.1. As a result of this selection, set the new state of the interface to either
DS Other,BackuporDS👑
Any State + Interface Down 🚫
- New state:
Down - Action: Reset all variables in the interface data structure and disable all timers. Then destroy all neighbor connections tied to the interface by generating the
KillNbrevent on every neighbor listed in the interface data structure 💀
Any State + Loop Ind 🔁
- New state:
Loopback - Action: Same reset as above! Reset all variables in the interface data structure, disable all timers, and destroy all neighbor connections tied to the interface by generating the
KillNbrevent on every neighbor listed in the interface data structure 🙈
Loopback + Unloop Ind 🦋
- New state:
Down - Action: Nothing else needed beyond switching the interface state to
Down, because the interface was already reset when it entered theLoopbackstate 🫧
4. Neighbor Data Structure ✨
okay so every switch holds a conversation with each of its neighboring switches, and each conversation gets its own neighbor data structure 🗣️ A conversation is tied to a switch interface and identified by the neighboring switch ID 🆔
Here's a fun one: if two switches share multiple attached links, you get multiple conversations, and each one has its own unique neighbor data structure. Each separate conversation is treated as a separate neighbor 👯
The neighbor data structure holds everything relevant to any adjacency formed between the two neighbors. Just remember that not every neighbor becomes adjacent 🫶 An adjacency is basically a highly developed conversation between two switches, so it's a lot more than just saying hi 💖
Here are the fields, bestie 💅
- State: The functional level of the neighbor conversation. See Section 4.1 for a complete description of neighbor states 🌈
- Inactivity timer: A one-shot timer used to decide when to declare the neighbor down if no Hello packet is received from this (multi-access) neighbor. Its length is
SwitchDeadIntervalseconds, as contained in the neighbor's Hello packet. This timer is not used on point-to-point links 🕰️ - Master/slave flag: A flag saying whether the local switch acts as the master or the slave in the database exchange process (see Section 7.2). The master/slave relationship is negotiated when the conversation changes to the
ExStartstate 🤝 - Sequence number: A 4-octet number that identifies individual Database Description packets. When the neighbor state
ExStartis entered and the database exchange process starts, the sequence number is set to a value not previously seen by the neighboring switch. (One possible scheme is to use the switch's time of day counter 🕐.) After that, the master increments it with each new Database Description packet sent. See Section 7.2 for more on the database exchange process 🔢 - Neighbor ID: The switch ID of the neighboring switch, either discovered by the VlanHello protocol [IDhello] or contained in the neighbor's Hello packets 🪪
- Neighbor priority: The switch priority of the neighboring switch, as contained in the neighbor's Hello packets. Switch priorities are used when selecting the designated switch for the attached multi-access link. Priority is not used on point-to-point links 🥇
- Interface identifier: A 10-octet value that uniquely identifies the interface over which this conversation is held. It's made of the 6-octet base MAC address of the neighbor switch, followed by the 4-octet local port number of the interface 🧩
- Neighbor's designated switch: The switch ID identifying the neighbor's idea of the designated switch, as contained in the neighbor's Hello packets. This value is used in the local selection of the designated switch. It is not used on point-to-point links 👑
- Neighbor's backup designated switch: The switch ID identifying the neighbor's idea of the backup designated switch, as contained in the neighbor's Hello packets. This value is used in the local selection of the backup designated switch. It is not used on point-to-point links ✨
- Link state retransmission list: The list of link state advertisements that have been forwarded over this adjacency but not yet acknowledged. The local switch retransmits these at periodic intervals until they're acknowledged or until the adjacency is destroyed. (For more on retransmitting link state advertisements, see Section 8.2.5.) 🔁
- Database summary list: The set of link state advertisement headers that summarize the local link state database. When the conversation changes to the
Exchangestate, this list is sent to the neighbor via Database Description packets. (For more on database synchronization, see Section 7.) 📋 - Link state request list: The list of link state advertisements that must be received in order to synchronize with the neighbor switch's link state database. This list is built as Database Description packets come in, and then it's sent to the neighbor in Link State Request packets. (For more on database synchronization, see Section 7.) 📨
4.1 Neighbor States ✨
okay so this section is the rundown of every stage a conversation with a neighbor switch can be in 💬 they're listed in order of progressing functionality, so you start at the bottom (totally broken) and climb up to the fully working one 🧗♀️. That ordering is actually how the spec talks about groups, like "those neighbors/adjacencies in state greater than X" 🙈
Figure 2 is the neighbor state machine. The arrows are the events that trigger each state change (those get explained in Section 4.2), and the full detailed walkthrough lives in Section 4.3 🦋
Down
Bestie, this is the starting point 🌱 every neighbor conversation begins here.
Init
Here the neighbor has been found, but the two switches can't hear each other both ways yet 📡 every neighbor in this state or higher gets listed in the VLS Hello packets the local switch sends out over the matching (multi-access) interface.
+----------+ KillNbr, LLDown, +-----------+
| Down | <--------------------- | any state |
+----------+ or Inactivity Timer +-----------+
|
Hello |
Rcvd |
|
V
+-----< [pt-to-pt?]
| yes |
| | no
| V
| +----------+ 1-Way +----------+
| | Init | <-------- | >= 2-way |
| +----------+ +----------+
| |
| 2-Way |
| Rcvd | +-------+ AdjOK? +------------+
| +----------------> | 2-Way | <------- | >= ExStart |
| | (no adjacency) +-------+ no +------------+
| |
| V
| +---------+ Seq Number Mismatch +-------------+
+----> | ExStart | <--------------------- | >= Exchange |
+---------+ or BadLSReq +-------------+
|
Negotiation |
Done |
V
+----------+
| Exchange |
+----------+
|
Exchange | +--------+
Done +----------------------> | Full |
| (request list empty) +--------+
| ^
V |
+---------+ Loading Done |
| Loading | ----------------------->
+---------+
Figure 2: Neighbor State Machine2-Way
This is the bidirectional glow-up 💖 both switches can hear each other now, and it's the highest state you can reach before actually starting to build an adjacency. On a multi-access link, the designated switch and the backup designated switch get picked from the neighbors in 2-Way or higher 👑
ExStart
Now the two switches are really getting serious 💍 they're working out which one is the master, plus the starting sequence number for the Database Descriptor packets. Neighbor conversations in this state or higher are called adjacencies 🫶
Exchange
Here the switches swap Database Description packets 📦 (Section 7.2 has the full play-by-play). Every adjacency in Exchange or higher gets used by the distribution procedure (Section 8.2), and they can send and receive every type of VLSP routing packet 🚀
Loading
The local switch is asking the neighbor for the newer advertisements it spotted during Exchange, using Link State Request packets 🔍
Full
Fully adjacent, no cap 🎀 these adjacencies now show up in the switch link and network link advertisements made for the link. Iconic ✨
4.2 Events Causing Neighbor State Changes 💅
okay so the neighbor conversation's state changes because of neighbor events, and this section is the list of those events 📋 you can spot them as arrows in Figure 2, and more info on the state machine is in Section 4.3 🦋
Hello Received
This one fires when a Hello packet shows up from a neighbor 👋
2-Way Received
This fires when the local switch spots its own switch ID inside the neighbor's Hello packet. That means the two switches can hear each other both ways now 🙌
Negotiation Done
This fires once the master/slave relationship has been sorted out and the initial packet sequence numbers have been swapped 🤝 it kicks off the database exchange process (Section 7.2).
Exchange Done
This fires when the database exchange is finished and both switches have each sent a full run of Database Description packets 🎉 (More on that in Section 7.2.)
BadLSReq
This fires when a Link State Request comes in asking for a link state advertisement that isn't in the database. It's a sign that something went wrong with the synchronization 🙈
Loading Done
This fires when every Link State Update for all the out-of-date parts of the database has been received 📬 (See Section 7.3.)
AdjOK?
This is the big decision moment 💭 it fires when the switch has to decide whether to establish or keep an adjacency with the neighbor. It can start some adjacencies and tear others down 💀
Seq Number Mismatch
This fires when a Database Description packet arrives with any of the following:
- The packet contains an unexpected sequence number.
- The packet (unexpectedly) has the Init bit set.
- The packet has a different Options field than was previously seen.
All of these mean something went wrong while the adjacency was being set up 😭
1-Way
This fires when bidirectional communication with the neighbor is lost 💔 aka a Hello packet came in from the neighbor and the local switch isn't listed in it anymore.
KillNbr
This fires when talking to the neighbor is no longer possible at all 🚫
Inactivity Timer
This fires when the inactivity timer runs out, meaning no Hello packets have come from the neighbor in SwitchDeadInterval seconds ⏰ this timer is only used on broadcast (multi-access) links.
LLDown
This event is generated by the lower-level switch discovery protocols, and it means the neighbor is now unreachable 🌙
4.3 Neighbor State Machine ✨
okay so this is where we get into the nitty gritty of the neighbor state machine 🎀 It's a detailed walkthrough, and I'm obsessed with how it's laid out.
Neighbor states (see Section 4.1) change because of all kinds of events (see Section 4.2). But the same event can hit differently depending on where the conversation with the neighbor currently is 🙈 So the state machine in this section is organized by the current neighbor state and the event that just happened. For each state and event pair, you get the new neighbor state plus a description of the processing it needs.
heads up 💀 when the neighbor state changes because of an interface Neighbor Change event (see Section 3.2), it may be necessary to rerun the designated switch selection algorithm. And if the interface tied to the neighbor conversation is in the DS state (aka the local switch is the designated switch), changes in the neighbor state might cause a new network link advertisement to be originated (see Section 8.1).
when the neighbor state machine has to invoke the interface state machine, it does that as a scheduled task 🧚 this keeps things clean because neither state machine ends up running recursively. no chaos!
State(s): Down Event: Hello Received New state: Depends on the interface type Action: If the interface type of the associated link is point-to-point, change the neighbor state to ExStart. Otherwise, change the neighbor state to Init and start the inactivity timer for the neighbor. If the timer expires before another Hello packet is received, the neighbor switch is declared dead. 💔
State(s): Init or greater Event: Hello Received New state: No state change Action: If the interface type of the associated link is point-to-point, determine whether this notification is for a different neighbor than the one previously seen. If so, generate an Interface Down event for the associated interface, reset the interface type to broadcast and generate an Interface Up event.
Note: This procedure of generating an Interface Down event and changing the interface type to broadcast is also executed if the neighbor for whom the notification was received is running an older version of the protocol software (see Section 6.1). In previous versions of the protocol, all interfaces were treated as if they were broadcast. 🕰️
If the interface type is broadcast, reset the inactivity timer for the neighbor. ⏰
State(s): Init Event: 2-Way Received New state: Depends on action routine Action: Determine whether an adjacency will be formed with the neighbor (see Section 6.4). If no adjacency is to be formed, change the neighbor state to 2-Way.
Otherwise, change the neighbor state to ExStart. Initialize the sequence number for this neighbor and declare the local switch to be master for the database exchange process. (See Section 7.2.) 👑
State(s): ExStart Event: Negotiation Done New state: Exchange Action: The Negotiation Done event signals the start of the database exchange process. See Section 7.2 for a detailed description of this process. 🫶
State(s): Exchange Event: Exchange Done New state: Depends on action routine Action: If the neighbor Link state request list is empty, change the neighbor state to Full. This is the adjacency's final state. 🌈
Otherwise, change the neighbor state to Loading. Begin sending Link State Request packets to the neighbor requesting the most recent link state advertisements, as discovered during the database exchange process. (See Section 7.2.) These advertisements are listed in the link state request list associated with the neighbor. 📬
State(s): Loading Event: Loading Done New state: Full Action: No action is required beyond changing the neighbor state to Full. This is the adjacency's final state. 🎉
State(s): 2-Way Event: AdjOK? New state: Depends on action routine Action: If no adjacency is to be formed with the neighboring switch (see Section 6.4), retain the neighbor state at 2-Way. Otherwise, change the neighbor state to ExStart. Initialize the sequence number for this neighbor and declare the local switch to be master for the database exchange process. (See Section 7.2.) 🍓
State(s): ExStart or greater Event: AdjOK? New state: Depends on action routine Action: If an adjacency should still be formed with the neighboring switch (see Section 6.4), no state change and no further action is necessary. Otherwise, tear down the (possibly partially formed) adjacency. Clear the link state retransmission list, database summary list and link state request list and change the neighbor state to 2-Way. 🧹
State(s): Exchange or greater Event: Seq Number Mismatch New state: ExStart Action: Tear down the (possibly partially formed) adjacency. Clear the link state retransmission list, database summary list and link state request list. Change the neighbor state to ExStart and make another attempt to establish the adjacency. 😤
State(s): Exchange or greater Event: BadLSReq New state: ExStart Action: Tear down the (possibly partially formed) adjacency. Clear the link state retransmission list, database summary list and link state request list. Change the neighbor state to ExStart and make another attempt to establish the adjacency. 💅
State(s): Any state Event: KillNbr New state: Down Action: Terminate the neighbor conversation. Disable the inactivity timer and clear the link state retransmission list, database summary list and link state request list. 🪦
State(s): Any state Event: LLDown New state: Down Action: Terminate the neighbor conversation. Disable the inactivity timer and clear the link state retransmission list, database summary list and link state request list. 📉
State(s): Any state Event: Inactivity Timer New state: Down Action: Terminate the neighbor conversation. Disable the inactivity timer and clear the link state retransmission list, database summary list and link state request list. ⌛
State(s): 2-Way or greater Event: 1-Way Received New state: Init Action: Tear down the adjacency between the switches, if any. Clear the link state retransmission list, database summary list and link state request list. 🙅♀️
State(s): 2-Way or greater Event: 2-Way received New state: No state change Action: No action required. ✅
State(s): Init Event: 1-Way received New state: No state change Action: No action required. 🌸
5. Area Data Structure 🗺️
The area data structure contains all the info needed to run the basic routing algorithm. One of its components is the link state database, which is basically the collection of all switch link and network link advertisements generated by the switches. 💜
The area data structure contains the following items:
Area ID A 4-octet value identifying the area. Since VLSP does not support multiple areas, the value here is always zero. 0️⃣
Associated switch interfaces A list of interface IDs of the local switch interfaces connected to network links.
Link state database The collection of all current link state advertisements for the switch fabric. This collection consists of the following:
Switch link advertisements A list of the switch link advertisements for all switches in the fabric. Switch link advertisements describe the state of each switch's interfaces. 🔌
Network link advertisements A list of the network link advertisements for all multi-access network links in the switch fabric. Network link advertisements describe the set of switches currently connected to each link. 🕸️
Best path(s) A set of end-to-end hop descriptions for all equal-cost best paths from the local switch to every other switch in the fabric. Each hop is specified by the interface ID of the next link in the path. Best paths are derived from the collected switch link and network link advertisements using the Dijkstra algorithm. [Perlman] 🏆
5.1 Adding and Deleting Link State Advertisements
The link state database within the area data structure must contain, at most, a single instance of each link state advertisement. To keep the database current, a switch adds link state advertisements to the database under the following conditions:
- When a link state advertisement is received during the distribution process
- When the switch itself generates a link state advertisement
(See Section 8.2.4 for information on installing link state advertisements.)
Likewise, a switch deletes link state advertisements from the database under the following conditions:
- When a link state advertisement has been superseded by a newer instance during the flooding process
- When the switch generates a newer instance of one of its self-originated advertisements
Note that when an advertisement is deleted from the link state database, it must also be removed from the link state retransmission list of all neighboring switches. 🗑️
5.2 Accessing Link State Advertisements
An implementation of the VLS protocol must provide access to individual link state advertisements, based on the advertisement's type, link state identifier, and advertising switch [1]. This lookup function is invoked during the link state distribution procedure and during calculation of the set of best paths. In addition, a switch can use the function to determine whether it has originated a particular link state advertisement, and if so, with what sequence number. 🔎
5.3 Best Path Lookup
An implementation of the VLS protocol must provide access to multiple equal-cost best paths, based on the base MAC addresses of the source and destination switches. This lookup function should return up to three equal-cost paths. Paths should be returned as lists of end-to-end hop information, with each hop specified as an interface ID of the next link in the path -- the 6-octet base MAC address of the next switch and the 4-octet local port number of the link interface. 🛣️
6. Discovery Process 🔍
The first operational stage of the VLS protocol is the discovery process. During this stage, each switch dynamically detects its neighboring switches and establishes a relationship with each of these neighbors. This process has the following component steps:
- Neighboring switches are detected on each functioning network interface.
- Bidirectional communication is established with each neighbor switch.
- A designated switch and backup designated switch are selected for each multi-access network link.
- An adjacent relationship is established with selected neighbors on each link.
6.1 Neighbor Discovery ✨
okay so when the switch first comes online 🌸, VLSP assumes all network links are point-to-point, and that no more than one neighboring switch will be discovered on any one port. so at startup, VLSP relies on the VlanHello protocol [IDhello] to discover its neighbor switches. 🔍
As each neighbor gets detected, VlanHello triggers a Found Neighbor event, which tells VLSP that a new neighbor has shown up 👀. (Check [IDhello] for the details on the Found Neighbor event and what info gets passed along.) VLSP adds the neighbor switch ID to its list of known neighbors and makes a new neighbor data structure with a neighbor status of Down. Then a Hello Received neighbor event gets generated, which flips the neighbor state to ExStart. ✨
There are two situations where VLSP changes an interface's type to broadcast:
- If VLSP gets a later notification from VlanHello saying there's a second (different) neighbor switch on the port, the interface is now known to be multi-access 🙈. VLSP generates an
Interface Downevent for the interface, resets the interface type tobroadcast, and then generates anInterface Upevent. - If the functional level of the neighbor switch is less than 2, the neighbor is running an older version of VLSP where all links were treated as broadcast links. VLSP changes the interface type to
broadcastright away and generates anInterface Upevent.
In both cases, VLSP takes over communication over the interface by swapping its own VLSP Hello packets with the neighbors on the link. 💌
Note: These Hello packets are in addition to the Interswitch Keepalive messages sent by VlanHello. VlanHello keeps watching the condition of the interface and tells VLSP about any change.
Each Hello packet carries the following data used during discovery on multi-access links:
- The switch ID and priority of the sending switch
- Values specifying the interval timers to be used for sending Hello packets and for deciding whether to declare a neighbor switch Down.
- The switch ID of the designated switch and the backup designated switch for the link, as understood by the sending switch
- A list of switch IDs of all neighboring switches seen so far on the link
For a detailed description of the Hello packet format, see Section 10.6.1.
When VLSP gets a Hello packet (on a broadcast link), it first tries to identify the sending switch by matching its switch ID against one of the known neighbors listed in the interface data structure. If this is the first Hello packet from that switch, the switch ID goes into the list of known neighbors and a new neighbor data structure gets made with a neighbor status of Down.
Now the rest of the Hello packet gets examined, and the right interface and neighbor events are generated. In every case, a neighbor Hello Received event is generated. Other events may also be generated, kicking off more steps in discovery or other actions, as needed.
For a detailed description of the interface state machine, see Section 3.3. For a detailed description of the neighbor state machine, see Section 4.3.
6.2 Bidirectional Communication 💬
Before a conversation can proceed with a neighbor switch, bidirectional communication must be established with that neighbor. Bidirectional communication is detected in one of two ways:
- On a point-to-point link, the VlanHello protocol sees its own switch ID listed in an Interswitch Keepalive message it has received from the neighbor.
- On a multi-access link, VLSP sees its own switch ID listed in a VLSP Hello packet it has received from the neighbor.
In either case, a neighbor 2-Way Received neighbor event is generated.
Once bidirectional communication is up with a neighbor, the local switch figures out whether an adjacency will be formed with that neighbor. However, if the link is multi-access, a designated switch and a backup designated switch must first be selected for the link. The next section describes the designated switch, the backup designated switch, and how they get picked. 🫶
6.3 Designated Switch 👑
Every multi-access network link has a designated switch. The designated switch does the following for the routing protocol:
- It originates a network link advertisement on behalf of the link, listing the set of switches (including itself) currently attached to the link. For a detailed description of network link advertisements, see Section 11.3.
- It becomes adjacent to all other switches on the link. Since the link state databases are synchronized across adjacencies, the designated switch plays a central part in the synchronization process. For a description of synchronization, see Section 7.
Each multi-access network link also has a backup designated switch. Its main job is to act as standby for the designated switch. If the current designated switch fails, the backup designated switch becomes the designated switch.
To make that handoff smooth, the backup designated switch forms an adjacency with every other switch on the link. So when it has to take over for the designated switch, its link state database is already synchronized with everyone else's on the link. 🫶
Note: Point-to-point network links have neither a designated switch or a backup designated switch.
6.3.1 Selecting the Designated Switch 🎀
When a multi-access link interface first becomes functional, the switch sets a one-shot Wait timer (with a value of SwitchDeadInterval seconds) for the interface. The point of this timer is to make sure all switches attached to the link get a chance to establish bidirectional communication before the designated switch and backup designated switch are selected.
When the Wait timer is set, the interface enters the Waiting state. During this state, the switch exchanges Hello packets with its neighbors, trying to establish bidirectional communication. The interface leaves the Waiting state under one of these conditions:
- The Wait timer expires.
- A Hello packet is received indicating that a designated switch or a backup designated switch has already been specified for the interface.
At this point, if the switch sees that a designated switch is already selected for the link, it accepts that designated switch, regardless of its own switch priority and MAC address. This usually means the switch came up late on a fully working link. It makes the designated switch harder to predict on a particular link, but it means the designated switch doesn't change needlessly, which would force a resynchronization of the databases.
If no designated switch is currently specified for the link, the switch starts the actual selection process. Note that this selection algorithm only operates on a list of neighbor switches that are eligible to become the designated switch. A neighbor is eligible if it has a switch priority greater than zero and its neighbor state is 2-Way or greater. The local switch includes itself on the list of eligible switches as long as it has a switch priority greater than zero.
The selection process includes these steps:
- The current values of the link's designated switch and backup designated switch are saved for use in step 6.
- The new backup designated switch is selected as follows:
- a) Eliminate from consideration those switches that have declared themselves to be the designated switch.
- b) If one or more of the remaining switches have declared themselves to be the backup designated switch, eliminate from consideration all other switches.
- c) From the remaining list of eligible switches, select the switch having the highest switch priority as the backup designated switch. If multiple switches have the same (highest) priority, select the switch with the highest switch ID as the backup designated switch.
- The new designated switch is selected as follows:
- a) If one or more of the switches have declared themselves to be the designated switch, eliminate from consideration all other switches.
- b) From the remaining list of eligible switches, select the switch having the highest switch priority as the designated switch. If multiple switches have the same (highest) priority, select the switch with the highest switch ID as the designated switch.
- If the local switch has been newly selected as either the designated switch or the backup designated switch, or is now no longer the designated switch or the backup designated switch, repeat steps 2 and 3, above, and then proceed to step 5.
If the local switch is now the designated switch, it eliminates itself from consideration at step 2a when the selection of the backup designated switch is repeated. Likewise, if the local switch is now the backup designated switch, it eliminates itself from consideration at step 3a when the selection of the designated switch is repeated. This makes sure no switch selects itself as both backup designated switch and designated switch [2].
- Set the interface state to the appropriate value, as follows:
- If the local switch is now the designated switch, set the interface state to
DS. - If the local switch is now the backup designated switch, set the interface state to
Backup. - Otherwise, set the interface state to
DS Other.
- If the local switch is now the designated switch, set the interface state to
- If either the designated switch or backup designated switch has now changed, the set of adjacencies associated with this link must be modified. Some adjacencies may need to be formed, while others may need to be broken. Generate the neighbor
AdjOK?event for all neighbors with a state of2-Wayor higher to trigger a reexamination of adjacency eligibility.
Caution: If VLSP is implemented with configurable parameters, care must be exercised in specifying the switch priorities. Note that if the local switch is not itself eligible to become the designated switch (i.e., it has a switch priority of 0), it is possible that neither a backup designated switch nor a designated switch will be selected by the above procedure. Note also that if the local switch is the only attached switch that is eligible to become the designated switch, it will select itself as designated switch and there will be no backup designated switch for the link. For this reason, it is advisable to specify a default switch priority of 1 for all switches. 🌈
6.4. Adjacencies
okay so VLSP makes adjacencies with neighboring switches so they can swap routing info 🦋 Not every pair of neighbors ends up adjacent, bestie. On a multi-access link, two switches only form an adjacency if one of them is the designated switch or the backup designated switch 👑
Adjacencies are tied to the network link the two switches share. So if two switches have multiple links in common, they can have multiple adjacencies between them ✨
The decision to form an adjacency happens in two spots in the neighbor state machine:
- When bidirectional communication is first established with the neighbor.
- When the designated switch or backup designated switch on the attached link changes.
The rules for establishing an adjacency between two neighbors go like this:
- On a point-to-point link, the two neighboring switches always establish an adjacency. no exceptions, it's giving simplicity 💖
- On a multi-access link, an adjacency gets established with the neighboring switch under one of these conditions:
- The local switch itself is the designated switch.
- The local switch itself is the backup designated switch.
- The neighboring switch is the designated switch.
- The neighboring switch is the backup designated switch.
If no adjacency forms between two neighboring switches, the neighbor conversation state just stays at 2-Way 🌸
7. Synchronizing the Databases
okay this part is so important bestie 😭 In an SPF-based routing algorithm, every switch's link state database has to stay in sync. VLSP keeps things simpler by only requiring adjacent switches to stay synchronized 🫶
The sync process starts when the switches try to bring up the adjacency. Each switch in the adjacency describes its database by sending a sequence of Database Description packets to its neighbor. Each Database Description packet describes a set of link state advertisements in the database. When the neighbor spots a link state advertisement that's more recent than its own copy, it makes a note to request that newer one 💅
During this exchange of Database Description packets (the database exchange process, iykyk), the two switches form a master/slave relationship 👑 Database Description packets sent by the master are called polls, and each poll has a sequence number. The slave acknowledges polls by echoing that sequence number back in its Database Description response packet 🎀
Once all Database Description packets have been sent and acknowledged, the database exchange process is done. At this point, each switch has a list of link state advertisements where its neighbor has more recent instances. Those get requested using Link State Request packets 🍓
Once the database exchange process is complete and all Link State Requests have been satisfied, the databases are considered synchronized and the neighbor states of both switches get set to Full, which means the adjacency is fully functional ✨ Fully functional adjacencies show up in the link state advertisements of both switches [3].
7.1. Link State Advertisements
Link state advertisements are the core of the database. A switch uses them to work out the set of best paths to the other switches in the fabric 🧚
Each link state advertisement starts with a standard header. This header has three data items that uniquely identify the advertisement:
- The link state type. The possible values are:
1 Switch link advertisement -- describes the collected states of
the switch's interfaces.
2 Network link advertisement -- describes the set of switches
attached to the network link.- The link state ID, defined as follows:
- For a switch link advertisement -- the switch ID of the originating switch
- For a network link advertisement -- the switch ID of the designated switch for the link
- The switch ID of the advertising switch -- the switch that generated the advertisement
The link state advertisement header also has three data items used to figure out which instance of a particular advertisement is the most current 🔥 (See Section 7.1.1 for how to determine which instance is the most current.)
- The link state sequence number
- The link state age, stored in seconds
- The link state checksum, a 16-bit unsigned value calculated over the entire contents of the link state advertisement, except for the age field
The rest of each link state advertisement holds data specific to its type. See Section 11 for a detailed description of the link state header, plus the format of a switch link or network link advertisement 💜
7.1.1. Determining Which Link State Advertisement Is Newer
At various points while syncing or updating the link state database, a switch has to figure out which instance of a particular link state advertisement is the most current. Here's how it decides 👀
- The advertisement with the greater sequence number is the most current.
- If both instances have the same sequence number, then:
- If the two instances have different checksum values, the instance with the larger checksum is considered the most current [4].
- If both instances have the same sequence number and the same checksum value, then:
- If one (and only one) of the instances has age
MaxAge, the instance of ageMaxAgeis considered the most current [5]. - Else, if the ages of the two instances differ by more than
MaxAgeDiff, the instance with the smaller (younger) age is considered the most current [6]. - Else, the two instances are considered identical.
- If one (and only one) of the instances has age
7.2. Database Exchange Process
The database exchange process has two stages, bestie:
- Negotiating the master/slave relationship
- Exchanging database summary information
7.2.1. Database Description Packets
Database Description packets describe a switch's link state database during the database exchange process 📋 Each one contains a list of headers for the link state advertisements currently stored in the sending switch's database. (See Section 11.1 for a description of a link state advertisement header.)
Besides the link state headers, each Database Description packet also has these data items:
- A flag (the
M-bit) that says whether or not more packets are coming. Depending on the size of the local database and the maximum packet size, the header list in a given Database Description packet might only be a partial list of the whole database. WhenM-bitis set, the list is only partial and more headers come in later packets 🌈 - A flag (the
I-bit) that says whether or not this is the first Database Description packet sent for this run of the database exchange process. - A flag (the
MS-bit) that says whether the sending switch thinks it's the master or the slave in the database exchange process. If the flag is set, the switch thinks it's the master 👑 - A 4-octet sequence number for the packet.
While the switches are negotiating who's master and who's slave, they swap "empty" Database Description packets. These are packets with no link summary info in them. Instead, the flags and sequence number are the info needed for the negotiation 💅
See Section 10.6.2 for a more detailed description of a Database Description packet.
7.2.2. Negotiating the Master/Slave Relationship
Before two switches can start actually exchanging database info, they have to decide between themselves who'll be the master and who'll be the slave. They also have to agree on the starting sequence number for the Database Description packets 🤝
Once a switch decides to form an adjacency with a neighbor, it sets the neighbor state to ExStart and starts sending empty Database Description packets to its neighbor. These packets carry the starting sequence number the switch plans to use. The I-bit, M-bit, and MS-bit flags are all set too. So each switch starts out believing it'll be the master 🦋
Empty Database Description packets get retransmitted every RxmtInterval seconds until the neighbor responds.
When a switch receives an empty Database Description packet from its neighbor, it works out who'll be master by comparing switch IDs. The switch with the highest switch ID becomes the master of the exchange. Based on that, the switch does the following:
- If the switch is going to be the slave of the database exchange process, it acknowledges that by sending another empty Database Description packet to the master. This packet contains the master's sequence number and has the
MS-bitandI-bitcleared. - The switch then generates a neighbor event of
Negotiation Doneto change its neighbor state toExchange, and waits for the first non-empty Database Description packet from the master. - If the switch is going to be the master of the database exchange, it waits to receive an acknowledgment from its neighbor. That's an empty Database Description packet with the
MS-bitandI-bitcleared, containing the sequence number the master previously sent. - When it receives that acknowledgment, it generates a neighbor event of
Negotiation Doneto change its neighbor state toExchangeand begin the actual exchange of Database Description packets 🎀
Heads up, bestie: during negotiation, if a switch gets an inconsistent packet, that triggers a neighbor event of Seq Number Mismatch, which terminates the process. See Section 4.3 for more info 🙈
7.2.3 Exchanging Database Description Packets
okay so once the neighbor state flips to Exchange 💅, the switches start swapping Database Description packets full of link state summary data. here's how it goes, step by step ✨
- The master sends a packet with a list of link state headers 🎀. If it's only part of the unexchanged database (aka more Database Description packets are coming), the packet has the
M-bitset. TheMS-bitis set and theI-bitis clear.
If the slave doesn't acknowledge the packet within RxmtInterval seconds, the master retransmits it 🔁.
- When the slave gets a packet, it checks the sequence number first to see if it's a duplicate 👀. If it is, the slave just acks it by clearing the
MS-bitand sending the packet back to the master. (ngl, the slave acks every Database Description packet it receives, even the duplicates 🙈.)
Otherwise, the slave processes the packet like this:
- For each link state header in the packet, the slave searches its own link state database to see if it already has an instance of that advertisement 🔍.
- If the slave doesn't have the link state advertisement, or the instance it has is older than the one in the packet, it creates an entry in its link state request list in the neighbor data structure. For how to tell which instance is the newest, check out Section 7.1.1 💜.
- Once the slave has looked at all the headers, it acks the packet by turning off the
MS-bitand sending it back to the master 🫶.
- When the master gets the first acknowledgment for a particular Database Description packet, it handles it like so 🔥:
- For each link state header in the packet, the master checks whether the slave says it has an instance of that advertisement that's newer than the master's own copy. If so, the master creates an entry in its link state request list in the neighbor data structure.
- Then the master increments the sequence number and sends the next packet with the next set of link state summary info, if there is any 🍓.
Any later acknowledgments for that same Database Description packet (the ones with the same sequence number) get thrown out 🗑️.
When the master sends the last bit of its database summary info, it clears the M-bit to say no more packets are coming 🌸.
- When the slave gets a Database Description packet with the
M-bitclear, it processes the packet like in step 2. After it's finished and has acked the packet to the master, it generates an Exchange Done neighbor event and its neighbor state changes toLoading🎉.
The database exchange is now complete for the slave, so it starts requesting the link state advertisements where the master has newer instances (see Section 7.3) ✨.
- When the master gets an acknowledgment for the final Database Description packet, it handles it the way described in step 3. Then it generates an Exchange Done neighbor event and its neighbor state changes to
Loading👑.
The database exchange is now complete for the master too, and it starts requesting the link state advertisements where the slave has newer instances (see Section 7.3) 🦋.
Heads up, bestie 🚨: if an inconsistent packet shows up during this exchange, it triggers a neighbor event of Seq Number Mismatch, and the whole process gets terminated 💀. Check Section 4.3 for more on that.
7.3 Updating the Database
okay, so when either switch finishes the database exchange and its neighbor state changes to Loading, it has a list of link state advertisements where the neighbor has a more recent instance 📋. That list gets stored in the neighbor data structure as the link state request list 🗂️.
To finish syncing its database with its neighbor's, the switch has to grab the most current instances of those advertisements 🫶.
It asks for them by sending its neighbor a Link State Request packet. That packet describes one or more link state advertisements using the advertisement's type, link state ID, and advertising switch 📨. (For the full scoop on the Link State Request packet, see Section 10.6.3 💅.) The switch keeps resending this packet every RxmtInterval seconds until the neighbor replies 🔁.
When the neighbor gets the Link State Request packet, it answers with a Link State Update packet containing its most current instance of each requested advertisement 🎁. (Also, the neighboring switch can be in any of the Exchange, Loading or Full neighbor states when it responds to a Link State Request packet 🌈.)
If the neighbor can't find a particular link state advertisement in its database, something went wrong with the synchronization 😭. The switch generates a BadLSReq neighbor event, and the partially formed adjacency gets torn down. See Section 4.3 for more info.
Depending on how big the link state request list is, it might take more than one Link State Request packet to get all the advertisements you need 📦. But here's the key bit ✋: there must be at most one Link State Request packet outstanding at any one time.
7.4 An Example
okay let's look at Figure 3 🧚. It shows an adjacency forming between two switches, S1 and S2, connected to a network link. S2 is the designated switch for the link, and it has a higher switch ID than S1 👑.
The neighbor state changes each switch goes through are listed on the sides of the figure 📝.
+--------+ +--------+
| Switch | | Switch |
| S1 | | S2 |
+--------+ +--------+
Down Down
Hello (DS=0, seen=0)
------------------------------------->
Init
Hello (DS=S2, seen=...,S1)
<-------------------------------------
ExStart
DB Description (Seq=x, I, M, Master)
------------------------------------->
ExStart
DB Description (Seq=y, I, M, Master)
<-------------------------------------
xchange
DB Description (Seq=y, M, Slave)
------------------------------------->
Exchange
DB Description (Seq=y+1, M, Master)
<-------------------------------------
DB Description (Seq=y+1, M, Slave)
------------------------------------->
.
.
.
DB Description (Seq=y+n, Master)
<-------------------------------------
DB Description (Seq=y+n, Slave)
------------------------------------->
Loading Full
Link State Request
<-------------------------------------
Link State Update
------------------------------------->
.
.
.
Link State Request
<-------------------------------------
Link State Update
------------------------------------->
Full
Figure 3: An Example of Bringing Up an Adjacencyso at the top of Figure 3, S1's interface to the link comes up 🌱, and S1 starts sending Hello packets over it. At this point, S1 doesn't know who the designated switch is or who any other neighboring switches are 🤷♀️. S2 gets the Hello packet from S1 and changes its neighbor state to Init. In its next Hello packet, S2 says it's the designated switch and that it's received a Hello packet from S1 💖. S1 gets that Hello and changes its state to ExStart, kicking off the adjacency bring-up ✨.
S1 starts by claiming it's the master 😤. When it sees that S2 is actually the master (because S2 has the higher switch ID), S1 switches to slave and adopts S2's sequence number 🫡. Then the Database Description packets get exchanged, with the polls coming from the master (S2) and the acknowledgments coming from the slave (S1) 🔄. This back-and-forth ends when both the poll and its acknowledgment have the M-bit off 🏁.
In this example, S2 is assumed to have a completely up-to-date database, so it changes straight to Full 🥳. S1 changes to Full after it updates its database by sending Link State Request packets and receiving Link State Update packets back 💜.
Notice that in this example, S1 waits until it's received all the Database Description packets from S2 before sending any Link State Request packets 🙈. But that doesn't have to be the case! S1 could interleave sending Link State Request packets with receiving Database Description packets 🦋.
8. Maintaining the Databases
okay, so each switch advertises its state (aka its link state) by originating switch link advertisements 📣. On top of that, the designated switch on each network link advertises the state of that link by originating network link advertisements 🌐.
As covered in Section 7.1, link state advertisements are uniquely identified by their type, link state ID, and advertising switch 🪪.
Link state advertisements get distributed throughout the switch fabric using a reliable flooding algorithm 🌊. That's what makes sure every switch in the fabric hears about any link state changes ✨🫶.
8.1 Originating Link State Advertisements ✨
okay so a brand-new copy of each link state advertisement gets originated every single time the state of the switch or link changes 🔄 when that happens, its sequence number goes up, its age resets to zero, and its checksum gets calculated 🧮 then it gets installed into the local link state database and forwarded out every fully operational interface (aka the ones with a state greater than Waiting) so the whole switch fabric can hear about it 📣 see Section 8.2.4 for how the install works and Section 8.2.5 for how forwarding works 💅
a switch originates a new instance of a link state advertisement for these reasons:
- the state of one of the switch's interfaces changes, so the contents of the matching switch link advertisement change too 🔥
- the designated switch on any of the switch's attached network links changes 😳 the switch originates a new switch link advertisement, and if the switch is now the designated switch itself, it also originates a new network link advertisement for that link 🫶
- one of the switch's neighbor states changes to or from Full 👀 if that changes the contents of the matching switch link advertisement, a new instance gets generated, and if the switch is the designated switch for the attached network link, it originates a new network link advertisement for the link too 🦋
two instances of the same link state advertisement MUST NOT be originated within the time period MinLSInterval 🚫 heads up, this might mean the second instance has to wait up to MinLSInterval seconds before it can be generated ⏳
8.1.1 Switch Link Advertisements
a switch link advertisement describes the collected states of all functioning links attached to the originating switch, which is basically every attached link with an interface state greater than Down 🌸 a switch originates an empty switch link advertisement the moment it first becomes functional, and then it generates a fresh instance every time one of its interfaces reaches a fully functioning state (Point-to-Point or better) 🎀
every link in the advertisement gets a type based on the state of its interface, as shown in Table 4 💖
Interface state Link type Description
Point-to-Point 1 Point-to-point link
DS Other* 2 Multi-access link
Backup* 2 Multi-access link
DS** 2 Multi-access link
*If a full adjacency has been formed with the designated
switch.
**If a full adjacency has been formed with at least one
other switch on the link.
Table 4: Link Types in a Switch Link Advertisementevery link also gets a link identifier based on its link type ✨ generally speaking, that value points to another switch that also originates advertisements for the same link, so it works as a key for finding the other link state advertisements for that link 🗝️ the relationship between link type and ID is in Table 5 🧚
Type Description Link ID
1 Point-to-point link Switch ID of neighbor switch
2 Multi-access link Switch ID of designated switch
Table 5: Link IDs in a Switch Link Advertisementon top of a type and an identifier, each link description also specifies the interface ID of the associated network link 🫧
last but not least, each link description includes the cost of sending a packet over the link 💰 this output cost is expressed in the link state metric and it MUST be greater than zero 💜
to see what a switch link advertisement looks like in action, check out the switch fabric in Figure 4 👑 in this example, switch SW1 has 5 neighboring switches (the boxes) spread over 3 network links (the lines) 🌈 each box has its base MAC address written next to it 🙈 on SW1, ports 01 and 02 hook up to point-to-point network links, and port 03 hooks up to a multi-access network link with three attached switches 🍓 the interface state of each port is shown right next to the line for its link 🔥
00-00-1d-22-23-c5
+-------+
| SW2 |
+-------+
|
| Point-to-Point
|
| 01
+-------+ Loopback +-------+
| SW3 |----------------| SW1 | 00-00-1d-1f-05-81
+-------+ 02 +-------+
00-00-1d-17-35-a4 | 03
|
| DS Other
|
+--------------------+--------------------+
| | |
| DS Other | Backup | DS
| | |
+-------+ +-------+ +-------+
| SW4 | | SW5 | | SW6 |
+-------+ +-------+ +-------+
00-00-1d-4a-26-b3 00-00-1d-4a-27-1c 00-00-1d-7e-84-2e
Figure 4: Sample Switch Fabricthe switch link advertisement that SW1 generates would contain these data items 🧾
; switch link advertisement for switch SW1
LS age = 0 ; always true on origination
Options = (T-bit|E-bit) ; options
LS type = 1 ; this is a switch link advert
; SW1's switch ID
Link State ID = 00-00-1d-1f-05-81-00-00-00-00
Advertising switch = 00-00-1d-1f-05-81-00-00-00-00
# links = 2
; link on interface port 1
Link ID = 00-00-1d-22-23-c5-00-00-00-00 ; switch ID
Link Data = 00-00-1d-1f-05-81-00-00-00-01 ; interface ID
Type = 1 ; pt-to-pt link
# other metrics = 0 ; TOS 0 only
TOS 0 metric = 1
; link on interface port 2 is not fully functional
; link on interface port 3
Link ID = 00-00-1d-7e-84-2e-00-00-00-00 ; switch ID of DS
Link Data = 00-00-1d-1f-05-81-00-00-00-03 ; interface ID
Type = 2 ; multi-access
# other metrics = 0 ; TOS 0 only
TOS 0 metric = 2(see Section 11.2 for the full, detailed format of a switch link advertisement 📖)
8.1.2 Network Link Advertisements
network link advertisements describe the switches attached to each multi-access network link 🕸️
Note: Network link advertisements are not generated for point-to-point links. 🙅♀️
a network link advertisement is originated by the designated switch for the associated multi-access link, but only once that switch has established a full adjacency with at least one other switch on the link 🤝 each advertisement lists the switch IDs of the switches that are fully adjacent to the designated switch, and the designated switch includes itself in that list 🫶
to see the format of a network link advertisement in action, look at Figure 4 again 👀 this time, only switch SW6 generates network link advertisements, because SW6 is the designated switch of the multi-access network link between SW1 and switches SW4, SW5, and SW6 💁♀️
the network link advertisement that SW6 generates would contain these data items 🧾
; network link advertisement for switch SW6
LS age = 0 ; always true on origination
Options = (T-bit|E-bit) ; options
LS type = 2 ; this is a network link advert
; SW6's switch ID
Link State ID = 00-00-1d-73-84-2e-00-00-00-00
Advertising switch = 00-00-1d-73-84-2e-00-00-00-00
Attached switch = 00-00-1d-7e-84-2e-00-00-00-00
Attached switch = 00-00-1d-4a-26-b3-00-00-00-00
Attached switch = 00-00-1d-1f-05-81-00-00-00-00
Attached switch = 00-00-1d-4a-27-1c-00-00-00-00(see Section 11.3 for the full, detailed format of a network link advertisement 📖)
8.2 Distributing Link State Advertisements 🚀
link state advertisements get spread around the switch fabric wrapped up inside Link State Update packets 🎁 a single Link State Update packet can carry several different advertisements at once 📦
to make distribution reliable, each advertisement MUST be explicitly acknowledged in a Link State Acknowledgment packet 🫡 multiple acknowledgments can be bundled together into one Link State Acknowledgment packet though 🧺 and a sending switch keeps retransmitting unacknowledged Link State Update packets at regular intervals until they get acknowledged 🔁
here's the lineup for the rest of this section 💖
- Section 8.2.1 gives an overview of the distribution process 🗺️
- Section 8.2.2 describes how an incoming Link State Update packet gets processed 📥
- Section 8.2.3 describes how a Link State Packet gets forwarded, both by the originating switch and by an intermediate receiving switch 📤
- Section 8.2.4 describes how advertisements get installed into the local database 🗄️
- Section 8.2.5 describes the retransmission of unacknowledged advertisements 🔁
- Section 8.2.6 describes how advertisements get acknowledged 🫶
8.2.1 Overview
okay so the whole vibe of link state advertisement distribution is adjacencies 💅 every switch only has to stay in sync with its adjacent neighbors. that's it. no need to keep up with the whole fabric, just your people 🫶
when a switch makes a brand new instance of a link state advertisement, it wraps it up in a Link State Update packet and floods it out every fully operational interface. that means any interface whose state is greater than Waiting 🦋 but only the neighbors that are adjacent to the sender actually need to process it 👀
the sender tells its neighbors who should process the advertisement by picking a multicast destination in the network layer address info (see Section 10.3) 🎀 and the value in the network layer destination switch ID field depends on the state of the interface it's sent out of:
- If the interface state is
Point-to-Point,DS, orBackup, the switch is adjacent to every other switch on the link, so all the neighboring switches must process the packet 🌈 The destination field gets set to the multicast switch IDAllSPFSwitches. - If the interface state is
DS Other, the switch is only adjacent to the designated switch and the backup designated switch, so only those two neighbors must process the packet 💜 The destination field gets set to the multicast switch IDAllDSwitches.
the receiving side uses similar logic when a Link State Update packet with a new instance of a link state advertisement comes in. after it processes and acknowledges the packet, the receiving switch forwards the Link State Update packet like this:
- On the interface the original Link State Update packet came in on:
- If the receiving switch is the designated switch for the attached network link, the packet goes to all other switches on the link. (The destination field is set to
AllSPFSwitches.) The originating switch will notice that it was the advertisement originator and discard the packet 🙈 - If the receiving switch is not the designated switch for the attached network link, the packet is not sent back out the interface it came in on 🚫
- If the receiving switch is the designated switch for the attached network link, the packet goes to all other switches on the link. (The destination field is set to
- On all other interfaces:
- If the receiving switch is the designated switch for the attached network link, the packet is forwarded to all switches on the link. (The destination field is set to
AllSPFSwitches.) ✨ - If the receiving switch is neither the designated switch or the backup designated switch for the attached network link, the packet is forwarded only to the designated switch and the backup designated switch. (The destination field is set to
AllDSwitches.) 🧚
- If the receiving switch is the designated switch for the attached network link, the packet is forwarded to all switches on the link. (The destination field is set to
every Link State Update packet keeps getting forwarded and processed this way until all switches in the fabric have heard about the new instance of the link state advertisement. the whole fabric gets the tea eventually 🍓
8.2.2 Processing an Incoming Link State Update Packet
okay so when a Link State Update packet shows up, it goes through a bunch of consistency checks first 🔍 the packet is tied to one specific neighbor, and if that neighbor's state is less than Exchange, the entire Link State Update packet gets tossed out 💀
then every link state advertisement inside the packet gets processed like this:
- Validate the advertisement's link state checksum and type. If the checksum is invalid or the type is unknown, discard the advertisement without acknowledging it. 🙅♀️
- If the advertisement's age is equal to
MaxAgeand there is currently no instance of the advertisement in the local link state database, then do the following:- a) Acknowledge the advertisement by sending a Link State Acknowledgment packet to the sending neighbor (see Section 8.2.6). 💌
- b) Purge all outstanding requests for equal or previous instances of the advertisement from the sending neighbor's Link State Request list. 🧹
- c) If the neighbor is
ExchangeorLoading, install the advertisement in the link state database (see Section 8.2.4). Otherwise, discard the advertisement.
- If the advertisement's age is equal to
MaxAgeand there is an instance of the advertisement in the local link state database, then do the following:- a) If the advertisement is listed in the link state retransmission list of any neighbor, remove the advertisement from the retransmission list(s) and delete the database copy of the advertisement. 🗑️
- b) Discard the received (
MaxAge) advertisement without acknowledging it.
- If the advertisement's age is less than
MaxAge, attempt to locate an instance of the advertisement in the local link state database. If there is no database copy of this advertisement, or the received advertisement is more recent than the database copy (see Section 7.1.1), do the following:- a) If there is already a database copy, and if the database copy was installed less than
MinLSIntervalseconds ago, discard the new advertisement without acknowledging it. ⏳ - b) Otherwise, forward the new advertisement out some subset of the local interfaces (see Section 8.2.3). Note whether the advertisement was sent back out the receiving interface for later use by the acknowledgment process. 📤
- c) Remove the current database copy from the Link state retransmission lists of all neighbors. 🧼
- d) Install the new advertisement in the link state database, replacing the current database copy. (Note that this may cause the calculation of the set of best paths to be scheduled. See Section 9.) Timestamp the new advertisement with the time that it was received to prevent installation of another instance within
MinLSIntervalseconds. ⏰ - e) Acknowledge the advertisement, if necessary, by sending a Link State Acknowledgment packet back out the receiving interface. (See Section 8.2.6.) 💕
- f) If the link state advertisement was initially advertised by the local switch itself, advance the advertisement sequence number and issue a new instance of the advertisement. (Receipt of a newer instance of an advertisement means that the local copy of the advertisement is left over from before the last time the switch was restarted.) 🔄
- a) If there is already a database copy, and if the database copy was installed less than
- If the received advertisement is the same instance as the database copy (as determined by the algorithm described in Section 7.1.1), do the following:
- a) If the advertisement is listed in the neighbor's link state retransmission list, the local switch is expecting an acknowledgment for this advertisement. Treat the received advertisement as an implied acknowledgment, and remove the advertisement from the link state retransmission list. Note this implied acknowledgment for later use by the acknowledgment process (Section 8.2.6). 🤝
- b) Acknowledge the advertisement, if necessary, by sending a Link State Acknowledgment packet back out the receiving interface. (See Section 8.2.6.) ✅
if the database copy of the advertisement is more recent than the instance that just came in, do the following:
- a) Determine whether the instance is listed in the neighbor link state request list. If so, an error has occurred in the database exchange process. Restart the database exchange process by generating a neighbor
BadLSReqevent for the sending neighbor and terminate processing of the Link State Update packet. 😱 - b) Otherwise, generate an unusual event to network management and discard the advertisement. 🚨
8.2.3 Forwarding Link State Advertisements 🎀
okay so when a brand-new instance of an advertisement gets originated, or after an incoming one has been processed, the switch MUST decide which interfaces and which neighbors the advertisement gets forwarded to. Sometimes the switch skips an interface because it can tell the neighbors on that attached link have already gotten it (or will get it) from another switch on the link. iykyk 💅
The call on each interface goes like this:
- Each neighboring switch attached to the interface gets checked for whether it should receive and process the new advertisement. For each neighbor, these steps run:
- a) If the neighbor state is less than
Exchange, the neighbor need not receive or process the new advertisement. - b) If the neighbor state is
ExchangeorLoading, look at the link state request list tied to that neighbor. If an instance of the new advertisement is on that list, the neighbor already has an instance, so compare the new one to the neighbor's copy:- If the new advertisement is less recent, the neighbor need not receive or process it.
- If the two copies are the same instance, delete the advertisement from the link state request list. The neighbor need not receive or process the new advertisement [7].
- Otherwise, the new advertisement is more recent. Delete it from the link state request list. The neighbor MAY need to receive and process the new advertisement.
- c) If the new advertisement was received from this neighbor, the neighbor need not receive or process it.
- d) Add the new advertisement to the link state retransmission list for the neighbor.
- a) If the neighbor state is less than
- The switch MUST now decide whether to forward the new advertisement out the interface.
- a) If the advertisement wasn't added to any link state retransmission lists for neighbors attached to the interface, there's no need to forward it out.
- b) If it was received on this interface from either the designated switch or the backup designated switch, there's no need to forward it out. Chances are all the neighbors on that attached network link already got it 🙈
- c) If it was received on this interface and the interface state is
Point-to-Point, there's no need to forward it, since the neighbor switch originated it. - d) If it was received on this interface and the interface state is
Backup(aka the switch itself is the backup designated switch), there's no need to forward it out. The designated switch will distribute advertisements on the attached network link. - e) Otherwise, the advertisement MUST be forwarded out the interface.
To forward a link state advertisement, the switch first increments the advertisement's age by InfTransDelay seconds to account for transmission time over the link. Then it copies the advertisement into a Link State Update packet. ✨
Forwarded advertisements go to all adjacent switches associated with the interface. If the interface state is Point-to-Point, DS, or Backup, the destination switch ID field of the network layer address information is set to the multicast switch ID AllSPFSwitches. If the interface state is DS Other, the destination switch ID field is set to the multicast switch ID AllDSwitches. main character multicast energy 🦋
8.2.4 Installing Link State Advertisements in the Database 💜
When a new link state advertisement gets installed into the link state database, whether the switch originated it or received it, the switch MUST figure out whether the best paths need recalculating. To do that, you do the following:
- Compare the contents of the new instance with the contents of the old instance (assuming the older one is available). This comparison does NOT include any data from the link state header. Differences in header fields, like the sequence number and checksum (which are guaranteed to differ between instances), don't matter for deciding whether to recalculate the set of best paths.
- If the contents of the two instances are the same, there's no need to recalculate the set of best paths.
- Otherwise, the set of best paths MUST be recalculated.
Note also that the older instance of the advertisement MUST be removed from the link state database when the new advertisement is installed. The older instance MUST also be removed from the link state retransmission lists of all neighbors. bye bye old copies 👋
8.2.5 Retransmitting Link State Advertisements 🌸
When a switch sends a link state advertisement to an adjacent neighbor, it records the advertisement in that neighbor's link state retransmission list. To keep distribution reliable, the switch keeps periodically retransmitting whatever is in the list until it's acknowledged. Persistence is giving 💅
The interval timer that triggers retransmission is set to RxmtInterval seconds, as found in the interface data structure. ngl, if this value is too low, you get needless retransmissions. If it's too high, the speed at which the databases sync across adjacencies can take a hit when packets get lost 💀
When the interval timer expires, the entries in the retransmission list get formatted into one or more Link State Update packets. (Remember, multiple advertisements can fit into a single Link State Update packet.) The age field of each advertisement is incremented by InfTransDelay, as found in the interface data structure, before the advertisement is copied into the outgoing packet.
Link State Update packets containing retransmitted advertisements are always sent directly to the adjacent switch. That means the destination field of the network layer addressing information is set to the switch ID of the neighboring switch. Direct message, no cap 🎀
If the adjacent switch goes down, retransmissions keep going until the switch failure is detected and the adjacency is torn down by the VLSP discovery process. Once the adjacency is torn down, the link state retransmission list gets cleared. the end of the line for that list 😭
8.2.6 Acknowledging Link State Advertisements 🫶
Every link state advertisement a switch receives MUST be acknowledged. Usually that's done by sending a Link State Acknowledgment packet. Acknowledgments can also happen implicitly, by sending Link State Update packets (see step 4a of Section 8.2.2). Two ways to say "got it" 🍓
Multiple acknowledgments can be grouped together into a single Link State Acknowledgment packet.
Sending an acknowledgment
Link State Acknowledgment packets go back out the interface the advertisement was received on. The packet can be sent immediately to the sending neighbor, or it can be delayed and sent when an interval timer expires.
- Delayed acknowledgments make it easier to format multiple acknowledgments into a single packet. That lets one packet acknowledge several neighbors at once, by putting a multicast switch ID in the destination field of the network layer addressing information (see below). Delaying also randomizes the acknowledgment packets sent by the multiple switches on a multi-access network link. Smart and chill 🧚
Note that the interval used to time delayed acknowledgments MUST be short (less than RxmtInterval), or needless retransmissions will ensue.
Delayed acknowledgments are sent to all adjacent switches associated with the interface. If the interface state is Point-to-Point, DS, or Backup, the destination field of the network layer addressing information is set to the multicast switch ID AllSPFSwitches. If the interface state is DS Other, the destination field is set to the multicast switch ID AllDSwitches.
- Immediate acknowledgments go directly to a specific neighbor, in response to receiving duplicate link state advertisements. They get sent right away when the duplicate arrives. ⚡
The method for sending a Link State Acknowledgment packet, delayed or immediate, depends on the circumstances around receiving the advertisement, as shown in Table 6. Switches with an interface state of Backup send acknowledgments differently than everyone else, because they play a slightly different role in distribution (see Section 8.2.3). It's giving different job, different rules 👑
Action taken in state
Circumstances Backup Other states
Advertisement was No ack sent No ack sent
forwarded back out
receiving interface
Advertisement is Delayed ack sent Delayed ack
more recent than if advertisement sent
database copy, but received from DS,
was not forwarded else do nothing
back out receiving
interface
Advertisement was a Delayed ack sent No ack sent
duplicate treated if advertisement
as an implied acknow- received from DS,
ledgment (step 4a of else do nothing
Section 8.2.2)
Advertisement was a Immediate ack Immediate ack
duplicate not treated sent sent
as an implied acknow-
ledgment
Advertisement age Immediate ack Immediate ack
equal to MaxAge and sent sent
no current instance
found in database
Table 6: Sending Link State AcknowledgmentsReceiving an acknowledgment
When a Link State Acknowledgment packet arrives, it first goes through a bunch of consistency checks. The big one: the packet is tied to a specific neighbor. If that neighbor's state is less than Exchange, the entire Link State Acknowledgment packet gets discarded. Bye 🙈
Each acknowledgment inside the packet gets processed like this:
- If the advertisement being acknowledged has an instance in the link state retransmission list for the sending neighbor, do the following:
- If the acknowledgment is for the same instance as the one in the list (as determined by the procedure described in Section 7.1.1), remove that instance from the retransmission list. Done and dusted ✅
- Otherwise, log the acknowledgment as questionable. sus ack alert 🤨
8.3 Aging the Link State Database ⏳
okay so every link state advertisement has an age field 🕰️ that counts how old it is in seconds. When an advertisement gets copied into a Link State Update packet to go out a particular interface, the age goes up by InfTransDelay seconds to account for the time it spends traveling over the link. 🚗💨 But it never goes past MaxAge, and advertisements sitting at MaxAge are not used to calculate best paths. bestie, that's a whole vibe check 💅
If an advertisement's age hits MaxAge, the switch flushes it out of the switch fabric like it's cleaning out the group chat 🧹 It does this in two steps:
- Originate a new instance of the advertisement with the age field set to
MaxAge. The distribution process will eventually get the advertisement removed from the retransmission lists of all switches in the fabric. 🌊 - Once the advertisement is no longer in the link state retransmission list of any neighbor, and no neighbor is in a state of Exchange or Loading, remove the advertisement from the local link state database. 👋
8.3.1 Premature Aging of Advertisements 🥀
okay this one is kind of dramatic 😭 A link state advertisement can be prematurely flushed from the switch fabric by forcing its age to MaxAge and then redistributing it. It's giving "I'm leaving before the party is over" energy 🚪
A switch that used to be the designated switch for a multi-access network link, but lost that status because of a failover to the backup designated switch, prematurely ages the network link advertisements it originated for that link. 🔄
Premature aging also happens when an advertisement's sequence number has to wrap. That's when the current instance has a sequence number of 0x7fffffff. In this situation, the advertisement gets prematurely aged so the next instance can be originated with a sequence number of 0x80000001 and be recognized as the most recent instance. 🔢✨ Main character glow-up, literally.
A switch may only prematurely age those link state advertisements for which it is the advertising switch. 🙅♀️ No touching other people's stuff, periodt 💜
9. Calculating the Best Paths 🗺️
okay, once an adjacency has been formed and the two switches have synchronized their databases, each switch in the adjacency works out the best path(s) to all other switches in the fabric. Each switch uses itself as the root of each path 🌳 Here, "best" means the path with the lowest total cost metric across all hops. If there are multiple paths tied for that lowest total cost metric, they all get calculated 👯♀️ Best paths get stored in the area data structure. 🗄️
Paths are calculated with the well-known Dijkstra algorithm 🧠 If you want a detailed explanation of how it works, go check [Perlman], or any of the standard textbooks on network routing. 📚
Also, whenever there is a change in an adjacency relationship, or any change that alters the topology of the switch fabric, the set of best paths must be recalculated. 🔁 Lowkey the most important rule here 🔥
10. Protocol Packets 📦
This section describes VLS protocol packets and link state advertisements. 💌
There are five distinct VLSP packet types, listed in Table 7 👇
Type Packet Name Function Description
1 Hello Select DS/Backup DS Section 10.6.1
2 Database Summarize database
Description contents Section 10.6.2
3 LS Request Database download Section 10.6.3
4 LS Update Database update Section 10.6.4
5 LS Ack Flooding acknow-
ledgment Section 10.6.5
Table 7: VLSP Packet TypesAll VLSP packets are encapsulated within a standard ISMP packet, with the VLS packet carried in the ISMP message body. 🎁 The ISMP packet is described in Section 10.1.
Since it's super important that the link state databases stay synchronized across the whole switch fabric, processing of both incoming and outgoing routing protocol packets should take priority over ordinary data packets. 🚦 Section 10.2 explains how packet processing works.
All VLSP packets start with network layer addressing information, described in Section 10.3, followed by a standard header, described in Section 10.4. 🪪
With the exception of Hello packets, all VLSP packets deal with lists of link state advertisements. The format of a link state advertisement is described in Section 11. 🫶
10.1 ISMP Packet Format 🧩
All VLSP packets are encapsulated within a standard ISMP packet. ISMP packets are variable length and have this general structure:
- Frame header
- ISMP packet header
- ISMP message body
10.1.1 Frame Header 🖼️
ISMP packets are encapsulated within an IEEE 802-compliant frame, using a standard header shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
+ Destination address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source address +
08 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
16 | |
+ +
: :Destination address 📬
This 6-octet field contains the Media Access Control (MAC) address of the multicast channel over which all switches in the fabric receive ISMP packets. The destination address of all ISMP packets contains a value of 01-00-1D-00-00-00. 💫
Source address 📤
This 6-octet field contains the physical (MAC) address of the switch that originated the ISMP packet. 🔌
Type 🏷️
This 2-octet field identifies the type of data carried within the frame. The type field of ISMP packets contains the value 0x81FD. 🎯
10.1.2 ISMP Packet Header 📋
The ISMP packet header is 6 octets long, as shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 |///////////////////////////////////////////////////////////////|
://////// Frame header /////////////////////////////////////////:
+//////// (14 octets) /////////+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 |///////////////////////////////| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | ISMP message type | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | |
+ +
: :Frame header 🧱
This 14-octet field contains the frame header. 🙌
Version 🔢
This 2-octet field contains the version number of the InterSwitch Message Protocol that this ISMP packet adheres to. This document describes ISMP Version 2.0. ✨
ISMP message type 🗂️
This 2-octet field contains a value indicating which type of ISMP message is contained within the message body. Valid values are:
1 (reserved)
2 Interswitch Keepalive messages
3 Interswitch Link State messages
4 Interswitch Spanning Tree BPDU messages and
Interswitch Remote Blocking messages
5 Interswitch Resolve and New User messages
6 (reserved)
7 Tag-Based Flood messages
8 Interswitch Tap messagesAll VLS protocol messages have an ISMP message type of 3. 🏆
Sequence number 🔁
This 2-octet field contains an internally generated sequence number used by the various protocol handlers for internal synchronization of messages. 🤝
10.1.3 ISMP Message Body 🍱
The ISMP message body is a variable-length field containing the actual data of the ISMP message. The length and content of this field are determined by the value found in the message type field. VLSP packets are contained in the ISMP message body. 💝
10.2 VLSP Packet Processing 🚥
Note that, with the exception of Hello packets, VLSP packets are sent only between adjacent neighbors. So all packets travel a single hop. 🦋
VLSP doesn't support fragmentation and reassembly of packets 🙅♀️ So packets containing lists of link state advertisements or advertisement headers must be formatted so they contain only as many advertisements or headers as will fit within the size constraints of a standard ethernet frame. 📏
When a protocol packet is received by a switch, it must first pass the following criteria before it's accepted for further processing:
- The checksum number must be correct. ✅
- The destination switch ID (as found in the network layer address information) must be the switch ID of the receiving switch, or one of the multicast switch IDs
AllSPFSwitchesorAllDSwitches.
If the destination switch ID is the multicast switch ID AllDSwitches, the state of the receiving interface must be Point-to-Point, DS, or Backup. 🎯
- The source switch ID (as found in the network layer address information) must not be that of the receiving switch. (That is, locally originated packets should be discarded.) 🗑️
At this point, if the packet is a Hello packet, it is accepted for further processing. 👋
Since all other packet types are only sent between adjacent neighbors, the packet must have been sent by one of the switch's active neighbors. If the source switch ID matches the switch ID of one of the receiving switch's active neighbors (as stored in the interface data structure associated with the inport interface), the packet is accepted for further processing. Otherwise, the packet is discarded. 🚫 That's the bouncer checking the guest list 🎟️✨
10.3 Network Layer Address Information ✨
okay so bestie, remember Section 2.2.1 where VLSP is borrowed from OSPF? 🦋 Parts of it depend on certain network layer addresses, especially the AllSPFSwitches and AllDSwitches multicast addresses that spread link state advertisements around the whole switch fabric 🌸 To make this easier to implement at the physical MAC layer, the network layer address info gets packed right into the VSLP packets 💅 It sits right after the ISMP frame and packet header and right before the VLSP packet header, like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: frame header / ISMP header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Unused (20 octets) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | |
+ Source switch ID +
24 | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
32 | |
+ Destination switch ID +
36 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | |
: VLSP header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Source switch ID 🍓
This 10-octet field contains the switch ID of the sending switch.
Destination switch ID 🎀
This 10-octet field contains the switch ID of the packet destination. The value here is set as follows:
- Hello packets are addressed to the multicast switch ID AllSPFSwitches.
- The designated switch and the backup designated switch address initial Link State Update packets and Link State Acknowledgment packets to the multicast switch ID AllSPFSwitches.
- All other switches address initial Link State Update packets and Link State Acknowledgment packets to the multicast switch ID AllDSwitches.
- Retransmissions of Link State Update packets are always addressed directly to the nonresponding switch.
- Database Description packets and Link State Request are always addressed directly to the other switch participating in the database exchange process.
VLSP header 🫶
This 30-octet field contains the VLSP standard header. See Section 10.4.
10.4 VLSP Packet Header 👑
Every VLSP packet starts with a common 30-octet header 💖 This header, together with the data in the network layer address information, has everything needed to figure out whether the packet should be accepted for further processing. (See Section 10.1.)
Here's the format of the VLSP header. Note that the header starts at offset 36 of the ISMP message body, right after the network layer address information 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: frame header / ISMP header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Network layer address information :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | (unused) | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44 | |
+ Source switch ID +
48 | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
52 | | Area ID . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
56 | Area ID . . . | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
60 | Autype | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authentication +
64 | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
68 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 🌸
This 1-octet field contains the packet type. Possible values are as follows:
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State AcknowledgmentPacket length 💜
This 2-octet field contains the length of the protocol packet, in bytes, calculated from the start of the VLSP header, at offset 20 of the ISMP message body. If the packet length is not an integral number of 16-bit words, the packet is padded with an octet of zero (see the description of the checksum field, below).
Switch ID 🦋
This 10-octet field contains the switch ID of the sending switch.
Area ID 🌈
This 4-octet field contains the area identifier. Since VLSP does not support multiple areas, the value here is always zero.
Checksum 🔥
This 2-octet field contains the packet checksum value. The checksum is calculated as the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet, beginning with the VLSP header, excluding the authentication field. If the packet length is not an integral number of 16-bit words, the packet is padded with an octet of zero before calculating the checksum.
AuType ⭐
This 2-octet field identifies the authentication scheme to be used for the packet. Since authentication is not supported by this version of VLSP, this field contains zero.
Authentication 🙈
This 8-octet field is reserved for use by the authentication scheme. Since authentication is not supported by this version of VLSP, this field contains zeroes.
10.5 Options Field 🌈
Hello packets, Database Description packets, and link state advertisements all carry a 1-octet options field 💜 Using this field, a switch can communicate its optional capabilities to other VLSP switches. The receiving switch can then choose whether or not to support those capabilities. So switches with differing capabilities can potentially be mixed within a single VLSP routing domain, which is giving flexibility 🫶
Two optional capabilities are currently defined in the options field: routing based on Type of Service (TOS), and support for external routing beyond the local switch fabric. Here's how they're laid out:
+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|E|T|
+-+-+-+-+-+-+-+-+
The options fieldT-bit 🎀
The T-bit specifies the switch's Type of Service (TOS) capability. If the T-bit is set, the switch supports routing based on nonzero types of service.
E-bit 🦋
The E-bit specifies the switch's external routing capability. If the E-bit is set, the switch supports external routing.
Note: The current version of VLSP supports neither of these capabilities. Therefore, both the T-bit and the E-bit are clear and the options field contains a value of zero. 🙈
10.6 Packet Formats 🧚
This section contains detailed descriptions of the five VLS protocol packets. Let's go! 💅✨
10.6.1 Hello Packets 👋✨
okay so Hello packets are the little "hey, I'm here!" messages 💖 switches send regularly over multi-access interfaces so they can find their neighbors and keep those relationships alive 🫶
Hello packets are NOT sent over point-to-point network links 🙅♀️ for those, the VLS protocol leans on the VlanHello protocol [IDhello] to tell it who its neighbors are. not me having to do extra work, lol 💅
since every switch on a shared network link has to agree on certain interface parameters 🎀, those parameters ride along in every Hello packet. if a switch gets a Hello with settings that don't match its own view of the interface, it just won't form a neighbor relationship with the sender. no drama, just a firm "nope" 💀
here's what the Hello packet looks like 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Network layer addressing / VLSP header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
70 | (unused -- must be 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
74 | HelloInt | Options | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
78 | DeadInt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
82 | |
+ Designated switch ID +
86 | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
90 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
94 | |
+ Backup designated switch ID +
98 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
102 | |
+ +
: Neighbor list :
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Network layer addressing / VLSP header 🧚 this 70-octet field holds the network layer addressing info plus the standard VLS protocol packet header. the packet header type field is set to a value of 1 ✨
HelloInt ⏱️ this 2-octet field is the interval, in seconds, at which this switch sends Hello packets 🌸
Options 🌈 this 1-octet field lists the optional capabilities the switch supports, as described in Section 10.5 💜
Priority 👑 this 1-octet field is the switch priority used when picking the designated switch and backup designated switch (see Section 6.3.1) 🔥. if the value is zero, the switch is ineligible to become either one. main character energy, but make it a no 🙈
DeadInt 💀 this 4-octet field is how long, in seconds, neighbors will wait before declaring the interface down once they stop getting Hello packets over it. its value equals the value of SwitchDeadInterval, as found in the interface data structure 🍓
Designated switch 🦋 this 10-octet field is the switch ID of the designated switch for this network link, as the sending switch currently understands it. it's set to zero if the designated switch selection process hasn't started yet 🎀
Backup designated switch 🫶 this 10-octet field is the switch ID of the backup designated switch for the network link, as the sending switch currently understands it. it's set to zero if the backup designated switch selection process hasn't started yet 💅
Neighbor list 🧁 this variable-length field is a list of switch IDs for every switch that the sending switch has gotten a valid Hello packet from within the last SwitchDeadInterval seconds 💖
10.6.2 Database Description Packets 📚💜
Database Description packets get exchanged while an adjacency is being formed between two neighboring switches 🤝. they describe what's in the topological database. for the full tea on the database exchange process, see Section 7.2 ☕
here's the format 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Network layer addressing / VLSP header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
70 | (unused -- must be 0) | Options | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
74 | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
78 | |
+ +
: Link state advertisement headers :
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Network layer addressing / VLSP header 🧚 this 70-octet field holds the network layer addressing info plus the standard VLS protocol packet header. the packet header type field is set to a value of 2 ✨
Options 🌈 this 1-octet field lists the optional capabilities the switch supports, as described in Section 10.5 💜
Flags 🔥 this 1-octet field is a set of bit flags that coordinate the database exchange process. the layout of this octet is:
+-+-+-+-+-+-+-+-+
|0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+I-bit (Init) 🌱 the I-bit signals the start of the exchange. it's set while the two switches work out the master/slave relationship and the starting sequence number 🤓
M-bit (More) 🎈 the M-bit is set to indicate that more Database Description packets are coming 🚀
MS-bit (Master/Slave) 👑 the MS-bit tells you which switch is the master of the exchange. if it's set, the sending switch is the master during the database exchange process. if it's clear, the switch is the slave 🦋
Sequence number 🔢 this 4-octet field sequences the Database Description packets during the exchange. the two switches agree on the initial value during master/slave negotiation, and the number goes up by one for each Database Description packet in the exchange 💖
to acknowledge each Database Description packet the master sends, the slave sends back a Database Description packet that echoes the sequence number of the packet it's acknowledging 🫶
Link state advertisement headers 📜 this variable-length field is a list of link state headers that describe a chunk of the master's topological database. each header uniquely identifies a link state advertisement and its current instance (see Section 11.1 for the detailed breakdown of a link state advertisement header) 🍓. the number of headers in the list is worked out implicitly from the length of the packet, as stored in the VLSP packet header (see Section 10.4) ✨
10.6.3 Link State Request Packets
okay so Link State Request packets are the ones that ask for the good stuff 👑. The sending switch uses them to ask for the pieces of its neighbor's database that it found out (during the database exchange process) are more up-to-date than what it has in its own database 🧚. And they're sent as the last step in bringing up an adjacency 💖 (see Section 7.3).
Here's the layout of a Link State Request packet 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Network layer addressing / VLSP header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
70 | Link state type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
74 | |
+ Link state ID +
88 | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
82 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
86 | |
+ Advertising switch ID +
90 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
94 | |
: . . . :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Network layer addressing / VLSP header 🌸
This 70-octet field holds the network layer addressing info plus the standard VLS protocol packet header 💅. The packet header type field is set to a value of 3.
Link state type 🦋
This 4-octet field holds the link state type of the requested link state advertisement, as stored in the advertisement header ✨.
Link state ID 🍓
This 10-octet field holds the link state ID of the requested link state advertisement, as stored in the advertisement header 💜.
Advertising switch 🌈
This 10-octet field holds the switch ID of the advertising switch for the requested link state advertisement, as stored in the advertisement header 👑.
ngl, this is a subtle one. The last three fields uniquely identify the advertisement, but NOT its instance 🙈. So the receiving switch just responds with its most recent instance of that advertisement. Main character energy, it's giving "newest version or nothing" 💀.
You can request multiple link state advertisements in one Link State Request packet 🫶. Just repeat the link state type, ID, and advertising switch for each one you want. The number of advertisements requested gets worked out implicitly from the length of the packet, as stored in the VLSP packet header 🧚.
10.6.4 Link State Update Packets
Link State Update packets are the ones that answer a Link State Request packet, or that advertise a brand new instance of one or more link state advertisements 🔥. They get acknowledged with Link State Acknowledgment packets 🫶. For more on how Link State Update packets get used, check out Section 7 and Section 8 💖.
Here's the layout 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Network layer addressing / VLSP header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
70 | # advertisements |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
74 | |
+ +
: Link state advertisements :
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Network layer addressing / VLSP header 🌸
This 70-octet field holds the network layer addressing info plus the standard VLS protocol packet header 💅. The packet header type field is set to a value of 4.
# advertisements 🌷
This 4-octet field holds the number of link state advertisements included in the packet 🍓.
Link state advertisements 🌈
This variable-length field holds a list of link state advertisements 💜. For a detailed look at the different types of link state advertisements, see Section 11 👑.
10.6.5 Link State Acknowledgment Packets
Link State Acknowledgment Packets are how a switch explicitly acknowledges one or more Link State Update packets 🫶. That's what makes distributing link state advertisements reliable 🔥 (see Section 8.2.6).
Here's the layout 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Network layer addressing / VLSP header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
70 | |
+ +
: Link state advertisement headers :
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Network layer addressing / VLSP header 🌸
This 70-octet field holds the network layer addressing info plus the standard VLS protocol packet header 💅. The packet header type field is set to a value of 5.
Link state advertisement headers 🦋
This variable-length field holds a list of link state headers that are being acknowledged by this packet ✨. Each header uniquely identifies a link state advertisement and its current instance 💖. (See Section 11.1 for a detailed look at a link state advertisement header.) The number of headers in the list gets worked out implicitly from the length of the packet, as stored in the VLSP packet header (see Section 10.4) 🧚.
11. Link State Advertisement Formats ✨
Link state advertisements describe the different pieces of the routing topology inside the switch fabric 🌈. Every switch in the fabric keeps a complete set of all the link state advertisements generated throughout the fabric 👑. (Section 8.1 covers when a link state advertisement gets originated, and Section 8.2 covers how advertisements get distributed around the switch fabric 💅.) This whole collection, called the link state (or topological) database, is what gets used to calculate a set of best paths to all the other switches in the fabric 🔥.
There are two types of link state advertisement, as listed in Table 8 🍓.
Type Name Function Description
1 Switch link Lists all network Section 11.2
advertisement linksattached to
a switch
2 Network link Lists all adjacen- Section 11.3
advertisement cies on a network
link
Table 8: Link State Advertisement TypesEvery link state advertisement starts with a standard header 🫶, described in Section 11.1 💖.
11.1 Link State Advertisement Headers ✨
okay bestie, every link state advertisement starts with the same 32-octet header 💅 this header is how you know which advertisement you're looking at: its type, its link state ID, and the switch ID of whoever advertised it. and since multiple copies of the same advertisement can be floating around the switch fabric at once, the header also has the age, sequence number and checksum so a switch can figure out which copy is the newest 🧚
here's the layout 👇
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | Age | Options | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04 | |
+ Link state ID +
08 | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
16 | |
+ Advertising switch ID +
20 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Age ⏰ this 2-octet field contains the time, in seconds, since this instance of the link state advertisement was originated.
Options 🎀 this 1-octet field contains the optional capabilities supported by the advertising switch, as described in Section 10.5.
LS type 🌸 this 1-octet field contains the type of the link state advertisement. the possible values are:
1 Switch link advertisement
2 Network link advertisementLink state ID 🦋 this 10-octet field identifies the switch that originates advertisements for the link. what goes in here depends on the advertisement's type:
- for a switch link advertisement, this field contains the switch ID of the originating switch
- for a network link advertisement, this field contains the switch ID of the designated switch for the link
Note: in VLSP, the link state ID of an advertisement is always the same as the advertising switch. this level of redundancy results from the fact that OSPF uses additional types of link state advertisements for which the originating switch is not the advertising switch. 🙈
Advertising switch 💜 this 10-octet field contains the switch ID of the switch that originated the link state advertisement.
Sequence number 🔢 this 4-octet field is used to sequence the instances of a particular link state advertisement. the number is incremented for each new instance.
Checksum 🧮 this 2-octet field contains the checksum of the complete contents of the link state advertisement, excluding the age field. the checksum used is commonly referred to as the Fletcher checksum and is documented in [RFC905]. note that since this checksum is calculated for each separate advertisement, a protocol packet containing lists of advertisements or advertisement headers will contain multiple checksum values. ✨
Length 📏 this 2-octet field contains the total length, in octets, of the link state advertisement, including the header.
11.2 Switch Link Advertisements 🌈
a switch link advertisement is used to describe all functioning network links of a switch, including the cost of using each link. 🔥
each functioning switch in the fabric originates one, and only one, switch link advertisement -- all of the switch's links must be described in a single advertisement. a switch originates its first switch link advertisement (containing no links) when it first becomes functional. then it originates a new instance of the advertisement each time any of its neighbor states changes such that the contents of the advertisement changes. see Section 8.1 for details on originating a switch link advertisement. 💅
the format of a switch link advertisement is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Link state header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32 | (unused -- must be 0) | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
36 | |
+ Link ID +
40 | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
48 | |
+ Link data +
52 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
56 | Link type | # TOS | TOS 0 metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
60 | |
: . . . :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Link state header 🌟 this 32-octet field contains the standard link state advertisement header. the type field contains a 1, and the link state ID field contains the switch ID of the advertising switch.
# links 🧁 this 2-octet field contains the number of links described by this advertisement. this value must be equal to the total number of functioning network links attached to the switch.
Link ID 🗝️ this 10-octet field identifies the other switch that originates link state advertisements for the link, providing a key for accessing other link state advertisements for the link. the value here is based on the link type, as follows:
- for point-to-point links, this field contains the switch ID of the neighbor switch connected to the other end of the link.
- for multi-access links, this field contains the switch ID of the designated switch for the link.
Link data 🎯 this 10-octet field contains additional data necessary to calculate the set of best paths. typically, this field contains the interface ID of the link.
Link type 🧩 this 1-octet field contains the type of link being described. the possible values are as follows:
1 Point-to-point link
2 Multi-access link# TOS 🌷 this 1-octet field contains the number of nonzero type of service metrics specified for the link. since the current version of VLSP does not support routing based on nonzero types of service, this field contains a value of zero.
TOS 0 metric 💎 this 2-octet field contains the cost of using this link for the zero TOS. this value is expressed in the link state metric and must be greater than zero.
Note that the last five fields are repeated for all functioning network links attached to the advertising switch. if the interface state of attached link changes, the switch must originate a new instance of the switch link advertisement. 🚨
11.3 Network Link Advertisements 🦄
a network link advertisement is originated by the designated switch of each multi-access network link. the advertisement describes all switches attached to the link that are currently fully adjacent to the designated switch, including the designated switch itself. see Section 8.1 for details on originating a switch link advertisement. 🫶
network link advertisements are not generated for point-to-point network links. 🙅♀️
the format of a network link advertisement is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
: Link state header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32 | (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
36 | |
+ +
: Switch list :
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Link state header 🌺 this 32-octet field contains the standard link state advertisement header. the type field contains a 2, and the link state ID field contains the switch ID of the designated switch.
Switch list 👯 the switch IDs of all switches attached to the network link that are currently fully adjacent to the designated switch. the designated switch includes itself in this list. 👑
12. Protocol Parameters 🧚♀️
this section contains a compendium of the parameters used in the VLS protocol. 📚
12.1 Architectural Constants
okay bestie, VLS has a few protocol parameters with fixed architectural values 💅 Here's each constant, its value, and what it does ✨
AllSPFSwitches 🧚 The multicast switch ID that Hello packets and certain other protocol packets get addressed to. It shows up in the destination switch ID field of the network layer address information (see Section 10.3). Its value is E0-00-00-05-00-00-00-00. 💖
AllDSwitches 🦋 The multicast switch ID for Link State Update packets and Link State Acknowledgment packets, in the same destination switch ID field (see Section 10.3). It's used when those packets are headed to the designated switch or the backup designated switch of a network link. Its value is E0-00-00-06-00-00-00-00. 🫶
LSRefreshTime ⏰ The interval at which the set of best paths gets recalculated if no other state changes have forced a recalculation. It's set to 1800 seconds (30 minutes). 🌸
MinLSInterval 🎀 The minimum time between distinct originations of any particular link state advertisement. It's set to 5 seconds. 🍓
MaxAge 👑 The maximum age a link state advertisement can reach. When an advertisement's age hits MaxAge, it gets redistributed throughout the switch fabric. Once the originating switch gets an acknowledgment for it, meaning it's been removed from every neighbor's Link state retransmission list, the advertisement gets removed from the originating switch's database. Advertisements with age MaxAge are not used to calculate the set of best paths. MaxAge must be greater than LSRefreshTime. It's set to 3600 seconds (1 hour). 😭
MaxAgeDiff 🌈 The maximum time disparity in ages that can happen for a single link state instance as it travels through the switch fabric. Most of that time is spent sitting on switch output queues (so it isn't aging during that stretch) while the advertisement is distributed. It's set to 900 seconds (15 minutes). 🧚
LSInfinity 💀 The link state metric value that means "this destination is unreachable." It's defined as a binary value of all ones. 🙈
12.2 Configurable Parameters
Many of the switch interface parameters VLSP uses can be made configurable if the implementer wants 🎀 Some have sample default values, which are listed below.
Heads up: some of these describe the individual interfaces and their attached network links. Those parameters must be consistent across all the switches attached to that link 🫶
Interface output cost(s) 💸 The cost of sending a packet over the interface, expressed in the link state metric. This gets advertised as the link cost for this interface in the switch's switch link advertisement. The interface output cost must always be greater than zero. ✨
RxmtInterval 🔁 The number of seconds between link state advertisement retransmissions for adjacencies established on this interface. This value is also used when retransmitting Database Description packets and Link State Request packets. It must be greater than the expected round-trip delay between any two switches on the attached link. However, the value should be conservative, or needless retransmissions will result. A typical value for a local area network is 5 seconds. 🌸
InfTransDelay 🚚 The estimated number of seconds it takes to transmit a Link State Update packet over this interface. Link state advertisements inside that packet must have their age incremented by this amount before transmission. This value must account for the transmission and propagation delays for the interface, and it must be greater than zero. A typical value for a local area network is 1 second. 💅
Switch priority 👑 An 8-bit unsigned integer. When two switches attached to the same network link contend for selection as the designated switch, the switch with the highest priority takes precedence. If both switches have the same priority, the switch with the highest base MAC address becomes the designated switch. A switch whose switch priority is set to zero is ineligible to become the designated switch on the attached link. 🥀
HelloInterval 👋 The length of time, in seconds, between the Hello packets the switch sends over the interface. This value is advertised in the switch's Hello packets. It must be the same for all switches attached to a common network link. The smaller this value is set, the faster topological changes get detected. A smaller interval also generates more routing traffic, though. A typical value for a local area network is 10 seconds. 🍓
SwitchDeadInterval 💤 The length of time, in seconds, that neighboring switches will wait before declaring the interface down once they stop receiving Hello packets over it. This value is advertised in the switch's Hello packets. It must be the same for all switches attached to a common network link, and it should be some multiple of the HelloInterval parameter. A typical value is 4 times HelloInterval. 🦋
13. End Notes
[1] Okay so, while calculating the set of best paths, a network link advertisement has to be found using only its link state ID. The lookup still works perfectly fine here, since no two network advertisements can share the same link state ID 🧠✨
[2] This one is super instructive 🤓 Think about what happens when the designated switch for a network link fails. Call the designated switch for the link S1 and the backup designated switch S2. If switch S1 fails (or its interface to the link goes down), the other switches on the link will notice S1 is gone within SwitchDeadInterval seconds. Not every switch notices at exactly the same moment. Any switch that spots S1's absence before S2 does will temporarily pick S2 as both designated switch and backup designated switch. Once S2 detects that S1 is down, it moves itself up to designated switch. At that point, the remaining switch with the highest switch priority gets selected as the backup designated switch 👑
[3] It's possible for a switch to resynchronize any of its fully established adjacencies by setting the neighbor state back to ExStart. That makes the switch on the other end of the adjacency process a SeqNumberMismatch event, and it also reverts to the ExStart state too 🔄
[4] When two advertisements have different checksum values, they're treated as separate instances. This can happen when a switch restarts and loses track of its previous sequence number. Since both advertisements have the same sequence number in that case, there's no way to tell which one is actually newer 🤷♀️ If the wrong advertisement gets accepted as newer, the originating switch will originate another instance.
[5] An instance of an advertisement is only originated with an age of MaxAge when it's about to be flushed from the database 🗑️ That happens either when the advertisement has naturally aged to MaxAge, or (more typically) when the sequence number has to wrap. So a received instance with an age of MaxAge must be processed as the most recent one, so it can be flushed properly from the database.
[6] MaxAgeDiff is an architectural constant that sets the maximum disparity in ages, in seconds, that can happen for a single link state instance as it's distributed throughout the switch fabric. If two advertisements differ by more than this amount, they're assumed to be different instances of the same advertisement. This can happen when a switch restarts and loses track of its previous sequence number 🌀
[7] This is how the link state request list gets emptied, which makes the neighbor state change to Full 🎉
14. Security Considerations
Plot twist: this document doesn't address security concerns at all 💀
Security concerns are not addressed in this document. 🙈
15. References
- [Perlman] Perlman, R., Interconnections: Bridges and Routers. Addison-Wesley Publishing Company. 1992. 📚
- [RFC905] McKenzie, A., "ISO Transport Protocol specification ISO DP 8073", RFC 905, April 1984. 📖
- [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 📖
- [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. 📖
- [IDsfvlan] Ruffen, D., Len, T. and J. Yanacek, "Cabletron's SecureFast VLAN Operational Model", RFC 2643, August 1999. 📖
- [IDhello] Hamilton, D. and D. Ruffen, "Cabletron's VlanHello Protocol Specification", RFC 2641, August 1999. 📖
16. Author's Address
Laura Kane
Cabletron Systems, Inc.
Post Office Box 5005
Rochester, NH 03866-5005
Phone:(603) 332-9400
EMail: lkane@ctron.com17. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. 🔒
This document and translations of it may be copied and furnished to others. Derivative works that comment on or otherwise explain it, or help with its implementation, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind. That's allowed as long as the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The one exception is when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed. The other exception is when it's required to translate it into languages other than English. 🫶
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. ✨
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💅
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society. 💖🎀
📦 where this page comes from
- ietf: rfc2642 1999-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms