Chapter 9: IPv6 Performance

Introduction

Network performance is directly related to routing. The amount of traffic that leaves the local network (external traffic) compared to the amount of traffic that occurs on the network is constantly increasing. This is due in part to the demand for more services, especially graphics based services. Speeds for LANs, MANs and WANs have also increased to hundreds of megabits per second, with gigabit networks not far in the future. Routers need to perform their functions of processing and forwarding IP datagrams much quicker than before.

This chapter reviews:

• The trends affecting IPv6 performance.
• IPv6 performance versus IPv4’s
• RSVP Protocol
• Mentat’s MING solution
• The pulse of vendors and consumers

IETF’s Efforts for IPv6 Performance

The IETF is working with other organizations to develop algorithms that map addresses between IPv6 and other environments. For example, mapping algorithms already exist or are under development for various types of addresses including mapping algorithms for Novell IPX addresses, some types of OSI Network Service Access Points (NSAPs), E164 addresses and SNA addresses. Such mappings will provide an unambiguous one-to-one map between routers and subnets.

When we look at IPv6’s header’s characteristics, we notice that there are fewer fields in an IPv6 packet header than in IPv4. To increase the speed, at which a packet travels past a router, separate optional headers are placed between the IPv6 header and the transport layer header. Most of these are not examined or processed by routers along the packet’s path. This not only simplifies, but also speeds up router processing. Additional optional headers are also easier to add, making IPv6 more flexible than IPv4. Because the IPv6 packet header has a fixed length, processing is also simplified.

IPv6 does not fragment packets as they are routed, as IPv4 does. Instead, packet fragmentation and reassembly will be done exclusively in the communicating hosts, thus reducing the workload for intermediate routers. When the transition to IPv6 is complete, the Internet will consist of only networks with Maximum Transmission Units (MTUs) equal to or larger than 576 bytes.

Performance with IPv6 will be optimized by the use of flow labels. The flow source specifies in the label any special service requirements from routers along a path, such as priority, delay, or bandwidth. All packets in the sequence carry the same details of this information in the flow label to reserve the type of service they need from intermediate routers. Such a need would be for transmitting video or limiting traffic to a specific computer or application sends to avoid congestion.

Increased Efficiency

With IPv6, a flow can be one or multiple TCP connections, and a single application could generate a single flow or multiple flows. An example of a single flow would be a text page, and an example of a multiple flow would be an audio/visual conference. Packets that share a flow label also share path, resource allocation, discard requirements, accounting, and security attributes. The flow label is defined before transmission.

But IPv6 also offers increased efficiency through simplified headers and optimization of packets.

Simplified Headers

IPv6 simplifies the packet header from 12 data elements in IPv4 to only 8 elements. This reduces the computation required to process headers, thereby speeding up routing.

Fragmentation and other optional control functions are moved into hop-by-hop and end-destination extension headers that follow the standard header. The options in the end-destination extension header are not processed until the final destination, further reducing the computation required to process IPv6 packets as they pass through each router.

Packet Size Optimization

Before sending messages in IPv6, using the Path MTU Discovery algorithm, the source determines the maximum packet size supported by all routers along the path to the destination. The source computer then divides the message into packets that require no fragmentation by routers, reducing the computational load on the routers.

Flow I.D.s

An identification number assigned to each conversation allows all routers along the path to store relevant information concerning the conversation, thereby minimizing the computation necessary to deliver each individual packet. The section "Increased Performance with Flow Labels" provides more detailed information about the usage of flow.

Reducing Loads on Hosts through Multicasting

The multicast function in IPv6 allows hosts and routers to send neighbor discovery messages only to those machines that have registered to receive them, removing the necessity for all other machines to examine and discard irrelevant packets.

Allowing Route Aggregation through Multiple Addresses

IPv6 allows multiple addresses per device interface, making route aggregation simple and efficient. For example, if a host is using multiple access providers, it can have separate addresses aggregated under each provider's address space. In IPv4, addresses have little or no connection to routing paths and therefore routers must maintain enormous tables of routing paths. Address aggregation in IPv6 allows routers to maintain small tables of prefixes that deliver the packets to the correct access provider.

Increasing Performance with Flow Labels

As mentioned earlier in this chapter, the performance of IPv6 can be increased by the use of flow labels. On chapter 7, "IPv6 Headers," we discussed that the concept of Flow Labels is new on IPv6, as it is a new IP header field. The Flow Label field is used for handling real time data traffic, which helps to optimize the performance in IPv6.

ISPs could use Flow label to provide better performance of services to customers by lowering delays or increasing bandwidth. For example, the network provider's routers might be able to recognize a large amount of traffic and use the Flow Label field to establish a special route that gives the TCP connection better service.

However, using Flow Labels in individual TCP connections changes the handling of route caches in routers. Putting Flow Labels in each datagram changes the cache into a Flow Label cache. This means every TCP connection has a cache entry thus creating the potential for cache explosion.

Flow labels can also improve IPv6 performance by identifying to the network a stream of packets that needs special handling above and beyond its default best-effort forwarding. By using flow-based routing, internetworks could receive some of the deterministic characteristics associated with connection-oriented switching technology and telephony virtual circuits. Desktop video or audio streams could be given a flow label that would tell routers about the need of controlled amount of end-to-end latency.

Flow labels can also be used to give traffic flows a specific level of security, propagation delay, such as with VSATs transmissions, or cost. Experimental work with non-standard IPv4 QoS implementations has already shown that it is quite feasible to convey video and audio streams across the mesh internetwork topologies without excessive degradation. IPv6 paves the way for production application of this sort.

Is IPv6 Performance Satisfactory?

Is IPv6 performance satisfactory to attract consumers? If so, why is IETF and the whole IPv6 workgroups so quiet lately (fall/winter of 1997)? As you can see, there is a lot of engineering into IPv6, but not much is discussed about its performance, at least not as much is it deserves, after all, fast networks has become a major necessity. One factor that contributes to it is the fact that most of IPv6 existence is still in a box, in a Greenfield, in the lab.

Take for example the report of Forrester Research , Cambridge, Mass., of a year ago, showing that 82 percent of Fortune 1000 firms had no plans to upgrade to IPv6 at all. Further, according to Brendan Hannigan, Forrester's senior analyst for network strategies, in a recent Internet study, respondents barely mentioned IPv6. Apparently, companies are happy with IPv4, even though it might be running out of addresses even sooner than later.

But we all know that we don’t have to move onto IPv6 to resolve the lack of address problem, as Classless Interdomain Routing (CIDR) addressing method is doing a great job aggregating IP addresses. Moreover, haven’t you noticed how alike IPv4 has become of IPv6? You can now add-on few features not available before, such as quality of service (QoS) and security.

IPv6 Performance Challenges

We hope we’re not opening a can of worms here, but we can clearly foresee IPv6 performance as a problem. The reason is very simple, and we believe network administrators already are figuring it out:

• Dual protocol stacks configuration will be typical, at least during the first wave of transition from IPv4 onto IPv6. The simple, single-stack days will be over, at least for awhile, as client machines, servers and routers likely will run (have to run) both IPv4 and IPv6 protocols. This approach alone will compromise IPv6 performance.
• Tunneling is IETF’s proposition for transition from IPv4 onto IPv6. By having machines running both stacks, as discussed above, it will be able to talk to both subnets. The problem here is that, not only the dual protocol stack already compromises performance, but when you use a client, running IPv6 to send a file to a server running IPv6 by "tunneling" the packets in IPv4 you will have a noticeable loss of performance.

On the 6bone testbed network, for instance, traffic is noticeably slower, this without taking in consideration the many tunneling problems created by nodes that are down on the backbone.

Vendors like Cisco seem to understand the impasse and are currently offering some IPv6-like features in its IPv4-based Internetwork Operating System. For starters, Cisco uses the Resource Reservation Protocol (RSVP) to deliver QoS. RSVP is a protocol developed to enhance IPv4 that lets network managers allocate bandwidth based on an application's requirements be they voice, data or video.

Resource Reservation Protocol to the Rescue

The Resource Reservation Protocol (RSVP) is the reservation protocol of choice on the Internet. Multicast applications, such as high-speed video transmission, will definitely depend on a protocol like RSVP in order to guarantee high levels of what is called "Quality of Service" (QoS). Many of these new applications require a different approach to routing and resource allocation than do generic data applications. RSVP is different from many IP protocols, as it is a receiver-driven protocol. Thus, it is up to the receiver to select which source they want to receive as well as the amount of bandwidth they are prepared to reserve or pay for, if they are in a commercial network.

TIP: What is Quality of Service after all? Quality of Service requirements and solutions are a set of basic requirements that a network must meet in order to deliver application traffic in a usable form. These requirements are centered on bandwidth and delay characteristics.

Quality of Service requirements has increased considerable with the advent of multimedia applications. The reason for it is that multimedia applications require reliable and fast transmissions, otherwise, what the recipient will get can be a bunch of "chopped" and delayed set of packets. Unfortunately, the way lower level protocols, such as Ethernet, ATM and Token Ring, handle packets to IP to be forwarded to its destination are prone for delays or "bursts" in the packet delivered. This can happen because in every routed IP networks, each packet of information is examined by every router in the data path. Usually you will find several intermediate routers between the source and the destination, joining the different networks. As the packet "hops" from one router to another, the IP protocol in each router decides which is the past path for that packet to go next, which can easily delay the arrival of a packet at its destination, and many times the packet will never make it.

For most data applications, this "bursty" delivery is acceptable and lends itself to high performance and high availability, but for multimedia applications, involving both voice and/or video, the traffic must have to be "streamed" or transmitted continuously, and not in bursts. The challenge for the networking community is to accommodate these different requirements while continuing to maintain high network performance and availability.

It was to meet this challenge that IETF developed the Resource ReserVation Protocol (RSVP). RSVP is an end-to-end protocol compatible with current TCP/IP based networks, capable to provide the means to support a special Quality of Service for multimedia applications and others that needs it, while maintaining current internetworking methods, preserving, therefore, the existing network infrastructures.

Functional Description

The RSVP protocol operates on top of IP, in the transport layer. It is a control protocol comparable to ICMP (Internet Control Message Protocol) or IGMP (Internet Gateway Message Protocol), designed to operate with the current and future unicast and multicast routing protocols. Some applications are suited for one Receiver while it is desirable with other applications to have the potential to send to more than one Receiver without having to broadcast to the entire network.

The components of RSVP are:

• Sender – responsible for letting the Receiver know there is data to be sent and what Quality of Service is needed.
• Receiver – responsible for sending out a notice to Hosts or Routers so they can prepare for the upcoming data
• Hosts or Routers – responsible for setting aside all the proper resources.

Once all the above steps are completed, the Sender can successfully send the data.

With RSVP, the application is able to provide advanced notification as to the network resources it will need. By granting the reservation, the affected hosts and routers commit to providing these resources. If the router is not capable of providing them, or the resources are not available, the host or router can refuse the reservation. The application is notified right away that the network cannot support it, thereby avoiding the time and cost of a trial and error approach.

The two main concepts of the RSVP protocol are:

• Flows, characterized by the traffic streams from a Sender to one or more Receivers, are identified in the IPv6 header by a "flow label." Prior to sending out a flow, the Sender transmits a "path message" destined for the Receiver. The message contains the source IP address, destination IP address and a flowspec. The flowspec, made up of the rate and delay bounds for the flow, is the Quality of Service that the flow requires. The path message is routed to the Receiver by the hosts and routers along the flow's path.
• Reservations - The Receiver is provided with the path message and is then responsible for making the actual reservation. With the Receiver making the reservation, there is greater flexibility in handling multicast flows. This Receiver-based model allows for a distributed solution enabling heterogeneous Receivers to make reservations tailored to their needs.

Receiver-based protocol is more effective for heterogeneous networking environments. Also, in order to assure reservations are still in place and that any "moves or changes" on the network are aware of the reservation, RSVP incorporates an approach called "soft state." This term is used because RSVP paths and reservations are considered tentative. Resources are put aside when a router accepts a reservation, but if a flow is not received, it will time out and free up its resources. With the soft state approach, the Sender periodically sends its path message and the Receiver continues to send its reservation request in order to refresh any time-outs or changes that may have occurred.

In summary, below is a list of RSVP features:

• RSVP makes resource reservations for unicast and multicast Receivers using a soft state approach for keeping the reservations up-to-date.
• RSVP is uni-directional.
• Receivers in RSVP initiate and maintain the resource reservation for a flow.
• RSVP is not a routing protocol, but relies upon routing protocols for delivering flows.
• RSVP supports IPV4 and IPV6.

The RSVP area is developing very quickly, counting with efforts making on the standards. Cisco is at the moment the major player promoting RSVP, working very closely with the IETF to resolve its known limitations. You can count on RSVP becoming a requirement for multimedia applications and router manufacturers in 1998.

Vendors Are Gearing Up

FTP Software was the first vendor to ship a commercial IPv6 product in US. Secure Client 3.0 has been available for several months. FTP is not alone, as Digital Equipment, IBM and Sun Microsystems, and many others are beginning to offer their IPv6 commercial offerings.

According to an article at TechWeb News, dated of June of 1997 (http://www.techweb.com/wire/news/june/0609ip.html) "IBM will make its prototype IPv6 software for AIX a full-fledged product by the fourth quarter, while Digital will beef up its early adopter kit for the Alpha AS/500 server and its RoamAbout routers next year. Sun, meanwhile, will put IPv6 in Solaris version 5 next year. And Cisco and 3Com will add version 6 to their router software later this year."

FTP already shipped a set of applications for IPv6 for Windows 95 and NT 4.0 platforms-the Network Access Suite, which comes with apps like Network Files System, file transfer and terminal emulation.

Another vendor, Mentat, a member of the IETF IP Next Generation Working Group writing the new standard, is calling the attention of IPv6 implementation groups, as they set the pace for IPv6 implementations. Mentat’s implementation of IPv6, known as Mentat IP Next Generation (MING), will deliver the same high levels of performance and reliability that have built their reputation as one of the leading suppliers of TCP/IP. Although the IPv6 specifications are currently "proposed standards," Mentat confirmed that the domestic version of MING will fully comply with all official standards. MING is currently being integrated for release by UNIX operating system and router vendors.

Mentat IP Next Generation (MING)

Mentat’s personnel provided the following information with regards to Mentat’s IP Next Generation (MING), which incorporates Mentat's leading-edge experience in network software. For additional information, please check the Notes above.

MING is built upon Mentat’s TCP for STREAMS and includes components to allow applications to use IPv6, IPv4, or IPv6 over IPv4 tunneling, thereby insuring a smooth and high performance transition to IPv6. MING will operate in any System V Release 4 (SVR4) compatible STREAMS environment. Coupled with our popular Mentat Portable Streams, OEM's can achieve the full benefits of IPv6 on systems without native STREAMS.

Besides operating in any STREAMS environment, MING can be coupled with Mentat Portable Streams to achieve the full benefits of IPv6 on systems without native STREAMS. MING is a complete, fully compliant implementation of IPv6. It includes components to allow applications to use IPv6, IPv4, or IPv6 over IPv4 tunneling, insuring a smooth transition to IPv6.

MING’s Overview

MING is licensed as a portable source code product and will operate in any System V Release 4 (SVR4) compatible STREAMS environment. Coupled with the popular Mentat Portable Streams, OEM's can achieve the full benefits of IPv6 on systems without native STREAMS.

Design and Performance

The code is optimized for maximum throughput in the main data path. Packet retransmission, unresolved routes, and similar conditions are handled as out-of-line special cases. The basic design is structured to facilitate multiprocessing. Multiple threads can execute in different modules, even in the same stream, with minimal synchronization checks. Furthermore, packet "fan out" at the IP layer permits multiple processors to drive data packets simultaneously on multiple streams.

Some of MING’s Main Features

MING source code is written entirely in ANSI C. Port-specific issues, such as byte ordering, memory alignment, and synchronization primitives, are isolated into macros and system dependent header files. The software provides:

• Full conformance with all relevant IPv6 RFCs as they become standards.
• SVR4 TCP replacement capability - existing IPv4 applications will run without recompilation.
• Full MIB-II support.
• Full Multicast support.
• Full support for all IPv4 to IPv6 transition mechanisms.
• Full support for ioctl's and socket options including BSD v6 API extensions.
• Socket library with UNIX domain support.
• Conformance with TPI, DLPI, and STREAMS.

Programming Interfaces

MING supports the STREAMS-standard Transport Provider Interface (TPI) as its application-side interface. This design provides access to the protocol from any user library or upper level module written to conform to TPI.

MING includes a Sockets library and module for use with TCP, UDP, or other TPI compliant providers. This library emulates the socket semantics of Sun's SunOS 4.1. The product uses the Data Link Provider Interface (DLPI), v2.0, to communicate with STREAMS-based network device drivers. By using this interface definition, MING interfaces with a variety of device drivers without modification. DLPI also allows MING to coexist with other protocols using the same network interfaces.

Architecture

Designed as a set of STREAMS modules, MING is connected together as shown on figure 9.1. At initialization, each DLPI device is connected directly to an IPv6 module for IPv6 access or to a pair of streams linking IP, ARP, and the device driver for IPv4 access.

MING Streams Configuration Diagram

When application opens an interface to a transport provider, the result is a new instance of IP, with the transport module, TCP or UDP, pushed above it. Normally, a suitable interface module for XTI/TLI or Sockets is pushed as well.

Components

The following are the main components of MING:

• Core Modules - TCP, UDP, IP and IPv6, including gateway routing, ICMP, and Multicast support.
• Raw IP, Raw IPv6 Modules - Provides applications with direct access to IP for use with ICMP[v6] and private protocols.
• Sockets Support - Module and Sockets library which provides BSD sockets emulation, including UNIX domain interprocess communication.
• Utility programs - Programs to configure and verify TCP/IP operation.

Mentat Portable Stream

Mentat Portable Streams (MPS) is an innovative development and run-time environment for network protocols, device and terminal drivers, and other kernel-level I/O facilities. MPS provides full multiprocessor support and is easily ported.

MPS, allows any operating system to incorporate STREAMS-based protocols, such as Mentat's own high performance TCP/IP and XTP, as well as X.25, AppleTalk, OSI, and other protocols from other vendors, helping increase performance on IPv6.

MPS Components diagram

From Here

Chapter 10, "Transmitting IPv6 Packets over the Ethernet," provides an overview of the various technologies and medium that can be used to transmit IPv6 packets. It looks as high-speed solutions, their trends and challenges as well.