Recipe for routing in the new public network

Routers must incorporate advanced features and perform more efficiently if they are to meet tomorrow's requirements.

By TIM HALE, Ericsson

The planets seem to be aligning for network carriers that want to begin the migration to Internet Protocol (IP) networks. Where once this move seemed an overwhelming idea that made running disparate networks seem a comfortable-if not unwise-business plan, today's carriers are looking to a future where "the network" will mean "IP." And, in turn, smart, fast IP routing won't be an option but a requirement to ensure true quality of service (QoS). Accordingly, the routing landscape in the core will be made up of several routing "must-haves."

As private IP networks mesh with the Internet, it's clear from a scalability standpoint that a key IP routing essential is the ability to handle both interior gateway protocols (IGPs) and exterior gateway protocols (EGPs). As some routers are tasked with forwarding information through several different network elements that are all controlled by the same administrative authority (like a private backbone network), otherwise known as autonomous system (AS), IGPs are the standard for exchanging information within that AS. On the other hand, shuttling information between different ASs calls into play EGPs (or more specifically, the Border Gateway Protocol-BGP).

The Internet is a collection of Autonomous Systems (ASs). ASs run interior gateway protocols such as open shortest path first (OSPF) and intermediate system to intermediate system (IS-IS) within their boundaries and interconnect via an exterior gateway protocol called the Border Gateway Protocol (BGP). From a purely technical standpoint, IS-IS is quite similar to OSPF, since both are based on the shortest-path-first algorithm, and both support routing hierarchies, type of service, and authentication.

Although link-state protocols provide adequate scalability in terms of routing within an AS, alone they do not scale to afford global connectivity via the Internet. BGP-4, therefore, is the definitive standard for exterior routing on the Internet. But BGP traffic traversing between, and particularly within, ASs can result in control traffic getting out of control.

Enter "route reflectors," which are designed to further control the overabundance of BGP peering. Their primary responsibility is to reduce the number of update messages sent within an AS. By arranging BGP routers in clusters, with one router in a cluster serving as the route reflector, the reflector can redistribute routing information to each client peer and to non-client peers outside the cluster. The benefit? Because the reflector is "reflecting" routes within the cluster, the clustered routers do not have to be fully meshed.

When a reflector receives a route, it simply selects the best path. If the route, however, came from outside the cluster, the reflector sends the route to all peers within the cluster. Conversely, if the route was generated from a client peer, the reflector sends the route to all non-client peers, except the originator. The internal BGP (IBGP) traffic is, in turn, reduced since none of the client peers send routes to other client peers.

Route reflection is a concept that has been growing in popularity, particularly when dealing with overhead and scalability issues that are par for the course in larger networks. And the transition from a non-route-reflector topology to one that uses such a scheme tends to be an easy migration, since only one device in a cluster needs to be modified to perform such tasks.

Internet Protocol traffic enters and exits a Multiprotocol Label Switching (MPLS) backbone from the network's edge routers called label edge routers and is switched along a path through core routers known as label switch routers. MPLS traffic engineering is accomplished by establishing label-switched paths that can support the desired quality of service between the ingress points and egress points.

Reducing IBGP mesh is just one "must" in terms of scaling any IP network for the Internet. Another strategic ne cessity lies in the control over the network harnessed through the administration of routing policies. These policies can be used to retrain which paths are selected across the Internet or across a private network. Without such policies in place, traffic would be permitted to enter the network in unpredictable patterns, possibly jeopardizing security and bandwidth expectations.

Effective routing policy allows for network operators to exact a measure of control over routing information that's transferred between routing protocols and the routing table. Moreover, routing information can be filtered so that some of it is transferred, thereby allowing for properties to be set in association with the routes.

Routing policy allows for the filtration of routes a routing protocol is importing and exporting from a routing table. The information associated with a route can also be set on its export or import by the routing table. It is this application of routing policy-both on export and import- that determines the control of the routes a routing protocol is using to determine active routes and also the control of the routes the protocol advertises to its neighbors.

Taking advantage of route reflectors, confederations, and routing policies, though, is only half the battle. True stability and scalability are not achieved until damaging route-flapping is addressed. A major culprit of poor Internet service is partly due to the tremendous quantity of updates received by routers in a network's backbone. Update messages, generated when network elements broadcast non-operational or operation statuses that affect routes, can cause significant traffic congestion, especially since these updates can be computationally intensive for a border router, for example. Some route-flapping is unavoidable, but in excess, these updates can bring down older software-based routers.

The cure to this problem comes in the form of two remedies: route aggregation and flap dampening. Route aggregation sets limits on the visibility of topological details, so local changes are not broadcast unnecessarily to backbone networks, while flap dampening shuts down "ill-behaved" routes once they have "flapped" up to or beyond a predefined threshold.

One major problem that has contributed to poor Internet service is so-called "route-flapping." The stream of routing updates received by all backbone routers causes route-flapping to occur. Effectively, every transition between operational and non-operational states of network equipment affecting connectivity generates a wave of update messages rolling over the backbone.

In a network enabled by an optimized switching technology for large IP networks called Multiprotocol Label Switching (MPLS), every packet is labeled with forwarding instructions used by the nodes. Rather than just relying on a packet's destination IP address, packets are given their navigational cues by advanced edge routers capable of calculating the path and intelligently assigning labels based on traffic classification. (The controlled path the packet ultimately takes is called an LSP, or label-switched path.)

Since most routers are meshed with vast numbers of other routers via an array of paths, each servicing various customers and traffic types, network providers need to map traffic from the different priority subscriber types to different routes within a given AS. By doing this, high-priority, delay-sensitive traffic like voice over IP (VoIP) is switched along predictable, congestion-free paths, while more "vanilla" loads (like simple Internet-access subscription traffic) are distributed throughout the AS in an effort to fully utilize the infrastructure.

At the network's edge, label edge routers (LERs) can "write" labels to IP packets as they come in or remove them as they leave. These labels correspond to the hops in the engineered LSP the packet is destined to follow. Ideally, an edge router in the new public network would be designed as an LER, able to function in both ATM and IP core network environments. At the core, label switch routers switch the traffic in and out of appropriate ports and swap incoming labels for outgoing ones.

Using this methodology, LSPs can be based on class-of-service parameters and differentiated-service (DiffServ) priorities contained in incoming packets. This sort of intelligence on the network's edge will combine with critical core techniques to handle prioritized traffic (like traffic conditioning, scheduling, and congestion control) and set the stage for robust end-to-end services such as new virtual-private-network services for adherence to predefined service-level agreements (SLAs).

Today's IGPs alone cannot provide the kind of intelligent, prioritized route mapping allowed under MPLS. Using only hop count to determine best-path routing does not afford network operators the advanced traffic engineering dictated by edge requirements that are more sophisticated than ever. Routers must now also be capable of MPLS traffic engineering, especially with the increased demand for VoIP and other high-priority traffic.

Once the slower handlers of packets, routers in the new public network are being asked to not only move packets from one place to another, but also to look deep into the packets and arrive at complex decisions surrounding the nature and priority of the payloads they handle.

Therefore, designers of new routing systems must replicate the forwarding performance previously available only through traditional switching.

However, delivering wire-speed functionality with longest-match lookups for variable-sized packets is, without question, more complicated than the relatively simple switching goal behind the support of wire-speed performance with fixed-length lookups and for fixed-sized cells. That said, software-based routing is simply not a feasible solution in a network with QoS aims.

Today's IP routers are built with open architectures and advanced ASIC processing technology onboard so that the same silicon can be used to support new or evolving routing and lookup applications. This ASIC technology is making fundamental improvements in the network fabric, with features such as packet filtering, traffic analysis, and load balancing.

In ASIC-enabled filtering, packets are scanned and matched to a user-configured filter rule. Upon processing, the router can accept the packet, discard the packet without notification, or reject the packet with notification. Filtering packets is especially useful from a security perspective, since unwanted or unnecessary traffic can be prevented from transport into the core. Additionally, the burden of such security measures is removed from the enterprise, as it is implemented instead in the service-provider network. Bottom line: Traffic reaching operators' customers arrives with a heightened level of integrity.

Over and above IP address verification and password protection, ASICs can help prevent various forms of hack attacks such as source address spoofing and the better-known denial-of-service (or DoS) intrusions. By relying on the wirespeed filtering, sampling, and logging capabilities of today's ASICs, routers have little difficulty revealing the source of unauthorized marauders.

ASICs are also making in-depth traffic analysis a reality by employing useful tools such as packet sampling, logging, and counting. ASICs also allow for load-balancing, meaning that various flows are streamed onto multiple circuits in such a way that packets containing a particular source-destination/port-address pair are always forwarded out of the same physical interface. That way, all packets from a certain flow are always channeled over the same circuit, maintaining individual flow integrity.

No longer will the transport of packets through an IP network simply be a question of "from where" and "where to." As the edge and core normalize in terms of their intelligence, IP traffic will move through a network equipped to handle the delivery of packets as well as understand the best way to transport information based on intelligent parameters.

Tim Hale is director of product marketing, IP infrastructure, at Ericsson (Burlington, MA).