RFC 1195
Use of OSI IS-IS for routing in TCP/IP and dual environments
okay bestie, RFC 1195 is here and it's giving protocol glow-up 💖
First, the title block tea ☕:
- RFC number: 1195 🎀
- Title: Use of OSI IS-IS for Routing in TCP/IP and Dual Environments 🦋
- Author: R. Callon, from Digital Equipment Corporation 💅
- Date: December 1990 🌸
- Category: IAB Standards Track 👑 (the status section says so)
- Obsoletes / Updates: this header doesn't list either one, so nothing to report ✨
- Group: the header says "Network Working Working Group" (double "working," lol 🙈) but it's the Network Working Group
Status of This Memo ✨
Okay so this part is basically the fine print 📜 This RFC specifies a protocol on the IAB Standards Track for the Internet community, and it wants discussion and suggestions for improvements 💬. For the official standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 🔍. Distribution of this memo is unlimited 🌈.
This RFC comes in both postscript and text versions. The postscript version is recommended whenever possible 📄, because the text version may have figures that are less informative or missing entirely 🙈.
Abstract 🧚
Here's the big idea 💜 This RFC specifies an integrated routing protocol based on the OSI Intra-Domain IS-IS Routing Protocol. It can be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI 🌐. One routing protocol can handle pure IP environments, pure OSI environments, and dual environments all at once, which is honestly iconic 👑. This specification was developed by the IS-IS working group of the Internet Engineering Task Force 🫶.
The OSI IS-IS protocol is mature and ready for implementation and real operational use 🔥. Its most recent version is in ISO DP 10589 [1]. So the proposed standard for using IS-IS with TCP/IP sticks with that version (plus a minor bug correction, covered in Annex B 🛠️). The plan is that future versions will upgrade to the final International Standard version of IS-IS once it's out 🦋.
Comments should go to isis@merit.edu 💌.
Contents 📚
1 Introduction: Overview of the Protocol
1.1 What the Integrated IS-IS offers
1.2 Overview of the ISO IS-IS Protocol
1.3 Overview of the Integrated IS-IS
1.4 Support of Mixed Routing Domains
1.5 Advantages of Using Integrated IS-IS
2 Symbols and Abbreviations
3 Subnetwork Independent Functions
3.1 Exchange of Routing Information
3.2 Hierarchical Abbreviation of IP Reachability Information
3.3 Addressing Routers in IS-IS Packets
3.4 External Links
3.5 Type of Service Routing
3.6 Multiple LSPs and SNPs
3.7 IP-Only Operation
3.8 Encapsulation
3.9 Authentication
3.10 Order of Preference of Routes / Dijkstra Computation
4 Subnetwork Dependent Functions
4.1 Link Demultiplexing
4.2 Multiple IP Addresses per Interface
4.3 LANs, Designated Routers, and Pseudonodes
4.4 Maintaining Router Adjacencies
4.5 Forwarding to Incompatible Routers
5 Structure and Encoding of PDUs
5.1 Overview of IS-IS PDUs
5.2 Overview of IP-Specific Information for IS-IS
5.3 Encoding of IP-Specific Fields in IS-IS PDUs
6 Security Considerations
7 Author's Address
8 References
A Inter-Domain Routing Protocol Information
A.1 Inter-Domain Information Type
A.2 Encoding
B Encoding of Sequence Number Packets
B.1 Level 1 Complete Sequence Numbers PDU
B.2 Level 2 Complete Sequence Numbers PDU
B.3 Level 1 Partial Sequence Numbers PDU
B.4 Level 2 Partial Sequence Numbers PDU
C Dijkstra Calculation and Forwarding
C.1 SPF Algorithm for IP and Dual Use
C.2 Forwarding of IP packets
D Use of the Authentication Field
D.1 Authentication Field in IS-IS packets
D.2 Authentication Type 1 - Simple Password
E Interaction of the Integrated IS-IS with Brouters
E.1 The Problem
E.2 Possible Solutions
Figures
1 ISO Hierarchical Address Structure
2 An Example
3 Encoding of Variable Length Fields1 Introduction: Overview of the Protocol 🌟
Let's set the scene 🎬 TCP/IP keeps growing as a multi-vendor communications architecture 📈. OSI is expected to show up at some point, and we expect TCP/IP and OSI to coexist for a long time 🤝. That means routers need to handle IP traffic and OSI traffic in parallel. It's a must-have, not a nice-to-have 💅.
There are two main ways routing protocols can support routers that do both OSI and IP 🔀. The first is called "Ships in the Night," which uses completely independent routing protocols for each suite 🚢. This spec goes a different route 🛣️: a single integrated protocol for interior routing (calculating routes within a routing domain) for both suites 💖.
This integrated design is built on the OSI Intra-domain IS-IS routing protocol [1], with IP-specific functions added on top 🎀. This RFC is a companion to the OSI IS-IS Routing spec, so it only describes the additional features that are needed 📎.
By supporting both IP and OSI traffic, this design handles traffic to IP hosts, OSI end systems, and dual end systems 🫶. It's "integrated" because IS-IS can be used for pure-IP environments, pure-OSI environments, and dual environments alike 🦋. It also lets dual (IP and OSI) routing domains connect to other dual domains, IP-only domains, and OSI-only domains 🌈.
The protocol here is based on the work of the IETF IS-IS working group 💜.
1.1 What the Integrated IS-IS offers ✨
This is the menu 🍓 The integrated IS-IS gives you a single routing protocol that efficiently routes both TCP/IP and OSI at the same time 🔥. It builds on the OSI IS-IS routing protocol and adds IP-specific information 🧩. It explicitly supports IP subnetting, variable subnet masks, TOS-based routing, and external routing 🗺️. There's also room for authentication information, including passwords or other mechanisms 🔐. The exact form of authentication mechanisms other than passwords is outside the scope of this document 🙈.
OSI and IP packets both get forwarded "as is." They go straight over the underlying link layer services, with no need for mutual encapsulation 🚀. The integrated IS-IS is a dynamic routing protocol based on the SPF (Dijkstra) routing algorithm 🧠.
This protocol lets IP-only, OSI-only, and dual (IP and OSI) routers all mix together, as defined below 🎀.
An IP-only IS-IS router (or "IP-only" router) is one that: (i) uses IS-IS as the routing protocol for IP, as specified in this report; and (ii) doesn't otherwise support OSI protocols 🌸. For example, these routers couldn't forward OSI CLNP packets 🙈.
An OSI-only router is one that uses IS-IS as the routing protocol for OSI, as specified in [1]. OSI-only routers are generally expected to conform to OSI standards, and they can be implemented independently of this specification 🧚.
A dual IS-IS router (or "dual" router) is one that uses IS-IS as a single integrated routing protocol for both IP and OSI, as specified in this report 👑.
This approach doesn't change how IP packets are handled 💅. IP-only and dual routers are required to conform to the requirements of Internet Gateways [4]. The integrated IS-IS protocol here is an Interior Gateway Protocol (IGP) that provides routing within a TCP/IP routing domain (i.e., autonomous system) 🌐. Other router functions (e.g., operation of ICMP, ARP, EGP, etc.) aren't affected by this proposal 🫶.
Similarly, this approach doesn't change how OSI packets are handled 🦋. Nothing changes at all about ISO 8473 Data packets and Error Reports, or about ISO 9542 Redirects and ES Hellos 💖. ISO 9542 IS Hellos sent on LANs are also unchanged 🌈. ISO 9542 IS Hellos sent on point-to-point links are unchanged except for the addition of IP-related information 🎀. Other OSI packets (specifically the ones used by the IS-IS intra-domain routing protocol) also stay the same, except for added IP-related information 📎.
This approach reuses the existing IS-IS packets and adds IP-specific fields to them. Specifically: (i) authentication information may be added to all IS-IS packets; (ii) the protocols each router supports, along with each router's IP addresses, are specified in ISO 9542 IS Hello, IS-IS Hello and Link State Packets; (iii) internally reachable IP addresses are specified in all Link State Packets; and (iv) externally reachable IP addresses, along with external routing protocol information, may be specified in level 2 Link State Packets 🧩. The detailed encoding and interpretation of all this info is in sections 3, 4, and 5 of this RFC 📖.
This protocol can route an IP-only routing domain, where all routers are IP-only 🌸. It can also route a pure dual domain, where all routers are dual 💜. And it can handle a mixed domain, where some routers are IP-only, some are OSI-only, and some are dual 🔀. The specific topology restrictions for that last case are in section 1.4 ("Support of Mixed Routing Domains") 🗺️. Using IS-IS for pure OSI domains is specified in [1] 🧡.
This protocol doesn't limit which network management protocol(s) you use to manage IS-IS-based routers 🛠️. The management information bases (MIBs) for IP-only, OSI-only, and dual routers, compatible with CMIP, CMOT, and/or SNMP, are covered in a separate companion document [8] 📚💅
1.2 Overview of the ISO IS-IS Protocol 💖
okay bestie, so IS-IS was developed in ISO to do routing for pure OSI environments 🎀. It's built to work alongside ISO 8473 (The ISO Connectionless Network Layer Protocol [2]) and ISO 9542 (The ISO End System to Intermediate System Protocol [3]). This section gives you the quick tea on how IS-IS supports pure OSI setups ✨. Enhancements for IP and dual environments are specified elsewhere in this report 🦋.
In IS-IS, the network gets split into "routing domains" 🌸. Network management draws the boundaries by setting some links to be "exterior links" 🧚. If a link is marked "exterior", no IS-IS routing messages get sent on that link 🙈.
Rn ISO doesn't have a standard for inter-domain routing (aka routing between separate autonomous routing domains) 💀. So instead, they use manual configuration 🍓. The link is statically configured with the set of address prefixes reachable through it, plus the method for reaching them. That could be the DTE address to dial, or the fact that the DTE address should be pulled out of the IDP portion of the ISO address 💅.
OSI IS-IS routing is giving two-level hierarchical routing 👑. A routing domain gets partitioned into areas 🌈. Level 1 routers know the topology inside their area, including every router and end system there 💜. But they do NOT know who the routers or destinations outside their area are 😭. So they forward all traffic for outside destinations to a level 2 router in their area 🫶. Level 2 routers know the level 2 topology and which addresses are reachable via each level 2 router ✨. They don't need to know the topology within any level 1 area, except to the extent that a level 2 router may also be a level 1 router within a single area 🎀. Only level 2 routers can exchange data packets or routing information directly with external routers located outside the routing domains 👑.
+----------------------+-------------------------------+
| IDP | DSP |
+----------------------+-------------------------------+
. . .
. . .
. . .
+-----+----------------+----------+--------------+-----+
| AFI | IDI | HO-DSP | ID | SEL |
+-----+----------------+----------+--------------+-----+
Figure 1 - ISO Hierarchical Address StructureAs you can see in figure 1, ISO addresses are split into the Initial Domain Part (IDP) and the Domain Specific Part (DSP) 🦋. The IDP is the part ISO standardizes, and it specifies the format and the authority responsible for assigning the rest of the address 💖. The DSP gets assigned by whatever addressing authority the IDP points to 🌸. The DSP is then further split into a "High Order Part of DSP" (HO-DSP), a system identifier (ID), and an NSAP selector (SEL) 🍓. The HO-DSP can use any format the authority identified by the IDP wants 💅. Put together, [IDP,HO-DSP] identifies both the routing domain AND the area inside it 😭. That's why [IDP, HO-DSP] may be referred to as the "Area Address" 🔥.
Usually every node in an area has the same area address 🌈. Sometimes, though, an area might have multiple addresses 🧚. Here's why that's a thing:
- Changing an area's address is a whole process 🎀. The most graceful way to go from address A to address B is to first let the area have both A and B. Then, once every node in the area recognizes both addresses, the nodes can be modified one by one to "forget" address A 💜.
- Maybe you want to merge areas A and B into one area 🫶. The method is to add knowledge of address B into the A partition one by one, and similarly add knowledge of address A into the B partition ✨.
- You might want to partition an area C into two areas, A and B (where "A" might equal "C", in which case this example becomes one of removing a portion of an area) 👑. You do this by first introducing knowledge of address A into the appropriate nodes (the ones destined to become area A), and knowledge of address B into the appropriate nodes. Then you one by one remove knowledge of address C 💅.
Since OSI addressing explicitly identifies the area, it's super easy for level 1 routers to spot packets going to destinations outside their area, which need to be forwarded to level 2 routers 🌸.
In IS-IS, there are two types of routers 🦋:
- Level 1 intermediate systems 💖: these nodes route based on the ID portion of the ISO address, and they route within an area 🍓. They check the destination address in a packet to see whether the destination is within the area. If it is, they route toward the destination. If not, they route to the nearest level 2 router 🧚.
- Level 2 intermediate systems 🌈: these nodes route based on the area address (i.e., on the combination of
[IDP, HO-DSP]) 💜. They route toward areas, without caring about the internal structure of an area 🎀. A level 2 IS may also be a level 1 IS in one area ✨.
A level 1 router has its area portion of the address manually configured 💅. It will refuse to become a neighbor with a node whose area addresses don't overlap its own 😭. But here's the nuance: if a level 1 router has area addresses A, B, and C, and a neighbor has area addresses B and D, the level 1 router WILL accept the other node as a neighbor 🫶.
A level 2 router will accept another level 2 router as a neighbor, regardless of area address 👑. However, if the area addresses don't overlap, both routers consider the link to be "level 2 only", and only level 2 LSPs flow on it 🔥. External links (to other routing domains) must be from level 2 routers 🌈.
IS-IS offers an optional partition repair function 🌸. In the unlikely event that a level 1 area becomes partitioned, this function (if implemented) lets the partition get repaired using level 2 routes 🦋.
IS-IS requires that the set of level 2 routers be connected 🍓. If the level 2 backbone gets partitioned, there's no provision for using level 1 links to repair a level 2 partition 💀.
In unusual cases, a single level 2 router may lose connectivity to the level 2 backbone 🙈. When that happens, the level 2 router indicates in its level 1 LSPs that it is not "attached" ✨. This lets level 1 routers in the area send traffic for destinations outside the domain to a different level 2 router 💖. So level 1 routers only route traffic to destinations outside their area toward level 2 routers that indicate in their level 1 LSPs that they are "attached" 🧚.
An end system may autoconfigure the area portion of its address by extracting the area portion of a neighboring router's address 🎀. If that's the case, the endnode will always accept a router as a neighbor 🌈. Since the standard does not specify that the end system MUST autoconfigure its area address, an end system may be configured with an area address instead 💜. In that case, the end system would ignore router neighbors with non-matching area addresses 😭.
Broadcast subnetworks, like LANs, need special treatment 🫶. This solves two sets of issues 💅: (i) without special treatment, each router on the subnetwork would announce a link to every other router on the subnetwork, resulting in n-squared links reported 💀; and (ii) again without special treatment, each router on the LAN would report the same identical list of end systems on the LAN, which is a whole lot of duplication 🙈.
These problems get avoided by using a "pseudonode", which represents the LAN 🌸. Each router on the LAN reports that it has a link to the pseudonode (rather than reporting a link to every other router on the LAN) 🦋. One of the routers on the LAN is elected "designated router" 👑. The designated router then sends out an LSP on behalf of the pseudonode, reporting links to all of the routers on the LAN 🔥. This brings the potential n-squared links down to n links 🍓. And only the pseudonode LSP includes the list of end systems on the LAN, which eliminates the potential duplication 🌈 (for more on designated routers and pseudonodes, see [1]) ✨.
The IS-IS provides for optional Quality of Service (QOS) routing 💖, based on throughput (the default metric), delay, expense, or residual error probability 💅. This is described in greater detail in section 3.5, and in [1] 🧚.
1.3 Overview of the Integrated IS-IS 🦋
okay so the integrated IS-IS lets a single routing protocol route both IP and OSI packets 💖 which means the same two-level hierarchy gets used for both. Each area is set to be IP-only (only IP traffic gets routed there), OSI-only (only OSI traffic), or dual (both IP and OSI) 🌸
No partial overlap, bestie! 🙅♀️ This proposal doesn't allow OSI and IP areas to partly overlap. If one area is OSI-only and another is IP-only, then no router is allowed to sit in both. And there's only one backbone for the whole routing domain. No separate OSI backbone and IP backbone, sorry not sorry 💅
Same energy for the IP-only and dual areas: the amount of knowledge routers keep about specific IP destinations is supposed to be as close as possible to what happens with OSI. So IP-capable level 1 routers keep track of the topology inside their area and can route directly to IP destinations in that area ✨ But they don't keep info about destinations outside the area. Just like normal OSI routing, traffic headed outside the area gets forwarded to the nearest level 2 router 🧚 Also, IP routes to subnets, not individual end systems, so IP routers don't need to store or pass around lists of IP host identifiers. (Quick aside: routes to hosts can still be announced by using a subnet mask of all ones 🎀)
The IP address structure lets networks get split into subnets, and lets subnets get recursively subdivided into smaller subnets 🌈 But it's undesireable to force any specific relationship between IP subnet addresses and IS-IS areas. Why? Lots of dual routers will be dropped into existing environments that already have IP and/or OSI addresses assigned. And even when IP addresses aren't pre-assigned yet, IP's address limits already constrain what can be assigned 😭 So there's no requirement tying IP addresses to the area structure. IP addresses can be assigned completely independently of OSI addresses and the IS-IS area structure. That said, as described in section 3.2 ("Hierarchical Abbreviation of IP Reachability Information"), you get better efficiency and scaling in the routing algorithm if the IP address assignment structure somewhat matches the area structure 👑
Inside an area, level 1 routers swap link state packets that identify the IP addresses each router can reach. Specifically, zero or more [IP address, subnet mask, metric] combinations can be included in each Link State Packet. Each level 1 router is manually configured with the [IP address, subnet mask, metric] combinations reachable on each interface. A level 1 router routes like this:
- If a specified destination address matches an
[IP address, subnet mask, metric]reachable within the area, the packet is routed via level 1 routing. - If a specified destination address does not match any
[IP address, subnet mask, metric]combination listed as reachable within the area, the packet is routed towards the nearest level 2 router.
Using the limited IP address space flexibly is a big deal if we want to handle the growth coming for IP environments 🔥 So an area (and by extension a routing domain) can use a bunch of different address masks for different subnets at the same time. Generally, if a specified destination address matches more than one [IP address, subnet mask] pair, the more specific one is the one routed towards. That's the one with more "1" bits in the mask, and it's called "best match" routing 🎯
Level 2 routers put a complete list of [IP address, subnet mask, metric] in their level 2 LSPs, covering all IP addresses reachable in their area. As section 3 explains, this info can come from a mix of the level 1 LSPs (from level 1 routers in the same area) and/or manual configuration. On top of that, level 2 routers can report external reachability information, for addresses reachable via routers in other routing domains (autonomous systems) 🌍
Default routes can be announced by using a subnet mask containing all zeroes. Be careful with these, though, because they can cause "black holes" 😬 Default routes are only permitted at level 2, as external routes (meaning they're included in the IP External Reachability Information field, as explained in sections 3 and 5). Default routes are not permitted at level 1. Nope, not allowed!
The integrated IS-IS also offers optional Type of Service (TOS) routing, using the QOS feature from IS-IS 🍓
1.4 Support of Mixed Routing Domains 🧩
The integrated IS-IS proposal specifically allows for three kinds of routing domains:
- Pure IP
- Pure OSI
- Dual
In a pure IP routing domain, every router has to be IP-capable 💜 IP-only routers can be freely mixed with dual routers. Some fields that are specifically about OSI operation may be included by dual routers, and IP-only routers just ignore them. Only IP traffic gets routed in a pure IP domain. Any OSI traffic may be discarded, except for the IS-IS packets needed to keep the routing protocol running.
In a pure OSI routing domain, every router has to be OSI-capable. OSI-only routers can be freely mixed with dual routers. Some fields specifically about IP operation may be included by dual routers, and OSI-only routers ignore them. Only OSI traffic gets routed in a pure OSI domain, and any IP traffic may be discarded.
In a dual routing domain, IP-only, OSI-only, and dual routers can all be mixed on a per-area basis 🌷 Each area can itself be defined as pure IP, pure OSI, or dual.
In a pure IP area within a dual domain, IP-only and dual routers can be freely mixed. Only IP traffic can be routed by level 1 routing inside a pure IP area.
In a pure OSI area within a dual domain, OSI-only and dual routers can be freely mixed. Only OSI traffic can be routed by level 1 routing inside a pure OSI area.
In a dual area within a dual routing domain, only dual routers may be used. Both IP and OSI traffic can be routed within a dual area.
Within a dual domain, if both IP and OSI traffic are going to be routed between areas, then all level 2 routers must be dual 🫶
1.5 Advantages of Using Integrated IS-IS 🏆
Using integrated IS-IS as one protocol for routing both IP and OSI packets in a dual environment has big advantages over using separate protocols to route IP and OSI traffic independently. Let's get into it 💅
The other approach is called "Ships In the Night" (S.I.N.). With S.I.N., completely separate routing protocols handle IP and OSI. For example, OSPF [5] might route IP traffic while IS-IS [1] routes OSI traffic. With S.I.N., the two protocols more or less run independently. However, dual routers have to implement both routing protocols, so there's some competition for resources 😤
Also, S.I.N. and integrated IS-IS aren't really totally separate options. If integrated IS-IS is used within a routing domain to route IP and OSI traffic, it's still possible to use other independent routing protocols for routing other protocol suites 🧚
Future optional extensions to IS-IS might get defined for routing other common protocol suites. But those future options are outside the scope of this document. This section only compares integrated IS-IS and S.I.N. for routing IP and OSI 🌈
A main advantage of integrated IS-IS is the network management effort it needs. Since integrated IS-IS provides a single routing protocol, inside a single coordinated routing domain using a single backbone, there's less information to configure. That, combined with a single coordinated MIB, makes network management simpler 🎀
Also, the two protocols under S.I.N. aren't really independent, because they have to share common resources. With integrated IS-IS, the interactions are explicit, but with S.I.N., they're implicit. Since the interactions are explicit, it may be easier to manage and debug dual routers 🔍
Another perk: since integrated IS-IS only needs one routing protocol, it uses fewer resources. Less implementation resources are needed (since only one protocol has to be implemented), less CPU and memory get used in the router (since only one protocol has to run), and less network resources get used (since only one set of routing packets has to be transmitted). This mostly turns into money saved, since all three of those resources cost money 💸 So dual routers based on integrated IS-IS should be less expensive to buy and to operate than dual routers based on S.I.N.
Note that the two protocols under S.I.N. still aren't really independent, since they share common resources. For example, if one routing protocol gets unstable and starts using excessive resources, the other protocol is likely to suffer. A bug in one protocol could crash the other 😱 With integrated IS-IS, though, the interactions are explicit and defined into the protocol and software interactions. With S.I.N., they stay implicit.
Integrated IS-IS also reduces how often you'll likely need software upgrades. If your router has two different routing protocols, you have to upgrade the software any time EITHER of the protocols changes. If you use a single integrated routing protocol, software changes are still likely to be needed, just less often 🙌
Finally, routing protocols have serious real-time requirements ⏰ In IS-IS, those real-time requirements are explicitly specified. In other routing protocols, they're implicit. Still, all routing protocols have real-time guarantees that must be met for correct operation. Ensuring real-time compliance is already hard enough in the implementation of a single real-time system. With S.I.N., implementing two semi-independent real-time protocols in one device makes that even harder 🥲
Last but not least, both integrated IS-IS and S.I.N. allow for independence of external routes (traffic from/to outside the routing domain), and they both allow for independent assignment of OSI and TCP/IP addresses ✨
2 Symbols and Abbreviations ✨
okay bestie, this is the glossary section and it's giving alphabet soup 🍜 but every single acronym here matters, so save these to your brain 🧠💖 I kept the list exactly as it was in the spec because the layout is part of the vibe 🎀
AA Administrative Authority
(a three octet field in the GOSIP version 2.0 NSAP
address format)
AFI Authority and Format Identifier
(the first octet of all OSI NSAP addresses -- identifies
format of the rest of the address)
CLNP Connection-Less Network Protocol
(ISO 8473, the OSI connectionless network layer protocol
-- very similar to IP)
DFI DSP Format Identifier
(a one octet field in the GOSIP version 2.0 NSAP address
format)
ES End System
(The OSI term for a host)
ES-IS End System to Intermediate System Routeing Exchange
Protocol (ISO 9542 -- OSI protocol between routers
and end systems)
ICD International Code Designator
(ISO standard for identifying organizations)
IP Internetwork Protocol
(an Internet Standard Network Layer Protocol)
IS Intermediate System
(The OSI term for a router)
IS-IS Intermediate System to Intermediate System Routeing
Exchange Protocol
(the ISO protocol for routing within a single
routing domain)
IS-IS Hello An Hello packet defined by the IS-IS protocol
(a type of packet used by the IS-IS protocol)
ISH An Hello packet defined by ISO 9542 (ES-IS protocol).
(not the same as IS-IS Hello)
ISO International Organization for Standardization
(an international body which is authorized to write
standards of many kinds)
LSP Link State Packet
(a type of packet used by the IS-IS protocol)
NLPID Network Layer Protocol ID
(A one-octet field identifying a network layer protocol)
NSAP Network Service Access Point
(a conceptual interface point at which the network
service is made available)
SEL NSAP Selector
(the last octet of NSAP addresses, also called NSEL)
OSI Open Systems Interconnection
(an international standard protocol architecture)
RD Routing Domain
(the set of routers and end systems using a single
instance of a routing protocol such as IS-IS)
SNPA Subnetwork Point of Attachment
(a conceptual interface at which a subnetwork service
is provided)
TCP Transmission Control Protocol
(an Internet Standard Transport Layer Protocol)
TCP/IP The protocol suite based on TCP, IP, and related
protocols (the Internet standard protocol
architecture)3 Subnetwork Independent Functions 🦋
3.1 Exchange of Routing Information 💖
okay so routers talking to each other is the core of everything 🫶 The exchange of routing information between routers uses the normal routing packet exchange from the OSI IS-IS routing spec, with extra IP-specific info stuffed into the IS-IS routing packets. It's giving reuse, no cap 💅
The IS-IS protocol lets every IS-IS packet carry variable length fields. These fields use a "Code, Length, Value" triplet, where the code and the length are each one octet, and the value can be anywhere from 0 to 254 octets long 🎀 IS-IS also says: "Any codes in a received PDU that are not recognised are ignored and passed through unchanged". This applies to every router running IS-IS, whether it's OSI-only, IP-only, or dual 🌈 This is the magic trick: IP info can be encoded so OSI-only routers just skip it, and OSI info can be encoded so IP-only routers just skip it too ✨ Iconic behavior from both sides 👑
IP-capable routers (that's all the IP-only and dual ones) need to know which network layer protocols the other routers in their area support 🧚 This info shows up in a "protocols supported" field, which goes in all IS-IS Hello packets and all Link State Packets. The field uses the NLPID (Network Layer Protocol Identifier), which is a one-octet value ISO assigned to identify network level protocols. NLPID values have been assigned to ISO 8473 and to IP 🍓
IP-capable routers also need the IP address of the adjacent interface on their neighboring routers. This one is so important 😭 It's required for sending ICMP redirects, because when an IP-capable router sends an ICMP redirect to a host, it must include the IP address of the appropriate interface of the correct next-hop router. The info gets shared by putting the IP interface address in the IS-IS Hello packets. Specifically, each IS-IS Hello packet contains the IP address(es) of the interface it's transmitted over. The IS-IS also lets multiple IP addresses be assigned to each physical interface, so no one gets left out 🌸
Sometimes it's useful for IP-capable routers to figure out the IP address(es) of all the other routers at their level. Level 1 routers want all the other routers in their area, and level 2 routers want all the other level 2 routers in the routing domain 💜 This is handy whenever an IP packet needs to go to a router, like for encapsulation or for sending network management packets. The info is shared by including IP addresses in LSPs. Each IS-IS LSP includes one or more IP addresses of the router that sent it. An IP-capable router is required to include at least one of its IP addresses in its LSPs, and it may optionally include several or all of them 🎀 If a single router is both a level 1 and a level 2 router, it's required to include the same IP address(es) in both its level 1 and level 2 LSPs. Consistency is everything, bestie 🫶
IP-capable routers also need to know the correct route to any given IP destination address 🗺️ Level 1 routers need to know which IP addresses are reachable from each level 1 router in their area. They also need to find level 2 routers, for traffic going to IP addresses outside their area. Level 2 routers need to know which IP addresses are reachable internally (either directly or via level 1 routing) from other level 2 routers, and which addresses are reachable externally from other level 2 routers. All of this info is shared by including IP reachable address information in the Link State Packets ✨
Okay, now the metrics drama 🙈 Internal reachability (inside the routing domain) and external reachability (outside the domain) are announced separately, in level 2 LSPs. Reachable IP addresses include a default metric, and they may include multiple TOS-specific metrics. Generally, for external routes, metrics can be of type "internal" (directly comparable with internal metrics) or of type "external" (not comparable with the internal metric). A route using internal metrics always wins over a route using external metrics 👑 That means a route using internal metrics is either announced as "IP internal reachability information", or announced as "IP external reachability information" with an internal metric. A route using external metrics is announced as "IP external reachability information" with an external metric. Internal routes always get the crown 💅
The detailed encoding of the IP-specific info that goes in routing packets is in section 5 (Structure and Encoding of PDUs) 📖 That's where the nitty-gritty lives, so grab a snack and get ready 🍿💖
3.2. Hierarchical Abbreviation of IP Reachability Information ✨
okay so, level 2 routers put a list in their level 2 LSPs of every [IP address, subnet mask, metric] combo they can reach in their area 🗺️ Generally that info MAY be worked out from the level 1 LSPs of all the routers in the area. ngl, if we ignored resource limits, a level 2 router could just copy every [IP address, subnet mask, metric] entry from all of its level 1 routers into its own level 2 LSP (with the metric adjusted properly) 🙃 But for hierarchical routing to scale to huge routing domains, we really, really want to shrink that reachable address info. It's giving efficiency 💅
This gets done with manual configuration of summary addresses 🎀 Each level 2 router MAY be configured with one or more [IP address, subnet mask, metric] entries to announce in its level 2 LSPs.
The reachable addresses from the level 1 LSPs get compared with the configured ones. Anything redundant from the level 1 LSPs does NOT go into the level 2 LSPs 🙈 Usually the configured info is more inclusive, meaning a subnet mask with fewer bits set to 1. So one configured address/submask pair (or a small handful of them) can hierarchically supercede a whole bunch of entries from level 1 LSPs. Main character energy for summaries 👑
The manually configured addresses only get included in level 2 LSPs if they match at least one address that's reachable in the area. For those level 2 addresses, the metric values to announce are also configured by hand 🧚 And the configured addresses supercede reachable address entries from level 1 LSPs based ONLY on the IP address and subnet mask. The metric values don't count when deciding whether a configured address supercedes an address from a level 1 LSP 🦋
Any address from a level 1 LSP that ISN'T superceded by the manual config gets included in the level 2 LSPs. In that case the metric announced in the level 2 LSPs is the sum of the metric announced in the matching level 1 LSP plus the distance from the level 2 router to the right level 1 router. Also, note: if that sum comes out greater than 63 (the biggest value that can be reported in level 2 LSPs), then the value 63 MUST be used 🔥
Delay, expense, and error metrics (basically the TOS metrics other than the default metric) only get included if all three of these are true 🌸
- the level 2 router supports that specific TOS;
- the path from the level 2 router to the appropriate level 1 router is made up of links that support that specific TOS; and
- the level 1 router that can reach the address directly also supports that specific TOS for this route, as shown in its level 1 LSP.
Next up, the same [IP address, subnet mask] pair can totally show up in level 1 LSPs sent by multiple level 1 routers in the same area 🫶 In that case (assuming it isn't superceded by a manually configured entry), only ONE such entry SHALL be included in the level 2 LSP. The metric value(s) announced in the level 2 LSPs are the MINIMUM of the metric value(s) that would be calculated for each of those level 1 LSP entries. Lowest wins, bestie 🏆
A level 2 router has IP addresses it can reach directly through its own interfaces. For the purposes of putting reachable address info into level 2 LSPs, these "directly reachable" addresses get treated exactly the same as addresses received in level 1 LSPs 💜
Here's where it gets a little spicy 🌶️ Manually configured addresses can hierarchically supercede multiple level 1 reachable address entries. BUT there may be some IP addresses that match a manually configured address and still AREN'T reachable via level 1 routing. So if a level 2 router gets an IP packet whose IP address matches a manually configured address it's including in its level 2 LSP, and that address is NOT reachable via level 1 routing in the area, then the packet MUST be discarded. An error report MAY be returned in this case (as specified in RFC 1009), with the reason for discard set to destination unreachable 😭
Heads up: a summary can be a bit greedy, so a packet can match the summary without the area actually having a route for it. That's why the discard rule above exists 🙈
Figure 2 - An Example Routing Domain (not shown)Okay, example time 🍓 An example is illustrated in figure 2. Say the network number for the whole routing domain is 17 (a class A network). Each area gets a subnet number made from the next 8 bits. The area can be split further by giving the next eight bits to each LAN in the area, which gives each one a 24 bit subnet mask (counting the network and subnet fields). Then 8 bits are left for the host field ✨ Now say that, for one particular area (subnet number 17.133), there are a bunch of IP capable level 1 routers announcing subnets 17.133.5, 17.133.43, and 17.133.57 in the special IP entry of their level 1 LSPs 📦
Now, to save space in level 2 LSPs, the level 2 routers in this area are configured to announce subnet 17.133. Only that one address has to go into the level 2 LSPs 🎉 So if an IP packet shows up for an address in 17.133.5, 17.133.43, or 17.133.57, other level 2 routers in other areas will know to send the traffic to this area 🚀
Because of the 17.133 entry in the level 2 LSPs, the three subnet addresses starting with 17.133 don't all have to be listed separately in the level 2 LSPs. Lowkey genius 🧠
Now, if some traffic shows up for an unreachable address like 17.133.124.7, the level 2 routers in other areas of this routing domain will think this area can handle it. They'll forward the traffic to the level 2 routers in this area, and those routers will have to discard it 💀
Let's say subnet number 17.133.125 is actually reachable through some other area, like the lower right hand area. In that case, the level 2 router in the left area would be announcing reachability to subnet 17.133 (according to its manual config). Meanwhile, the level 2 router in the lower right area would be announcing reachability to subnet 17.133.125 (according to the info from its received level 1 LSPs). Because of best match routing, this still works out correctly 🦋 All traffic from other areas destined for 17.133.125 gets sent to the level 2 router in the lower right area. All the other traffic to 17.133 (meaning any IP address that starts with 17.133 but doesn't start with 17.133.125) gets sent to the level 2 router in the leftmost area 🌈
3.3 Addressing Routers in IS-IS Packets ✨
okay so the IS-IS packet formats explicitly require that OSI-style addresses of routers show up in the packets 🎀 these addresses are used to figure out which area a router belongs to, for example. so every router that uses IS-IS has to have an OSI style address assigned 💖 for IP-only routers, these addresses are ONLY used for running IS-IS. they're not used for anything else (like EGP, ICMP, or other TCP/IP protocols) 🙈
for OSI-only and dual routers, getting NSAP addresses is pretty straightforward, but it's outside the scope of this spec 💅 standards bodies are setting up ways to hand out globally unique OSI NSAP addresses, so all OSI-only and dual routers MAY therefore use normal OSI addresses when they're running IS-IS 🫶
for IP-only routers, there are two ways to get NSAP addresses for use with IS-IS 👑
- for environments where OSI is being used, or where it's expected to be used in the future, it's permissible to get NSAP address assignments the normal way, give normal NSAP addresses to IP-only routers, and use those in IS-IS. this approach is RECOMMENDED even for pure IP routing domains, because it'll make it way easier to migrate from IP-only to dual operation later 🦋
- in some cases routers may only have TCP/IP addresses, and it may be undesirable to go through the normal NSAP assignment process 😭 so an alternate mechanism is provided below for algorithmically generating a valid OSI style address from existing IP address and autonomous system number assignments 🧚
where desired, for IP-only routers, for use in IS-IS packet formats only, OSI-style addresses (compatible with the USA GOSIP version 2.0 NSAP address format [9]) MAY be derived as follows:
AFI 1 octet value "47" (specifies ICD format)
ICD 2 octet value "00 05" (specifies Internet/Gosip)
DFI 1 octet value "xx"
AA 3 octets value "xx xx xx" (specifies special
IP-only use of NSAPs)
Reserved 2 octets must be "00 00"
RD 2 octets contains autonomous system number
Area 2 octets must be assigned as described below
ID 6 octets must be assigned as described below
SEL 1 octet used as described belowthe AFI value of "47" and the ICD value of "00 05" specify the Gosip Version 2.0 addressing format 🌸 the DFI number of "xx" and the AA of "xx xx xx" say that this special NSAP address format is being used, solely for IS-IS packet formats in an IP-only environment 💜 the reserved field MUST contain "00 00", as specified in GOSIP version 2.0 🔥
the routing domain field contains the Autonomous System number. strictly speaking, this isn't necessary, since IS-IS packets are only exchanged within a single AS 🙈 BUT including the AS number in this address format makes sure everything still works right if routers from separate routing domains/ASs get accidentally placed on the same link 😭 the AS number here is only used to define unique NSAP addresses, and it doesn't imply any coupling with exterior routing protocols 🦋
the Area field MUST be assigned by the authority responsible for the routing domain, so that each area in the routing domain has a unique Area value 🌈
the ID MUST be assigned by the authority responsible for the routing domain. the ID MUST be assigned so that every router in the routing domain has a unique value 💀 it's RECOMMENDED that one of the following methods is used:
- use a unique IEEE 802 48 bit station ID
- use the value hex "02 00" prepended to an IP address of the router
IEEE 802 addresses, if used, MUST appear in IEEE canonical format 🫶
since IEEE 802 station IDs are assigned to be globally unique, using them clearly guarantees uniqueness in the area ✨ also, all assigned IEEE 802 station IDs have the global/local bit set to zero 🍓 so prepending that pattern to the front of the IP address makes sure format (2) can't produce addresses that collide with format (1) 🙌 and as long as IP addresses are also globally unique, format (2) will produce unique IDs for routers too 💖
the indicated hex value is specified in IEEE 802 canonical form [10]. in IEEE 802 addresses, the multicast bit is the least significant bit of the first byte, and the global/local bit is the next least significant bit of the first byte 🧠 so the indicated prefix sets the global/local bit to 1, and all other bits in the first two octets to 0 🫧
⚠️ note that within an area, whether ISO addresses are configured into the routers through ISO address assignment, or whether the ISO-style address is generated directly from the AS number and IP address, ALL routers within an area MUST have the same high order part of address (AFI, ICD, DFI, AA, RD, and Area). this ISO-style address is used in IS-IS Hello messages and is the basis by which routers recognize whether neighbor nodes are in or out of their area 💅
3.4 External Links 🌍
external connectivity (i.e., communications with routers outside of the routing domain) is only done by level 2 routers 👑 the ISO version of IS-IS lets external OSI routes get reported as "reachable address prefixes" in level 2 LSPs. the integrated IS-IS also lets external IP reachable addresses (i.e., IP addresses reachable via inter-domain routing) get reported in level 2 LSPs in the "IP external reachability information" field 💖 external OSI and external IP routes are handled independently 🫶
the routes announced in IP external reachability information entries include ALL routes to outside of the routing domain 🌸 that includes routes learned from OSPF, EGP, RIP, or any other external protocol 😤
external routes may make use of "internal" or "external" metrics ✨ internal metrics are comparable with the metrics used for internal routes, so when you're choosing between an internal route and an external route using internal metrics, the metric values can be directly compared 🧮 external metrics, on the other hand, can't be directly compared with internal metrics 🙅♀️ any route defined solely using internal metrics is ALWAYS preferred to any route defined using external metrics 🔥 when an external route using external metrics MUST be used, the lowest value of the external metric is preferred, no matter what the internal cost is to reach the exit point 💅
it's useful, when running external routing protocols, to have a way for border routers (i.e., routers in the same routing domain that can route externally to other domains) to figure out each other's existence and exchange external information 🧚 (in a form only the border routers themselves understand 🤫) this is made possible by including "inter-domain routing protocol information" fields in level 2 LSPs 🎀 the inter-domain routing protocol information field is NOT included in pseudonode LSPs 🙈
there may be multiple types of external inter-domain routing protocol information exchanged between border routers 💜 so IS-IS specifies that each occurrence of the inter-domain routing protocol information field includes a "type" field, which says what type of inter-domain routing protocol information is enclosed 🦋 values for the type field will be specified in future versions of the "Assigned Numbers" RFC 📜 the initial values for this field are specified in Annex A of this specification ✨
information in the inter-domain routing protocol information field gets carried in level 2 LSPs, so ALL level 2 routers in the domain will need to store it 😭 but only the level 2 routers directly involved in external routing will actually use it 🥹 when designing the use of this field, it's super important to think carefully about the storage requirements it puts on level 2 routers (including the ones that aren't directly involved in external routing) 💀
the protocols used to exchange routing information directly between border routers and external routers (in other routing domains / autonomous systems) are outside the scope of this specification 🌈
3.5 Type of Service Routing 🚦
the integrated IS-IS protocol provides IP Type of Service (TOS) routing, through the Quality of Service (QOS) feature of IS-IS 💖 this lets you route based on throughput (the default metric), delay, expense, or residual error probability 🎀 any particular packet may be routed on the basis of any ONE of these four metrics, but routing on general combinations of metrics is NOT supported 🙅♀️
the support for TOS/QOS is OPTIONAL 🫶 if a particular packet calls for a specific TOS, and the correct path from source to destination is made up of routers that ALL support that TOS, then the packet will be routed on the optimal path ✨ but if there's no path made up of routers that support that type of service, the packet will be forwarded using the default metric instead 🦋 this gives you TOS service where it's actually needed, while still giving acceptable service when an unsupported TOS gets requested 💅
💭 NOTE - IP does not have a cost TOS. there is therefore no mapping of IP TOS metrics which corresponds to the minimum cost metric 🙈
the IP TOS field maps onto the four available metrics like this 🌸
Bits 0-2 (Precedence): This field does not affect the route, but
rather may affect other aspects of packet
forwarding.
Bits 3 (Delay), 4 (Throughput) and 5 (Reliability):
000 (all normal) Use default metric
100 (low delay) Use delay metric
010 (high throughput) Use default metric
001 (high reliabiity) Use reliability metric
other Use default metric3.6. Multiple LSPs and SNPs ✨
okay so sometimes IS-IS packets (specifically Link State Packets and Complete Sequence Number Packets) are just too chunky to fit into one packet 😭. The OSI IS-IS [1] lets LSPs and CSNPs get split into multiple packets. This is totally separate from ISO 8473 segmentation, and it's also separate from IP fragmentation 🫶. Splitting things up like this is so iconic because (i) when the info in the IS-IS changes, only the packets that are affected need to be reissued 💅, and (ii) when one packet shows up, you can start processing it right away without waiting for every other packet of that type from the same router 🦋.
The Integrated IS-IS uses that same multiple packet function, as defined in [1]. IP-specific fields in IS-IS packets can get split across multiple packets too 🌈. As specified in section 5 ("Structure and Encoding of PDUs"), some of the IP-specific fields (the ones that can be pretty long) can be split into several occurrences of the same field, which lets the fields spread across different packets 🧚.
Multiple LSPs from the same router are told apart by their LSP number 🔢. Most variable length fields MAY occur in an LSP with any LSP number. Some specific variable length fields may be required to occur in LSP number 0 👑. Except where explicitly stated otherwise, when an IS-IS router issues multiple LSPs, the IP-specific fields MAY occur in an LSP with any LSP number 💖.
Complete Sequence Number Packets may be split into multiple packets, and the range each packet applies to is explicitly reported in the packet itself 🍓. Partial Sequence Number Packets are inherently partial, so they can easily be split into multiple packets if that's necessary. Again, where it's applicable, IP-specific fields MAY occur in any SNP 💜.
3.7. IP-Only Operation 🌸
For IP-only routers, the format for IS-IS packets stays unchanged. Literally the same 🙌. BUT there are some variable length fields from the IS-IS packets that can be left out. Specifically:
IS-IS Hello Packets:
- no change
IS-IS Link State Packets:
- the "End Systems Neighbours" entries are omitted
- the "Prefix Neighbours" entries are omitted
IS-IS Sequence Number Packets:
- no change
3.8. Encapsulation 🎁
Future versions of the Integrated IS-IS may specify optional encapsulation mechanisms for partition repair, and for forwarding packets through incompatible routers. That means forwarding OSI packets through IP-only routers, and forwarding IP packets through OSI-only routers 🚚. The details of encapsulation and decapsulation are for further study 🔮. Routers complying with the Integrated IS-IS are NOT REQUIRED to implement encapsulation nor decapsulation. No pressure 😌.
3.9. Authentication 🔐
The authentication field lets each IS-IS packet carry information used to authenticate the originator and/or the contents of the packet. The authentication information in each packet is used to authenticate the entire packet, including the OSI and IP parts 🛡️. If a packet arrives with invalid authentication information, then the entire packet is discarded 🗑️. If an LSP or SNP is split into multiple packets (as described in section 3.6), then each one is authenticated independently.
Use of the authentication field is OPTIONAL. Routers are NOT REQUIRED to be able to interpret authentication information. As with other fields in the Integrated IS-IS, if a router does not implement authentication, then it will ignore any authentication field that may be present in an IS-IS packet 🙈.
Annex D specifies a proposed use of the authentication field 📎.
3.10. Order of Preference of Routes / Dijkstra Computation 🗺️
We define the term "IP reachability entry" to mean the combination of the [IP address, subnet mask]. The Dijkstra calculation MUST calculate routes to each distinct IP reachability entry. For the Dijkstra calculation, each IP reachability entry can be treated in much the same way as an OSI end system 🧑💻. Naturally, each IP reachability entry is treated as distinct from any OSI end systems that may also be reachable in the same area or routing domain.
For any particular IP reachability entry, it's the same as another entry if and only if: (i) the subnet masks are identical; and (ii) for each bit in the subnet mask which has the value "1", the IP address is identical. This is super easy to test. You zero out the bits in the IP address that line up with a zero bit in the mask, treat the entry as a 64 bit quantity, and then check for equality between different 64 bit quantities 🧮. So the actual calculation of routes to IP reachability entries is no more complex than calculating routes to OSI end systems. The only difference is swapping a 48-bit test for a 64-bit test ✨.
The Dijkstra computation does not take into consideration whether a router is IP-only, OSI-only, or dual. The topological restrictions specified in section 1.4 make sure IP packets only get sent via IP-capable routers, and OSI packets only get sent via OSI-capable routers 🛣️.
The Integrated IS-IS prefers routes within the area (via level 1 routing) whenever possible. If level 2 routes must be used, then routes within the routing domain (specifically, those routes using internal metrics) are preferred over routes outside of the routing domain (using external metrics) 🏡.
The Integrated IS-IS protocol makes use of "best match" routing of IP packets. This implies that a particular destination address may match more than one entry in the forwarding database. If a particular IP packet has a destination address that matches two different IP reachability entries, then the entry whose mask contains the most "1" bits is preferred 🎯.
IP packets whose destination is a router are routed the same way as any other IP packet. They get forwarded first to the appropriate subnet, and then forwarded on that subnet to the destination host (which just happens to be a router in this case) 📦. In particular, the IP forwarding database does not contain explicit routes to the individual "IP interface addresses" listed by each router in its LSP.
However, host routes (routes with a subnet mask of all ones) may of course be included in the IP reachability entries, and they're handled in the same manner as other IP reachability entries 💻.
To make sure different router implementations interoperate correctly, the order of preference of possible routes needs to be specified 🤝. For OSI destinations, this is outside the scope of this report. For IP destinations, it's specified in sections 3.10.1 and 3.10.2 below. Annex C specifies a detailed Dijkstra calculation and forwarding algorithm that's compatible with the order of preference of routes specified here 📜.
With IS-IS, if a route to a given destination is advertised, or a link between routers is advertised, then metric values associated with some or all of the specified TOS metric types may be associated with that destination or link 🌈. However, the default metric MUST always be available. Normally this ensures that if a route using any TOS metric is available, then a route using the default metric will also be available. The only exception is where the corresponding route using the default metric has a total cost (within the area, or within the level 2 backbone) greater than MaxPathMetric 🙃.
When figuring out the route to a particular destination for a specified TOS, only routes using either the requested TOS metric or the default TOS metric are considered 🔍.
3.10.1. Order of Preference of Routes In Level 1 Routing 🏠
If a given destination is reachable within an area via a route using either the requested TOS or the default TOS, then IS-IS will always make use of a path within the area (via level 1 routing). This happens regardless of whether an alternate path exists outside of the area (via level 2 routing) 🙌. In this case, routes within the area are selected as follows:
- Amongst routes in the area, if the specified destination address matches more than one
[IP address, subnet mask]pair, then the more specific address match (the one with more "1" bits in the mask) is preferred 💖. - Amongst routes in the area to equally specific address matches, routes on which the requested TOS (if any) is supported are always preferred to routes on which the requested TOS is not supported ✨.
- Amongst routes in the area of the same TOS to equally specific address matches, the shortest routes are preferred. For determination of the shortest path, if a route on which the specified TOS is supported is available, then the specified TOS metric is used. Otherwise, the default metric is used. Amongst routes of equal cost, load splitting may be performed as specified in [1] 🏁.
For a level 1 only router (i.e., a router which does not take part in level 2 routing, or a level 2 router which is not "attached"), if a given destination is not reachable within an area, then level 1 routing will always route to a level 2 router as follows:
- Amongst routes in the area to attached level 2 routers, routes on which the requested TOS (if any) is supported are always preferred to routes on which the requested TOS is not supported 🌟.
- Amongst routes in the area of the same TOS to attached level 2 routers, the shortest routes are preferred. For determination of the shortest path, if a route on which the specified TOS is supported is available, then the specified TOS metric is used. Otherwise, the default metric is used. Amongst routes of equal cost, load splitting may be performed as specified in [1] 🦋.
3.10.2 Order of Preference of Routes in Level 2 Routing
okay so bestie, this is where level 2 routers figure out which route to pick 💅✨ For level 2 routers that also play in level 1 routing, routes learned through level 1 routing are ALWAYS preferred over level 2 routes. That's true whether the route uses the requested TOS or the default TOS 🌸 Level 2 routes only get a say when the destination isn't reachable through level 1, or when the router is a level 2 only router (one that doesn't take part in level 1 routing at all). Then the level 2 rules kick in, and they're giving very ordered and very serious 🧚
- Routes using internal metrics only are always preferred to routes using external metrics. No cap, internal always wins 👑
- If a route using internal metrics only is available:
- a) If the destination address matches more than one [IP address, subnet mask] pair, the more specific address match (the one with the largest number of "1"s in the subnet mask) is preferred 🎀
- b) Among routes with equally specific address matches (the same number of "1"s in the subnet mask), routes that support the requested TOS (if there is one) are always preferred over routes that don't support the requested TOS 💖
- c) Among routes of the same TOS with equally specific address matches, the shortest path is preferred. To figure out the shortest path, if a route supporting the specified TOS is available, the specified TOS metric gets used. Otherwise, the default metric is used. Among routes of equal cost, loadsplitting may be performed as specified in [1] 🦋
NOTE: Internal routes (routes to destinations announced in the "IP Internal Reachability Information" field) and external routes using internal metrics (routes to destinations announced in the "IP External Reachability Information" field, with a metric of type "internal") are treated identically for the purpose of the order of preference of routes, and the Dijkstra calculation. It's giving equal treatment, iykyk 🫶
- If a route using internal metrics only is not available, but a route using external metrics is available:
- a) If the destination address matches more than one [IP address, subnet mask] pair, the more specific address match is preferred.
NOTE: For external routes, the subnet mask will normally correspond precisely to the network number. That means this test will always find equal length matching strings. It's still included so that future versions can migrate to more general handling of external addresses 🔮
- b) Among routes with equally specific matches, routes that support the requested TOS (if there is one) are always preferred over routes that don't support the requested TOS. NOTE: For external routes, the route only counts as supporting the requested TOS if the internal route to the appropriate border router supports the requested TOS, AND the external route reported by the border router also supports the requested TOS 🌈
- c) Among routes of the same TOS with an equal length matching address string, the shortest path is preferred. To determine the shortest path:
- (i) Routes with a smaller announced external metric are always preferred 💜
- (ii) Among routes with an equal external metric, routes with a shorter internal metric are preferred. Among routes of equal cost, loadsplitting may be performed as specified in [1] ✨
For level 2 routers that announce manually configured summary addresses in their level 2 LSPs, there will sometimes be IP addresses that match those manually configured addresses but don't match any addresses actually reachable through level 1 routing in the area. Generally, packets to those addresses are handled by these rules 🙈
- If the specified destination is reachable via level 1 routing, then according to the order of preference of routes above, the packet gets delivered via level 1 routing 🌸
- If the specified destination is not reachable via level 1 routing, but is reachable via level 2 routing, and there are other level 2 routers that offer more desirable routes according to the rules above (for example, a route with a more specific match, or a route with an equally specific match that supports the correct TOS), then level 2 routing forwards the packet along the more desirable route 🧚♀️
- If the specified destination is not reachable via level 1 routing, and the manually configured summary address advertised by this router (the router that received the packet and is trying to forward it) represents the most desirable route, then the destination is unreachable and the packet must be discarded. Oof, that's a hard no 💀
4 Subnetwork Dependent Functions 🦋
4.1 Link Demultiplexing
okay so dual routers might receive a mix of OSI packets and IP packets 🌈 They need to be able to clearly and unambiguously tell the two protocol suites apart, or it's total chaos 😭
This problem isn't unique to the integrated IS-IS routing protocol. Honestly, it'll show up in any multi-protocol environment. People are already working on it independently, and it's outside the scope of this specification 🫶
In general, the link type is a configuration parameter. For example, whether to use PPP, HDLC, or some other point-to-point protocol over a point-to-point link gets configured. For any particular link type, a method must be defined for encapsulating both OSI and IP packets. Defining those methods for common link types is outside the scope of this specification 💅
IP packets get encapsulated directly over the underlying link layer service, using the normal method for transmitting IP packets over each type of link. Same vibe for OSI packets: they're encapsulated directly over the underlying link layer service, using the normal method for transmitting OSI packets over each type of link ✨ Finally, IS-IS packets are encapsulated using the normal method for transmitting OSI packets over any particular link type. This means that all IS-IS routers, including IP-only routers, must be able to receive IS-IS packets using the normal encapsulation for OSI packets. Main character requirement 👑
4.2 Multiple IP Addresses per Interface
The integrated IS-IS lets each router have multiple IP addresses for each physical interface, up to the maximum number that can fit in a single "IP Interface Address" field (so, up to 63 addresses per interface) 🎀 For example, if there are two logical subnets on the same LAN, the interface can have two IP addresses, one for each logical subnet. Each IS-IS Hello packet includes a list of the IP addresses associated with the physical interface the Hello is sent over 🦋
It's permissible to implement routers that conform to the Integrated IS-IS specification and restrict the number of IP addresses per interface. However, IP-capable routers must be able to interact correctly with other routers that assign multiple IP addresses per physical interface (up to the maximum of 63 addresses per interface) 🌸
Sometimes an interface has no IP addresses assigned, like on some point-to-point links. Where that's the case, the IS-IS Hello sent on that interface may omit the IP Interface Address field, or it may include the IP Interface Address field with zero entries 🍓
4.3 LANs, Designated Routers, and Pseudonodes
The maintenance of designated routers and pseudonodes is specified in [1], and this proposal doesn't change it. If IP-only and dual routers (or OSI-only and dual routers) are mixed on the same LAN in a pure IP area (or a pure OSI area, respectively), any router on the LAN may be elected designated router 🧚
BUT there's a fundamental difference in how OSI and TCP/IP handle LANs and other broadcast subnetworks, so pay attention bestie 👀
With OSI, the ES-IS protocol (ISO 9542) lets end systems and routers automatically figure out their connectivity. That means all end systems on the LAN can potentially route via any of the routers on the LAN 💜
TCP/IP, on the other hand, explicitly assigns subnet identifiers to each local area network. Sometimes one physical LAN can have multiple subnet identifiers assigned to it 🙃 In that case, end systems (hosts) with an address on one logical subnet are explicitly barred from sending IP packets directly to a router whose address places it on a different logical subnet. Each router is manually configured to know which subnets it can reach on each interface. When there are multiple logical subnets on the same LAN, each router can only exchange IP packets with the end systems that are on the same logical subnet. This means it isn't enough for the pseudonode LSP to announce all subnets on the LAN (that is, all [IP address, subnet mask] pairs reachable on the LAN) 😤
So each router needs to announce, in its LSPs, the subnets it can reach on each interface, including interfaces to broadcast subnetworks like LANs 🌈 The pseudonode LSP does not specify the IP addresses reachable on the LAN (it does not contain the IP reachability field) 🎀
As specified elsewhere (see the forthcoming update to the "Requirements of IP Gateways" [4]), routers may send ICMP redirects only if: (i) the IP packet is being forwarded over the same physical interface it arrived on; and (ii) the source address of the forwarded IP packet, the IP address of this router's interface (as indicated by the source address of the ICMP redirect), and the IP address of the router the packet is being redirected to (again, as indicated in the ICMP redirect) are all on the same IP subnet. Those are the rules, no exceptions 💖
4.4 Maintaining Router Adjacencies ✨
okay so IS-IS figures out whether two routers should become neighbors without looking at their IP interface addresses at all 🧚. This matters because when multiple logical subnets sit on the same physical LAN, two routers can share physical connectivity and still have no logical subnet in common, and an adjacency can still come up between them 🙈. So IP-capable IS-IS routers MUST be able to forward IP packets over those existing adjacencies to routers they're physically connected to, even when the neighbor's adjacent interface is on a different logical IP subnet. main character energy 💅
For point-to-point links, IS-IS needs an exchange of ISO 9542 ISHs as the very first step in setting up the link between routers 🔗. That means every IS-IS router is REQUIRED to transmit and receive ISO 9542 ISH packets on point-to-point links 💖.
The "protocols supported" field (defined in section 5 below) MUST be present in all IS-IS Hello packets sent by dual and IP-only routers 🎀. If it's missing, the packet is assumed to have come from an OSI-only router 👀. The same goes for those 9542 ISHs on point-to-point links where there is (or may be) another IS-IS router at the other end: they MUST also contain the "protocols supported" field. Here's the tea 🫖: if this field ends up in a 9542 ISH and there's an ordinary OSI-only End System on the other end, ISO 9542 says that End System is REQUIRED to ignore the field and read the ISH correctly. So it's totally safe to always include this field in ISHs sent over point-to-point links 🫶.
Dual routers MUST operate in a dual fashion on every link in the routing domain where they run IS-IS 👑. That means the "protocols supported" value MUST be identical on every link. Basically, for any one router running IS-IS, all of the Hellos and LSPs it sends MUST contain the same "protocols supported" values 🌈.
4.5 Forwarding to Incompatible Routers ✨
sometimes a dual router has to forward an IP packet to an OSI-only router, or an OSI packet to an IP-only router 🙃. When that happens, the packet MUST be discarded 🗑️. An error report MAY be sent, following the IP or ISO 8473 spec (whichever applies). The reason for discard in that error report SHOULD be "destination host unreachable" for IP, or "destination unreachable" for OSI 💀.
Similarly, because of errors, an IP-only router might end up forwarding an IP packet to an OSI-only router. Again, the packet MUST be discarded, as covered above 🧹. This can only happen if IP-only and OSI-only routers are in the same area, which is a configuration error 🚨.
5 Structure and Encoding of PDUs 💜
this section is all about the extra packet fields for using the ISO IS-IS Intra-Domain Routing protocol in pure IP and dual environments 🌸. The same packet types as in IS-IS [1] are used, and all the fixed fields stay exactly the same. The new stuff lives in extra variable length fields, which we get into right here ✨.
5.1 Overview of IS-IS PDUs 🦋
IS-IS routing packets come in three main flavors: (i) Hello Packets; (ii) Link State Packets (LSPs); and (iii) Sequence Number Packets (SNPs) 🍓.
Hello packets set up and maintain adjacencies between neighboring routers 👋. There are three kinds:
(i) "Level 1 LAN IS to IS Hello PDUs" are used by level 1 routers on broadcast LANs. (ii) "Level 2 LAN IS to IS Hello PDUs" are used by level 2 routers on broadcast LANs. (iii) "Point-to-Point IS to IS Hello PDUs" are used on non-broadcast media, like point-to-point links or general topology subnetworks 🔌.
On point-to-point links, ISO 9542 ISHs (intermediate system Hellos) get exchanged first to initialize the link and let each router know whether there's a router on the other end, before IS-IS Hellos start flowing 🤝. All routers running IS-IS (IP-only, OSI-only, or dual) that have any point-to-point interfaces MUST be able to transmit ISO 9542 ISHs on those links 💅.
Link State Packets (LSPs) are how link state information gets exchanged 📦. There are two kinds: (i) "Level 1 Link State PDUs" are sent by level 1 routers, and (ii) "Level 2 Link State PDUs" are sent by level 2 routers. Heads up: level 2 routers are usually level 1 routers too, so they send both kinds 🫠.
Sequence number PDUs make sure neighbors agree on which LSP from each other router is the newest 🔢. They're kind of like acknowledgement packets, but way more efficient 🚀. There are four types: (i) "Level 1 Complete Sequence Numbers PDU"; (ii) "Level 2 Complete Sequence Numbers PDU"; (iii) "Level 1 Partial Sequence Numbers PDU"; and (iv) "Level 2 Partial Sequence Numbers PDU" 🧾. A partial sequence number packet lists the most recent sequence number of one or more LSPs, and works a lot like an acknowledgement. The difference is that it can acknowledge several LSPs at once, and it can also act as a request for information 🙌. A complete sequence number packet lists the most recent sequence number of every LSP in the database 📚. Because of that, it's perfect for keeping databases in sync between adjacent routers, either periodically or whenever a link first comes up 🔄.
5.2 Overview of IP-Specific Information for IS-IS 🌈
six new fields get defined for the Integrated IS-IS: (i) "Protocols Supported"; (ii) "IP Interface Address"; (iii) "Authentication Information"; (iv) "IP Internal Reachability Information"; (v) "IP External Reachability Information"; and (vi) "Inter-Domain Routing Protocol Information" 🎀.
The "Protocols Supported" field tells you which protocols each router supports 🗂️. This field MUST be included in all IS-IS Hello packets and all LSPs with LSP number 0 sent by IP-capable routers. If it's not in an IS-IS Hello packet or an LSP with LSP number 0, the packet MAY be assumed to have come from an OSI-only router 🕵️♀️. The "Protocols Supported" field MUST also be included in ISO 9542 ISHs that IP-capable routers send over point-to-point links to other IS-IS routers 🔗.
The "IP Interface Address" is included in all IS-IS Hello packets and LSPs sent by IP-only and dual routers 🏠. In Hello packets it shows up just once, and it holds the IP address(es) of the interface the Hello goes out on (up to 63 IP addresses per interface, max) 🔢. If an interface has no IP address assigned, this field MAY be left out, or included with zero entries 🫥. In Link State Packets, this field is a list of one or more IP addresses for the interfaces of the router that originated the LSP. Every IP-capable router MUST include this field in its LSPs 📜. This field MAY show up multiple times in an LSP, and MAY appear in an LSP with any LSP number 🔁.
The "Authentication Information" field is OPTIONAL in all IS-IS PDUs 🔐. When it's used, it carries info for authenticating the packet. Every IS-IS packet (including 9542 IS Hellos) MAY be authenticated with this field 🛡️.
The "IP Internal Reachability Information" field MAY be present in all LSPs sent by IP-capable routers 🗺️. When it's there, it lists zero or more [IP address, subnet mask, metrics] entries that the originating router can reach. Each entry MUST contain a default metric, and it MAY also contain delay, expense, and error metrics 📊. If an IP-capable router doesn't directly reach any IP addresses, it MAY leave this field out, or include it with zero [IP address, subnet mask, metrics] entries 😴. In level 1 LSPs, this field only includes entries the originating router directly reaches through one of its interfaces 🎯. In level 2 LSPs, it includes entries reachable through one of its interfaces, or indirectly via level 1 routing 🧭. This field MAY occur multiple times in an LSP, and MAY appear in an LSP with any LSP number 🔁.
The "IP External Reachability Information" field MAY be present in level 2 LSPs sent by level 2 IP-capable routers 🌍. When it's there, it lists zero or more [IP address, subnet mask, metrics] entries reachable by the originating router. Each entry MUST contain a default metric, and it MAY contain delay, expense, and error metrics 🧮. Each entry MAY carry metrics of type "internal" or of type "external" 🏷️. If a level 2 router doesn't have any external routes (through neighboring routers in other routing domains), it MAY leave this field out, or include it with zero entries 🫧. This field only includes entries the originating router reaches over a direct link to an external router 🔗. It MAY occur multiple times in a level 2 LSP, and MAY appear in an LSP with any LSP number 🔁.
The "Inter-Domain Routing Protocol Information" field MAY be present in level 2 LSPs sent by level 2 IP-capable routers 🌐. It's sent for the convenience of the external routing protocol, and IS-IS itself doesn't use it 🤷♀️. For example, it MAY be used to help border routers find each other 👀. This field MAY occur multiple times in a level 2 LSP, and MAY appear in an LSP with any LSP number 🔁.
The DP 10589 version of OSI IS-IS doesn't currently let you add TLV-encoded variable length fields to Sequence Number Packets 🙅♀️. That's getting fixed in future versions of 10589, and it's expected to be the only change in future 10589 versions that isn't backward-compatible with the DP version 🧩. So the Integrated IS-IS uses a corrected version of DP 10589, where the SNP encoding has been fixed 🔧. The correct encoding of sequence number packets (as expected to appear in future versions of ISO 10589) is in Annex B of this specification 📎.
All IP-specific info gets encoded in IS-IS packets as variable length fields 🧱. Every variable length field in IS-IS is encoded like this:
No. of Octets
+---------------------------+
| CODE | 1
+---------------------------+
| LENGTH | 1
+---------------------------+
| VALUE | LENGTH
+---------------------------+Figure 3 - Encoding of Variable Length Fields
Any codes in a received PDU that aren't recognised SHALL be ignored 🙈. For packets that get forwarded (specifically Link State Packets), those codes get passed on unchanged 📬.
In general, an IS-IS PDU can contain multiple variable length fields. Some hold OSI-specific info (specified in [1]) and some hold IP-specific info (specified below) 🍰. Unless it's explicitly stated otherwise, these variable length fields MAY show up in any order 🎉.
5.3 Encoding of IP-Specific Fields in IS-IS PDUs 🎀
okay so this section is the detailed encoding of every IP-specific field in IS-IS PDUs 🧚 bestie, if a field can show up in more than one type of PDU, it gets written out again for each PDU type it belongs to. no shortcuts 💅
bit and octet numbering is the same as in [1] 🦋 octets in a PDU are numbered from 1 going up, and bits in an octet are numbered 1 to 8, where bit 1 is the least significant bit and is pictured on the right ✨ when consecutive octets make up a number, the lower octet number holds the most significant value. it's giving math class but make it iconic 🌸
5.3.1 Level 1 LAN IS to IS Hello PDU
- Here are the extra codes for IP support 🌈
- Protocols Supported -- the set of Network Layer Protocol Identifiers for the Network Layer protocols this Intermediate System can relay 💜
- CODE - 129
- LENGTH - total length of the value field (one octet per protocol supported).
- VALUE - one octet NLPID (as assigned by ISO/TR 9577) for each supported data protocol.
- Protocols Supported -- the set of Network Layer Protocol Identifiers for the Network Layer protocols this Intermediate System can relay 💜
No. of Octets
+---------------------------+
| NLPID | 1
+---------------------------+
: :
: :
|---------------------------|
| NLPID | 1
+---------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.- IP Interface Address -- the IP address(es) of the interface that matches the SNPA this PDU gets sent over 🍓
- CODE - 132
- LENGTH - total length of the value field (four octets per address).
- VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address of the Interface.- Authentication Information -- info used to authenticate the PDU 🔐
- CODE - 133
- LENGTH - total length of the value field.
- VALUE - TBD.
5.3.2 Level 2 LAN IS to IS Hello PDU
- Extra IP codes, same energy as the Level 1 one 🫶
- Protocols Supported -- the set of Network Layer Protocol Identifiers for the Network Layer protocols this Intermediate System can relay 💜
- CODE - 129
- LENGTH - total length of the value field (one octet per protocol supported).
- VALUE - one octet NLPID (as assigned by ISO/TR 9577) for each supported data protocol.
- Protocols Supported -- the set of Network Layer Protocol Identifiers for the Network Layer protocols this Intermediate System can relay 💜
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.- IP Interface Address -- the IP address(es) of the interface that matches the SNPA this PDU gets sent over 🍓
- CODE - 132
- LENGTH - total length of the value field (four octets per address).
- VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address of the Interface.- Authentication Information -- info used to authenticate the PDU 🔐
- CODE - 133
- LENGTH - total length of the value field
- VALUE - TBD
5.3.3 Point-to-Point IS to IS Hello PDU
- Extra IP codes for point-to-point links 🦋
- Protocols Supported -- the set of Network Layer Protocol Identifiers for the Network Layer protocols this Intermediate System can relay 💜
- CODE - 129
- LENGTH - total length of the value field (one octet per protocol supported).
- VALUE - one octet NLPID (as assigned by ISO/TR 9577) for each supported data protocol.
- Protocols Supported -- the set of Network Layer Protocol Identifiers for the Network Layer protocols this Intermediate System can relay 💜
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.- IP Interface Address -- the IP address(es) of the interface that matches the SNPA this PDU gets sent over 🍓
- CODE - 132
- LENGTH - total length of the value field (four octets per address).
- VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address of the Interface.- Authentication Information -- info used to authenticate the PDU 🔐
- CODE - 133
- LENGTH - total length of the value field
- VALUE - TBD
5.3.4 Level 1 Link State PDU
- Extra IP codes for LSPs 🌸
- Protocols Supported -- the set of Network Layer Protocol Identifiers for the Network Layer protocols this Intermediate System can relay.
- This must appear once in LSP number 0. 👑
- CODE - 129
- LENGTH - total length of the value field (one octet per protocol supported).
- VALUE - one octet NLPID (as assigned by ISO/TR 9577) for each supported data protocol.
- Protocols Supported -- the set of Network Layer Protocol Identifiers for the Network Layer protocols this Intermediate System can relay.
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.- IP Interface Addresses -- the IP address of one or more interfaces matching the SNPAs enabled on this Intermediate system (so, one or more IP addresses of this router) 🏠
- This is allowed to show up multiple times, and in an LSP with any LSP number. ✨
- CODE - 132
- LENGTH - total length of the value field (four octets per address).
- VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address- Authentication Information -- info used to authenticate the PDU 🔐
- CODE - 133
- LENGTH - total length of the value field
- VALUE - TBD
- IP Internal Reachability Information -- IP addresses inside the routing domain that are reachable directly through one or more interfaces on this Intermediate system 🧭
- This is allowed to show up multiple times, and in an LSP with any LSP number. However, this field must not appear in pseudonode LSPs. 🚫
- CODE - 128.
- LENGTH - a multiple of 12.
- VALUE -
No. of Octets
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
: :
: :
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+- DEFAULT METRIC is the value of the default metric for the link to the listed neighbor 📏. Bit 8 of this field is reserved, must be set to zero on transmission, and is ignored on reception. Bit 7 of this field (marked I/E) indicates the metric type (internal or external) for all four TOS metrics, and must be set to zero, which means internal metrics. 💖
- DELAY METRIC is the value of the delay metric for the link to the listed neighbor. If this IS doesn't support this metric, it shall set the bit "S" to 1 to say the metric is unsupported. Bit 7 of this field is reserved, must be set to zero on transmission, and is ignored on reception. 🙈
- EXPENSE METRIC is the value of the expense metric for the link to the listed neighbor. If this IS doesn't support this metric, it shall set the bit "S" to 1 to say the metric is unsupported. Bit 7 of this field is reserved, must be set to zero on transmission, and is ignored on reception. 💸
- ERROR METRIC is the value of the error metric for the link to the listed neighbor. If this IS doesn't support this metric, it shall set the bit "S" to 1 to say the metric is unsupported. Bit 7 of this field is reserved, must be set to zero on transmission, and is ignored on reception. 💀
- IP ADDRESS is a 4-octet Internet address 🌐
- SUBNET MASK is a 4 octet IP subnet mask 🎭
5.3.5 Level 2 Link State PDU
- Additional codes for IP support are:
- Protocols Supported -- okay, this is the set of Network Layer Protocol Identifiers for the network layer protocols this Intermediate System can relay. Think of it as the router's guest list 💅
- CODE - 129
- LENGTH - total length of the value field (one octet per protocol supported).
- VALUE - one octet NLPID (as assigned by ISO/TR 9577) for each supported data protocol.
- Protocols Supported -- okay, this is the set of Network Layer Protocol Identifiers for the network layer protocols this Intermediate System can relay. Think of it as the router's guest list 💅
This MUST appear once in LSP number 0. 🔥
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
- IP Interface Addresses -- the IP address of one or more interfaces that correspond to the SNPAs enabled on this Intermediate System (so, one or more IP addresses of this router) 🦋
This is permitted to appear multiple times, and in an LSP with any LSP number. If a router is both a level 1 and a level 2 router, it MUST include the same IP addresses in its level 1 and level 2 LSPs. Bestie, this is the consistency check of the century 🫶
- CODE - 132
- LENGTH - total length of the value field (four octets per address).
- VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+IP ADDRESS - 4 octet IP Address
- Authentication Information -- info used to authenticate the PDU 🔐
- CODE - 133
- LENGTH - total length of the value field
- VALUE - TBD
- IP Internal Reachability Information -- IP addresses within the routing domain that are reachable directly via one or more interfaces on this Intermediate System. Main character energy 👑
This is permitted to appear multiple times, and in an LSP with any LSP number. However, this field MUST NOT appear in pseudonode LSPs. 💀
- CODE - 128.
- LENGTH - a multiple of 12.
- VALUE -
No. of Octets
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
: :
: :
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+- DEFAULT METRIC is the value of the default metric for the link to the listed neighbor. Bit 8 of this field is reserved, and MUST be set to zero on transmission and ignored on reception. Bit 7 of this field indicates the metric type (internal or external) for all four TOS metrics, and MUST be set to zero, indicating internal metrics.
- DELAY METRIC is the value of the delay metric for the link to the listed neighbor. If this IS does not support this metric, it SHALL set the bit "S" to 1 to indicate that the metric is unsupported. Bit 7 of this field is reserved, and MUST be set to zero on transmission and ignored on reception.
- EXPENSE METRIC is the value of the expense metric for the link to the listed neighbor. If this IS does not support this metric, it SHALL set the bit "S" to 1 to indicate that the metric is unsupported. Bit 7 of this field is reserved, and MUST be set to zero on transmission and ignored on reception.
- ERROR METRIC is the value of the error metric for the link to the listed neighbor. If this IS does not support this metric, it SHALL set the bit "S" to 1 to indicate that the metric is unsupported. Bit 7 of this field is reserved, and MUST be set to zero on transmission and ignored on reception.
- IP ADDRESS is a 4-octet Internet address.
- SUBNET MASK is a 4 octet IP subnet mask.
- IP External Reachability Information -- IP addresses outside the routing domain that are reachable via interfaces on this Intermediate System 🌍
This is permitted to appear multiple times, and in an LSP with any LSP number. However, this field MUST NOT appear in pseudonode LSPs.
- CODE - 130.
- LENGTH - a multiple of 12.
- VALUE -
No. of Octets
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
: :
: :
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+- DEFAULT METRIC is the value of the default metric for the path to the listed IP addresses. Bit 8 of this field is reserved, and MUST be set to zero on transmission and ignored on reception. Bit 7 of this field indicates the metric type (internal or external) for all four TOS metrics, and MAY be set to zero, indicating internal metrics, or MAY be set to 1, indicating external metrics.
- DELAY METRIC is the value of the delay metric for the path to the listed IP addresses. If this IS does not support this metric, it SHALL set the bit "S" to 1 to indicate that the metric is unsupported. Bit 7 of this field is reserved, and MUST be set to zero on transmission and ignored on reception.
- EXPENSE METRIC is the value of the expense metric for the link to the listed IP addresses. If this IS does not support this metric, it SHALL set the bit "S" to 1 to indicate that the metric is unsupported. Bit 7 of this field is reserved, and MUST be set to zero on transmission and ignored on reception.
- ERROR METRIC is the value of the error metric for the link to the listed IP addresses. If this IS does not support this metric, it SHALL set the bit "S" to 1 to indicate that the metric is unsupported. Bit 7 of this field is reserved, and MUST be set to zero on transmission and ignored on reception.
- IP ADDRESS is a 4-octet Internet address.
- SUBNET MASK is a 4 octet IP subnet mask.
- Inter-Domain Routing Protocol Information -- inter-domain routing protocol info that gets carried transparently through level 2, for the convenience of any Inter-Domain protocol running in the boundary ISs. It's giving pass-through 🎀
This is permitted to appear multiple times, and in an LSP with any LSP number.
- CODE - 131.
- LENGTH - total length of the value field
- VALUE -
No. of Octets
+-------------------------------+
| Inter-Domain Information Type | 1
+-------------------------------+
| External Information | VARIABLE
+-------------------------------+- INTER-DOMAIN INFORMATION TYPE indicates the type of the external information encoded in the field.
- EXTERNAL INFORMATION contains inter-domain routing protocol information, and is passed transparently by the IS-IS protocol.
5.3.6 Level 1 Complete Sequence Numbers PDU
- Additional codes for IP support are:
- Authentication Information -- info used to authenticate the PDU 🔐
- CODE - 133
- LENGTH - total length of the value field
- VALUE - TBD
- Authentication Information -- info used to authenticate the PDU 🔐
5.3.7 Level 2 Complete Sequence Numbers PDU
- Additional codes for IP support are:
- Authentication Information -- info used to authenticate the PDU 🔐
- CODE - 133
- LENGTH - total length of the value field
- VALUE - TBD
- Authentication Information -- info used to authenticate the PDU 🔐
5.3.8 Level 1 Partial Sequence Numbers PDU
- Additional codes for IP support are:
- Authentication Information -- info used to authenticate the PDU 🔐
- CODE - 133
- LENGTH - total length of the value field
- VALUE - TBD
- Authentication Information -- info used to authenticate the PDU 🔐
5.3.9 Level 2 Partial Sequence Numbers PDU
- Additional codes for IP support are:
- Authentication Information -- info used to authenticate the PDU 🔐
- CODE - 133
- LENGTH - total length of the value field
- VALUE - TBD
- Authentication Information -- info used to authenticate the PDU 🔐
5.3.10 ISO 9542 ISH PDU
- Additional codes for IP support are:
- Protocols Supported -- the set of Network Layer Protocol Identifiers for the network layer protocols this Intermediate System can relay, same guest list energy as before 💖
This appears in ISO 9542 ISH PDUs transmitted on point-to-point links.
- CODE - 129
- LENGTH - total length of the value field (one octet per protocol supported).
- VALUE - one octet NLPID (as assigned by ISO/TR 9577) for each supported data protocol.
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
- Authentication Information -- info used to authenticate the PDU 🔐
- CODE - 133
- LENGTH - total length of the value field
- VALUE - TBD
6. Security Considerations 🔐✨
okay bestie, security time 🥺🔐 so integrated IS-IS has a spot for auth info in every IS-IS packet 🎀. It's extensible, so it could hold multiple auth mechanisms, BUT right now the ONLY defined one is a simple password, sent in the clear with no encryption (see Annex D) 💀. ngl, a simple password does NOT give you useful protection against someone who's intentionally being a menace 🙈. Think of it more as a weak shield against accidents, like when someone fat-fingers a config 🫠. Defining other auth mechanisms is out of scope for this doc 📌.
Other security stuff isn't covered in this doc either 🤷♀️.
7. Author's Address 🖋️
Ross Callon
Digital Equipment Corporation
550 King Street, LKG 1-2/A19
Littleton, MA 01460-1289
508-486-50098. References 📚
[1] "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO DP 10589, February 1990.
[2] "Protocol for Providing the Connectionless-Mode Network Service", ISO 8473, March 1987.
[3] "End System to Intermediate System Routeing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service (ISO 8473)", ISO 9542, March 1988.
[4] Braden,R., and Postel,J., "Requirements for Internet Gateways", RFC 1009, June 1987.
[5] Moy,J., "The OSPF Specification", RFC 1131, October 1989.
[6] Postel,J., "Internetwork Protocol", RFC 791, September 1981.
[7] Postel,J., "Internet Control Message Protocol", RFC 792, September 1981.
[8] "MIB for Use with the Extended OSI IS-IS in TCP/IP and Dual Environments", forthcoming.
[9] GOSIP Advanced Requirements Group, "Government Open Systems Interconnection Profile (GOSIP) Version 2.0 [Final Text]", Federal Information Processing Standard, U.S. Department of Commerce, National Institute of Standards and Technology, Gaithersburg, MD, October 1990.
[10] "Standard for Local Area Networks and Metropolitan Area Networks: Overview and Architecture of Network Standards", IEEE Standard 802.1a-1990.
Annex A: Inter-Domain Routing Protocol Information 🌸
This annex is where we spell out the contents and encoding of the Inter-Domain Routing Protocol Information (IDRPI) field 🧚. It's an integral part of the Integrated IS-IS spec, BUT it's expected that this annex MAY be augmented or superceded by future efforts outside the scope of the IS-IS spec 🔮.
A.1. Inter-Domain Information Type 🏷️
So the IDRPI field is one octet of inter-domain information type, plus a variable-length external information field 💕. This section sets the initial values for that type field. Other values for the inter-domain information type will get assigned and maintained in future versions of the "Assigned Numbers" RFC ✨.
The following types have been assigned:
Type = 0 reserved
Type = 1 local (uses routing-domain specific format)
Type = 2 AS Number TagType = 1 means the inter-domain routing protocol info uses a format that's local to the routing domain 🏠.
Type = 2 means the info carries autonomous system info that tags IP external reachability info 🎀. In this case the entry MUST include a single AS number, and that number tags every External IP Reachability entry after it, until the end of the LSP or until the next occurence of the Inter-Domain Routing Protocol Information field 💅.
A.2. Encoding 🧩
As specified in section 5.3.5, the IDPRI entry is a variable length field, and it's encoded like this 💖:
- CODE - 131
- LENGTH - total length of the value field
- VALUE -
No. of Octets
+-------------------------------+
| Inter-Domain Information Type | 1
+-------------------------------+
| External Information | VARIABLE
+-------------------------------+INTER-DOMAIN INFORMATION TYPE tells you what kind of external info is inside the field 👀.
EXTERNAL INFORMATION holds inter-domain routing protocol info, and IS-IS passes it along transparently 🫶.
The inter-domain information type field tells you what's in the external information field, like so:
Type = 0 is reserved. It MUST NOT be sent, and it MUST be ignored on receipt 🙅♀️.
Type = 1 means the external information field has info in a locally specified format 🌈.
Type = 2 means the external information field holds an autonomous system number tag 🔥. This tag gets applied to the IP external reachability entries that come after it. In this case, the "inter-domain routing protocol information" entry MUST contain precisely one 2 octet AS number. The AS tag stays attached to the subsequent IP External Reachability entries until the end of the LSP, or until the next occurence of the Inter-Domain Routing Protocol Information field. Here's what the VALUE looks like for this one 💜:
- VALUE -
No. of Octets
+---------------------------------+
| Inter-Domain Information Type=2 | 1
+---------------------------------+
| Autonomous System Number | 2
+---------------------------------+Annex B: Encoding of Sequence Number Packets 🦋
Integrated IS-IS builds on the ISO Draft Proposed standard for Intra-domain routing (ISO DP 10589 [1]) as its base routing protocol, and IP support gets added on top 🌸.
BUT here's the tea: DP 10589 has a bug in how it encodes the variable length fields in Sequence Number Packets 😭. Those SNP fields are not flexible (you can't define additional variable length fields for sequence number packets), and they don't match how every other IS-IS and ES-IS packet encodes its variable length fields 🙈.
The SNP encoding is expected to get fixed in future versions of 10589 🔧. This bug is also the only expected change to 10589 that can't be made backward compatible with existing DP 10589 implementations 💀. So the current version of Integrated IS-IS uses the anticipated future encoding for the variable length part of the SNPs. That should let future versions of this spec stay compatible with implementations based on this one 🫶.
This annex specifies the SNP encoding, as amended to fix the variable length fields. It's an integral part of the Integrated IS-IS spec 🔥.
The SNP encoding for OSI-only use is shown in this section. For IP-only or Integrated use, the additional variable length fields specified in sections 5.3.6 through 5.3.9 also apply to SNPs 💅.
B.1. Level 1 Complete Sequence Numbers PDU 🍓
No. of Octets
+--------------------------------+
| INTRA-DOMAIN ROUTEING | 1
| PROTOCOL DISCRIMINATOR |
+--------------------------------+
| LENGTH INDICATOR | 1
+--------------------------------+
| VERSION/PROTOCOL ID EXT | 1
+--------------------------------+
| RESERVED | 1
+--------------------------------+
| R | R | R | TYPE | 1
+--------------------------------+
| VERSION | 1
+--------------------------------+
| ECO | 1
+--------------------------------+
| USER ECO | 1
+--------------------------------+
| PDU LENGTH | 2
+--------------------------------+
| SOURCE ID | 7
+--------------------------------+
| START LSP ID | 8
+--------------------------------+
| END LSP ID | 8
+================================+====================
| VARIABLE LENGTH FIELDS | VARIABLE
+--------------------------------+- INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR - architectural constant
- LENGTH INDICATOR - Header Length in octets (33.)
- VERSION/PROTOCOL ID EXTENSION - 1
- RESERVED - transmitted as 0, ignored on receipt
- TYPE (bits 1 through 5) - 24. Note bits 6, 7 and 8 are Reserved, which means they are transmitted as 0 and ignored on receipt.
- VERSION - 1
- ECO - transmitted as zero, ignored on receipt
- USER ECO - transmitted as zero, ignored on receipt
- PDU LENGTH - Entire Length of this PDU, in octets, including header
- SOURCE ID - 7 octet ID of Intermediate System (with zero Circuit ID) generating this Sequence Numbers PDU.
- START LSP ID - 8 octet ID of first LSP in the range covered by this Complete Sequence Numbers PDU.
- END LSP ID - 8 octet ID of last LSP in the range covered by this Complete Sequence Numbers PDU.
- VARIABLE LENGTH FIELDS - fields of the form:
No. of Octets
+--------------------------------+
| CODE | 1
+--------------------------------+
| LENGTH | 1
+--------------------------------+
| VALUE | LENGTH
+--------------------------------+Any codes in a received CSNP that aren't recognised get ignored 🙃.
Currently defined codes are:
- 7 LSP Entries -- This MAY appear multiple times. The option fields, if they appear more than once, SHALL appear sorted into ascending LSPID order 📋.
- CODE - 9
- LENGTH - total length of the value field.
- VALUE - a list of LSP entries of the form:
No. of Octets
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
: :
: :
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+7 REMAINING LIFETIME - Remaining Lifetime of LSP. ⏳
7 LSP ID - 8 octet ID of the LSP to which this entry refers. 🆔
7 LSP SEQ NUMBER - Sequence number of LSP. 🔢
B.2. Level 2 Complete Sequence Numbers PDU ✨
okay bestie, this is the Level 2 Complete Sequence Numbers PDU, and the header layout is giving very structured 🎀
No. of Octets
+--------------------------------+
| INTRA-DOMAIN ROUTEING | 1
| PROTOCOL DISCRIMINATOR |
+--------------------------------+
| LENGTH INDICATOR | 1
+--------------------------------+
| VERSION/PROTOCOL ID EXT | 1
+--------------------------------+
| RESERVED | 1
+--------------------------------+
| R | R | R | TYPE | 1
+--------------------------------+
| VERSION | 1
+--------------------------------+
| ECO | 1
+--------------------------------+
| USER ECO | 1
+--------------------------------+
| PDU LENGTH | 2
+--------------------------------+
| SOURCE ID | 7
+--------------------------------+
| START LSP ID | 8
+--------------------------------+
| END LSP ID | 8
+================================+====================
| VARIABLE LENGTH FIELDS | VARIABLE
+--------------------------------+- INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR - architectural constant
- LENGTH INDICATOR - Header Length in octets (33.)
- VERSION/PROTOCOL ID EXTENSION - 1
- RESERVED - transmitted as 0, ignored on receipt
- TYPE (bits 1 through 5) - 25. Note bits 6, 7 and 8 are Reserved, which means they are transmitted as 0 and ignored on receipt.
- VERSION - 1
- ECO - transmitted as zero, ignored on receipt
- USER ECO - transmitted as zero, ignored on receipt
- PDU LENGTH - Entire Length of this PDU, in octets, including header
- SOURCE ID - 7 octet ID of Intermediate System (with zero Circuit ID) generating this Sequence Numbers PDU.
- START LSP ID - 8 octet ID of first LSP in the range covered by this Complete Sequence Numbers PDU.
- END LSP ID - 8 octet ID of last LSP in the range covered by this Complete Sequence Numbers PDU.
- VARIABLE LENGTH FIELDS - fields of the form:
No. of Octets
+--------------------------------+
| CODE | 1
+--------------------------------+
| LENGTH | 1
+--------------------------------+
| VALUE | LENGTH
+--------------------------------+Any codes in a received CSNP that are not recognised are ignored.
Currently defined codes are:
- LSP Entries -- this may appear multiple times. The option fields, if they appear more than once, shall appear sorted into ascending LSPID order.
- CODE - 9
- LENGTH - total length of the value field.
- VALUE - a list of LSP entries of the form:
No. of Octets
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
: :
: :
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+- REMAINING LIFETIME - Remaining Lifetime of LSP.
- LSP ID - 8 octet ID of the LSP to which this entry refers.
- LSP SEQ NUMBER - Sequence number of LSP.
- CHECKSUM - Checksum reported in LSP.
The entries shall be sorted into ascending LSPID order (the LSP number octet of the LSPID is the least significant octet).
B.3. Level 1 Partial Sequence Numbers PDU 🧚
next up is the Level 1 Partial Sequence Numbers PDU, which is the same vibe but with its own numbers and a shorter header 💅
No. of Octets
+--------------------------------+
| INTRA-DOMAIN ROUTEING | 1
| PROTOCOL DISCRIMINATOR |
+--------------------------------+
| LENGTH INDICATOR | 1
+--------------------------------+
| VERSION/PROTOCOL ID EXT | 1
+--------------------------------+
| RESERVED | 1
+--------------------------------+
| R | R | R | TYPE | 1
+--------------------------------+
| VERSION | 1
+--------------------------------+
| ECO | 1
+--------------------------------+
| USER ECO | 1
+--------------------------------+
| PDU LENGTH | 2
+--------------------------------+
| SOURCE ID | 7
+================================+====================
| VARIABLE LENGTH FIELDS | VARIABLE
+--------------------------------+- INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR - architectural constant
- LENGTH INDICATOR - Header Length in octets (17.)
- VERSION/PROTOCOL ID EXTENSION - 1
- RESERVED - transmitted as 0, ignored on receipt
- TYPE (bits 1 through 5) 26. Note bits 6, 7 and 8 are Reserved, which means they are transmitted as 0 and ignored on receipt.
- VERSION - 1
- ECO - transmitted as zero, ignored on receipt
- USER ECO - transmitted as zero, ignored on receipt
- PDU LENGTH - Entire Length of this PDU, in octets, including header
- SOURCE ID - 7 octet ID of Intermediate system (with zero Circuit ID) generating this Sequence Numbers PDU.
- VARIABLE LENGTH FIELDS - fields of the form:
No. of Octets
+--------------------------------+
| CODE | 1
+--------------------------------+
| LENGTH | 1
+--------------------------------+
| VALUE | LENGTH
+--------------------------------+Any codes in a received PSNP that are not recognised are ignored.
Currently defined codes are:
- LSP Entries - this may appear multiple times. The option fields, if they appear more than once, shall appear sorted into ascending LSPID order.
- CODE - 9
- LENGTH - total length of the value field.
- VALUE - a list of LSP entries of the form:
No. of Octets
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
: :
: :
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+- REMAINING LIFETIME - Remaining Lifetime of LSP.
- LSP ID - 8 octet ID of the LSP to which this entry refers.
- LSP SEQ NUMBER - Sequence number of LSP.
- CHECKSUM - Checksum reported in LSP.
The entries shall be sorted into ascending LSPID order (the LSP number octet of the LSPID is the least significant octet).
B.4. Level 2 Partial Sequence Numbers PDU 💖
and last but not least in this part, the Level 2 Partial Sequence Numbers PDU, which is basically the Level 1 PSNP's sibling with its own type number 🫶
No. of Octets
+--------------------------------+
| INTRA-DOMAIN ROUTEING | 1
| PROTOCOL DISCRIMINATOR |
+--------------------------------+
| LENGTH INDICATOR | 1
+--------------------------------+
| VERSION/PROTOCOL ID EXT | 1
+--------------------------------+
| RESERVED | 1
+--------------------------------+
| R | R | R | TYPE | 1
+--------------------------------+
| VERSION | 1
+--------------------------------+
| ECO | 1
+--------------------------------+
| USER ECO | 1
+--------------------------------+
| PDU LENGTH | 2
+--------------------------------+
| SOURCE ID | 7
+================================+====================
| VARIABLE LENGTH FIELDS | VARIABLE
+--------------------------------+- INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR - architectural constant
- LENGTH INDICATOR - Header Length in octets (17.)
- VERSION/PROTOCOL ID EXTENSION - 1
- RESERVED - transmitted as 0, ignored on receipt
- TYPE (bits 1 through 5) - 27. Note bits 6, 7 and 8 are Reserved, which means they are transmitted as 0 and ignored on receipt.
- VERSION - 1
- ECO - transmitted as zero, ignored on receipt
- USER ECO - transmitted as zero, ignored on receipt
- PDU LENGTH - Entire Length of this PDU, in octets, including header
- SOURCE ID - 7 octet ID of Intermediate system (with zero Circuit ID) generating this Sequence Numbers PDU.
- VARIABLE LENGTH FIELDS - fields of the form:
No. of Octets
+--------------------------------+
| CODE | 1
+--------------------------------+
| LENGTH | 1
+--------------------------------+
| VALUE | LENGTH
+--------------------------------+Any codes in a received PSNP that are not recognised are ignored.
Currently defined codes are:
- LSP Entries -- this may appear multiple times 🎀 The option fields, if they appear more than once, shall appear sorted into ascending LSPID order 💅
- CODE -
9 - LENGTH - total length of the value field.
- VALUE - a list of LSP entries of the form: 🧚
No. of Octets
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
: :
: :
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+- REMAINING LIFETIME - Remaining Lifetime of LSP. ⏳
- LSP ID - 8 octet ID of the LSP to which this entry refers. 🆔
- LSP SEQ NUMBER - Sequence number of LSP. 🔢
- CHECKSUM - Checksum reported in LSP. ✅
The entries shall be sorted into ascending LSPID order (the LSP number octet of the LSPID is the least significant octet) 🫶
Annex C: Dijkstra Calculation and Forwarding 🧚
Okay so, Annex C.2 of ISO DP 10589 [1] already specifies the SPF (Dijkstra) algorithm for calculating routes with the IS-IS routing protocol 🦋 This annex is giving modifications to that algorithm so it can handle IP and dual routing, plus a compatible way of forwarding IP packets. The end result is an order of route preference that matches what section 3.10 describes, so it all lines up 💜
This annex is included for informational purposes. ℹ️
C.1 SPF Algorithm for IP and Dual Use
This section specifies an SPF Algorithm for calculating routes with the IS-IS routing protocol, supporting both TCP/IP and OSI 🌈 It's based on an extension to the algorithm in annex C.2 of ISO DP 10589 [1], so bestie, you already know the vibe ✨
An algorithm invented by Dijkstra, known as shortest path first (SPF), is the basis for the route calculation 🍓 Its computational complexity is the square of the number of nodes, but for sparse networks (networks which are not highly connected) that can drop to the number of links in the domain times the log of the number of nodes. Iconic glow-up 💅
A number of additional optimizations are possible: 👑
- If the routing metric is defined over a small finite field (as in this standard), the factor of log n may be removed by using data structures which maintain a separate list of systems for each value of the metric, rather than sorting the systems by logical distance. 🧠
- Updates can be performed incrementally without requiring a complete recalculation. However, a full update must be done periodically to ensure recovery from data corruption. Studies suggest that with a very small number of link changes (perhaps 2), the expected computation complexity of the incremental update exceeds the complete recalculation. So this annex specifies the algorithm only for the full update 🙈
- If only End System LSP information has changed, it is not necessary to re-compute the entire Dijkstra tree. If the proper data structures are used, End Systems (including IP reachability entries) may be attached and detached as leaves of the tree, and their forwarding information base entries altered as appropriate. 🌸
The original SPF algorithm does not support load splitting over multiple paths. The algorithm in this annex does permit load splitting, by identifying a set of equal cost paths to each destination rather than a single least cost path 🔥
C.1.1 Databases
PATHS -- this represents an acyclic directed graph of shortest paths from the system S performing the calculation. It is stored as a set of triples of the form <N,d(N),{Adj(N)}>, where:
N is a system identifier. In the level 1 algorithm, N is a 6 octet ID for OSI end systems, a 7 octet ID for routers, or an 8 octet IP Internal Reachability Information entry. For a router which is not a pseudonode, it is the 6 octet system ID, with a 0 appended octet. For a pseudonode it is a true 7 octet quantity, comprised of the 6 octet Designated Intermediate System ID and the extra octet assigned by the Designated Router. The IP Internal Reachability Information entries consist of a 4 octet IP address plus a 4 octet subnet mask, and will always be a leaf, i.e., "End System" in PATHS. 🌳
In the level 2 algorithm, N is either a 7 octet router or pseudonode ID (as in the level 1 algorithm); a variable length OSI address prefix; an 8 octet IP Internal Reachability Information Entry, or an 8 octet IP External Reachability Information entry. The variable length OSI address prefixes and 8 octet IP Reachability Information entries will always be a leaf, i.e., "End System" in PATHS. As above, the IP Reachability Information entries consist of an [IP address, subnet mask] combination. 🍃
d(N) is N's distance from S (i.e., the total metric value from N to S). 📏
{Adj(N)} is a set of valid adjacencies that S may use for forwarding to N. 🛣️
When a system is placed on PATHS, the path(s) designated by its position in the graph is guaranteed to be a shortest path. 💖
TENT -- this is a list of triples of the form <N,d(N),{Adj(N)}>, where N, d(N), and {Adj(N)} are as defined above for PATHS. ⏳
TENT can intuitively be thought of as a tentative placement of a system in PATHS. In other words, the triple <N,x,{A}> in TENT means that if N were placed in PATHS, d(N) would be x, but N cannot be placed on PATHS until it is guaranteed that no path shorter than x exists. 🤔
Similarly, the triple <N,x,{A,B}> in TENT means that if N were placed in PATHS, then d(N) would be x via either adjacency A or B. 🦋
Note: It is suggested that the implementation maintain the database TENT as a set of list of triples of the form<*,Dist,*>, sorted by distanceDist. In addition, it is necessary to be able to process those systems which are pseudonodes before any non-pseudonodes at the same distanceDist. ✨
The 8 octet system identifiers which specify IP reachability entries must always be distinguishable from other system identifiers. As specified in section 3.10, two IP reachability entries which differ only in the subnet mask are still considered to be separate, and will therefore have distinct system identifiers N. The SPF algorithm will therefore calculate routes to each such entry, and the correct entry will be selected in the forwarding process. 🎀
C.1.2 Use of Metrics in the SPF Algorithm
Internal metrics are not comparable to external metrics. For external routes (routes to destinations outside of the routing domain), the cost d(N) of the path from N to S may include both internal and external metrics. So d(N) may be maintained as a two-dimensioned vector quantity (specifying internal and external metric values). It's giving math with main character energy 📐
d(N) is initialized to [internal metric = 0, external metric = 0]. 🌱
In incrementing d(N) by 1, if the internal metric value is less than the maximum value MaxPathMetric, then the internal metric value is incremented by one and the external metric value is left unchanged. If the internal metric value is equal to the maximum value MaxPathMetric, then the internal metric value is set to 0 and the external metric value is incremented by 1. Note that this can be implemented in a straightforward manner by maintaining the external metric as the high order bits of the distance. 🔢
In the code of the algorithm below, the current path length is held in the variable tentlength. This variable is a two-dimensional quantity, tentlength=[internal metric, external metric], and is used for comparing the current path length with d(N) as described above. tentlength is incremented in the same manner as d(N). 💅
C.1.3 Overview of the Algorithm
The basic algorithm, which builds PATHS from scratch, starts out by putting the system doing the computation on PATHS (no shorter path to SELF can possibly exist). TENT is then pre-loaded from the local adjacency database. 🚀
Note that a system is not placed on PATHS unless no shorter path to that system exists. When a system N is placed on PATHS, the path to each neighbor M of N, through N, is examined, as the path to N plus the link from N to M. If <M,*,*> is in PATHS, this new path will be longer, and thus ignored. 🙅♀️
If <M,*,*> is in TENT and the new path is shorter, the old entry is removed from TENT and the new path is placed in TENT. If the new path is the same length as the one in TENT, then the set of potential adjacencies {Adj(M)} is set to the union of the old set (in TENT) and the new set {Adj(N)}. If M is not in TENT, then the path is added to TENT. 🧩
Next the algorithm finds the triple <N,x,{Adj(N)}> in TENT with minimal x. Note: This is done efficiently because of the optimization described above. When the list of triples for distance Dist is exhausted, the algorithm then increments Dist until it finds a list with a triple of the form <*,Dist,*>. 🔍
N is placed in PATHS. We know that no path to N can be shorter than x at this point, because all paths through systems already in PATHS have already been considered, and paths through systems in TENT still have to be greater than x, because x is minimal in TENT. Periodt 🫶
When TENT is empty, PATHS is complete. 🎉
Note that external metrics can only occur in "IP External Reachability Information" entries, which correspond to a leaf (i.e., End System in PATHS). Any route utilizing an entry with an external metric will always be considered to be less desirable than any entry which uses an internal metric. This implies that in the addition of systems to PATHS, all systems reachable via internal routes are always added before any system reachable via external routes. 🌈
C.1.4. The Algorithm ✨
okay bestie, so the Decision Process Algorithm must be run once for each supported routing metric (aka each supported Type of Service) 💅. A level 1 router runs it on the level 1 LSP database to compute level 1 paths. For level 1 routers that aren't also level 2 routers, that includes the path to the nearest attached level 2 router 🧚. Level 2 routers also run it separately on the level 2 LSP database to compute level 2 paths. And IP-capable level 2 routers must keep level 2 internal IP routes separate from level 2 external IP routes 🫶.
ngl, that means a router that's both level 1 and level 2, and supports all four routing metrics, has to run SPF 8 times (assuming partition repair isn't implemented) 😭🔥.
Now the partition repair part 🩹. If this system is a Level 2 Router that supports the partition repair optional function, the Decision Process algorithm for computing Level 1 paths must be run twice for the default metric. The first run figures out which of the area's manualAreaAddresses are reachable in this partition, and it elects a Partition Designated Level 2 Router for the partition 👑. That Partition Designated Level 2 Router is the one that works out whether the area is partitioned, and then makes virtual Level 1 links to the other Partition Designated Level 2 Routers in the area to repair the Level 1 partition. More on that in section 7.2.10 of [1] 💖.
The SPF algorithm specified here calculates routes for both OSI and IP 🌈. Routes get calculated to all system identifiers N, and N can be an OSI End System, the OSI address of a router, or an IP reachability entry. When it comes to the forwarding database, it's up to the implementation whether the IP forwarding database is kept separate from the OSI one. This annex will refer to entries in those two forwarding databases separately where it makes sense, but that's not meant to rule out any particular implementation method ✨.
OSI and IP figure out "is this packet in the area?" in different ways. OSI uses area addresses, while IP decides a destination is not in the area by checking the level 1 forwarding database and seeing that there's no entry for it inside the area 🙈. The route to the nearest level 2 router gets its own entry in the forwarding database for OSI and a separate one for IP. For IP, that route to the nearest attached level 2 router may be entered as a default route (aka a route with a subnet mask of all 0s) 🍓.
One approach is to put the results of each Dijkstra run in its own forwarding database. For a router that supports both level 1 and level 2 routing (including level 2 internal and level 2 external routes), and supports all four types of service, that works out to twelve separate IP forwarding databases 😳. Implementations can cut that down by combining the info from the multiple Dijkstra calculations into a single database per supported TOS. Section C.2 below covers that bit 🧠.
The SPF algorithm specified in section C.2.3 of [1] is amended to look like this 📝:
Step 0: Initialize TENT and PATHS to empty. Initialize tentlength to
[internalmetric=0, externalmetric=0].
(tentlength is the pathlength of elements in TENT that we are
examining.)
1) Add <SELF,0,W> to PATHS, where W is a special value indicating
traffic to SELF is passed up to internal processes (rather than
forwarded).
2) Now pre-load TENT with the local adjacency database (Each
entry made to TENT must be marked as being either an End System
or a router to enable the check at the end of Step 2 to be made
correctly - Note that each local IP reachability entry is
included as an adjacency, and is marked as being an End System).
For each adjacency Adj(N) (including level 1 OSI Manual
Adjacencies, or level 2 OSI enabled reachable addresses, and
IP reachability entries) on enabled circuits, to system N of
SELF in state "Up" compute:
d(N) = cost of the parent circuit of the adjacency (N),
obtained from metric.k , where k = one of {default metric,
delay metric, monetary metric, error metric}
Adj(N) = the adjacency number of the adjacency to N
3) If a triple <N,x,{Adj(M)}> is in TENT, then:
If x = d(N), then {Adj(M)} <--- {Adj(M)} U {Adj(N)}.
4) If N is a router or an OSI End System entry, and there are now
more adjacencies in {Adj(M)} than maximumPathSplits, then remove
excess adjacencies as described in Clause 7.2.7 of [1]. If N
is an IP Reachability Entry, then excess adjacencies may be
removed as desired. This will not effect the correctness of
routing, but may eliminate the determinism for IP routes (i.e.,
IP packets still follow optimal routes within an area, but
where multiple equally good routes exist, will not necessarily
follow precisely the route that any one particular router
would have anticipated).
5) If x < d(N), do nothing.
6) If x > d(N), remove <N,x,{Adj(M)}> from TENT and add the triple
<N,d(N),{Adj(N)}>.
7) If no triple <N,x,{Adj(M)}> is in TENT, then add <N,d(N),{Adj(N)}>
to TENT.
8) Now add systems to which the local router does not have adjacencies,
but which are mentioned in neighboring pseudonode LSPs. The
adjacency for such systems is set to that of the designated router.
Note that this does not include IP reachability entries from
neighboring pseudonode LSPs. In particular, the pseudonode LSPs
do not include IP reachability entries.
9) For all broadcast circuits in state "On", find the pseudonode
LSP for that circuit (specifically, the LSP with number zero and
with the first 7 octets of LSPID equal to LnCircuitID for that
circuit, where n is 1 (for level 1 routing) or 2 (level 2
routing)). If it is present, for all the neighbors N reported in
all the LSPs of this pseudonode which do not exist in TENT add
an entry <N,d(N),{Adj(N)}> to TENT, where:
d(N) = metric.k of the circuit.
Adj(N) = the adjacency number of the adjacency to the DR.
10) Go to Step 2.Step 1 is where things get a bit spicy 🌶️, so buckle up:
Step 1: Examine the zeroeth link state PDU of P, the system just
placed on PATHS (i.e., the LSP with the same first 7 octets of LSPID
as P, and LSP number zero).
1) If this LSP is present, and the "Infinite Hippity Cost" bit is
clear, then for each LSP of P (i.e., all LSPs with the same
first 7 octets of LSPID and P, irrespective of the value of
LSP number) compute:
dist(P,N) = d(P) + metric.k(P,N)
for each neighbor N (both End System and router) of the system P. If
the "Infinite Hippity Cost" bit is set, only consider the End System
neighbors of the system P. Note that the End Systems neighbors of the
system P includes IP reachable address entries included in the LSPs
from system P. Here, d(P) is the second element of the triple
<P,d(P),{Adj(P)}>
and metric.k(P,N) is the cost of the link from P to N as reported in
P's link state PDU.
2) If dist(P,N) > MaxPathMetric, then do nothing.
3) If <N,d(N),{Adj(N)}> is in PATHS, then do nothing.
Note: d(N) must be less than dist(P,N), or else N would not
have been put into PATHS. An additional sanity check may be
done here to ensure that d(N) is in fact less than dist(P,N)
4) If a triple <N,x,{Adj(N)}> is in TENT, then:
a) If x = dist(P,N), then {Adj(N)} <-- {Adj(N)} U {Adj(P)}.
b) If N is a router or an OSI end system, and there are now more
adjacencies in {Adj(N)} than maximumPath Splits, then remove
excess adjacencies, as described in clause 7.2.7 of [1]. For
IP Reachability Entries, excess adjacencies may be removed as
desired. This will not effect the correctness of routing, but
may eliminate the determinism for IP routes (i.e., IP packets
will still follow optimal routes within an area, but where
multiple equally good routes exist, will not necessarily follow
precisely the route that any one particular router would have
anticipated).
c) if x < dist(P,N), do nothing.
d) if x > dist(P,N), remove <N,x,{Adj(N)}> from TENT, and add
<N,dist(P,N),{Adj(P)}>
5) if no triple <N,x,{Adj(N)}> is in TENT, then add
<N,dist(P,N),{Adj(P)}> to TENT.And finally Step 2, the grand finale 🎀:
Step 2: If TENT is empty, stop. Else:
1) Find the element <P,x,{Adj(P)}>, with minimal x as follows:
a) If an element <*,tentlength,*> remains in TENT in the list for
tentlength, choose that element. If there are more than one
elements in the list for tentlength, choose one of the elements
(if any) for a system which is a pseudonode in preference to one
for a non-pseudonode. If there are no more elements in the list
for tentlength, increment tentlength and repeat Step 2.
b) Remove <P,tentlength,{Adj(P)}> from TENT.
c) Add <P,d(P),{Adj(P)}> to PATHS.
d) If this is the Level 2 Decision Process running, and the system
just added to PATHS listed itself as Partition Designated Level 2
Intermediate system, then additionally add <AREA.P,d(P),{Adj(P)}>
to PATHS, where AREA.P is the Network Entity Title of the other
end of the Virtual Link, obtained by taking the first AREA
listed in P's LSP and appending P's ID.
e) If the system just added to PATHS was an end system, go to
step 2. Else go to Step 1.NOTE 🫣: in the level 2 context, the "End Systems" are the set of Reachable Address Prefixes (for OSI), the set of Area Addresses with zero cost (again, for OSI), plus the set of IP reachability entries (including both internal and external). Don't skip this one, it matters!
C.2. Forwarding of IP packets 📦
The SPF algorithm in section C.1 can be used to calculate (logically) separate IP forwarding tables for each type of service, and for level 1, level 2 internal, and level 2 external routes 🦋. Section C.2.1 explains how to forward IP packets using these multiple forwarding databases, and section C.2.2 explains how those multiple databases can be combined into a single forwarding database per supported TOS 🌸.
C.2.1 Basic Method for Forwarding IP packets ✨
Okay bestie, this is the forwarding flow, and it's giving very "check the closest match first, then fall back" energy 💅
For level 1-only routers:
- Determine if the IP destination address matches any entry in the level 1 forwarding table for the specified TOS.
- Determine if the IP destination address matches any entry in the level 1 forwarding table for the default TOS.
- If default TOS resulted in more specific entry, forward according to default TOS.
- If equally specific entries found, or specified TOS resulted in more specific entry, forward according to specified TOS.
- If no entry was found (which includes no default route entry), then destination is unreachable.
Note: For level 1 only routers, the route to the nearest attached level 2 router will be entered into the forwarding database as a default route (i.e., a route with a subnet mask which is all 0). Thus this last event (no entry found) can occur only if there is no attached level 2 router reachable in the area. 🌸
For routers which are both level 1 and level 2 routers:
- Determine if the IP destination address matches any entry in the level 1 forwarding table for the specified TOS.
- Determine if the IP destination address matches any entry in the level 1 forwarding table for the default TOS.
- If default TOS resulted in more specific entry (i.e., more bits in the subnet mask take the value 1), forward according to default TOS.
- If equally specific entries found, or specified TOS resulted in more specific entry, forward according to specified TOS.
- If no entry found:
- Determine if the IP destination address matches any entry in the level 2 internal forwarding table for the specified TOS.
- Determine if the IP destination address matches any entry in the level 2 internal forwarding table for the default TOS.
- If default TOS resulted in more specific entry, forward according to default TOS.
- If equally specific entries found, or specified TOS resulted in more specific entry, forward according to specified TOS.
- If no entry found:
- Determine if the IP destination address matches any entry in the level 2 external forwarding table for the specified TOS.
- Determine if the IP destination address matches any entry in the level 2 external forwarding table for the default TOS.
- If default TOS resulted in more specific entry, forward according to default TOS.
- If equally specific entries found, or specified TOS resulted in more specific entry, forward according to specified TOS.
- If no entry is found, then destination is unreachable.
For level 2-only routers, the above algorithm can be used, except since there is no level 1 forwarding database, the corresponding steps can be skipped. 🧚
As discussed in section 3.10.2, for level 2 routers which are announcing manually configured summary addresses in their level 2 LSPs, in some cases there will exist IP addresses which match the manually configured addresses, but which do not match any addresses which are reachable via level 1 routing in the area. Packets to such addresses are handled according to the rules specified in section 3.10.2. This may be accomplished by adding the manually configured [IP address, subnet mask] entry to the level 2 forwarding database (for the appropriate TOS), with a special "next hop" address which specifies that packets for which this entry is selected are to be discarded. This will work correctly because more desireable entries (such as delivering the packet via level 1 routing to the correct destination, or a more specific level 2 route) will automatically take precedence according to the forwarding rules specified above. Less desireable routes (such as using a level 2 external route to the "default route" entry) are not possible because other level 2 routers will believe the summary addresses advertised by this router. 🦋
C.2.2 Reduction of IP Forwarding Databases 💜
This part is so clever, like packing three suitcases into one without losing a single outfit 🧳
The multiple forwarding databases used in the basic forwarding method in section C.2.1 can be reduced, by combining the multiple databases into one database for each supported TOS.
For reduction of IP forwarding databases, it is assumed that for any two overlapping address entries, either the entries are identical, or one range contains the other. In other words, for any two [IP address, subnet mask] entries A and B, if there is at least one IP address which matches both entries, then either: (i) the two entries are identical; or (ii) entry A contains entry B (i.e., any IP address which matches entry B also matches entry A); or (iii) entry B contains entry A (any IP address which matches entry A also matches entry B).
Non-contiguous subnet masks can be configured to violate this assumption. For example, consider the two entries:
- A=[address="01010101 00000101 00000000 00000000",
mask="11111111 00001111 00000000 00000000"]
- B=[address="01010101 01010000 00000000 00000000",
mask="11111111 11110000 00000000 00000000"]In this case neither entry contains the other. Specifically;
- there are IP addresses which match both A and B (e.g.,
"01010101 01010101 xxxxxxxx xxxxxxxx"), - there are IP addresses which match A but not B (e.g.,
"01010101 11110101 xxxxxxxx xxxxxxxx") - there are IP addresses which match B but not A (e.g.,
"01010101 01011111 xxxxxxxx xxxxxxxx").
The reduction of the multiple forwarding databases for each TOS to a single database for each TOS is based on the use of "best match" routing, combined with reduction of the entries placed in the forwarding database in order to eliminate entries which are not to be selected (based on the order of preference of routes specified in section 3.10). The specific algorithm for creation of the IP forwarding database can be described as follows:
- Make use of the the Dijkstra algorithm described in section C.1 to create separate forwarding databases for each supported TOS for level 1 routes, level 2 internal routes, and level 2 external routes. (Note that each entry in the forwarding database will specify an
[IP address, subnet mask]combination, as well as the next hop router for IP packets which match that entry). - For each level 1 route entry which has been placed in the level 1 IP forwarding database for a specific TOS, copy that entry into the overall IP forwarding database for that TOS.
- For each route entry X which has been placed in the level 2 internal IP forwarding database for a specific TOS, search for overlapping entries in the level 1 IP forwarding database for the specific TOS, and also for the default TOS:
- a) If there is any overlapping entry Y in the level 1 forwarding database (for the specfic TOS, or for the default TOS) such that either (i) Y contains X; or (ii) Y is identically specific to X; then ignore entry X.
- b) Otherwise, copy entry X into the overall IP forwarding database for the specific TOS.
- For each route entry X which has been placed in the level 2 external IP forwarding database for a specific TOS, search for overlapping entries in the level 1 IP forwarding database for the specific TOS, and for the default TOS, and the level 2 internal IP forwarding database for the specific TOS, and for the default TOS.
- a) If there is an overlapping entry Y such that either (i) Y contains X; or (ii) Y is identically specific to X; then ignore entry X.
- b) Otherwise, copy entry X into the overall IP forwarding database for the specific TOS.
This method will result in one forwarding database for each supported TOS. The forwarding of packets can then be simplified to be as follows:
- For IP packets which map to the default TOS metric (or to an unsupported TOS metric), search the default TOS forwarding database and select the entry which has the most specific match. Forward the packet accordingly.
- For packets which map to a specific (non-default) TOS metric, search the specific TOS forwarding database and select the entry j which has the most specific match. Also search the default TOS forwarding database and select the entry k which has the most specific match. Forward the packet as follows:
- a) If k is more specific than j, forward according to entry k.
- b) If j and k are equally specific, forward according to entry j.
- c) If j is more specific than k, forward according to entry j.
Annex D Use of the Authentication Field 🔐
Okay this annex is literally about adding a little lock to your packets, and I'm here for it 🫶
The use of the Authentication field is outside of the scope of this specification. However, there is a urgent need for simple error detection/authentication mechanisms (such as a simple password) to protect against certain types of errors. This annex therefore proposes a possible use of this field.
This annex is included for informational purposes. 🍓
D.1 Authentication Field in IS-IS packets
All IS-IS packets may optionally include the authentication field, as described in sections 3.9 and 5 of this specification. As described in section 5, the authentication field is encoded as a (Code, Length, Value) triplet. This annex proposes that the contents of the Value field consist of a one octet "Authentication Type" field, plus a variable length "Authentication Information" field. A specific value of the "Authentication Type" is assigned to passwords, transmitted in the clear without encryption. The authentication field is encoded as follows:
7 Authentication Information -- Information used to authenticate
the PDU
x CODE - 133
x LENGTH - total length of the value field
x VALUE -
No. of Octets
+--------------------------------+
| Authentication Type | 1
+--------------------------------+
| Authentication Information | VARIABLE
+--------------------------------+The Authentication Type is assigned as follows:
Type = 0 reserved
Type = 1 simple password
Type > 1 reservedD.2 Authentication Type 1 - Simple Password 🔑
Okay bestie, so this one is Authentication Type 1, the simple password. 🌸 A variable-length password gets sent in the clear, meaning NOT encrypted, inside the Authentication Information field.
WARNING 🚨: A simple password does not give you useful protection against intentional misbehavior. Since it's sent in plain text with no encryption, a hostile system can easily snoop the passwords and send authenticated packets of its own. Simple passwords SHOULD only be treated as weak protection against accidental errors, like a misconfiguration by accident. 🙈
The password SHALL be configured on a per-link, per-area, and per-domain basis. So when this form of authentication is used:
- IS-IS Hello and 9542 IS Hello packets SHALL contain the per-link password
- Level 1 Link State Packets SHALL contain the per-area password
- Level 2 Link State Packets SHALL contain the per-domain password
- Level 1 Sequence Number Packets SHALL contain the per-area password
- Level 2 Sequence Number Packets SHALL contain the per-domain password
Each of these three passwords SHALL also be configured with two things: (i) a "Transmit Password", which is a single password value, and (ii) "Receive Passwords", which is a set of passwords. The transmit password is always the one that gets sent. ✨ But ANY password in the receive set will be accepted when a packet comes in. This is what lets you swap passwords gracefully without losing connectivity for a moment. 💖
Here's an example, because examples make everything click. 🧚 Say an area has the configured area password OLDAREAPASSWORD. Then the per-area transmit password is OLDAREAPASSWORD, and the per-area receive password set is {OLDAREAPASSWORD}. Now you want to switch to "NEWERPASSWORD". 🍓
- First, manually configure every router in the area so the per-area receive password set is
{OLDAREAPASSWORD, NEWERPASSWORD}. Once that's done, all routers still send the old passwordOLDAREAPASSWORDin their level 1 LSPs and SNPs, but they'll now also acceptNEWERPASSWORD. - Next, configure the routers so the per-area transmit password is
NEWERPASSWORD. Once that's done, everyone is sending the new password but still accepts the old one. 👑 - Last step: change every router so the per-area receive password set is
{NEWERPASSWORD}. Done and dusted! 💅
The genius part is that if you set transmit and receive values this way, the network keeps working the whole time. 🦋 Halfway through step two, some routers will be sending level 1 LSPs and SNPs with the old password, and others with the new one. That's fine, because during step two every router in the area accepts level 1 LSPs and SNPs using EITHER password. Iconic. 😭
Annex E Interaction of the Integrated IS-IS with Brouters 🌈
A "brouter" is a device that operates as both a bridge and a router. 🌷 One common flavor acts as a router for IP traffic and as a bridge for every other type of traffic.
Depending on how a brouter is implemented and on the network topology, there is an obscure bug that can pop up from the way the Integrated IS-IS protocol and brouters interact. 💀 This annex walks through an example of the bug and proposes a simple fix to how brouters operate so the problem goes away.
This annex is included for informational purposes. ✨
E.1 The Problem 🙈
Picture a brouter that treats IP packets like a normal IP router would, and treats all other packets like a bridge.
Now imagine two routers, "X" and "Y" (both implementing the Integrated IS-IS protocol), two Ethernets, and a brouter B, all wired up like this:
| |
+----+---+ +----+---+
| Router | | Router |
| X | | Y |
+----+---+ +----+---+
| |
-----+------------+- -+------------+----
| |
+-+-----+-+
| Brouter |
| B |
+---------+So X and Y are both running the Integrated IS-IS protocol and are both level 1 routers in the same area. That means X and Y send IS-IS Hello packets out on the LAN. The brouter receives and forwards those Hellos using its normal bridge functions. X and Y also receive each other's IS-IS LSP packets. From the brouter's point of view, X and Y are just exchanging OSI packets, so it forwards them with regular bridge functions. 🦋 From X and Y's point of view, they're on the same LAN, so they learn each other's 48-bit Ethernet addresses and swap routing information. Everybody's happy so far! 🌸
Here's where it gets messy. Suppose X gets an IP packet that it needs to forward via Y. X thinks Y is on the same Ethernet, so it sends the IP packet straight to Y, using normal Ethernet encapsulation and Y's 48-bit Ethernet address as the destination in the Ethernet header. 😱 Now the brouter, thinking like a bridge, says: "this is an IP packet, and I don't forward IP packets as a bridge." Meanwhile, the brouter thinking like an IP router says: "this is an IP packet, and I know how to forward those. BUT this is addressed to an Ethernet address that isn't mine, so I'll ignore it." 💀 Result: the IP packet never gets forwarded. Major.
The root of the drama: X and Y use OSI packets to figure out the connectivity of the path between them, but then they try to send IP packets over that same path. And there's a device sitting on that path that treats OSI and IP packets differently. 🔥
This can also happen in more complicated topologies, anytime a brouter treats OSI and IP packets in a fundamentally different way. Watch out! 👀
E.2 Possible Solutions 💜
E.2.1 More Sophisticated Brouter 🎀
The fix is for brouter B to get a little more sophisticated. Specifically, it needs to follow these rules:
- For packets that are not IP packets, act as a bridge (same as before).
- For IP packets sent to an Ethernet broadcast or multicast address, act as an IP router (also the same as before).
- For IP packets sent to my own Ethernet 48-bit address(es), act as an IP router (still the same as before).
- For IP packets sent to a single-station 48-bit address that is NOT one of my addresses, act as a bridge (THIS IS NEW). ✨
With this change, the IP packet X sends to Y gets forwarded by the brouter, which is acting as a bridge in that case. 🧚 That lets the brouter and the multiprotocol routers interoperate properly. Slay. 👑
E.2.2 Dual Router / Brouter 🦋
Another option is for the brouter to route both OSI and IP equally. 🌈 If the brouter used the Integrated IS-IS for this, then it could be part of the same routing domain and interoperate like any other dual router. (The one thing it can't do that a regular dual router can is bridge other protocol suites, though.) If it used other protocols to route OSI and IP instead, then it would need to be part of a different routing domain, and it could interoperate with Integrated IS-IS routers just like any other external router. 💖
📦 where this page comes from
- ietf: rfc1195 1990-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms