Section 3.2. Message Encapsulation

3.2. Message Encapsulation

OSPF operates directly over IP, with a protocol number of 89. The source address of all OSPF messages is always the local end of an adjacency, and all messages are either multicast to one of two reserved multicast addresses, 224.0.0.5 and 224.0.0.6, or unicast to the distant end of an adjacency. At no time does OSPF broadcast its messages. The rules for when to multicast and when to unicast, and what the two reserved multicast addresses signify, are discussed in context in later chapters. For now, it is enough to know how the messages are sent.

IS-IS operates not over the network layer like OSPF, but over the data link layer. But like OSPF, IS-IS messages are either unicast or multicastnever broadcast. The source address of IS-IS messages is always the data link layer address (the MAC address, for example) of the local end of the adjacency, and the destination address is either the data link layer address of the distant end of the adjacency or, on broadcast media such as Ethernet, one of two reserved multicast MAC addresses: 0180:c200:0014 or 0180:c200:0015. As with OSPF, the rules for when to unicast and when to multicast, and how the two reserved multicast addresses are used, is explained in context in the appropriate chapters.

Encapsulating messages at the IP layer or at the data link layer each presents both advantages and disadvantages. One point of contrast is security. Because it runs over IP, OSPF can beand has beenthe target of spoofing and denial-of-service (DoS) attacks. Several tools are openly available for both snooping and attacking OSPF, such as IRPAS and Nemesis. Because of this vulnerability, both authentication and careful filtering are strongly recommended on OSPF networks with exposure to untrusted sources. IS-IS is not vulnerable to IP-based external attacks because it is not an IP protocol and runs over the data link layer. Attacking IS-IS requires direct access to a network link or router. Securing OSPF and IS-IS is detailed in Chapter 9.

Another issue arising from the choice of encapsulation layer is message prioritization. In times of congestion, when packets cannot be sent immediately on a link, routers put the packets in a queue. The problem is that if the congestion is severe, the queue can fill up, and subsequent arriving packets are dropped. Some applications are more sensitive to packet loss than others, so many routers support the creation of multiple queues on an interface, and the assignment of each packet to one of the multiple queues based on one or more parameters. The queues are then serviced in such a way that the packets in some queues are given a better chance of being transmitted than packets in other queues. This procedure of classifying packets, sorting them into queues according to their classification, and then servicing the queues with differing levels of preference is called class of service (CoS).

Obviously, in times of congestion routing protocol packets should receive the best preferential treatment because if routing messages do not get through the routing protocol can fail, and then no other packets will be routed. OSPF marks the precedence field in the IP header of all its messages as "network control" (binary 110), so that if a router is set up for CoS queuing these packets are placed into the highest-priority queue. Some router manufacturers implement a high-priority queue by default and place packets marked for network control into this queue.

Because IS-IS is not an IP protocol, prioritizing its messages is more problematic. Some router manufacturers, such as Juniper Networks and Cisco Systems, use proprietary internal mechanisms to tag IS-IS messages in such a way that they can be added to the same network control queue as OSPF. In any IS-IS network, using routers that either prioritize IS-IS messages automatically and internally or allow configured prioritization of IS-IS traffic by some manual means is essential to the stability of network routing.

Finally, IS-IS can potentially present a problem in some ATM environments. Specifically, AAL5MUX encapsulation (also called null encapsulation or VC multiplexing) limits each virtual circuit (VC) to a single Layer 3 protocol. Because IS-IS messages are not IP packets, they cannot be sent over the same VC as the IP traffic being routed. To send IS-IS and IP traffic over the same VC, AAL5SNAP encapsulation (also called LLC/SNAP encapsulation) or AAL5NLPID encapsulation must be used.

The problem is this: SNAP and NLPID encapsulation add a header to the packet being encapsulated in the AAL5 frame, which identifies the enclosed protocol type, so that the receiving system can read the SNAP or NLPID header and send the encapsulated packet to the correct protocol stack. Approximately 40 percent of normal IP traffic consists of small 40-byte TCP acknowledgements. The AAL5 header adds 8 bytes to make each TCP ACK 48 bytes, exactly the payload size of one ATM cell. But an LLC/SNAP header adds another 8 bytes, and an NLPID header adds 2 bytes, bringing the size of each TCP ACK encapsulated in either AAL5SNAP or AAL5NLPID to either 56 or 50 bytes. That means two ATM cells are required to carry each TCP ACK, and most of the second cell is empty. The result is that when using AAL5SNAP or AAL5NLPID encapsulation, the number of cells required to carry some 40 percent of normal IP traffic doubles, adding greatly to the overall cell tax.

AAL5MUX drops the packet and AAL5 header directly into a cell with no other headers. For TCP ACKs, this means that with the AAL5 header each ACK is 48 bytes long and fits exactly into the payload of a single cell, improving overall efficiency. But this also means that the receiving system has no header information to identify the encapsulated protocol. Instead, a single protocol is identified implicitly by the VC itself. As a result, IS-IS and IP cannot be carried in the same VC, because the receiving system does not have enough information to demultiplex the two protocols to their individual stacks.

Henk Smit of Cisco Systems proposed a solution to this problem.^[1] Although AAL5MUX does not provide a header for the end system to identify the encapsulated message, what if the end system just looked at the first part of the message itself? The first octet in every IP header is the 4-bit version number and the 4-bit header length. Depending on the length of the options field in the IPv4 header, this first byte is always between 0x45 and 0x4f inclusive. The first byte of every IS-IS message is the Intradomain Routing Protocol Discriminator, which is always 0x83. So, the receiving system can look at the first byte of the message and distinguish between IP and IS-IS, without depending on the ATM layer to demultiplex. As it turns out, no one has implemented this solution primarily because there has been no demand for it. IS-IS for IP is seldom found outside of large Internet service provider networks, and most of these networks, over the past few years, have been migrating their cores away from ATM. You can draw the conclusion that if there has been no demand, the IS-IS over AAL5MUX problem has apparently not been a problem for many users.

^[1] Henk Smit, "IS-IS and IP over the Same ATM VC with AAL5MUX Encapsulation," draft-hsmit-isis-ip-aalmux-00.txt. Draft expired December 1999.