RFC 2174
A MAPOS version 1 Extension - Switch-Switch Protocol
Status of this Memo ✨
Quick legal-ish bit first, bestie 💅 This memo gives information to the Internet community, but it does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌈
Authors' Note 📝
This memo documents a MAPOS (Multiple Access Protocol over SONET/SDH) version 1 extension, the Switch Switch Protocol, which gives you dynamic routing for unicast, broadcast, and multicast 🦋 This document is not the product of an IETF working group, and it's not a standards track document. It also hasn't necessarily had the big, in-depth community review that standards track documents get, so keep that in mind 🫶
Abstract 🌸
So this doc describes a MAPOS version 1 extension called SSP (Switch Switch Protocol). MAPOS is a multiple access protocol for sending network-protocol packets, wrapped up in High-Level Data Link Control (HDLC) frames, over SONET/SDH. In a MAPOS network, a SONET switch gives the end nodes their multiple access capability ✨ SSP is a Distance Vector family protocol, and it handles unicast and broadcast/multicast routing for environments with multiple SONET switches 🧚
1. Introduction 🎀
Okay so this document is an extension to MAPOS version 1, the Switch Switch Protocol, for routing both unicast and broadcast/multicast frames 💜 MAPOS[1] (Multiple Access Protocol over SONET (Synchronous Optical Network) / SDH (Synchronous Digital Hierarchy) [2][3][4][5]) is a link layer protocol for sending HDLC frames over SONET/SDH. A SONET switch gives each node multiple access capability 🍓
SSP is a dynamic routing protocol built for when a MAPOS network segment spans several switches. It's a Distance Vector family protocol, and it does both unicast and broadcast/multicast routing, so it's giving full coverage 👑 The doc goes like this: first, the outline of SSP. Next, the unicast and broadcast/multicast routing algorithms. Then, the detailed SSP protocol itself 🔥
2. Constraints in Designing SSP 🔥
SSP is a unified routing protocol that supports both unicast and broadcast/multicast 💖 The unicast side is based on the Distance Vector [6][7] algorithm, and the broadcast/multicast side is based on the spanning tree[8] algorithm 🌈 In MAPOS version 1, a small number of switches is assumed in a segment. So unlike DVMRP (Distance Vector Multicast Routing Protocol)[8], TRPB (Truncated Reverse Path Broadcasting) is not supported, just to keep things simple. The result is that multicast frames get treated exactly like broadcast frames and get delivered to every node 🙈
There are two constraints on designing the broadcast/multicast routing algorithm in MAPOS version 1:
(1) there is no source address field in MAPOS HDLC frames
(2) there is no TTL (Time To Live) field in MAPOS HDLC frames to prevent forwarding loop.
Okay so for the first problem, the VRPB (Virtual Reverse Path Broadcast) algorithm comes in 🦋 With VRPB, every broadcast and multicast frame is assumed to be generated by a node under one specific switch called the VSS (Virtual Source Switch). The VSS is the switch with the smallest switch number in the MAPOS network 👑 Each switch works out its own place in the spanning tree rooted at the VSS, all on its own. Whenever a switch gets a broadcast/multicast frame, it forwards that frame to all upstream and downstream switches, except the one that sent the frame to the local switch 💅
For the second problem, the forward delay timer is introduced ⏱️ Even when a switch finds a new VSS, it suspends forwarding for a set period of time. This timer makes sure all the switches end up with consistent routing information and stay synchronized after a topology change. It's iconic, honestly 🫶
3. Unicast Routing in SSP 🧚
This section covers the address structure of MAPOS version 1 and the SSP unicast routing that's built on top of it 🎀
3.1 Address Structure of MAPOS version 1 💜
In a multiple switch environment, a node address is made of the switch number and the port number the node is connected to. As shown in Figure 1, the address length is 8 bits, and the LSB is always 1, which marks the end of the address field 🌸 An MSB of 0 means it's a unicast address. The switch and port number fields are variable-length. In this document, a unicast address is written as "0 <switch-number> <port number>". Note that the port number includes the EA bit 💖
An MSB of 1 means multicast or broadcast. For broadcast, the address field is all 1s (0xff in hex). For multicast, the remaining bits give a group address. The switch number field is variable-length. A multicast address is written as "1 <group address>" ✨
Switch Number(variable length)
|
| +--- Port Number
| |
V V
|<->|<------->|
+-------------+-+
| | | | | | | | |
| | |1|
+-+-----------+-+
^ ^
| |
| +------- EA bit (always 1)
|
1 : broadcast, multicast
0 : unicast
Figure 1 Address FormatFigure 2 shows an example of a SONET LAN made of three switches. In this setup, two bits of a node address are used for the switch number. Node N1 is connected to port 0x03 (000011 in binary) of switch S2, which is numbered 0x2. So the node address is 01000011 in binary. Node N4 has the address 01101001 in binary, since its switch number is 0x3 and its port number is 0x09 🦋
01000011
+------+
| node |
| N1 |
+------+
01000101 |0x03 |0x03 00101001
+------+ +---+----+ +---+----+ +------+
| node +-----+ SONET +---------+ SONET +------+ node |
| N2 | 0x05| Switch |0x09 0x05| Switch |0x09 | N3 |
+------+ | S2 | | S1 | +------+
| (0x2) | | (0x1) |
+---+----+ +---+----+
|0x07 |0x07
| |
| |0x03 01101001
| +---+----+ +------+
+--------------+ SONET +-----+ node |
0x05| Switch |0x09 | N4 |
| S3 | +------+
| (0x3) |
+---+----+
|0x07
Figure 2 Multiple SONET Switch Environment3.2 Forwarding Unicast Frames 🚀
Unicast frames take the shortest path 🛣️ For example, a frame from node N4 headed to N1 gets forwarded by switch S3 and then S2. These SONET switches forward an HDLC frame based on the destination switch number that's in the destination address 💅
Each switch keeps a routing table with entries for the possible destination switches. Each entry has the subnet mask, the next hop (the adjacent switch on the shortest path to the destination), the metric that measures the total distance to the destination, and other parameters tied to the entry, like timers 🌈 For example, the routing table in switch S1 looks like Table 1. A metric value of 1 means the destination switch is an adjacent switch. A value of 16 means it's unreachable. The values between 17 and 31 also mean unreachable, but they're special values used for split horizon with poisoned reverse [8] 🙈
+-------------------------+----------+--------+------------+
| destination | subnet | next hop | metric | other |
| switch | mask | port | | parameters |
+-------------+-----------+----------+--------+------------+
| 01000000 | 11100000 | 00000101 | 1 | |
+-------------+-----------+----------+--------+------------+
| 01100000 | 11100000 | 00000111 | 1 | |
+-------------+-----------+----------+--------+------------+
Table 1 An Example of a Routing TableWhen a switch receives a unicast frame, it pulls the switch number out of the destination address. If that equals the local switch number, the frame goes to the local node through the port given in the destination address. Otherwise, the switch looks up its routing table for a matching destination switch number by masking the destination address with the matching subnet mask. If it finds a matching entry, the frame is sent to an adjacent switch through the next hop port in that entry. If not, it's silently discarded or sent to the control processor for error processing 🥺
3.4 Protocol Overview 🧠
This subsection gives an overview of the unicast routing protocol and its algorithm 💖
3.4.1 Route Exchange 💌
SSP is a distance vector protocol that establishes and maintains the routing table ✨ In SSP, each switch sends a routing update message to every adjacent switch every FULL_UPDATE_TIME (10 seconds by default). The update message is a copy of the routing table, meaning the routes themselves 🦋
When a switch gets an update message from an adjacent switch through a port, it adds the cost associated with that port, usually 1, to every metric value in the message. The result is a set of new metrics from the receiving switch to the destination switches. Next, it compares those new metrics with the matching entries in the existing routing table. A smaller metric means a better route 🏆 So if the new metric is smaller than the existing one, the entry gets updated with the new metric and next hop. The next hop is the port the update message came in on. Otherwise, the entry stays unchanged. If the existing next hop is the same as the new one, the metric gets updated no matter what the metric value is. If no matching route is found, a new route entry is created 🌸
That's part 1 of 4 bestie, more coming up next 💜✨
3.4.2 Route Expiration
okay so, say a neighboring switch S advertises a route to R 💅 If no update message has come in from switch S for FULL_UPDATE_TIME * 3 (30 seconds by default), OR the route shows up with metric 16 from switch S, then the route to R gets marked unreachable by setting its metric to 16. so the route is still advertised even if nobody refreshes it for up to 30 seconds 🫶
here's how that works under the hood ✨ every routing table entry gets an EXPIRATION_TIMER (30 seconds by default, which is FULL_UPDATE_TIME *3). if another switch advertises a route to R, that new route replaces the unreachable one 🦋 even after a route is marked unreachable, the entry stays in the routing table for FULL_UPDATE_TIME * 3, and that's the whole point, because it lets the switch tell its neighbors about the unreachable route by sending update messages with metric 16. 📣 for this, every routing table entry also has a garbage collection timer, GC_TIMER (30 seconds by default), and the entry gets deleted when that timer expires. Figure 3 shows this whole transition, and it's giving "timeline glow-up" 🌸
The Last Update Expiration Garbage Collection
| | |
Routing V T T T V T T T V
Table +-------+-------+-------+-------+-------+-------X
Entry metric < 16 | metric = 16 |
----------------------->|---------------------->|
EXPIRATION_TIMER GC_TIMER
Stop Advertising
|
Advertised V
Metric -- metric <16 ------+-- metric = 16 -------X
T: FULL_UPDATE_TIME
Figure 3. Route Expiration3.4.3 Slow Convergence Prevention
bestie, this part is so important 🥺 two techniques get used to stop routing info from converging slowly: split horizon with poisoned reverse, and triggered update 🎀
Sn <------------- S3 <- S2 <- S1
(i) Before Outage
->
Sn <-- X -- S3 <- S2 <- S1
(ii) After Outage
Figure 4 An Example of Slow ConvergenceFigure 4 is an example of slow convergence[6] and honestly it's a mess 😭 in (i), three switches, S1, S2, and S3, all have a route to Sn. then in (ii), the connection to Sn drops because of an outage. but S2 keeps advertising the route, because S2 has no way to detect the outage right away and the route to Sn is still sitting in its routing table 💀 so S3 thinks S2 has the best route to Sn, with S2 as the next hop. this creates a transitive loop between S2 and S3 🔁 S2 and S3 keep incrementing the metric of the route to Sn every time they advertise it, and the loop keeps going until the metric hits 16. to shut down that slow convergence problem, split horizon with poisoned reverse gets used 🙅♀️
with split horizon with poisoned reverse, a route gets advertised as unreachable to the next hop. the metric is the received metric value plus 16. so in Figure 4, S2 advertises the route to Sn with the metric unreachable only to S3 🫠 that way S3 never considers S2 to be the next hop to Sn. this makes sure convergence is fast when a route disappears ⚡
the other technique, triggered update, makes a switch send an immediate update instead of waiting for the next periodic update. this happens when a switch detects a local port failure, or when it receives a message saying a route has become unreachable or that its metric has gone up 📨 it's a total speed boost for convergence 🚀
4. Broadcast/multicast Routing in SSP ✨
this section explains the VRPB algorithm and gives the outline of the broadcast/multicast routing protocol 🧚
4.1 Virtual Reverse Path Broadcast/Multicast Algorithm
SSP does broadcast/multicast routing using a spanning tree algorithm 🌳 like Section 2 said, the routing is based on the VRPB (Virtual Reverse Path Broadcast) algorithm. in VRPB, every switch assumes all broadcast and multicast frames come from one specific switch, the VSS (Virtual Source Switch). so unlike DVMRP, a MAPOS network only has ONE spanning tree at any given time 👑
frames get forwarded along the reverse path, computed as the shortest path from the VSS to all possible recipients 🛤️ the VSS is the switch with the lowest switch number in the network. the routing table holds all the unicast destination addresses, switch numbers included, so every switch can figure out who the VSS is on its own, just by searching for the smallest switch number in its unicast routing table 🔍
in Figure 2, switch S1 is the VSS 💖 each switch works out its place in the spanning tree relative to the VSS, plus which of its ports sit on the shortest path tree. so the spanning tree ends up looking like Figure 5. except for the VSS, each switch has one upstream port and zero or more downstream ports. the VSS has no upstream port, since it's the root of the spanning tree 🌟 and in Figure 2, switch S2's upstream port is port 0x09, and S2 has no downstream port.
S1 (VSS)
/ \
/ \
/ \
S2 S3
Figure 5 VRPB Spanning Treewhen a switch gets a broadcast/multicast frame, it forwards that frame to all of the upstream switch, the downstream switches, and the directly connected nodes 📦 but it does NOT send it back to the switch that sent it the frame. a bit mapped broadcast/multicast routing table may be used for this 🧩 the broadcast/multicast routing process marks every bit that matches a port the frame should go out of. then the forwarding process looks at those marks and broadcasts the frame to every port with its bit marked 🎯
4.2 Forwarding Broadcast/multicast Frames
when a switch forwards a broadcast/multicast frame, here's the vibe: (1) first it figures out the VSS by checking its unicast routing table. then (2) it checks its broadcast/multicast routing table for that VSS. a cache may be used to cut down on search overhead 🏃♀️ and (3) based on that routing table, the switch forwards the frame 📬
Figure 6 shows an example of S2's broadcast/multicast routing table for the VSS S1. it's a bit map table, and each bit matches a port. a value of 1 means the frame should be forwarded to a node or a switch through that port. if no bit is marked, the frame gets silently discarded 🫥 in the Figure 6 example, port 0x09 is the upstream port toward its VSS, S1. the other ports, 0x05 and 0x03, are the paths to N2 and N1 nodes, respectively 🍓
0F 0D 0B 09 07 05 03 01 --- port number
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 1 | 0 | 1 | 1 | 0 | --- 1: forward
+---+---+---+---+---+---+---+---+ 0: inhibit
Figure 6 Broadcast/Multicast Routing Table of S24.3 Forwarding Path Examples
okay picture this 🎬 a broadcast frame gets generated by N2 in Figure 2, and it's received by S2 💕
S2 passes it to all the connected nodes except the source, N2. so that's only N1. at the same time, it also forwards the frame to all its upstream and downstream switches. since S2 has no downstream switch, S2 forwards the frame to S1 through its upstream port 0x09 🌈
S1 is the VSS, so it passes the frame to all its local nodes, which is only N3. since S1 has no upstream switch, and S2 is the switch that sent the frame to S1, the frame ends up going only to a downstream switch, S3 🌸
S3 passes the frame to its local node, N4. since S3 has only an upstream port, and the frame came in through that port, S3 does NOT forward the frame to any switch 🙅♀️
the resulting path is shown in Figure 7. this isn't the optimal path, but VRPB at least makes sure broadcast/multicast frames reach all the nodes without looping 🔁✨ Figures 8 and 9 show the forwarding paths for frames generated by a node under S3 and S4, respectively 🧚
+-> N3
|
N2 -> S2 +-> S1 +-> S3 -> N4
|
+-> N1
Figure 7 Forwarding Path from N2 +-> N1
|
N3 -> S1 +-> S2 +-> N2
|
+-> S3 --> N4
Figure 8 Forwarding Path from N3 +-> N3
|
N4 -> S3 +-> S1 +-> S2 +-> N1
|
+-> N2
Figure 9 Forwarding Path from N44.4 Suppressing Routing Loop
to stop transitive routing loops, forward delay gets used 🙈 a switch pauses broadcast/multicast forwarding for a while after it finds a new VSS in the routing table. this stops transitive routing loops by giving all the switches time to have the same routing information and get synchronized ⏳ on top of controlling when frames get sent with forward delay, there's a second mechanism for controlling reception to prevent transitive routing loops too. that means broadcast/multicast frames received through any ports other than the upstream and downstream ports get discarded 🗑️
4.5 Upstream Switch Discovery
the upstream port is decided by the shortest reverse path to the VSS 🧭 it gets identified by looking at the next hop port of the route to the VSS in the local unicast routing table. when a new next hop to the VSS is discovered, the bit for the old next hop port gets cleared, and the bit for the new one gets marked as the upstream port in the broadcast/multicast routing table 🔄
4.6 Downstream Switch Discovery
to figure out the downstream ports, split horizon with poisoned reverse is used 🫶 when a switch receives a route with a metric poisoned by split horizon processing through a port (like we covered in Section 3.4.3), that port is considered a downstream port. in Figure 2, S1 is the VSS, and S2 sends the route information back to S1 with metric unreachable, based on split horizon with poisoned reverse. so S1 knows S2 is one of its downstreams 💜
4.7 Downstream Port Expiration ✨
Okay so when a poison reversed packet shows up on a port for the very first time, the local switch is like "ooh, a new downstream switch just appeared 👀💖". It marks the bit for that port and starts FORWARD_DELAY_TIMER (30 seconds by default, that is, FULL_UPDATE_TIME * 3) for it. Broadcast/multicast frames are not forwarded to that port until the timer expires 🎀.
Every time the local switch gets a poison reversed packet through a port, it resets PORT_EXPIRATION_TIMER (30 seconds by default, that is, FULL_UPDATE_TIME *3) for that port. If the poison reversed packets stop coming in (a continuous loss), or the downstream port fails, PORT_EXPIRATION_TIMER expires and the corresponding bit gets cleared 💀.
First Update Last Update
| |
V T T T T T T T V
+---+---+---+---+---+---+---+---+---+---+---+---+---
A bit in
the routing 0 0 0 1 1 1 1 1 1 1 0 0 0
table ^ ^
<--------->| <--------->|
^ route up ^ route down
| |
FORWARD_DELAY PORT_EXPIRATION
T: FULL_UPDATE_TIME
Figure 10. Port ExpirationNow, when a downstream switch finds another best path to the VSS or a new VSS, it stops split horizon with poison reverse and sends ordinary update messages instead 🦋. Whenever the local switch gets an ordinary update message from that downstream switch, it SHOULD immediately clear the corresponding bit in the routing table and stop forwarding broadcast/multicast frames. Iconic move 👑.
4.8 Node Discovery 🧚
When a NSP[9] packet arrives requesting a node address from a port, the local switch considers that a new node is connected 🌸. It marks the corresponding bit in the broadcast/multicast routing table. When the local switch detects that the port went down as described in [9], it clears the corresponding bit. Bye bye bit 🫶.
4.9 Invalidating The Broadcast/multicast Routing Table 💅
When a new VSS is discovered, or when the VSS becomes unreachable, the entire broadcast/multicast routing table gets invalidated. Main character energy: a change of upstream port affects the entire broadcast/multicast routing. A change of a downstream port, however, does not affect forwarding to other downstream ports, its upstream port, and nodes 🌈.
5. Detailed Protocol Operation 📖
This section explains SSP packet format and protocol processing in detail. Let's go 🔥.
5.1 Packet Format 🎀
This subsection describes the packet encapsulation in HDLC frame and the packet format.
5.1.1 Packet Format and Its Encapsulation 🍓
SSP packet format is designed based on RIP[6] and its successor, RIP2 [7]. Figure 11 shows the packet format. A SSP packet is encapsulated in the information field of a MAPOS HDLC frame. The HDLC protocol field of SSP is 0xFE05 in hex, as defined by the "MAPOS Version 1 Assigned Numbers" [10]. The packet is sent encapsulated in a unicast packet with the destination address 0000 0001, which indicates the control processor of an adjacent switch 💜.
(MSB) (LSB)
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----
| Command | Version | unused |SSP header
+---------------+---------------+-------------------------------+ -----
| Address Family Identifier | All 0 |
+-------------------------------+-------------------------------+
| HDLC Address | an SSP
+---------------------------------------------------------------+ route
| Subnet Mask | entry
+---------------------------------------------------------------+
| All 0 |
+---------------------------------------------------------------+
| Metric |
+---------------+---------------+-------------------------------+ ----
| Address Family Identifier | All 0 |
Figure 11 SSP packet formatThe maximum packet size is 512 octet. The first four octets are the SSP header. The remainder of the message is composed of 1 - 25 route entries. Each entry is 20 octets long 🧁.
5.1.2 SSP Header 🌷
SSP header consists of a Command field and a Version field. The Command field is one octet long and holds one of the following values:
1 - request A request to send all or part of SSP routing table.
2 - response A message containing all, or a part of the sender's
SSP routing table. This message may be sent in
response to a request, or it may be an update
message generated by the sender.The Version field indicates the version of SSP being used. The current version number is 1 ✨.
5.1.3 SSP Route Entries 🦄
Each entry has an address family identifier. It indicates an attribute of the entry. The SSP routing protocol uses 2 as its identifier by default. The identifier 0 indicates unspecified. This value is used when a switch requests other switches to send the entire SSP routing table. A recipient of the message SHOULD ignore all entries with unknown value 🙈.
The HDLC address is a destination address. It may be a switch address or a node address. The subsequent subnet mask is applied to the HDLC address to yield the switch number portion. The field is 4 octet long, and the address is placed in the least significant position.
Metric indicates the distance to the destination node. That is, how many switches a message must go through en route to the destination node. The metric field must contain a value between 1 and 31. The metric of 16 indicates that the destination is not reachable, and it is ignored by recipients 💀. The values between 17 and 31 are utilized for poisoned reverse with split horizon, and they also mean unreachable. The metric 0 indicates the local switch itself.
5.2 Routing Table 🗂️
Every switch has an SSP routing table. The table is a collection of route entries, one for every destination. An entry consists of the following information:
- (1) destination : A unicast destination address.
- (2) subnet mask : A mask to extract the switch address by applying bitwise AND with the destination address.
- (3) next hop port : The local port number connected to the adjacent switch along the path to the destination.
- (4) metric : Distance to the destination node. The metric of an adjacent switch is 1, and that of the local switch is 0.
- (5) timers for unicast routing : Timers associated with unicast routing, such as EXPIRATION_TIMER and GC_TIMER.
- (6) flags : Various flags associated with the route, such as the route change flag, which indicates that the route has changed recently or that it has timed out.
- (7) bit map routing table for broadcast/multicast : Each bit corresponding to the port to an upstream or a downstream switch of the spanning tree is marked, in addition to the ports to end nodes. Broadcast/multicast frames are forwarded only through those ports with their corresponding bit set. Since only one spanning tree exists at a time in a network, each route entry does not necessarily have to have this field 🌟.
- (8) timers for broadcast/multicast routing : Timers associated with broadcast/multicast routing, such as FORWARD_DELAY_TIMER and PORT_EXPIRATION_TIMER. These timers are prepared for each bit of the broadcast/multicast routing table.
5.3 Sending Routing Messages 📨
5.3.1 Packet Construction 🧩
Because of the split horizon with poisoned reverse, a routing message differs depending on the adjacent switch to which the message is being sent. The upstream switch of a route, that is, the next hop, receives a message which contains the corresponding route with a metric between 17 and 31. Switches that are not the upstream switch of any route receive the same message. Here, we assume that a packet for a routing message is constructed for an adjacent switch which is connected through the local port N.
First, set the Version field to 1, the current SSP version. Then, set the command to "response". Set other fields which are supposed to be zero to zero. Next, start filling in entries.
To fill in the entries, perform the following for each route. The destination HDLC address, netmask, and its metric are put into the entry in the packet. Routes must be included in the packet even if their metrics are unreachable (16). If the next hop port is N, 16 is added to the metric for split horizon with poisoned reverse.
Recall that the maximum packet size is 512 bytes. When there is no more space in a packet, send the current message and start a new one. If a triggered update is being generated, only entries whose route change flags are set need be included 🎯.
5.3.2 Sending update 📣
Sending update may be triggered in any of the following ways:
(1) Initial Update 🌅
When a switch first comes up, it SHOULD send to all adjacent switches a request asking for their entire routing tables. The destination address is 00000001. When a port comes online, the request packet is sent to the port. The packet requesting the entire routing table MUST have at least an entry with the address family identifier 0, meaning unspecified.
When a switch receives a request packet, it first checks the version number of the SSP header. If it is not 1, the packet is silently discarded. Otherwise, the address family identifier is examined. If the value is 0, the entire SSP routing table is returned in one or more response packets destined to 00000001. Otherwise, the request is silently discarded. Although the original RIP specification defines the partial routing table request, the SSP routing protocol omits it for the sake of simplicity 🙌.
(2) Periodic Update ⏰
Every switch participating in the routing process sends an update message (response message) to all its neighbor switches once every FULL_UPDATE_TIME (10 seconds). For the periodic update, a response packet(s) is used. The destination address is always 00000001. An update message contains the entire SSP routing table. The maximum packet size is 512byte. Thus, an update message may require several packets to be packed 📦.
(3) Triggered Update ⚡
When a route in the unicast routing table is changed, or a local port goes down, the switch advertises a triggered update packet without waiting for the full update time. The difference between a triggered update and the other updates is that triggered updates do not have to include the entire routing table. Only changed entries should be included. A triggered update may be suppressed if a regular periodic update is due 🫧.
Note that when a route is advertised as unreachable (metric 16) by an adjacent switch, the update process is triggered, as well as the expiration of the route in the local switch 🚨.
(4) On Termination 🌙
When a switch goes down, it is desirable to advertise all the routes with metric 16, that is, unreachable 💜.
5.4 Receiving Routing Messages ✨
okay so when a switch gets an update 📬, the very first thing it checks is the version number. if it is not 1, the update packet is silently discarded 🙈 (gone, no drama). otherwise it works through the entries one by one, bestie 💅
for each entry, the address family identifier gets checked. if it is not 2, the entry is ignored. otherwise the metric gets checked. the value should be between 0 and 31, and an entry with an illegal metric is ignored. next up, the HDLC address and the subnet mask get checked, and an entry with an invalid address such as broadcast is ignored too. if the entry passes all of these validation checks, it gets processed using the steps below 🦋
Step 1 - Process Poisoned Reverse
if the metric value is between 0 and 16, it is an unicast information. go ahead to Step 2 🌸
if the metric value is between 17 and 31, that's poisoned reverse 🔄. it means the local switch has been chosen as the next hop for the route. BUT, if the matching entry is not in the current routing table, or the message comes from a port connected to its upstream switch, the message is illegal. ignore it and go back to Step 1 for the next entry. otherwise:
- (1) Initialize the
PORT_EXPIRATION_TIMERcorresponding to the downstream port. - (2) Operate the
FORWARD_DELAY_TIMERas follows;- (2-1) If the broadcast/multicast forwarding was already enabled, go to (3).
- (2-2) If the
FORWARD_DELAY_TIMERcorresponding to the downstream port was already started, increment the timer. If the timer expires, mark the bit in thebroadcast/multicast routing tablecorresponding to the port and stop the timer. - (2-2) Otherwise, start the
FORWARD_DELAY_TIMER.
- (3) Return to Step 1 to process the next entry.
Step 2 - Process Unicast Routing Information
first, add the cost associated with the link, usually 1, to the metric. if the result is greater than 16, 16 is used. then look up the unicast routing table for the corresponding entry. there are two cases 👀
Case 1 no corresponding entry is found
if the new metric is 16, return to step 1 to process the next entry. otherwise:
- (1) Create a new route entry in the routing table
- (2) Initialize
EXPIRATION_TIMERandGC_TIMER - (3) The port corresponding to the new route is the
next_hopport for the route. Thus, mark the bit in thebroadcast/multicast routing tablecorresponding to the newnext_hopport and startFORWARD_DELAY_TIMER. If this new route is for the switch with the minimum switch number, select it as theVSSand use itsbroadcast/multicast routing table. (See NOTE 1.) - (4) Set the route change flag and invoke triggered update process
- (5) Return to step 1 to process the next entry.
[NOTE 1] There are two implementations; - (1) Prepare a spanning tree for each route and use only one corresponding to the currentVSS. In this case, each unicast route entry has a broadcast/unicast routing table. - (2) Prepare only one spanning tree corresponding to the currentVSS. In this case, a switch has only one broadcast/multicast routing table. In this document, the former is assumed.
Case 2. A corresponding entry is found
in this case, the update message gets handled differently depending on the new metric value 🎀
- (a)
new_metric < 16 & new_metric > current_metric- (1) If and only if the update is from the same port (
next_hopport) as the existing one,- (1-1) Update the entry
- (1-2) Initialize
EXPIRATION_TIMERandGC_TIMER
- (2) If the corresponding bit to the port, which the update message is received, is marked in the broadcast/multicast routing table, clear the bit.
- (3) Return to Step 1 and process the next entry.
- (1) If and only if the update is from the same port (
- (b)
new_metric < 16 & new_metric < current_metric- (1) Update the entry and clear the bit in the broadcast/multicast routing table corresponding to the old
next_hopport. - (2) Initialize
EXPIRATION_TIMER,GC_TIMER, andPORT_EXPIRATION_TIMERfor the newnext_hopport. - (3) Mark a bit in the broadcast/multicast routing table corresponding to the new
next_hopport and startFORWARD_DELAY_TIMER. - (4) Set the route change flag and invoke triggered update with poisoned reverse for the new
next_hop. - (5) Return to Step 1 to process the next entry.
- (1) Update the entry and clear the bit in the broadcast/multicast routing table corresponding to the old
- (c)
new_metric < 16 & new_metric = current_metric
if a new route with the same metric value as the existing routing table entry is received, use the old one as follows;
- (1) If the new next hop is equal to the current one, initialize
EXPIRATION_TIMERandGC_TIMER. Otherwise, ignore this update. - (2) If the bit corresponding to the port, from which the update message was received, is marked in the broadcast/multicast routing table, clear the bit.
- (3) Return to Step 1 to process the next entry.
- (d)
the new metric = 16 & the new next hop = the current one
if the current metric is not equal to 16, this is new unreachable information. then:
- (1) Update the entry and clear the bit in the broadcast/multicast routing table corresponding to the old
next_hopport. - (2) If this route is for the current
VSS, select a newVSSin the valid routing table entries. Valid means that the destination is reachable. - (3) Set the route change flag and invoke triggered update process to notify the unreachable route.
otherwise, do nothing and return to Step 1 to process the next entry.
- (e)
the new metric = 16 & the new next hop /= the current one- (1) If the bit corresponding to the port, from which the update message was received, is marked in the broadcast/multicast routing table, clear the bit.
- (2) Return to Step 1 to process the next entry.
5.5 Timers ⏰
the timer routine ticks up the following timers and runs their associated process when they expire 💖
(1) EXPIRATION_TIMER and GC_TIMER
The EXPIRATION_TIMERs and GC_TIMERs of each entry in the unicast routing table are incremented every FULL_UPDATE_TIME (10 seconds by default). When a EXPIRATION_TIMER expires, the metric is changed to unreachable(16), update process is triggered, and GC_TIMER is started. When a GC_TIMER expires, the entry is deleted from the local routing table. EXPIRATION_TIMER and GC_TIMER are cleared every time a switch receives a routing update.
(2) FORWARD_DELAY_TIMER
FORWARD_DELAY_TIMER is completely handled in the receive process and has no relation to the timer routine. 🙅♀️
(3) PORT_EXPIRATION_TIMER
PORT_EXPIRATION_TIMERs associated with each bit in the broadcast/multicast routing table are incremented every FULL_UPDATE_TIME (10 seconds by default). When the timer expires, the corresponding downstream switch is considered to be down and the corresponding bit in the broadcast/multicast routing table is cleared. This timer is cleared by the receive process every time a poisoned reverse packet is received from the corresponding switch.
6. Further considerations on implementation 🛠️
6.1 Port State
A switch assumes that every port is connected to a switch initially. Thus, it sends update packets to every port. When a node is connected to a port, the switch recognizes it by receiving an NSP request packet, and stops sending SSP packets to the port. Whenever a switch detects a connection failure such as loss of signal and out-of-synchronization, it should clear the internal state table corresponding of the port.
6.2 Half way connection problem
this one is a bit of a plot twist 😭 A port consists of two channels, transmit and receive. Although it is easy for a node or a switch to detect a receive channel failure, transmit channel failure may not be detected, causing half way connection. This results in a black hole 🕳️
Thus, whenever a switch receives a SSP update packet from a port, it SHOULD check the status of the corresponding transmit channel. SONET/SDH has a feedback mechanism for that purpose. The status of the local transmit channel received at the remote end can be sent back utilizing the overhead part, FEBE(Far End Block Error) and FERF(Far End Receive Failure), of the corresponding receive channel. If the signals indicates that the transmit channel has a problem, the SSP packet received from the remote end should be silently discarded. However, some SONET/SDH services do not provide path overhead transparency.
Although, SONET/SDH APS(Automatic Protection Switching) can be utilized to switch service from a failed line to a spare line, the function is out of scope of this protocol.
7. Security Considerations 🔐
Security issues are not discussed in this memo. 💀 I know, I know, a bold choice.
References 📚
- [1] Murakami, K. and M. Maruyama, "MAPOS - Multiple Access Protocol over SONET/SDH Version 1," RFC2171, June 1997.
- [2] CCITT Recommendation G.707: Synchronous Digital Hierarchy Bit Rates, 1990.
- [3] CCITT Recommendation G.708: Network Node Interface for Synchronous Digital Hierarchy, 1990.
- [4] CCITT Recommendation G.709: Synchronous Multiplexing Structure, 1990.
- [5] American National Standard for Telecommunications - Digital Hierarchy - Optical Interface Rates and Formats Specification, ANSI T1.105-1991.
- [6] Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058, Rutgers University, June 1988.
- [7] Malkin, G., "RIP Version 2 - Carrying Additional Information ", RFC1723, Xylogics, Inc., November 1994.
- [8] Pusateri, T., "Distance Vector Multicast Routing Protocol", September 1996, Work in Progress.
- [9] Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension - Node Switch Protocol," RFC2173, June 1997.
- [10] Maruyama, M. and K. Murakami, "MAPOS Version 1 Assigned Numbers," RFC2172, June 1997.
Acknowledgements 🫶
The authors would like to acknowledge the contributions and thoughtful suggestions of John P. Mullaney, Clark Bremer, Masayuki Kobayashi, Paul Francis, Toshiaki Yoshida, Takahiro Sajima, and Satoru Yagi. 🌈
Authors' Address 💌
Ken Murakami
NTT Software Laboratories
3-9-11, Midori-cho
Musashino-shi
Tokyo 180, Japan
E-mail: murakami@ntt-20.ecl.net
Mitsuru Maruyama
NTT Software Laboratories
3-9-11, Midori-cho
Musashino-shi
Tokyo 180, Japan
E-mail: mitsuru@ntt-20.ecl.net📦 where this page comes from
- ietf: rfc2174 1997-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms