WHITE PAPER

The Technology of IP Routers in the New Public Network

Ericsson IP Infrastructure January 2000

Ericssonl

TABLE OF CONTENTS
ROUTING BASICS ..................................................................................................................................................................................3 INTRODUCTION .........................................................................................................................................................................................3 ROUTING PROTOCOLS ..............................................................................................................................................................................3 Interior and Exterior Gateway Protocols ..........................................................................................................................................4 IP Multicast .........................................................................................................................................................................................4 SCALING THE INTERNET...........................................................................................................................................................................5 Route Reflectors...................................................................................................................................................................................5 Confederations ....................................................................................................................................................................................6 ROUTING POLICY .....................................................................................................................................................................................6 DESIGNING STABLE INTERNETS...............................................................................................................................................................7 TRAFFIC PATTERNS ARE CHANGING .......................................................................................................................................................8 THE NEW KIDS ON THE BLOCK......................................................................................................................................................8 MULTI PROTOCOL LABEL SWITCHING (MPLS)......................................................................................................................................9 MPLS Forwarding Process ................................................................................................................................................................9 MPLS Scalability.................................................................................................................................................................................9 ROUTING VS. MPLS...............................................................................................................................................................................11 TRAFFIC ENGINEERING...................................................................................................................................................................11 BACKGROUND ........................................................................................................................................................................................11 Evolution of Internet Backbone Traffic Control ..............................................................................................................................11 ISPs Decide Between a Routed Core and an ATM Core............................................................................................ 12 Metric-Based Traffic Control in a Routed Core..............................................................................................................................12 Absence of "Traffic Engineering" across a Routed Core............................................................................................ 12 Advantages and Disadvantages of a Routed Core ...................................................................................................... 12 PVC-Based Traffic Control in an ATM Core ..................................................................................................................................13 Traffic Engineering across an ATM Core................................................................................................................... 13 The "N-Squared" Problem over ATM Cores .............................................................................................................. 14 Advantages and Disadvantages of an ATM Core ....................................................................................................... 14 Traditional Router Cores vs. ATM Cores ........................................................................................................................................15 TRAFFIC ENGINEERING AND MPLS ......................................................................................................................................................15 MPLS Benefits ...................................................................................................................................................................................16 IP LAYER 3 QOS....................................................................................................................................................................................17 BACKGROUND ........................................................................................................................................................................................17 ARCHITECTURE ......................................................................................................................................................................................17 Traffic Conditioning..........................................................................................................................................................................17 Scheduling .........................................................................................................................................................................................18 Congestion Control ...........................................................................................................................................................................18 IP OVER SONET/SDH ..........................................................................................................................................................................19 What About IP Over ATM?........................................................................................................................................ 19 WIRESPEED ROUTERS......................................................................................................................................................................20

This document outlines the underlying technologies for Ericsson's AXI 520 and AXI 540 Internet routers. It starts with a basic introduction to Internet routing protocols, and continues with a review of MultiProtocol Label Switching (MPLS) technology and a short comparison of traditional routing vs. label switching over ATM. The importance of traffic engineering in the Internet ba ckbone is highlighted, with a discussion of the use of MPLS for traffic engineering. Finally, two newer IP technologies are introduced: IP Layer 3 QoS and IP over SONET/SDH. Both play an important role in the new generation of wirespeed giga bit routers and emerging public IP networks. ROUTING BASICS INTRODUCTION According to the OSI reference model [see Figure 1 below], the Network Layer (Layer 3) is concerned with getting pa ckets of user informa tion from the source all the way to the destination. Someti mes the Network Layer is referred to as the internetworking layer. Internetworking is the a bility to link disparate network technologies ( e.g. Ethernet, Fra me Relay, and ATM) into a single extended network - an "Internet". IP (Internet Protocol) is the internetworking, or the Layer 3, protocol for the global interconnection of networks known as the Internet.
End Node Layer 7 Layer 6 Layer 5 Layer 4 Layer 3 Layer 2 Layer 1 Application Presentation Session Transport Network Data Link Physical Router Network Data Link Physical Router Network Data Link Physical

IP pa ckets that need to cross network boundaries are transmitted through IP routers. IP routing is the process of moving IP pa ckets a cross the Internet from source to destination. An IP router is a device that forwards IP pa ckets (at Layer 3) by a full exa mination of the IP pa cket header. From this point on, we will call IP routers just routers, and IP routing just routing. ROUTING PROTOCOLS Routing involves two basic activities: deter mination of opti mal routing paths and forwarding of infor mation pa ckets through an internetwork. The forwarding of IP pa ckets is relatively straightforward. However, determining the opti mal routing path can be very complex. Routers within the Internet are organized hierarchically. Some routers are used to forward infor mation through one particular group of networks under the sa me administrative authority and control (called an Autonomous System, or AS). These routers are called interior routers, and they use a variety of Interior Gateway Protocols (IGPs) to accomplish the infor mation exchange within the AS. Routers that forward infor mation between ASs are called exterior routers, and they use Exterior Gateway Protocols (EGPs) to a ccomplish their function.
End Node Application Presentation Session Transport Network Data Link Physical

The need for both exterior and interior routing protocols is driven by the size of the Internet. You need both to control the scalability to Internet di mensions. Nor mally, an Internet Service Provider is considered as one AS.

Figure 1: Internetworking

Generally, data that needs to cross network boundaries is transmitted through routers, and routing is the process of moving infor mation a cross an internetwork (i.e. at Layer 3) from source to destination.

IP routing protocols are dyna mic routes are calculated at regular intervals by routers and routers communicate with one another by exchanging routing updates. By analyzing routing updates from all routers, a router can build a detailed picture of the network topology. This informa tion is compiled and stored in a routing ta ble [see Figure 2]. The routing table consists of destination address/next hop pairs.

Destination Address 127.10.0.0 142.56.10.0 34.5.156.0 176.113.1.0 . . . . . . . . .

Next Hop

54.32.42.12 54.32.42.12 54.32.42.12 54.32.42.10 . . 54.32.42.10 54.32.42.10 . . .

route in ISO Connectionless Network Protocol (CLNP) networks, a version has been created to support both CLNP and IP networks. This version is usually referred to as Integrated IS-IS.
Autonomous System I I OSPF E I

Autonomous System E IS-IS

BGP

BGP Autonomous System E BGP I I I OSPF

Figure 2: Routing Table

I -- Interior Router E -- Exterior Router

IGP -- Interior Gateway Protocol, OSPF or IS-IS EGP -- Exterior Gateway Protocol, BGP

IP routing specifies that IP packets travel through the Internet one hop at the time. The entire route is not known at that start of the journey. Instead, in ea ch router, the next destination is calculated by matching the destination address within the IP pa cket with the routing table in the router. IP routing is described as "connectionless1." Note that routing ta bles can also contain other para meters, such as infor mation a bout the desira bility of a path, the metric (i.e. cost, delay, etc) of a path, and so on. Interior and Exterior Gateway Protocols As stated above, the Internet is a collection of ASs. ASs run Interior Gateway Protocols such as OSPF and IS-IS within their boundaries, and interconnect via an Exterior Gateway Protocol, called the Border Gateway Protocol (BGP) [see Figure 3]. Both OSPF ( Open Shortest Path First) and IS-IS (Inter mediate System-to-Inter mediate System) are called Link State protocols. OSPF was developed in the late 1980s by the Internet Engineering Task Force (IETF), mainly for use in the Internet. IS-IS was developed by International Or ganization for Standardization (ISO). Although IS-IS was created to
1

Figure 3: Interior and Exterior Gateway Protocols

From a purely technical standpoint, IS-IS is quite similar to OSPF. Both are based on the shortest path first algorithm, someti mes referred to as the Dijkstra algorithm, and both support routing hierarchies, typeof-service and authentication. Although the Link State protocols have good routing scalability, they cannot by themselves provide a global connectivity solution for the whole Internet. EGP was introduced to control the expa nsion of routing and to provide a more structured view of the Internet. Currently, BGP-4 is the de facto standard for exterior routing in the Internet. IP Multicast Today, most Internet applications use point-topoint, or unicast traffic (i.e. traffic from one single network device to another). But as application developers work to deliver the sa me data (such as audio and video required for conferencing) to multiple devices connected to a network, another for m of traffic is required. The new for m of traffic is called multicast traffic, and involves the transmission of a single IP pa cket to multiple hosts. Multicast traffic requires a new class of routing protocols multicast protocols. Distant Vector Multicast Routing Protocol (DVMRP) is an early multicast protocol used for building the multicast ba ckbone a cross the Internet. Protocol Independent Multicast (PIM) is a more sophisticated protocol, standardized recently by the IETF. It has

Compared to ATM switching which is connection-oriented. The argument between connection-oriented and connection-less really has to do with where to put the complexity of retransmission of packets, (re)ordering of packets etc.. In the connection-oriented case, its in the network; in the connection-less case, its in the end-stations (hosts). One of the major cornerstones of the Internet is to keep the network as simple as possible.

two modes of behavior: dense mode and sparse mode. In dense mode, PIM is optimized for traffic intended for almost all hosts, while in sparse mode, PIM is opti mized for many data strea ms but ea ch data strea m goes to a relatively small number of hosts. SCALING THE INTERNET

not have to be directly connected to ea ch other. They are only logically fully meshed. However, this requirement does not scale when there are many IBGP routers. One way to reduce the IBGP mesh is to configure a route reflector. Route Reflectors

As previously mentioned, the Internet is a collection of ASs running Interior Gateway Protocols, such as OSPF and IS-IS, within their boundaries and interconnecting via an Exterior Gateway Protocol, called Border Gateway Protocol (BGP). This is not, however, the whole picture. BGP supports two types of exchanges of routing infor mation: exchanges between different ASs and exchanges within a single AS. When used between ASs, BGP is called External BGP (EBGP). When used within a single AS, BGP is called Internal BGP (IBGP). BGP deployments are configured such that all BGP routers within a single network must be fully meshed so that any external routing infor mation will be redistributed to all other routers within that network. Figure 4 below illustrates a simple IBGP configuration with three IBGP speakers (Routers A, B, and C). When Router A receives a route from an external neighbor, it must advertise it to both Router B and C.
Autonomous System IBGP RC RB

Route reflection provides one mea ns of decreasing BGP control traffic, minimizing the number of update messa ges sent within the AS. In route reflection, BGP routers are arranged in clusters. Each cluster consists of at least one router that acts as a route reflector, along with any number of client peers. BGP peers outside the cluster are called non-client peers. The route reflector reflects (redistributes) routing infor mation to ea ch client peer and to all nonclient peers. Because the route reflector redistributes routes within the cluster, the BGP routers within the cluster do not have to be fully meshed.
Autonomous System

RD
Route Reflector

Non-Clients

RA

RE RC

RB

Clients Cluster

Physical Connection IBGP

Figure 5: Route Reflector with Client & Non-Client Peers

IBGP RA

IBGP

EBGP

Figure 4: External BGP and Internal BGP

Router B and C do not re-advertise the IBGP learned route to other IBGP speakers because the routers do not pass routes learned from internal neighbors on to other internal neighbors, thus preventing a routing infor mation loop. Note, that Routers A, B and C do

When the route reflector receives a route, it selects the best path. Then, if the route ca me from a non-client peer, the route reflector sends the route to all client peers within the cluster. If the route ca me from a client peer, the route reflector sends the route to all non-client peers and to all client peers except the originator. In this process, none of the client peers sends routes to other client peers.
The route reflector concept is growing in popularity for large networks because it enables scalability without a lot of overhead. Migrating from a non-route reflector to a route reflector design is easy since only the route

reflectors need to be modified to behave as route reflectors; all others would be running as usual.

Confederations Confederations are another way to deal with the explosion of an IBGP mesh within an AS. Confederations are based on the concept that an AS can be broken into multiple sub-ASs. An IBGP full mesh is used within the sub-ASs, and EBGP is used between the sub-ASs, as well as between the confederation itself and the outside ASs [see Figure 6 below].
Autonomous System

Routing policy allows you to control the routing infor mation that is transferred between the routing protocols and the routing table. You can filter the routing infor mation so that only some of it is transferred, and you can set properties associated with the routes. Routing policy allows you to control (filter) which routes the routing protocol imports into the routing ta ble and which routes a routing protocol can export from the routing ta ble. Routing policy also allows you to set the infor mation associated with a route as it is being imported or exported by the routing table. By applying routing policy to routes being imported to the routing ta ble you control the routes that the routing protocol process uses in order to deter mine active routes. By applying routing policy to routes being exported from the routing ta ble you control the routes that a protocol advertises to its neighbors [see Figure 8].
Network Neighbors Routes Import Policy Export Policy Network Neighbors Routes

Sub AS #1

EBGP

RD RA
IBGP

Sub AS #2 IBGP

IBGP

RB
IBGP

RC

RE

Protocol
Physical Connection BGP peers

Routing Table

Protocol

Network Neighbors

Network Neighbors

Figure 6: Confederations
Packets In

Forwarding Table

Packets Out

ROUTING POLICY All routing protocols store their routing infor mation in a common routing ta ble. From the collected routing infor mation, the routing software calculates the best routes to ea ch destination. These routes are used to forward traffic through the router, and may be advertised to neighbors via one or more routing protocols.

Figure 8: Importing and Exporting Routing Policies

Routing policies are defined in the following circumstances: ! You do not want a routing protocol to transfer all its routes into the routing table. That is, you do not want the routing ta ble to learn a bout certain routes. You do not want a routing protocol to receive from the routing table all the a ctive routes learned by that protocol. You want a routing protocol to receive active routes learned from another routing protocol. This is someti mes called route redistribution. You want to set the infor mation associated with a route, such as the preference value, autonomous system path, or the BGP community.

!
BGP
Import

OSPF
Import Export

IS-IS
Import Export Export

Routing Table
Figure 7: Importing and Exporting Routes

FLAP SOURCE

In Figure 9 below, for exa mple, a large ISP provides Internet access to a second-tier ISP that advertises several hundred routes into the large ISP. The large ISP configures policy rules so that it accepts only the routes that it expects to receive from the smaller ISP. When the smaller ISP gets a new customer, it infor ms the large ISP that it will be forwarding an additional set of routes. The large ISP updates the list of routes that it will accept from the smaller ISP by modifying its routing policy filtering rules.
Corp Customer

Network A

Network B

Network C Network D

Tens/Hundreds of Routes

Figure 10: Route Flaps Rolling Over All Backbone Networks

Dial-In Users

Small ISP
Policy Filters

Large ISP

The Internet

Corp Customer

Figure 9: Policy Filtering

The control provided by the routing policies is strategic to backbone networks because it is the funda mental tool that controls how the networks are used. Routing policies determine the paths selected across the Internet and can play a role in the path selected across the Service Provider's network.

Because the Internet is so large, the average rate of updates is relatively high (100-200 updates a second). Handling of routing updates is very computationally intensive, because every new update requires matching against routing policies, which could be several thousands of rules for a border router of a large ISP. Some level of route fla p is unavoida ble, since routing updates carry vital infor mation about changes in network topology. However, excessive levels of route flap are extremely dangerous, and routers ( particularly older software-based routers) die under the burden of doing route updating. There are two methods of reducing da ma ging route flap: route a ggregation and flap da mpening by holding off introduction of routing updates of unsta ble routes. Route aggregation is the more powerful tool, as it limits visibility of details of topology, so the routing updates generated by topological changes of local significance do not rea ch ba ckbone networks. The other mechanism, route flap da mpening, categorizes routes as either well behaved or ill behaved. The recent history of a route is used as a basis for esti mating future sta bility. Under route flap da mpening, ea ch time a route flaps, it is given a penalty. Whenever the penalty rea ches a predefined threshold, the route is suppressed.

DESIGNING STABLE INTERNETS One major problem that has ca used poor Internet service is so-called route fla pping. The strea m of routing updates received by all backbone routers causes route flapping. Effectively, every transition between operational and non-operational states of network equipment affecting connectivity of some globally visible network generates waves of update messa ges rolling over all ba ckbone networks. Factors that affect route insta bilities on the Internet include hardware failures, link failures, software problems, network upgrades, insta bilities of IGPs and human error.

It must be noted that the route flap phenomenon is not unique to IP. Since route flap is caused by propa gation of infor mation about topological changes, any networking technology that incorporates dyna mic adaptive routing ( e.g. PNNI) will have to deal with route flap. TRAFFIC PATTERNS ARE CHANGING In the past, network architects have commonly used the rule that 80% of the traffic will stay local in the network, while only 20% of the traffic will flow between networks. Traffic patterns have now shifted, revising the 80/20 rule to 20/80, with 20% intranetwork traffic and 80% inter-network traffic [see Figure 11 below].

Gbps/MHz

Internet Bandwidth

Router CPU Speed

time
Figure 12: Internet Bandwidth vs. Conventional Router Speed

20%

80% Backbone

80% Workgroup
Figure 11: Traffic Pattern Change

20%

Data communication and telecommunication is merging. We will see a dra matic increase of voice and video in addition to best-effort data traffic on the Internet in coming years. Changes in the local loop require changes in the ba ckbone. We are seeing a two orders-of-ma gnitude improvement in residential access rates (28.8K to 2Mbps) through xDSL, Cable Modems, Fixed Wireless (LMDS) and FTTC, and in business access rates (1.5Mbps to 155Mbps) through metropolitan area fiber infrastructure (fiber-to-the-business). These changes in the local loop put even more pressure on the Internet ba ckbone. The Internet is suffering from severe growing pains, and routing is one of the major bottlenecks. But it is not routing that is slow - it's today's generation of software-based routers. ISPs are deploying a new generation of wirespeed routers to a ccommodate customer demands. However, ISPs building new public IP networks need more than just speed. Today's IP networks use conventional routing protocols to mana ge the network topology, and can be difficult to opti mize. Today's networks also have little ability to deliver Quality of Service ( QoS) to real-time services such as voice. IP alone doesnt solve these problems - but let's exa mine some new developments in the IETF that address these issues and bring.

Consider an exa mple. Assume there are four to five major ba ckbone providers in the US. And ea ch have ea ch have roughly the sa me number of customers/subscribers (i.e. they ea ch carry 20-25% of the total backbone traffic). That means that 75-80% of the traffic will leave, and 20-25% will stay in their networks. This is true for ea ch one of the ba ckbone provides in this exa mple, and is even more pronounced for small regional and local ISPs.

THE NEW KIDS ON THE BLOCK The Internet is growing, and it is growing VERY fast. Internet ba ckbones grow much faster than conventional routing technology does. The reason for that is that progress of conventional routing technology depends on the progress in speed of microprocessors, which follows Moores Law, i.e. doubling every two years. At the sa me ti me, Internet traffic is doubling every 6 to 7 months.

MULTI PROTOCOL LABEL SWITCHING (MPLS) MPLS is an opti mized switching technology for IP networks, and can run within ATM or Fra me Relay networks, as well as over PPP fra mes on point-topoint lines. The basic idea of MPLS is to prepend IP pa ckets with a Layer 2 routing la bel at the edge of an "MPLS cloud", and to perform all forwarding within the cloud based only on the label value. The key feature provided by MPLS is the a bility to provide label-switched paths (LSPs), which are similar to PVCs in ATM and Fra me Relay networks. An LSP is created by concatenation of one or more la bel switched hops, allowing a packet to be forwarded from one Label Switching Router (LSR) to another LSR across an ISP network [see Figure 13]. An LSR is a router that supports MPLS. The important point here is that the path of the LSP is not limited to what the IGP would choose as the shortest path to rea ch the destination IP address.
IPs shortest path

IP prefixes and are link-local. When a packet containing a label arrives at an LSR, the LSR exa mines the label and uses it as an index into its forwarding table [see Figure 14 below]. Each entry in the forwarding table contains an inbound label that is ma pped to a set of forwarding infor mation a pplied to all pa ckets that carry the same inbound la bel.
Inbound Interface 2 2 Inbound Label 25 256 Outbound Interface 5 3 Outbound Label 185 735

. . .

. . .

. . .

. . .

Figure 14: MPLS Forwarding Table

138.39/16

MPLS may make direct use of underlying Layer 2 forwarding - for exa mple ATM or Fra me Relay switching - by using the Virtual Circuit field in the ATM/Fra me Relay pa ckets to carry the MPLS label. Alternatively, it may use a label "shim" inserted in PPP or Ethernet pa ckets. It should be noted that MPLS forwarding procedures are similar to those of traditional Layer 2 "label swa pping" devices, such as ATM switches. ATM switches use the input port and the incoming VPI/VCI value as the index into a "cross-connect" table, from which they obtain an output port and an outgoing VPI/VCI value. Therefore if one or more labels can be encoded directly into the fields that are accessed by these lega cy switches, then the lega cy switches can, with suitable software upgrades, be used as LSRs. We will refer to such devices as "ATMLSRs". MPLS Scalability MPLS scalability is provided by two of the principles of routing. The first is that forwarding follows an inverted tree rooted at a destination. The second is that the concept of aggregation or hierarchies.

Traffic to
138.39/16

LSP path

Figure 13: Label Switched Paths (LSPs)

An LSR that receives an IP packet can choose to forward it along an LSP by wra pping an MPLS header around the pa cket and forward it to another LSR. The labeled pa cket will be forwarded along the LSP by ea ch LSR until it rea ches the end of the LSP, at which time the MPLS header will be removed and the pa cket will be forwarded based on Layer 3 infor mation like the IP destination address. MPLS Forwarding Process The forwarding process of each LSR is based on the concept of label swa pping. The la bels are bound to

10

LSPs with a single exit point sharing a common internal path can be merged to for m a multipoint-topoint tree. For an LSR, the merge operation is straightforward: both incoming LSPs will perfor m a standard label switching operation, but will result in the sa me outbound la bel.

138.39/16

Traffic to
138.39/16

Traffic to 138.39/16

Merging therefore requires capabilities (i.e. multipoint-to-point connectivity) which are not always available in ATM forwarding hardware. In those cases, where the ATM-LSR switch does not support merging, a full mesh connection a pproa ch has to be deployed, i.e. point-to-point LSPs between all ingress nodes to all the egress nodes in the MPLS network. For small networks the full mesh connection approa ch may suffice and not pose any scalability problems. However, in large enterprise ba ckbone or ISP networks, this will not scale well.
138.39/16

Traffic to
138.39/16

Traffic to 138.39/16 Traffic to

138.39/16

Traffic to 138.39/16

Figure 15: Traffic Merging

Traffic to

The second feature MPLS uses to scale networks is aggregation or hierarchies.

Note that for an ATM-LSR, the merge operation is less straightforward. In ATM, if one attempts to perfor m merging, the result ma y be the interleaving2 of cells from various pa ckets within a single VC. When this happens, it is impossible to reassemble the pa ckets later.

138.39/16

138.39/16

Traffic to
127.41/16

127.41/16

IP AA Pac L5 ke PD t U

Traffic to
208.14/16

208.14/16

Figure 17: Traffic Aggregation in an MPLS Network

ATM-LSR
Figure 16: Cell Interleaving in an ATM Switch

LSPs can be aggregated with other LSPs by adding a new la bel to the sta ck of la bels for ea ch LSP, effectively bundling the LSPs into a single tunnel. Two or more LSPs can be aggregated if they share a portion of their path. These aggregated LSPs can be ter minated at any point, resulting in de-aggregation of traffic. The la bel sta ck mechanism allows LSP tunneling to nest to any depth.

2 In ATM, the data packets are encapsulated into an ATM Adaptation Layer, say AAL5, and the AAL5 PDU is segmented into ATM cells with a VPI/VCI value and the cells are transmitted in sequence. Hence, if cells from several upstrea m links are transmitted onto the sa me downstrea m VPI/VCI, then cells from one PDU can get interleaved with cells from another PDU on the outgoing VPI/VCI, and result in corruption of the original PDUs by mis-sequencing the cells of each PDU.

11

Traffic to
138.39/16

138.39/16

second, such as the cost of the switching fabric itself, and the cost of buffering.
Arguments about price and performance in label switching versus conventional routing are not very relevant. It will be hard to justify label switching from a performance or cost standpoint alone. The true benefit of MPLS is the increased trafficengineering capabilities that it offers to conventional routing.

Traffic to
127.41/16

127.41/16

Traffic to
208.14/16

208.14/16

Figure 18: Aggregated LSP in an MPLS Network

One useful application of this technique is in Virtual Private Networks. ROUTING VS. MPLS One of the claims made for label switching is that it offers advantages over more conventional routing techniques -- that label switching would offer improved perfor mance and do so at a lower cost that conventional approa ches. Is this accurate? Recall that IP forwarding is ba sed on a longest-ma tch lookup, while MPLS is based on an exa ct match lookup (i.e. the sa me type of lookup as ATM). It has historically been fa ct that ATM switches could perfor m faster fixed-length lookups in hardware and that routers could perfor m longest-ma tch lookups in software. However, recent advances in silicon technology allow ASIC-based route lookup engines to run as fast as ATM VPI/VCI lookup engines. Because routers now can forward pa ckets at line rate/wirespeed (just like an ATM switch can forward cells), forwarding perfor mance is no longer an issue. The cost angle is harder to figures out because vendors list prices are not necessarily a direct indication of cost. Label switching only reduces the cost of the IP address lookup and forwarding decision. Even if this could be driven to zero, the impa ct on the cost of the whole system remains modest. This is because there are many other costs in building a device that can forward pa ckets at many giga bit per

TRAFFIC ENGINEERING BACKGROUND Once the physical network topology exists, the task of ma pping traffic onto that topology must be tackled. In the past, ma pping traffic onto a physical topology was not approa ched in a particularly scientific way. Instead, the ma pping simply took pla ce as a byproduct of routing configurations. The weaknesses in this haphazard ma pping were often resolved by simply over-provisioning bandwidth. As ISP networks grow larger, as the circuits supporting IP grow faster, and as the demands of customers become greater, the ma pping of traffic onto physical topologies needs to be a pproa ched in a funda mentally different way. The offered load must be supported in a controlled way and in an efficient manner. This ma pping of traffic onto a physical topology is called traffic engineering. Evolution of Internet Backbone Traffic Control In the early 1990s when ISPs networks were constructed over T1/E1 (1.5-2 Mbps) and T3/E3 (3245 Mbps) links, traffic control was achieved by ma nipulating routing metrics. Metric-based control was adequate because Internet ba ckbones were much smaller than today in ter ms of the number of routers, the number of links, and the a mount of traffic.

12

ISPs Decide Between a Routed Core and an ATM Core Around 1994 or 1995, the load on ISP networks was increasing to the point where they si mply had to go faster than T3. At the ti me, OC-3/STM-1 interfaces (155 Mbps) were available only on ATM switches; they were not yet available on router platfor ms. The ISPs had to make a decision whether they were going to continue with a routed core or migrate to an ATM core. Each ISP chartered their future course based on answers to a few questions:
"

beca use all trunks cost money even if they are underutilized.
Chicago Salt Lake Denver San Francisco Atlanta Phoenix Dallas New Orleans IGP shortest path route S.F. to D.C. New York Detroit

Washington D.C.

Did the ISP have enough faith in the ability of their traditional router vendor(s) to rapidly deliver OC3/STM-1 and OC-12/STM-4 interfaces for their products? Did the ISP consider the lack of bandwidth a significant threat to their business that required immediate resolution, even if the solution meant a serious overhaul to the core of their network?

Figure 19: IGP Shortest Path between SF and DC

"

As we will see, the ISPs that chose to migrate to an ATM core thrived and continued to experience growth. Meanwhile, the ISPs that remained with a traditional router core had grea ter challenges to grow because of the late delivery and poor perfor mance of OC-3/STM-1 SONET/SDH interfa ces for routers. In the next several sections, we'll discuss the advanta ges and disadvantages of ea ch of these choices. Metric-Based Traffic Control in a Routed Core As discussed earlier, routing metric manipulation provided a basic tool for traffic control in the early 1990s. However, as the ma gnitude and intrica cy of carrier networks increased, metric-ba sed traffic control beca me more and more complicated, to the point where it was simply not a viable option. Network administrators could still adjust link metrics to avoid congestion, but it beca me mor e difficult to ensure that a metric adjustment in one part of an enor mous network didn't create a new problem in another part of the network. Absence of "Traffic Engineering" across a Routed Core If the only method of traffic control is to manipulate IGP metrics, it is possible for some of a network's links to be lightly used and other links heavily congested. This state is not cost-effective for the ISP

There are several potential paths between the San Francisco POP and the Washington, DC POP. Assume that the "shortest path" selected by the routing protocol for traffic between San Francisco and Washington, DC is the SF-to-Chica go-to-DC route [see Figure 19 a bove]. Also assume that there is a large a mount of traffic going from San Francisco to Chica go and also a large a mount of traffic going from Chica go to Washington, DC. The result of this is that the traffic from San Francisco to Washington, DC has to compete a gainst both the San Francisco-to-Chica go and Chica go-to-Washington, DC traffic. However, if the network is only ca pa ble of selecting links based on the IGP metrics, situations like this will occur often. Reliance on IGP metrics creates paths that become traffic magnets. The result is congestion and poor perfor mance that does not exploit the economies of the bandwidth provisioned across the entire WAN. Advantages and Disadvantages of a Routed Core There are a number of benefits gained by remaining with a routed core when compared to migrating to an ATM-based core:
"

In a routed core, the physical topology and the logical topology are identical. This eliminates the "nsquared" problem associated with ATM networks. This "n-squared" problem, discussed in the next section, is manifest in the complexity of adding new edge nodes and the stress that a full-mesh topology places on routing protocols.

13

"

There is no "cell tax" in a routed core. If you assume 20% overhead for ATM when factoring in framing and realistic distribution of packets sizes, this means that on a 155-Mbps OC-3 link, 124 Mbps is available for data while 31Mbps is consumed by the ATM overhead. However, if you consider a 2.488-Gbps OC-48 link, 1.990 Gbps is available for data and 498 Mbps is required for the ATM overhead (almost a full OCR 12!). The lack of a cell tax in a routed core means that the available bandwidth is used much more efficiently. R Routed cores, by virtue of their connectionless operation, are more resilient in failure modes. In an ATM circuit-based network, backup Permanent Virtual Circuits (PVCs) must be designed and installed in the switches before a failure occurs. Because failures have the potential of occurring at any point in a network, it is extremely difficult to design secondary PVCs that can provide the sa me degree of resiliency as IP routing inherently provides.

point-to-point circuits between two routers. Figure 20 below illustrates how the physical topology a cross the ATM core differs from the logical topology across the ATM core.
Physical Topology Logical Topology

S S S

R R

"

PVC #1 PVC #2 PVC #3

Figure 20: Physical vs. Logical Topology

Despite these advanta ges, traditional routed cores have a few significant disadvanta ges:
"

In a routed core, the traffic load is not equally distributed across the network's links, causing inefficient use of network resources. Some of the links can become congested, while other links remain underutilized. This may be satisfactory in a sparsely connected network, but in a richlyconnected network it is necessary to control the paths that traffic takes in order to load the links relatively equally. Metric-based traffic control does not offer an adequate solution for traffic engineering. As ISP networks become more richly connected, it is difficult to ensure that a metric adjustment in one part of the network doesn't cause problems in another part of the network.
London

Traffic Engineering Across an ATM Core For an ISP with an ATM core, the paths that the PVCs take through the network are typically calculated by an off-line configuration utility. Some ATM switch vendors offer proprietary techniques for routing PVCs on-line while taking some traffic engineering concerns into a ccount. However, these features are imma ture, and an ISP frequently has to resort to full off-line path calculation. After the PVC mesh has been calculated, the supporting configurations are downloaded into the routers and the ATM switches to i mplement the full-mesh logical topology. For some ISPs, ea ch router not only participates in a full mesh of PVCs with the other routers, but also participates in a full-mesh of ba ckup PVCs with every other router. Figure 21 Below depicts the logical topology for an ISP network with an ATM core. [Note that only the primary PVCs are illustrated, not the secondary PVCs].
Oslo Router Stockholm Router

"

PVC-Based Traffic Control in an ATM Core When IP runs over an ATM network, routers circle the edge of the ATM cloud. Each router communicates with every other router by a set of PVCs configured a cross the ATM physical topology. The routers do not have direct a ccess to infor mation concerning the physical topology of the underlying network; they have knowledge only of the individual PVCs that appear to them as si mple

Router

ATM Core

Router Frankf

Router Paris

Figure 21: Full Mesh of PVCs in an ATM Network

14

ATM PVCs provide a tool for supporting precision traffic engineering. The ISP deter mines the path for the PVCs based on mea sured traffic patterns so that traffic flows are distributed across different physical links. Each PVC is provisioned so that it is a ble to accommodate the anticipated load. As the network's traffic matrix evolves over time, the underlying physical path supporting a particular PVC can be modified to accommodate shifting traffic loads a cross the physical links. After the PVCs are installed in the switched infrastructure, they are merged into the IP network by running IGP across ea ch PVC. Between any two routers, the IGP metric for the pri mary PVC is set such that it is more preferred than the ba ckup PVC. This guarantees that the ba ckup PVC is used only when the pri mary PVC is not available. The "N-Squared" Problem over ATM Cores One of ATM's limitations is that it requires a fullmesh overlay of PVCs to provide Layer 3 connectivity. This full-mesh of PVCs is the source of the "nsquared" problem. The "n-squared" effect makes it laborious to add new routers to the network and pla ces excessive stress on routing protocols. Figure 22 below illustrates the "n-squared" problem by the requirement to increase the number of PVCs when a new router is added to the network. For exa mple, when growing the network from five to six routers, the ISP is required to increase the number of PVCs from 20 to 30. The addition of a single new router requires ten additional PVCs. The new PVCs need to be positioned a cross the physical topology so that they have minimal impact on the existing PVCs. The task of adding a new router becomes even more challenging when the number of routers increases from 50 to 51. This requires the addition of 100 new PVCs.
5 Border Routers 6 Border Routers

The "n-squared" problem also manifests itself in the stress that a full-mesh of PVCs pla ces on routing protocols. Routing with a full-mesh of PVCs works over smaller networks. However, with large networks there are significant scaling problems. The flooding of LSPs becomes inefficient; ea ch router has too many adjacencies with logical neighbors, and the Dijkstra calculation becomes inefficient because of the large number of logical links. Advantages and Disadvantages of an ATM Core Despite the "n-squared" problem, there are a number of advanta ges to deploying an ATM-based core in an ISP network:
"

An ATM-based core fully supports traffic engineering via PVC configuration, permitting the ISP to precisely distribute traffic across all of their links so that the trunks are evenly used. This eliminates the traffic magnet effect of least-cost routing, which creates over-utilized and underutilized links. Traffic engineering makes the ISP more competitive within its market, allowing lower costs and better service to its customers. In an ATM-based core, the per-PVC statistics provided by the switches facilitate the monitoring of traffic patterns. Network designers provision each PVC to support specific traffic-engineering objectives. They constantly monitor traffic on the PVCs. If a given PVC begins to experience congestion, the ISP has all the information it needs to remedy the situation.

"

"

Yet despite the significant advantage of supporting traffic engineering, ATM-based cores still have a number of substantial limitations:
"

The full-mesh of ATM PVCs exhibits the "nsquared" problem. The ATM cell tax can consume a significant amount of bandwidth. As discussed earlier, the cell tax on an OC-48 can be as much as a full OC-12. The elimination of the cell tax in a routed core means that bandwidth is used as efficiently as possible and not wasted on unnecessary overhead. ATM-based cores, by virtue of their connectionoriented operation, are less resilient in failure modes. In a routed core, alternate paths are calculated on demand whenever a link or peer fails. In an ATMbased core, backup paths have to be calculated in

"

"

5(4) = 20

6(5) = 30

Figure 22: The "n-squared" Problem

15

advance and then installed in the switches to provide an immediate backup capability.
"

ATM-based cores require the management of two different networks: an ATM infrastructure and a logical IP overlay. The task of managing any given network has a specific a mount of associated cost. By running an IP network over an ATM network, an ISP doubles its overhead because it needs to manage two separate networks. Routing and traffic engineering occur on different sets of boxes (that is, routing happens on the routers and traffic engineering happens on the ATM switches). As a result, there are two configuration processes to design, operate, and debug.

Traditional Router Cores

Advantages Physical topology ma tches logical topology No n-squared problem No cell tax Resilient in failure modes

Disadvantages Underutilized links Overutilized links Engineering by routing metrics is complex ATM cell tax Full mesh of ATM PVCs; n-squared problem Less resilient in failure modes Requires mana gement of two separate networks

"

ATM Cores

Traffic Engineering supported through PVC configuration Per-PVC statistics monitor traffic patterns and provide feedba ck to traffic engineering

Traditional Router Cores vs. ATM Cores Back in 1994, ISPs were simply looking to obtain more bandwidth so they could handle increasing a mounts of network traffic. ISPs that decided to pursue an ATM-based core quickly discovered that the ATM core provided them with two critical features: the ability to perform traffic engineering to equalize the traffic loads across the network, and perPVC statistics to count traffic. ISPs have become very comfortable with the level of control that ATM-based cores provide when compared to traditional routed cores. Today, ISPs are not willing to give up the control that ATM provides. Despite the numerous limitation of ATM (i.e., the cell tax, the "n-squared" problem, and the cost of mana ging two separate networks), ISPs understand that they require trafficengineering ca pa bilities similar to ATM in order to successfully run their networks. The following table provides a summary of the benefits and limitations of traditional routed cores and ATM-based cores. As we enter the a ge of the optical Internet, any emerging traffic engineering solution must combine the advanta ges of routed cores and ATM-based cores while eliminating their disadvantages.

Multiprotocol Label Switching (MPLS) provides the solution to support traffic engineering in large service provider networks. It combines the advantages of router-based and ATM-based cores, while eliminating the disadvantages. A few of the benefits offered by MPLS include: Ability to precisely control the use of valuable resources during periods of rapid growth Stability under congestion and failure modes Providing ISPs the foundation for value-added services

TRAFFIC ENGINEERING AND MPLS Traffic enters and exits a backbone network from the network's border routers. In the context of traffic engineering, the border routers are called the ingress and egress points to and from the network. Traffic engineering is accomplished with MPLS by esta blishing LSPs between ingress points and egress points [see Figure 23 on the following pa ge].

16

LSR LSR Ingress LSR LSR

install the forwarding state along the LSP just as above.

"
LSR Egress LSR LSR

LSR LSR

Configure the head-end LSR with just the identification of the tail end LSR. In this case, normal IP routing is used to determine the path of the LSP. This configuration doesn't provide any value in terms of traffic engineering, though the configuration is easy and it might be useful in situations where services like Virtual Private Networks (VPNs) are needed.

LSP between Ingress LSR and Egress LSR

Figure 23: LSP between Ingress LSR and Egress LSR

Recall that the essence of traffic engineering is ma pping traffic onto a physical topology. This means that the crux of the issue is deter mining the path for LSPs. Ericsson's implementation of MPLS in its Internet routers supports a number of different ways to route an LSP:
"

In all these cases, any number of LSPs can be specified as backups for the primary LSP. If a circuit on which the primary LSP is routed fails, the head-end LSR will notice because it will stop hearing RSVP messa ges from the remote end. If this ha ppens, the head-end LSR can call on RSVP to create forwarding state for one of the ba ckup LSPs. MPLS Benefits Previously, it was suggested that any emerging solution providing traffic engineering across the optical Internet must combine the advantages of ATM and routed cores while eliminating the disadvantages. Let's conclude by exa mining how well MPLS meets this challenge.
"

Calculate the full path for the LSP off-line and statically configure all LSRs in the LSP with the necessary forwarding state. This is analogous to how some ISPs are currently using ATM. Calculate the full path for the LSP off-line and statically configure the head-end LSR with the full path. The head-end LSR then uses the Resource Reservation Setup Protocol (RSVP) as a dyna mic signaling protocol to install forwarding state in each LSR. Note that RSVP is being used only to install the forwarding state, and it does not reserve bandwidth or provide any assurance of minimal delay or jitter (i.e. no quality-of-service guarantees). Calculate a partial path for the LSP off-line and statically configure the head-end LSR with a subset of the LSRs in the path. The partial path that is specified can include any combination of strict and loose routes. For exa mple, imagine an ISP has a topology that includes two east-west paths across the country: one in the north through Chicago and one in the south through Dallas. Now ima gine that the ISP wants to establish an LSP between a router in New York and a router in San Francisco. The ISP could configure the partial path for the LSP to include a single loose-routed hop of an LSR in Dallas and the result is that the LSP will be routed along the southern path. The head-end LSR uses RSVP to

"

An MPLS core fully supports traffic engineering via LSP configuration. This permits the ISP to precisely distribute traffic across all of their links so the trunks are evenly used, or important traffic goes over the most reliable links. In an MPLS core, the per-LSP statistics reported by the LSRs provide exactly the type of information required for configuring new traffic engineering paths and also for deploying new physical topologies. In an MPLS core, the physical topology and the logical topology are identical. This eliminates the "nsquared" problem associated with ATM networks. The lack of a cell tax in an MPLS core means that the provisioned bandwidth is used much more efficiently than in an ATM core. An MPLS core converges the Layer 2 and Layer 3 networks required in an ATM-based core. The management of a single network reduces costs, and permits routing and traffic engineering to occur on the sa me platform. This simplifies the design, configuration, operation, and debugging of the entire network.

"

"

"

"

"

17

"

MPLS support for a dyna mic protocol, such as RSVP, simplifies the deployment of traffic engineered LSPs across the network. MPLS provides the foundation for ISPs to offer valueadded services. Future MPLS support for constraint-based routing achieves the sa me control as more-manual traffic engineering but with less human intervention because the network itself participates in LSP calculation. Both IP-over-ATM networks and pure IP router networks can evolve into IP/MPLS networks, since MPLS is supported over ATM and point-to-point IP.
MPLS is strategically significant for traffic engineering because it can provide most of the functionality available from the overlay model in an integrated and scalable manner and at lower cost than competing alternatives.

of service must, in the immortal words of Mike O'Dell3, be "more than three, less than nine, and proba bly a power of two." ARCHITECTURE The IETF Differentiated Services architecture is based on a simple model where traffic entering a network is conditioned at the edges of the network, and assigned to different behavior aggregates or class of service. The architecture achieves scalability by implementing complex conditioning functions only at network edge nodes, and by applying per-hop behaviors to aggregates of traffic which have been a ppropriately marked using the DS field in the IP header. Traffic Conditioning A traffic conditioner may contain the following elements: classifier, meter, marker, and shaper [see Figure 24 below]. The classifier and the meter select the pa ckets within a traffic stream4 a nd measure the strea m against a traffic profile. The marker and shaper perfor m control actions on the pa ckets depending on whether the traffic strea m is within its associated profile.

"

"

"

IP LAYER 3 QOS BACKGROUND A network service is a contract between a network provider and its customer, outlining the characteristics and behavior of network connectivity offered by the provider to the customer. A Service Level Agreement (SLA) may specify different aspects of network behavior, such as constraints on the type and a mount of data that can be sent on the network, and the perfor mance aspects of communication. The SLA would typically also include a billing scenario as well as the perfor mance aspects expected with the associated contra ct. Traditionally, network providers have tended to provide all of their customers with the sa me type of perfor mance (a best-effort service). However, with increasing competition a mong network providers, there is a need to offer different types or grades of perfor mance to customers, with network providers offering better perfor mance to customers who are willing to pay more. In order to provide the notion of differentiated services, the network provider needs to be a ble to categorize traffic entering its network into multiple categories or classes of service. The number of classes

Marker Packets Classifier Meter

Traffic Conditioner

Shaper

Figure 24: Traffic Conditioner

A pa cket strea m nor mally passes to a classifier first, and then a meter measures ma tched pa ckets against the profile as defined in the SLA. The pa ckets within the profile may leave the traffic conditioner or may be marked by the marker. The pa ckets that are out-ofprofile may be either marked or shaped according to the rules specified in the SLA.
3

Mike O'Dell is responsible for overall network architecture and technical strategic direction for UUNET. 4 A traffic strea m is an administratively significant set of one or more applicationto-application flows.

18

Scheduling A per-hop behavior is defined as the forwarding behavior a packet receives at a given network node. Per-hop behaviors are implemented in nodes by queue ma nagement and pa cket scheduling mechanisms [see Figure 25 below].
queues scheduling

packets in

packets out

Random Early Detection (RED) is a congestion avoidance mechanism. Instead of waiting for the queues to fill and then drop all incoming pa ckets (tail drop), congestion control intelligence monitors the average queue size and performs early discard on randomly selected pa ckets. Rather then drop all arriving pa ckets, pa ckets are dropped with a low, but increasing proba ble, risk instead of waiting until the queue is full. Of course, RED is only a solution for congested nodes/links and not a solution for overloaded networks.
Drop probability

congestion handling

100%

Figure 25: Scheduling of Packets

Weighted Fair Queuing ( WFQ) provides bandwidth allocation and delay bounds to traffic by segregating the traffic into a number of queues, and then serves these queues in a non first-in/first-out fashion, where an assigned weight per queue is considered [see Figure 26]. The weight represents how much the queue is serviced by the scheduler, compared to the other queues. If a queue is empty, the other queues will be given a share of the total available ca pa city according to their respective weights. WF Q ensures that queues do not starve of ba ndwidth, and that traffic gets predicta ble service.
queue selection based on DS field

0%

Queue length min max

Figure 27: Random Early Detection (RED)

In addition, RED statistically drops more pa ckets from large users than small. Therefore, traffic sources that generate the most traffic are more likely to be slowed down than traffic sources that generate little traffic. Weighted RED (WRED) generally drops pa ckets selectively based on IP precedence ( or DiffServ label value). WRED provides separate thresholds and weights for different IP precedence, allowing you to provide different qualities of service for different traffic. Standard traffic may be dropped more frequently than premium traffic during periods of congestion. WRED is usually used in the core routers of a network, rather than the edge. Edge routers assign IP precedence to pa ckets as they enter the network. WRED uses this precedence to deter mine how the core treats different types of traffic. An enhancement to RED, is the consideration of In/Out of profile marking of pa ckets called Random Early Detection In/ Out (RIO). RIO is in principle two RED algorithms operating at the sa me ti me, one for pa ckets marked In-profile and one for pa ckets

queues
75 50 10 2 weighted scheduling

packets in

packets out

Figure 26: Weighted Fair Queuing (WFQ)

Congestion Control A congestion-handling scheme is also needed to ensure that higher value traffic receives preferential treatment during congestion situations and as lower value traffic is discarded earlier and, potentially, more aggressively.

19

marked Out-of-profile. The Out algorithm starts dropping at a much shorter avera ge queue length, and drops much more aggressively than the In algorithm. With proper setting of parameters, the Out of profile traffic can be controlled before the queue grows to the point that any In traffic is dropped [see Figure 28 below].

ma pped directly to the SONET/SDH layer using "Packet over SONET" or POS. According to the OSI reference model, the SONET/SDH protocol is the physical layer (Layer 1) and IP is a network layer protocol (Layer 3). A data link layer (Layer 2) is required to interfa ce the SONET/SDH protocol with IP. The IETF has standardized on the Point-to-Point Protocol (PPP) to perfor m this function. The applica ble Request for Comments are:
" " "

Drop probability

100%

RFC 1619 - "PPP over SONET and SDH Circuits". RFC 1549- "PPP in HDLC Framing". RFC 1548 - Point-to-Point Protocol (PPP)

0%

Queue length min

OUT

max min
OUT IN

max
IN

Figure 28: Random Early Detection In/Out (RIO)

The for mat of IP pa ckets in the SONET/SDH synchronous payload envelope is simple. One byte is dedicated to the pa cket fla g at the beginning of the string and four bytes are dedicated to the PPP header (one address byte, one control byte and two for protocol bytes). The IP pa ckets are serially pla ced in the SONET/SDH fra me, and a cyclic redundancy check is added at the end. What About IP Over ATM? ISPs delivering pure data services are concerned with getting every possible drop of perfor mance out of their WAN infrastructure. With no real-ti me traffic load in their networks (i.e., no base of circuit-switched telephony subscribers), ISPs don't benefit from ATM's excellent multiplexing and jitter mana gement ca pa bilities. The cell structure of ATM responsible for these characteristics is seen only as a "cell tax" consuming 20-30% of the WANs bandwidth without generating any value.

IP OVER SONET/SDH The demand for bandwidth is skyrocketing in dataservice networks. With this dema nd comes the need for efficient bandwidth utilization, higher perfor mance, and simplicity. These trends have brought about the birth of a new IP-centric network model. The IP-centric network infrastructure is an IP-based, full-service network that takes advantage of IP Layer 3 QoS and such inherent IP characteristics as scalability, simplicity, and multicasting. In an IP-centric network, IP pa ckets are

20

IP over SONET OC-3 vs. IP over ATM SONET OC-3

160 140 120 100

support IP QoS, IP Multicast, and MPLS for traffic engineering. Ericsson's AXI 520 IP Core Router and AXI 540 Edge Aggregation Router are both exa mples of this new generation of wirespeed routers. These platfor ms, together with Ericsson's advanced IP network ma na gement solutions, deliver a highly effective and integration solution for carrier-class IP networks [see Figure 30 below].

Mbps

80 60 40 20 0 46 110 238 494 1006 1500 IP over SONET IP over ATM (AAL5SNAP) OC-3 Payload

Residential Customers Access POP

Aggregation Router
xDSL/Cable Modem

Backbone POP

High Speed Local Access

xDSL /CableModems

Bytes per IP Packet

OC-3
xDSL/Cable Modem

Figure 29: IP over SONET vs. IP over ATM (source: Cisco Systems, Inc.)

Cable/xDSL Access Mux OC-12 Variable Rate (up to OC-3) OC-12 OC-48

IP Backbone

Consideration of IP over SONET/SDH when a business model is IP-centric is essential. Packet over SONET in combination with giga bit routers leverages existing SONET/SDH technology and delivers simple and efficient bandwidth use, Layer 3 QoS, and scalability. However, carriers with a significant base of traditional circuit-switched services will still benefit from the unique ca pabilities of ATM, and can justify the "cell tax" for IP data services (at least until IP QoS technology is sufficiently mature to provide perfor mance equivalent to ATM).

Business Customers

Core Router

High-Capacity Access Router

Figure 30: The Wirespeed Router as the Cornerstone of the Backbone POP

WIRESPEED ROUTERS Traditionally, routing has been perfor med by software running on one or more microprocessors contained within a routing product. These so called software based routers were relatively slow and expensive. The new generation of routers perfor ms IP routing in specialized hardware, using shared memory or crossbar switching fabrics combined with routing in ASICs. This new breed of routers can route pa ckets at multigiga bit speeds, with low latency, to tens of millions of pa ckets per second. They support a wide range of WAN interfaces including T1/E1, T3/E3, OC3/STM-1, OC-12/STM-4 and OC-48/STM-16 directly over SONET/SDH or over ATM. They also

This new class of wirespeed routers changes many assumptions that organizations have been using to design their networks. No longer does routing need to be avoided due to the performance degradation it introduces. These ASIC-based wirespeed routers can forward IP at the sa me performance levels as Layer 2 switches.

Ericsson Inc. Data com Networks 77 South Bedford Street Burlington, MA 01803 www.ericsson.com/datacom