Brief Look at CLNS & CLNP

CLNS & CLNP - The ‘Future Network’, other tidbits

Exploring some old standards and the pieces they left behind

This post will likely grow over time. I’ll make this site’s repository public once it’s cleaned up a bit so diffs are accessible, and I will update this introductory paragraph to reflect any changes. I don’t intend to keep looking into CLNS at the moment, but I expect to pick it back up at some point.

I also apologize about the use of image tables in this post. That’s a stopgap measure that I’ll fix at a later date.

TODO: more complex table shortcode

Overview

What are they?

Sort of the ISO equivalent/failed alternative to the Internet Protocol (IP). See RFC 1561 for one (of several) examples of it being proposed as an alternative to the Internet Protocol, and RFC 926/941 for definitions of the protocol and address format respectively.

Definitions

Connection-less Network Service (CLNS) is the service supplied to higher-level applications by CLNP.

Connection-less Network Protocol (CLNP) is a Layer 3 protocol specified in ISO/IEC 8473-1.

CLNP and CLNS were essentially designed to be the OSI model’s network layer protocol (”This Protocol provides the connectionless-mode Network Service as defined in ISO 8341/DAD1”, from RFC 926.) They provide logical addressing and are the reason IS-IS (link state routing protocol similar to OSPF) and IDRP (path-vector routing protocol similar to BGP) exist.

Where will you see them used?

CLNS addresses are most prominently used for router identification addresses in the IS-IS routing protocol.

Interestingly, CLNP is apparently widely used with SONET/SDH [ANSI T1.105] - synchronous optical networking/synchronous digital hierarchy, both nearly equivalent protocols developed as replacements for older protocols for transporting telecom data (plesiochronous digital hierarchy). SDH/SONET are essentially the same, primarily designed to support real-time, uncompressed voice data encoded with PCM (pulse-code modulation), which results in systems that are not completely synchronized - thus the need for SONET/SDH. (Source for most of the above is Wikipedia) (Useful technical overview)

CLNS/CLNP were likely used for SONET’s management networks because, during the 1980s, the TCP/IP protocol stack was not widely used, and the OSI stack (including CLNS) was the emerging standard (according to this whitepaper from Marben, a telecom equipment supplier, about phasing out CLNS/CLNP for IP in SONET).

CLNS addressing

The addressing system used with CLNS is the “Network Service Access Point” (NSAP) format specified by ISO/IEC 8348 as part of the “Future Network” architecture.

Unfortunately, it costs 194 CHF (about $220) as with most ISO documentation, so I haven’t read it. The following section is pieced together from many different sources (mostly RFC 941), so please bear with me.

According to Cisco, NSAP addresses can be considered a ‘combination of IP address and upper-layer protocol in an IP header.’

The structure of a traditional NSAP address is as follows:

Table showing generic NSAP address layout (RFC 941)

A Network Entity Title (NET, router address) has a NSEL of 0.

Field descriptions:

Area Addresses: IDI and HO-DSP

IDI Format and Allocation

Per RFC 941, standard AFI values indicating IDI format and DSP syntax:

NSAP formats described in RFC 941

There are four total possible formats for the IDI:

  1. Binary
  2. Decimal
  3. Character (standard, no national variants)
  4. National Character (from a set determined by the issuing authority)

An AFI value in the “decimal” column implies that the DSP is using that (decimal) format type. Data format specification is why there are multiple AFI IDs per DSP syntax.

RFC 941 does not specify any formats that use the ‘character’ or ‘national character’ DSP syntax. All formats listed in RFC 941 have varying maximum lengths, but the overall maximum for a NSAP address of one of the types defined in RFC 941 is 20 bytes or 40 decimal digits in length.

Other CLNP Implementations

DOD IP Address in CLNP format (RFC 986):

DOD nested IPv4 in CLNS NSAP address definition

Likely serves the same purpose as backwards compatible IPv6 addresses.

Aeronautical Telecommunication Network

The ATN is an example of a network architecture that closely follows the OSI reference model, unlike the Internet. I was able to scrounge up a document detailing the Asia/Pacific ATN network’s addressing plan. This is their standardized NSAP address format (note it matches the 20 octet maximum defined in RFC 941):

ATN NSAP fields

Another table with full field titles (too long to fit in the one above):

ATN NSAP field titles

I highly recommend anyone interested in a more thorough description of the ATN’s NSAP addresses reads the document linked above - it goes into detail about each field.

A Brief Conclusion

You, like me, may be wondering just why you’ve never heard of this before (well, I sure hadn’t.) Why didn’t CLNS take off?

CLNS addresses are of variable length. According to this excellent post from 2008, this makes them difficult to handle in hardware and thus required additional hardware expense (likely significant, back in the early 1990s) to achieve wire-speed L3 forwarding. A lack of available hardware could have certainly influenced the path of the early Internet (towards the well supported IPv4.) This explanation sounds reasonable enough to me - it seems service providers and industry leaders would not be especially interested in replacing IPv4 with anything that causes additional cost.

Hopefully this was at least somewhat interesting. I’ll be going back to reading textbooks now.

References

Relevant RFCs

Web Resources

All data retrieved Jan 2024 unless otherwise specified. Archive.org links should, at worst, mostly represent what I looked at (they’re scrapes from a few months before retrieval)