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.