IS-IS vs. OSPF Part I: First steps in understanding IS-IS

The theme question is actually quite a good one, because it may seem like the fight has already been won by IS-IS in the Service Provider segment, and by OSPF on the enterprise market. So why ask it then? Well, because I got the following answer one too many times: “IS-IS is awesome, OSPF not so much. I have no idea how IS-IS works but it’s great. OSPF is so complicated and offers so little flexibility…”.

Well, that’s really wrong from my point of view. No protocol can be neither awesome nor despicable. They both offer you advantages and disadvantages, and knowing how they both work will help you make the best decision based on the needs of the network, not just because people say one is “great” and the other is not.

So, I am going to follow the steps I took to come to terms with IS-IS, and then we’ll see together, even though you’ll probably figure it out for yourselves by then, the comparative analysis of the two IGPs.


Step 1: Understanding CLNS & CLNP

Often network engineers freak out when they hear about the OSI stack, CLNP (Connectionless Network Protocol) and CLNS (Connectionless Network Service). In fact, the two terms are usually misused when talking about IS-IS so let’s first clear this out.

CLNS is the description of the service performed at the network layer in the OSI stack that doesn’t need a connection to be established in advance in order for data to be transmitted. This is actually the correspondent of the service that the Internet Protocol offers in the TCP/IP stack. So CLNS is a service.

The protocol that offers this service (or the implementation of the service) in the OSI stack is called CLNP (Connectionless Network Protocol). This actually performs a similar job to IP in the TCP/IP stack, addressing the datagrams and ensuring their best effort delivery.

As the OSI stack implemented the usage of the term “system” when referring to network devices, you may recall that there are two types of devices/systems – ESs (End Systems) and ISs (Intermediate Systems). Consequently, there are two segments where routing needs to be ensured. ES-IS and IS-IS, therefore there are two routing protocols: ES-IS and IS-IS.

For the ES-IS segment, ISs send ISHs (IS Hellos) to ESs, so that ESs can discover them, and ESs send ESHs (ES Hellos) to the ISs, to discover other nodes in the local subnet or discover routes that can take traffic to other subnets (there is no ARP or ICMP correspondent in the OSI stack). There is no default gateway in what the ESs are concerned, they are simply redirected by the ISs, in order for the optimal path to be chosen.

On the IS-IS segment, the protocol is simply called IS-IS and it helps intermediate systems exchange routing information. So, both ES-IS and IS-IS route CLNP but at different levels.

Particular thing about IS-IS, different from what happens with protocols that route IP, is that the PDUs (Protocol Data Units) are not encapsulated in CLNP, they are only encapsulated in the data link protocol header (e.g. Ethernet having DSAP = 0xFE/0xFEFE).


Short parenthesis – What is DSAP (Destination Service Access Point)/SSAP (Source Service Access Point) and why do I use it?

There are several Ethernet standards, right? Well, today in use are two: 802.3/802.2 Ethernet and Ethernet II. Ethernet 802.3/802.2 is the version that splits the data link layer, naming the upper half LLC-802.2 (Logical Link Control). The lower part together with the physical layer are called MAC-802.3 (Media Access Control). Ethernet II has the simple version of the header, and is accepted as well as 802.3 Ethernet, in all networks. So IS-IS is encapsulated in the 802.2/802.3 Ethernet frame, which contains both a LLC Header (DSAP, SSAP, Control) and MAC Header (Source MAC, Destination MAC, Length). So for IS-IS, the DSAP and SSAP fields are 0xFE (be carefull when configuring bridge groups and using LSAP lists. You must allow IS-IS LSAP otherwise it will fail!)

Further reading


Step 2: OSI context

In oder to really understand why IS-IS seems so weird and why it uses those impossible to understand acronyms (and not just memorize some numbers), we first need to take a look at the OSI way of addressing systems in the network. As in TCP/IP, there are several layers of addressing. Focusing on the network-layer addressing, we should know that it is implemented by using two types of hierarchical addresses: NSAP (Network Service Access Point) addresses and NETs (Network-Entity Titles), which are a particular case of NSAPs.

Defining NSAP
The NSAP is the location at which OSI network services are provided to the transport layer. Each transport-layer entity is assigned a single NSAP, which is individually addressed in an OSI internetwork using NSAP addresses.

An ES often has multiple NSAP addresses, one for each transport entity that it contains. In this case, the NSAP address for each transport entity usually differs only in the last byte (called the n-selector). Making an analogy to the TCP/IP Stack, NSAP addresses can be seen as IP addresses, and the N-SEL can be seen as the Protocol number in the IP Header, because it helps identify the Transport Protocol used (for example N-SEL = 0x21 for Transport Protocol 04).

A network-entity title (NET) is used to identify the network layer of a system without associating that system with a specific transport-layer entity (as an NSAP address does). This is obtained by setting the N-SEL to 0x00, meaning that there are no transport layer capabilities for the system (routers do not interfere with the transport layer). Also, an IS can have a single NET or multiple NETs, if it participates in multiple areas or domains.

Difference between IP Addresses and NSAPs
The big difference between NSAP style addressing and IP style addressing is that usually there will be a single NSAP address for the entire router, whereas with IP there will be one per interface.

Structure of the NSAP address

photo 1

The really nasty thing with NSAPs is that they can be variable in length. More accurately, they may have between 8 and 20 bytes.

Initial Domain Part (IDP)
The IDP field is divided into two parts: the Authority Format Identifier (AFI – 1Byte) and the Initial Domain Identifier (IDI – variable length).
– The AFI provides information about the structure and content of the IDI and DSP fields, such as whether the IDI is of variable length and whether the DSP uses decimal or binary notation. The values for the AFI may be between 0 and 99, each identifying the IDI and DSP format.
– The IDI specifies the entity that can assign values to the DSP portion of the NSAP address.

Domain-Specific Part (DSP)
– The HO-DSP (High-Order DSP) or Area field identifies the specific area within a domain.
– The Sys-ID (6B) field identifies a specific station within an area. It is usually chosen as the base MAC Address of the system.
– The Selector field (1B), which was discussed above, identifies a Transport Layer protocol.

Example of commonly used NSAPs
– AFI = 49. (private address space)
– IDI = 1 or 2 bytes (49.01xx. or 49.0001.)
– HO-DSP = 1 or 2 bytes (49.0101. or 49.0001.0001.)
– System ID = 6 byte MAC (49.0101.aaaa.bbbb.cccc. or 49.0001.0001.aaaa.bbbb.cccc.)
– N-SEL = 1B (49.0101.aaaa.bbbb.cccc.00 or 49.0001.0001.aaaa.bbbb.cccc.00)

Multiple NSAPs on a router
A router can be configured with multiple NETs if you want to migrate from Area A to Area B, merge area A and area B or partition area C in areas A and B. This is because a system can only be part of one area at a time so if IS X has NETs 49.0101.aaaa.bbbb.cccc.00 and 49.0102.aaaa.bbbb.cccc.00, then the two different areas will actually become a single one.


Step 3: Understanding the IS-IS Hierarchy

After figuring out the addressing, IS-IS doesn’t seem to be that complicated anymore, right? Well, let’s go one step further today and understand the hierarchy that governs IS-IS. OSPF also uses a hierarchical design, with Area 0 as a backbone area (spine) and the other areas as leaves attached to the spine, forming a leaf-spine-leaf network design. What me must keep in mind is that Area/Domain boundaries in OSPF are defined by the routers themselves (ABRs and ASBRs)

IS-IS defines two types of systems: Level 1 ISs and Level 2 ISs.
– Level 1 ISs are capable of routing only inside the area they are part of, based on the System ID. If they don’t have the route in their own area, they send the packet to the closest Level 2 IS.
– Level 2 ISs are capable of routing between areas.

The backbone of the IS-IS domain is formed from a continuous collection of Level 2 capable routers that may be part of different areas. As systems are identified using NSAPs, a system can be only in one area at a time, so the area boundaries are on the links, not on the ISs themselves. For example, below the backbone is formed from ISs B and C, B being in area 1 and C in area 2:

A(L1-area1) —L1 link— B(L2-area1) —L2 Link— C(L2-area2) —L1 link— D(L1-area2)

There is the necessity of the L2 backbone to be contiguous because each L2 router will tell the L1 routers it connects to that it is “attached” to the backbone, so that they would know that it has inter-area connectivity. If an L2 IS loses connectivity to the backbone, it will stop advertising himself as “attached” and L1 ISs would no longer consider it for inter-area reachability.

Note: We will be discussing the link types more in depth in a subsequent section.


Step 4: Briefly about Integrated/Dual IS-IS

Throughout this article, the main focus was on the OSI stack and protocols. You may ask yourself why, everyone uses TCP/IP right? That’s not entirely true. Currently, in most optical network deployments, the OSI stack steals the show, together with IS-IS which ensures routing is properly made. And if you’re still not convinced, well, IS-IS can be used as an IGP to support IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments.

The main reason for that is that it is independent on the Network Layer protocols. It is directly encapsulated in the data link header so it doesn’t really care for which protocol it facilitates the propagation of routing information. We’ll see how that is possible at a later time, but for now, the brief explanation is that routing info is carried as TLVs (Type Length Value) of the form Subnet>Mask>Metric.

Being independent on the Network Layer protocol, we’ll see that besides routing OSI and IPv4, is can very well route IPv6. This solves a problem that could be quite annoying in large scale domains, which is the competition for resources. Instead of running OSPFv2 for IPv4 and OSPFv3 for IPv6 (which are totally incompatible and act as two distinct routing protocols), if you have already deployed IS-IS for IPv4, the IPv6 integration is seamless.


Part II Preview: IS-IS operation, link and packet types, data structures, external links, wide metric style and more…

Facebook Comments

Leave a Reply