Performance in a Router Network

A customer perceives the network performance by the response time seen for the application. The IBM 2210 and 6611 Network Processor are some examples of the many contributors to response time, and their performance in the customer environment is really defined by their contribution to the overall system response time.

Performance varies by protocol and packet size in the router network. Kevin Tolly, in an article in Network World (Aug. 10, 1992), states that “traffic on a typical corporate internet consists of larger frames, such as those used in Novell, Inc. NetWare or Microsoft Corp. LAN Manager file transfers. Measuring performance using 64-byte packets is largely of academic interest, since virtually no applications use such small packets.”

Performance information then must be specified in such a way that expectations for a given LAN or WAN interface are factored into the network design. WAN speed is often the limiting factor in throughput or response time measurements. Traffic patterns of the protocols being supported are also a factor when designing a network to support the necessary response time for an application. 

Another performance consideration that is added to the aggregate of the performance and capacity is the overhead of router-to-router exchanges. As each protocol is added, a new flow of exchanges between the routers must occur. Network management is another internal flow that must be given consideration when determining the necessary box performance to support the system performance requirements. 

Routers were designed with connectionless-oriented protocols in mind. Each data packet finds its way through the network with the information available in its header. Path information is maintained via router information exchanges outlined in protocols such as TCP/IP¢s RIP and OSPF. Broadcasts are used to learn locations of other end stations, services, and zones. Today's connection-oriented protocols are encapsulated to take on these characteristics. Performance under this encapsulation may be more comparable from the end stations point of reference, such as response time, as each implementation provides unique function in its support of connection-oriented protocols ranging from spoofing to broadcast and flow control.

Performance is limited by the hardware on which the function is being tested. Each interface must be tested with the protocols and function supported on it. After looking at the card level performance, box level performance information becomes one of the entities in the overall network performance information. Only then can performance be estimated for the network and bottlenecks pinpointed. End-to-end response time is the last of the performance information that can be gathered. 

The primary metrics used to characterize the performance of a device are:

· Responsiveness is the time interval between an input and the corresponding output.

· Productivity is the amount of work done during a time interval.

· Utilization is the ratio of busy time to elapsed time.

Each is used to describe some aspect of how well a device processes jobs (units of work to be performed by the system). For routers, a job is usually synonymous with a routed packet.

Performance in Routers

Performance has become one of the hot topics in the multiprotocol router market today. Therefore, performance results must provide sufficient information so valid comparisons are made for the network that is to be built. The definition of performance in a multiprotocol router network has required revision as the router network has evolved. When the device was a single protocol, single media machine, performance could easily be reported in frames per second. This speed specification was a sufficient performance rating given the environment was simple and well understood. As multiple media interfaces and multiple connectionless protocols were added, performance was presented as maximum speed for the specific protocol or the generic maximum throughput for the box. This led to some confusion since the type of frames and environmental modifiers were not specified.

In today's network, where the router is used for LAN interconnection and WAN transport for connectionless and connection-oriented protocols, performance reporting must be standardized to allow for comparison in both the bridged and routed environments. This standardization must result in information valid for a production environment where multiple protocols are enabled in the router, frames of router exchange information flow, and filters are activated. 

Many vendors still quote total theoretical box throughput for their boxes as sufficient input for the router decision. These reports often come without the specification of the environment in which the performance test was made. The test bed may have no likeness to production environments as the test may be chosen to optimize for maximum speed. Without a controlled environment to record the speed, these recordings are not easily compared to other vendors'

performance information. To offset this, the Internet Engineering Task Force (IEFT) formed the Benchmark Methodology Working Group (BMWG) to establish guidelines for performance testing. Terminology, test environment (frame size, router information exchange, single and multiple protocol mixture, etc) and, in the future, packet content are specified to give the marketplace data that are compared and contrasted when making purchase decisions.

The Benchmark Methodology Working Group (BMWG) of the Internet Engineering Task Force (IEFT) defined the following RFCs:

· Benchmarking Terminology (RFC1242) - Available

· Benchmarking Methodology - Draft

· Benchmarking Methodology: Test Frame Formats - Draft

In spite of the attention performance receives, it is only one of several important selection criteria and must always be weighed with the other critical determining

factors in the network, such as:

· Required functions and protocols supported

· Reliability and availability

· Network management capability

· Quality and level of service provided by vendor

· Total cost of ownership (hardware, software, service and support)

Routing Table Maintenance Protocols

Routing tables are held by routers to define paths to destinations in an internetwork. They are normally created and maintained by routing table maintenance protocols.

Routing table maintenance protocols that maintain routing tables for IP networks are normally referred to as IP routing protocols. This term is used throughout this section.

Each routing table maintenance protocol uses a different algorithm to determine when new routes are available and what the best routes are that should be added to the routing table. These algorithms compare routes on the basis of some measurement of distance or cost associated with a route. 

Routes consist of three elements: a destination, the identity of the next hop in the path to the destination and the distance or cost of the complete route to the destination. The distance or cost of the route is referred to as a metric . 

In some protocols the metric is purely the number of hops to the destination; in others, it is a measure of the number of seconds to reach the destination. Modern protocols allow the cost of each network link to be set during network design. In this case the network link cost is normally an indication of the speed of the network, although it could be used to indicate other types of cost such as the lease cost of a telecommunications circuit. 

Each protocol suite (such as TCP/IP, DECnet, AppleTalk) has its own routing table maintenance protocol. Some, such as TCP/IP, offer alternates. 

The routing table maintenance protocols for each suite are:

TCP/IP

· Routing Information Protocol (RIP)

· Open Shortest Path First (OSPF)

· HELLO

· Exterior Gateway Protocol (EGP)

· Border Gateway Protocol (BGP)

· Static Routes

NetWare

· Routing Information Protocol (RIP)

Xerox Network Service (XNS)

· Routing Information Protocol (RIP)

AppleTalk

· Routing Table Maintenance Protocol (RTMP)

DECnet

· DECnet phase IV

Banyan VIrtual NEtworking System Protocol (VINES)

· VINES Routing Update Protocol (VINES RTP)

TCP/IP, NetWare and XNS all have routing information protocols. All derive from the XNS routing information protocol, but all are different .

Routers

Routers act as network layer relays between networks.

While bridges are normally restricted to connecting LANs within an internetwork,

routers have the capability of connecting networks of different types

A router participates as a device on each attached network and exchanges information with devices on those networks. These are end node capabilities.

A router has the additional capability of exchanging information with other routers and with end nodes on remote networks as long as they support the same network layer protocol.

Therefore, routers are protocol-dependent, unlike bridges.

Packet

Packets (also known as frames) are defined as chunk data which has been packaged, addressed, and sent into the network towards its destination much as a letter is placed into an envelope, addressed, and dropped into a mailbox.

The data may represent an entire message or a segment of a message, depending on media or device limitations on the amount of information that may be enveloped.

Routers forward packets based on information held in the network layer headers of packets they receive on their attached networks. Network layer headers contain address information (typically consisting of a network identifier and a host identifier) and associated control to allow the packets to be routed to their correct destination. Packets that have no network layer header, or that have a network layer header for a protocol not supported by a particular router, are discarded.

There are a number of network layer protocols, each of which has its own network layer header format for addressing and control.

A router must be configured with the network layer address of each of its network connections. When it receives an incoming frame with a compatible network layer header, it determines whether the destination address is on the same network. If it is, then the frame is discarded. Otherwise, the router forwards the frame to the destination device (if on a network attached to the router), or to the next router in the path to the destination device.

In order to do this, a router must maintain routing tables containing information about the next router in the path to every reachable destination in the internetwork. The process for doing this includes two stages: 

• It must acquire route information.
  
• It must determine the best routes to insert into its routing table.
  

Route information can be acquired by manual configuration (these are called static routes), or can be learned automatically from other routers using routing table maintenance protocols (these are called dynamic routes)

Source-Route Transparent Bridging (SRT)

The IEEE 802.1 committee identified the need for source-route bridges to interoperate with transparent bridges in the same internetwork. A source-route transparent bridge (SRT) standard has been defined to achieve this goal. The principle behind SRT bridges is very simple. An SRT bridge inspects all received frames and looks for the presence of the routing information indicator (RII) and the routing information field (RIF). If these fields are present, the SRT bridge uses them and acts as a source-route bridge. If not, the SRT bridge operates in transparent bridge mode and forwards frames based on their MAC sublayer destination address and its associated entry in the filtering database. The source-route transparent bridge does not allow source-route bridge devices to communicate with transparent bridge devices. SRT bridge is the capability for its interfaces to understand both source-route bridging and transparent bridging devices. But an SRT bridge will never translate source-route bridge frames into transparent bridge frames, and vice versa.

Source-Route - Translational Bridge (SR-TB)

Source-Route - Translational Bridge (SR-TB) is not an ISO standard definition. However, more and more bridges are implementing the SR-TB because of the need to interconnect source-route bridge domain with transparent bridge domain. The goal of the source-route - translational bridge is to translate source-route bridge frame into a transparent bridge frame, and vice versa. The SR-TB bridges have to change the MAC layer protocol from (or to) Ethernet protocol to (or from) token-ring protocol. Actually, regarding the ISO bridge definition, this translation does not belong to a bridge. But it is implemented in a lot of bridges, in order to be able to interconnect source-route bridge domain and transparent bridge domain regardless of the protocol of the upper layer.

Tunnel Bridge

The tunnel bridge allows source-route bridge domains or transparent bridge domains to communicate across an IP network. The tunnel bridge receives bridged frames from its source-route bridge or transparent bridge domain. The frames are encapsulated into IP datagrams that are sent to the destination IP address. These IP datagrams are routed in the IP network as are other IP datagrams, with the IP rules. The destination IP address is actually another bridge implementing the tunnel bridge feature. This target bridge removes the IP envelope from these IP datagrams making them source-route bridge or transparent bridge frames. Then the target bridge sends these frames to its source-route bridge domain or transparent bridge domain in the same way that other bridged frames are sent.

With tunnel bridging, as far as the source-route bridge is concerned, the IP network is seen as a single LAN segment, regardless of the complexity of the IP network. Then it adds only one hop to cross this IP network. 

The number of hops from the source device to the source IP tunnel bridge, plus one hop to cross the IP network, plus the number of hops from the destination IP tunnel bridge to the destination device, must not exceed the 7-hop count limitation of the source-route bridge implementation.

Source-Route Bridging (SRB)

Source-route bridging is implemented by IBM and compatible bridge products for use over token-ring LAN segments.

Source-routing requires a sending device to specify the path that should be taken by a frame across an internetwork, rather than allowing the decision to be made by individual bridges. To do this a sending device must determine the best path to a destination and include it in all frames to that destination. The best path to a destination is found using a discovery process, one implementation of which is described in this section.

A sending device sends a discovery frame to the intended destination device marked single-route broadcast. Bridges in a token-ring internetwork should be configured using the token-ring spanning tree algorithm to permit only one path for single-route broadcast frames between devices. The destination device should therefore receive only a single copy of the discovery frame.

The destination device responds to the discovery frame with a discovery response frame, marked all-routes broadcast. This will contain the most significant bit (the route information indicator, also called RII) set in the source MAC address field, and an entry in the routing information field (RIF). This will initially contain zero in the bridge number field, and the number of the networks to which the destination device is attached in the segment number field.

The discovery response frame, because it is marked all-routes broadcast, will pass through all bridges on its way back to the original sending device. Each bridge that the frame passes through must insert its bridge number and LAN segment, and hence the frames that return to the original sending device contain the routes they have taken through the bridged internetwork.

The routing information field can currently only hold data for about seven bridges and eight LAN segments. If a frame is received by a bridge with this field full, it is discarded. This limits the number of bridge hops in the network to seven, and consequently the maximum size of source-route bridged internetworks.

The original sending device therefore receives one or more discovery response frames. These frames contain routing control and bridge and LAN segment numbers in their routing information fields. The routing control field indicates the number of bridge/LAN segments in the routing information field and also the maximum frame size that is supported by the route.

The sending device can now select the best route to use through the internetwork to reach the destination device. Current implementations select the route in the first received discovery response frame (the fastest path at the time of the discovery process), although the architecture allows route selection based on other criteria, for example, maximum frame size supported by the route.

Bridging Methods

There are two primary methods of bridging:
· Transparent bridging (mainly used with Ethernet LANs), also called spanning tree bridging (STB)
· Source-route bridging (SRB) (used in 802.5 LANs). Then, from these two primary methods of bridging, there are other methods listed as follows:
Source-route transparent bridging (SRT)
Source-route - translational bridging (SR-TB)
Tunnel bridge (IP encapsulation)
All of these bridging methods are supported by the IBM 2210.
In the following topics, we provide a summary description of these bridging
methods.

Transparent Bridging (STB)

A transparent bridge is also called a spanning tree bridge (STB).
Transparent bridging is normally used to connect LAN segments. It is specified in the ISO 8802-1 standard.

This form of bridging could also be used for connection of token-ring LAN segments, although this is not common.

Transparent bridging is based on the principle that a sending device can transmit a frame to a receiving device on a LAN network without having any knowledge of the location of, or the path to, that receiving device.

Transparent bridges within a network are responsible for forwarding the frame to the correct destination, making the determination of whether a frame should be forwarded based on MAC sub-layer destination address.

Transparent bridges achieve this by building and maintaining a filtering database that acts as a forwarding table for received frames. They build their database by copying all frames from the LANs to which they are attached and learning the location of devices by inspecting the MAC sub-layer source address in each received frame.

Figure: 1 Transparent Bridging

Figure 1 illustrates how a transparent bridge will build up its filtering database. When the bridge receives a frame from device D1 on port A, it learns that D1 is reached via the LAN on port A. Similarly, if a frame arrives from device D7 on port B, it learns that D7 is reached via the LAN on port B.

For each new source address the bridge sees on the LAN, it adds an additional entry in its database. In time a full picture is built up of all devices on the two LANs and via which port they are reached.

The bridge uses its filtering database to determine if an incoming frame should be forwarded or discarded. This is done by examining the MAC sub-layer destination address of each frame and comparing it to the list of addresses in the filtering database:
· If the destination address is not in the database, the frame is forwarded on each port except the receiving port.

. If the destination address is in the database and the frame was received on a port associated with the address, the frame is discarded.

· If the destination address is in the database and the frame was received on a port not associated with the address, the frame is forwarded to the associated port for this destination address in the database.

Transparent bridges require that there be only a single active path between any two LANs in an internetwork. This requirement is to ensure that frames do not loop in such a way that they are seen on both ports of a bridge. If this happens, the bridge will be unable to forward the frames correctly to their destination.

Transparent bridges support and use spanning tree protocol, which ensures a loop-free topology between all the transparent bridges within the network.

Bridges

Bridges act as data link layer relays between LANs.

A bridge participates as a device on the networks to which it is attached, exchanges information with devices on those networks, and forwards information between the networks selectively through the MAC address.
There are four types of bridges and they are classified by their hardware and
software capabilities.

Simple Bridges

Simple Bridges consist of two or more linked network interfaces connecting local area networks. Bridges interconnect separate local area networks (LANs) by relaying data frames between the separate MAC (media access control) entities of the bridged LANs.











Figure: Simple bridge connecting two homogeneous LANs.







The main functions of a simple bridge may be summarized as follows:

• The bridge reads all data frames transmitted on LAN A and receives those addressed to LAN B. Simple bridges make no changes to the content or format of the data frames that they receive. They also do not encapsulate frames with any additional headers. Most simple bridges contain routing addressing and routing intelligence. At a minimum, the bridge must know which addresses are on each connected network so that it can know which frames to pass on.
• The bridge retransmits the data frames addressed to LAN B using the MAC protocol for that LAN. Bridges should have enough buffer space to meet peak data traffic demands since data frames may arrive faster than the bridge can transmit them.
• The bridge does the same for LAN B-to-LAN A data frame traffic.

Complex Bridges

Complex Bridges carry out more sophisticated functions than simple bridges. These functions may include the bridge maintaining status information on the other bridges. This information includes the communication path cost as well as the number of hops required to reach each connected network. Periodic exchanges of information between bridges update all bridge information. These types of exchanges allow for dynamic routing between bridges.
Complex bridges can also modify frames and recognize and transmit packets from different LAN technologies (for example, token-ring and Ethernet). In this case the bridge is sometimes referred to as a translational bridge.
The Adaptive Source-Routing Transparent (ASRT) Bridge is the IBM 2210¢s
implementation of bridge technology. The ASRT Bridge is a collection of software components capable of several of the bridging options just described and more.

Local Bridges

Local Bridges provide connections between several LAN segments in the same geographical area. An example of this would be a bridge used to connect the various LANs located in your company's main headquarters.


Remote Bridges

Remote Bridges connect multiple LAN segments in different geographical areas. An example of this would be bridges used to connect LANs located in your company¢s main headquarters to LANs in other branch offices around the country. Because of the geographical differences, this configuration moves from a local area network configuration to a wide area network (WAN) configuration.
Remote bridges can differ from local bridges in several ways. One major
difference is found in the speed in which data is transmitted. WAN connections are generally slower than LAN connections. This difference in speed can make quite a difference when running time-sensitive applications. Another difference is found in the physical way that remote and local bridges are connected to LANs. In local bridges, the connections are made through local cabling media (for example, Ethernet). Remote bridge connections are made over the serial lines.