Ip Routers1

7/30/2019 Ip Routers1

1/20

The Technology of IP Routers inthe New Public Network

Ericsson IP InfrastructureJanuary 2000

Er i c s so n l

WHITE PAPER


2/20

2

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


3/20

3

This document outlines the underlying technologies

for Eri csson' s AXI 52 0 and AX I 54 0 I nternet r out ers.It starts with a basic introduction t o Int ern et r outi ngprotocols, and continues with a review of Multi-Pr ot ocol Label Switchin g (MPLS) t echn ol ogy and ashort comparison of traditional routing vs. labelswitching over ATM. The importance of trafficengi neerin g in t he Int ern et backbone is highlight ed,with a discussion of the use of MPLS for trafficengineering. Finally, two newer IP technologies areint rodu ced: IP Layer 3 QoS and IP overSONET/SDH . Both play an importa nt role in th enew generation of wirespeed gigabit routers andemerging public IP networks.

ROUTING BASICS

INTRODUCTION

According to the OSI reference model [see Figure 1below] , t he N etwork Layer (Layer 3) is concerned wit hgetting packets of user information from the source allth e way to th e destinat ion. Someti mes the NetworkLayer i s referr ed to as the internetworki ng layer.Int ern etw orkin g is the ability t o link di sparat enetwork technologies (e.g. Ethernet, Frame Relay, andATM) into a single extended network - an "Internet".

IP (Int ern et P rotocol) is th e int ern etworkin g, or t heLayer 3, protocol for the global interconnection ofnetworks known as the Internet.

G enerally, data that needs t o cr oss netw ork boundari esis transmitted through routers, and rout ingis theprocess of movin g informati on acr oss an int ern etwork(i.e. at Layer 3) from source to destination.

IP packets that need to cross network boundaries are

transmit ted t hrough I P routers. IP rout ingis theprocess of moving IP packets across the Internet fromsource to destination. An IP router is a device thatforwards IP packets (at Layer 3) by a full examinationof the IP packet header.

From this point on, we will call IP routers justrouters, and IP routing just routing.

ROUTING PROTOCOLS

Routing involves two basic activiti es: deter minati onof optimal routing paths and forwarding of

infor mati on pa ckets thr ough a n int ern etwork.

The forwardi ng of IP pa ckets is relativelystraightforward. H owever, det ermi nin g th e opti malrouting path can be very complex.

Routers within the Internet are organizedhierarchically. Some routers are used to forwardinformation through one particular group of networksunder the same administrative authority and control(called an A ut onomous System, or AS). These r out ers ar ecall ed int eri or r out ers, and th ey use a variety ofInteriorG at ew ay Pr otocol s(IGPs) to accomplish the

information exchange within the AS. Routers thatforward infor mati on between ASs ar e call ed ext eri orrouters, and they use Ex teri or G atew ay P rotocol s(EGPs)

to accomplish their function.

The need for both exterior andinterior routing protocols is drivenby the size of the Internet. Youneed both to control the scalabilityt o Int ern et di mensions.

N or mally, an Int ern et ServiceProvider is considered as one AS.

IP routing protocols are dynamic rout es are cal culat ed at regularintervals by routers and routerscommunicate with one another byexchanging r outi ng u pdates. Byanalyzing routing updates from all

routers, a router can build a detailed picture of thenetwork topology. This information is compiled andstor ed in a r outin g table [see Fi gure 2]. T he routi ngta ble consists of desti nati on addr ess/n ext hop pair s.

Layer 1

Layer 2

Layer 3

Layer 4

Layer 5

Layer 6

Layer 7 Application

Presentation

Session

Transport

Network

Data Link

Physical

End Node

Application

Presentation

Session

Transport

Network

Data Link

Physical

End Node

Router

Network

Data Link

Physical

Router

Network

Data Link

Physical

Figure 1: Internetworking


4/20

4

IP routing specifies that IP packets travel through theInternet one hop at the time. The entire route is notknown at that start of the journey. Instead, in eachrouter, the next destination is calculated by matchingth e destinati on address wit hin th e IP pa cket with t herouting table inth e r out er. IP routin g is descri bed as"connectionless1."

N ote that r outi ng ta bles can also contain oth erparameters, such as information about the desirabilityof 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 Int eri or Gat eway Protocols such as OSPF andIS-IS within their boundaries, and interconnect via anExterior Gateway Protocol, called the Border GatewayProtocol (BGP) [see Figure 3].

Both OSPF (Open Shortest Path First) and IS-IS(Int er mediat e Syst em-t o-I nter mediat e System) arecalled Link State protocols. OSPF was developed inth e lat e 198 0s by th e Int ern et Engin eerin g Task For ce(IETF), mainly for u se in t he Int ern et. IS-IS wasdeveloped by International Organization forStandardizati on (ISO). Alt hough IS-IS was cr eat ed t o

1 Compared to ATM switching which is connection-oriented. The argument

between connection-oriented and connecti on-l ess really has to do with where toput the complexity of retransmission of packets, (re)ordering of packets etc.. Inthe connection-oriented case, its in the network; in the connection-less case, itsin the end-stations (hosts). One of the major cornerstones of the Internet is tokeep the network as simple as possible.

rout e in ISO Connectionless N etwork Pr ot ocol

(CLNP) netw ork s, a version has been creat ed t osupport both CLNP and IP networks. T his version isusually referr ed t o as Int egrat ed IS-IS.

From a purely technical standpoint, IS-IS is quitesimilar to OSPF. Both are based on the short est pat hf irst algorithm, sometimes referred to as the D i j k st r a a lgor i thm, and both support routing hierarchies, type-of-service and authentication.

Although the Link State protocols have good routingscalability, they cannot by themselves provide a globalconnectivity solution for the whole Internet. EGP wasintroduced to control the expansion of routing and toprovide a more structured view of the Internet.Currently, BGP-4 is the de facto standard for exteriorrouting in the Internet.

IP Multicast

Today, most Internet applications use point-to-point, or uni cast traffic (i.e. traffic from one singl enetwork device to another). But as application

devel opers work t o deli ver the sa me data (such asaudio and video required for conferencing) to multipledevices conn ect ed t o a n etw ork, a noth er for m of tra fficis requir ed. The new form of traffic is cal led mult icasttraffic, and involves the tra nsmi ssion of a single IPpacket to multiple hosts. Multicast traffic requires anew class of routing protocols multicast protocols.Di stant Vect or M ulti cast R out in g Protocol (D VMRP)is an early multicast protocol used for building themulticast backbone across the Internet. ProtocolIndependent Multicast (PIM) is a more sophisticatedprotocol, standardized recently by the IETF. It has

DestinationAddress

Next Hop

127.10.0.0

142.56.10.0

34.5.156.0

176.113.1.0

54.32.42.12

54.32.42.12

54.32.42.12

54.32.42.10

54.32.42.10

54.32.42.10

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Figure 2: Routing Table

BGP

BGP

BGP

OSPF

IS- IS

I GP -- I nterior Gateway Protocol, OSPF or I S-I S

EGP -- Exteri or Gatew ay Protocol, BGP

Autonomous System

OSPF

Autonomous System Autonomous System

I

E

I

I

E

I

II

I

E

I -- Int er ior Router

E -- Exterior Router

Figure 3: I nterior and Ext eri or G ateway Protocols


5/20

5

two modes of behavior: dense mode and sparse mode.

In d ense mode, PIM i s optimi zed for t raffic int endedfor al most all hosts, whil e in sparse mode, PIM isopti mized for man y data str ea ms but ea ch data str ea mgoes to a relatively small number of hosts.

SCALING THE INTERNET

As previously ment ioned, t he Int ern et is a coll ecti onof ASs running Int eri or Gat eway Pr ot ocols, such asOSPF and IS-IS, within their boundaries andinterconnecting via an Exterior Gateway Protocol,call ed Border G at eway Protocol (BG P). Thi s is not,however, th e whol e pictur e.

BGP supports two types of exchanges of routinginfor mati on: exchan ges between different ASs andexchanges within a single AS. When used betweenASs, BGP is called External BGP (EBGP). When usedwithin a single AS, BGP is called Internal BGP(IBGP). BGP deployments are configured such thatall BGP routers within a single network must be fullymeshed so tha t any ext erna l routin g infor mat ion willbe redistribut ed t o all other routers within thatnetwork.

Figure 4 below illustrates a simple IBGP

configuration with three IBGP speakers (Routers A,B, and C). When Router A receives a route from anexternal neighbor, it must advertise it to both RouterB and C.

Router B and C do not re-advertise the IBGP learnedroute to other IBGP speakers because the routers donot pass routes learned from internal neighbors on toother int ernal n eigh bors, thus preventi ng a routinginfor mati on l oop. N ot e, t hat R out ers A, B and C do

not have to be directly connected to each other. They

are only logically fully meshed.

H owever, t his requir ement does not scal e when th er eare many IBGP routers. One way to reduce the IBGPmesh is to configure a route reflector.

Route Reflectors

Route reflection provides one means of decreasingBGP control traffic, minimizing the number ofupdate messages sent within the AS. In routereflection, BG P r out ers are arranged in clusters. Eachcluster consists of at least one router that acts as aroute reflector, along with any number of client peers.BGP peers outside the cluster are called non-clientpeers. T he rout e reflect or r eflect s (redistribu t es)routing information to each client peer and to all non-client peers. Because the route reflector redistributesroutes wit hin t he clust er, t he BGP routers wit hin th ecluster do not have to be fully meshed.

When the route reflector receives a route, it selects the

best path. Then, if the route ca me from a non-cli entpeer, the route reflector sends the route to all clientpeers wit hin t he clu ster. If the rout e ca me from aclient peer, the route reflector sends the route to allnon-client peers and to all client peers except theoriginator. In this process, none of the client peerssends routes to other client peers.

The route reflector concept is growing in popularity forlarge networks because it enables scalability without alot of overhead. Migrating from a non-route reflector toa route reflector design is easy since only the route

Autonomous System

EBGP

RC

I BGP

I BGP

RB

RA

I BGP

Figure 4: Ex ternal BGP and Internal BGP

Autonomous System

RB

RA

RC

RD

RE

Clients

Non-Clients

Route Reflector

Cluster

Physical ConnectionIBGP

Fi gure 5: R oute Ref l ector w it h C li ent & N on-C li ent P eers


6/20

6

reflectors need to be modified to behave as routereflectors; all others would be runnin g as usual.

Confederations

Confederations are another way to deal with theexpl osi on of an IBGP mesh wit hin a n AS.Confederati ons are based on th e concept tha t an AScan be broken into multiple sub-ASs. An IBGP fullmesh is used within the sub-ASs, and EBGP is usedbetw een t he sub-ASs, as well as between t heconfederati on i tself and th e out side ASs [ see Figure 6below].

ROUTING POLICY

All routing protocols store their routing informationin a common routing table. From the collectedrouti ng infor mat ion, th e r outi ng softwar e cal culat esthe best routes to each destination. These routes areused to forward traffic through the router, and may beadvertised to neighbors via one or more routingprotocols.

Routing policy allows you to control the routing

information that is transferred between the routingprotocols and the routing table. You can filter therouting information so that only some of it istra nsferr ed, and you can set pr opert ies associat ed withthe routes.

Routing poli cy allows you t o cont r ol (filt er) whi chroutes the routin g protocol imp ort s int o th e r outi ngtable and which routes a routing protocol can exportfrom the routing table. Routing policy also allows youto set the information associated with a route as it isbein g import ed or export ed by th e routin g table. Byapplyin g routing poli cy to rout es bein g import ed t o

th e r outi ng ta ble you contr ol t he rout es that t herouti ng pr ot ocol process uses in order t o det er mineactive routes. By applying routing policy to routesbeing exported from the routing table you control theroutes that a protocol advertises to its neighbors [seeFigure 8].

Routing policies are defined in the followingcircumstances:

! You do not want a routing protocol to transfer allits routes int o the routi ng tabl e. T hat is, you donot want t he routi ng ta ble to learn a bout certai nroutes.

! You do not want a routing protocol to receivefrom the routing table all the active routeslearned by that protocol.

! You want a routing protocol to receive activeroutes learned from another routing protocol.This is sometimes called route redistribution.

! You want to set the information associated with arout e, such as the prefer ence value, autonomoussystem path, or the BGP community.

Autonomous System

RA

RD

RE

Sub AS # 2Sub AS # 1

Physical ConnectionBGP peers

RB RC

EBGP

I BGPI BGPI BGP

I BGP

Figure 6: Confederations

Routing Table

BGP OSPF I S-I S

Import

Export

Import

Export

Import

Export

Fi gure 7: Import i ng and Ex port i ng Routes

Protocol

RoutesRoutes

ProtocolRoutingTable

Import Policy Export Policy

NetworkNeighbors

NetworkNeighbors

NetworkNeighbors

NetworkNeighbors

ForwardingTable

Packet s I n Packet s Out

Figure 8: Importing and Exporting Routing Policies


7/20

7

In Fi gure 9 bel ow, for exa mple, a large ISP provid esInt ern et a ccess to a second- tier ISP t hat advert isesseveral hundred routes into the large ISP. The largeISP configur es policy rul es so tha t i t accepts only theroutes that it expects to receive from the smaller ISP.When the smaller ISP gets a new customer, it informsthe large ISP that it will be forwarding an additionalset of rout es. Th e large ISP upda tes th e list of rout esthat it will accept from the smaller ISP by modifyingits routing policy filtering rules.

The control provided by the routing policies is strategicto backbone networks because it is the fundamentaltool that controls how the networks are used. Routingpolicies det er mine th e paths select ed across the Int ern etand can play a role in the path selected across the

Service Pr ovider's n etwork.

DESIGNING STABLE INTERNETS

One major problem that has caused poor Internetservice is so-cal led route flapping. The str ea m ofrouting updates received by all backbone routerscauses route flapping. Effectively, every transitionbetw een opera ti onal and n on-opera ti onal stat es ofnetwork equipment affecting connectivity of someglobally visible network generates waves of updatemessages r olli ng over all backbone n etwork s. Fact orsthat a ffect route instabiliti es on th e Int ern et includehardware failures, link failures, software problems,network upgrades, instabilities of IGPs and humanerror.

Because the Internet is so large, theaverage rate of updates is relatively high(100-200 updates a second). Handling ofrouting updates is very computationallyintensive, because every new updaterequires mat chin g against routin gpolicies, which could be several thousands

of rules for a border router of a large ISP. Some levelof route flap is unavoidable, since routing updatescarr y vita l infor mat ion about chan ges in n etworkt opol ogy. H owever, excessive l evels of rout e flap areextr emely da ngerous, and rout ers (parti cularly old er

software-based routers) die under the burden ofdoing route updating.

There are two methods of reducing damaging routeflap: route aggregation and flap dampening byholding off introduction of routing updates ofunstable routes.

Route aggregation is the more powerful tool, as itlimits visibility of details of topology, so the routingupdat es generat ed by topologi cal chan ges of localsignificance do not reach backbone networks. Theother mechanism, route flap dampening, categorizes

routes as either well behaved or ill behaved. Therecent history of a route is used as a basis foresti mati ng futur e stabilit y. U nder r out e flapdampening, each time a route flaps, it is given apenalt y. W henever t he penalty rea ches a pr edefinedthreshold, the route is suppressed.

Small I SP Large I SP The I nt ernet

Policy Filter s

Tens/Hundreds of Routes

Corp Customer

Corp Customer

Dial-In Users

Figure 9: Policy Filt erin g

Network B

Network C

Network A

Network D

FLAP SOURCE

Figure 10: R oute Flaps Rolli ng Over All Backbone N etwork


8/20

8

It must be noted that the route flap phenomenon is

not unique to IP. Since route flap is caused bypropagation of information about topological changes,any networking technology that incorporates dynamicadaptive routing (e.g. PNNI) will have to deal withroute flap.

TRAFFIC PATTERNS ARE CHANGING

In the past, network architects have commonly usedthe rule that 80% of the traffic will stay local in thenetwork, while only 20% of the traffic will flowbetw een n etworks. Traffic pat t erns have now shifted,revising the 80/20 rule to 20/80, with 20% intra-

network traffic and 80% inter-network traffic [seeFigure 11 below].

Consider an exa mple. Assume th er e are four to fivemaj or backbone provid ers in th e US. And ea ch haveeach have roughly the same number ofcustomers/subscri bers (i.e. they ea ch carry 20-2 5% ofth e t otal backbone traffic). That mean s tha t 75-80 %of the traffic will leave, and 20-25% will stay in theirnetworks. This is true for each one of the backboneprovides in thi s example, and i s even mor epronoun ced for small regional and l ocal ISPs.

THE NEW KIDS ON THE BLOCK

The Internet is growing, and it is growing VERY fast.Internet backbones grow much faster thanconventi onal r outi ng t echn ology d oes. The reason forthat is that progress of conventional routingtechnology depends on the progress in speed ofmi cr oprocessors, whi ch foll ows M oor es Law, i. e.doubling every two years. At the same time, Internettraffic is doubling every 6 to 7 months.

Data communi cati on and t elecommuni cati on ismer gin g. W e will see a dra matic in cr ease of voice andvideo in addition to best-effort data traffic on theInternet in coming years.

Changes in the local loop require changes in thebackbone. W e ar e seein g a two ord ers-of-ma gnit ude

improvement in residential access rates (28.8K to2Mbps) through xDSL, Cable Modems, FixedWir eless (LMDS) and FTT C, and i n business accessrates (1.5M bps to 155 Mbps) t hrough metr opolita narea fiber infrastructure (fiber-to-the-business). Thesechanges in the local loop put even more pressure onthe Internet backbone.

The Internet is suffering from severe growing pains,and routing is one of the major bottlenecks. But it isnot routing that is slow - it's today's generation ofsoftware-based routers. ISPs are deploying a newgeneration of wirespeed routers to accommodate

customer demands.

H owever, ISPs buildin g new public IP n etwork s needmore tha n just speed. T oday's IP network s useconventional routing protocols to manage the networktopology, and can be difficult to optimize. Today'snetworks also have little ability to deliver Quality ofService (QoS) t o real- ti me servi ces such as voice. IPalone doesnt solve these pr obl ems - but l et' s exa minesome new developments in the IETF that addressth ese issues and bring.

80%Workgroup

20%

20%

80%Backbone

Figure 11: Traffic Patt ern C hange

Internet

Bandwidth

Router

CPU Speed

time

Gbps/MHz

Figure 12: Internet Bandwidth vs. Conventional Router Speed


9/20

9

MULTI PROTOCOL LABEL SWITCHING (MPLS)

MPLS is an optimized switching technology for IPnetworks, and can run within ATM or Frame Relaynetw ork s, as well as over P PP frames on poin t-t o-poin t lines. The basic id ea of MPLS is to pr epend IPpackets with a Layer 2 r outi ng la bel at th e edg e of an"MPLS cloud", and t o perform a ll forwardi ng wit hinthe cloud based only on the label value.

The key feature provided by MPLS is the ability toprovide labelswit ched pat hs (LSPs), which are si milarto PVCs in ATM and Frame Relay networks. An LSPis cr eated by concat enat ion of one or mor e label

switched h ops, all owing a packet t o be forward edfrom one Label Swit ching Rout er (LSR) t o an oth erLSR across an ISP n etw ork [ see Fi gure 13] . An LSR isa router that support s MPLS. Th e i mporta nt pointhere is that the path of the LSP is not limited to whatthe IGP would choose as the shortest path to reach thedestination IP address.

An LSR that receives an IP packet can choose toforward i t al ong a n LSP by wrapping an MPLS head eraround the packet and forward it to another LSR. The

labeled packet will be forward ed along th e LSP byeach LSR until it reaches the end of the LSP, at whichtime the MPLS header will be removed and the packetwill be forward ed based on Layer 3 i nfor mat i on likethe IP destination address.

MPLS Forwarding Process

The forwarding process of each LSR is based on theconcept of label swapping. T he labels are bound to

IP prefixes and ar e link- local. W hen a packet

conta ining a la bel arr ives at an LSR, th e LSR examin esthe label and uses it as an index into its forwardingtable [see Figure 14 below]. Each entry in theforwarding table contains an inbound label that ismapped to a set of forwarding information applied toall packets that carry the same inbound label.

MPLS may make direct use of underlying Layer 2forwardi ng - for exampl e ATM or Fra me Relayswit chin g - by usin g th e Virt ual Circuit field in th eATM/Frame Relay packets to carry the MPLS label.Alt erna tively, it may use a label "shim" insert ed inPPP or Ethernet packets.

It should be noted that MPLS forwarding proceduresare similar to those of traditional Layer 2 "labelswapping" devices, such as ATM swit ches. AT Mswit ches use th e input port an d t he incomin gVPI/ VCI value as the index int o a "cr oss-connect"table, from which th ey obtain an out put port a nd anout goin g VPI/ VCI valu e. Ther efor e if one or mor elabels can be encoded directly into the fields that areaccessed by these legacy switches, then the legacyswitches can, with suitable software upgrades, be usedas LSRs. W e will refer t o such d evices as "ATM-

LSRs".

MPLS Scalability

MPLS scalability is provided by two of the principlesof routing. The first is that forwarding follows aninverted tree rooted at a destination. The second isthat the concept of aggregation or hierarchies.

138.39/ 16

Traffic to138.39/16

IPs shortest path

LSP path

Fi gure 13 : L abel Switched P aths (L SPs)

InboundInterface

InboundLabel

OutboundI nterface

OutboundLabel

2 25 5 185

2 256 3 735

. . . .

. . . .

. . . .

F i gu re 14 : M PL S F orward ing T ab le


10/20

10

LSPs with a singl e exit poin t sharing a common

internal path can be merged to for m a multi point -t o-point tree. For an LSR, the merge operation isstraightforward: both incoming LSPs will perform astandard label switching operation, but will result inthe same outbound label.

N ot e that for an ATM-LSR, th e mer geoperation is less straightforward. In ATM, ifone attempts to perform merging, the resultmay be the interleaving2 of cells from variouspackets within a single VC. W hen t hishappens, it is impossible to reassemble thepackets later.

2 In ATM, the data packets are encapsulated into an ATM Adaptati on Layer, say

AAL5, and the AAL5 PDU is segmented into ATM cells with a VPI/VCI valueand th e cells are transmit ted in sequence. H ence, if cells from several upst rea mlinks are transmitt ed onto the same downstream VPI/VCI, then cells from onePDU can get interleaved with cells from another PDU on the outgoingVPI/VCI, and result in corruption of the original PDUs by mis-sequencing thecells of each PDU.

Mer ging th er efore requir es capabili ti es (i.e.

mult ipoint- t o- point conn ecti vit y) whi ch ar e notalways availabl e in ATM forwardi ng har dware. I nthose cases, where the ATM-LSR switch does notsupport merging, a full mesh connection approach hasto be deployed, i.e. point-to-point LSPs between allingress nodes to all the egress nodes in the MPLS

network. For small networksthe full mesh connectionapproach may suffice and notpose any scalability problems.H owever, in lar ge ent er prisebackbone or ISP netw orks,this will not scale well.

The second feature MPLS usesto scale networks isaggregat i on or hierarchies.

LSPs can be aggregated with other LSPs by adding anew label to the stack of labels for each LSP,effectively bundling the LSPs into a single tunnel.Two or mor e LSPs can be aggregated if they share aportion of their path. These aggregated LSPs can be

t er minated at any poin t, r esulting i n de-a ggr egati onof traffic. The label stack mechanism allows LSPtu nneling t o nest t o any dept h.

IPPacket

AAL5PDU

ATM-LSR

Fi gure 16 : Cel l In ter l eav ing in an A T M Swi tch

138.39/16

Traffic to38.39/16

Traffic to138.39/16

Traffic to138.39/16

138.39/16

Traffic to138.39/16

Traffic to138.39/16

Traffic to

138.39/16

Fi gure 15 : Tr af f ic M erging

138.39/16

127.41/16

208.14/16

Traffic to138.39/16

Traffic to127.41/16

Traffic to208.14/16

Fi gure 17 : T raf f i c A ggregat ion in an M PL S Network


11/20

11

One useful application of this technique is in VirtualPri vat e N etworks.

ROUTING VS. MPLS

One of the claims made for label switching is that itoffers advantages over more conventional routing

techniques -- that label switching would offeri mproved performan ce and do so at a lower cost t hatconventi onal appr oaches. Is this accurat e?

Recall that IP forwarding is based on a longest-matchlookup, while MPLS is based on an exact matchlookup (i.e. the same type of lookup as ATM). It hashistorically been fact that ATM switches couldperform faster fixed-length lookups in hardware andthat routers could perform longest-match lookups insoftware. H owever, recent advan ces in sili cont echn ology allow ASIC- based r out e looku p engin es torun a s fast as ATM VPI/VCI l ooku p engin es. Becau se

rout ers n ow can forward pa ckets at li ne rate/wir espeed(just like an ATM swit ch can f orward cell s),forwarding perfor mance is no longer an issue.

The cost an gle is harder to figur es out becau sevendors list prices are not necessarily a directindication of cost. Label switching only reduces thecost of the IP address lookup and forwarding decision.Even if thi s could be driven to zero, t he impact on t hecost of the whole system remains modest. This isbecause there are many other costs in building adevice tha t can forward packet s at many gigabit per

second, such as the cost of the

switchin g fabric itself, and t he cost ofbuffering.

Arguments about price andperfor man ce in la bel switching versusconventional routing are not veryrelevant. It will be hard to justify labelswit ching from a perfor mance or coststandpoint alone. The true benefit ofMPLS is the increased traffic-engineering capabilities that it offers toconventional routing.

TRAFFIC ENGINEERING

BACKGROUND

On ce the physical n etwork top ol ogy exists, th e task ofmapping traffic onto that topology must be tackled.In the past, mapping traffic onto a physical topologywas not appr oached in a part i cularly sci ent ific way.Instead, the mapping simply took place as a by-

produ ct of routi ng configurati ons. Th e weak nesses inthis haphazard mapping were often resolved by simplyover-provisioning bandwidth. As ISP networks growlarger, as the circuits supporting IP grow faster, andas the demands of customers become gr eat er, t hemap ping of traffic ont o physical t opol ogi es needs tobe approached in a fundamentally different way. Theoffer ed l oad must be supp ort ed in a cont roll ed wayand in an efficient manner. This mapping of trafficonto a physical topology is called tr aff i c engineeri ng.

Evolution of Internet Backbone Traffic Control

In the early 1990s when ISPs networks wereconstr ucted over T 1/E1 (1.5-2 M bps) and T 3/E3 (32-45 Mbps) links, traffic control was achieved bymanipulating routing metrics. Metric-based controlwas adequate because Internet backbones were muchsmaller than t oday in t er ms of the nu mber of rout ers,the number of links, and the amount of traffic.

138.39/16

127.41/16

208.14/16

Traffic to

138.39/16

Traffic to127.41/16

Traffic to208.14/16

Fi gure 18 : A ggregated L SP i n an M PL S N etwork


12/20

12

ISPs Decide Between a Routed Core and an

ATM CoreAround 1994 or 1995, the load on ISP networks wasincreasing to the point where they simply had to gofaster than T 3. At th e time, OC-3/STM-1 int erfaces(155 Mbps) were available only on ATM switches;they were not yet available on router platforms. TheISPs had t o mak e a d ecision whether t hey wer e goin gto continue with a routed core or migrate to an ATMcore. Each ISP chartered their future course based onanswers to a few questions:

" Did the ISP have enough faith in the ability of theirtraditional router vendor(s) to rapidly deliver OC-3/STM-1 and OC-12/STM-4 interfaces for theirproducts?

" Did the ISP consider the lack of bandwidth asignificant threat to their business that requiredimmediate resolution, even if the solution meant aserious overhaul to the core of their network?

As we will see, the ISPs that chose to migrate to anATM core thrived and continued to experiencegrowth. Meanwhile, the ISPs that remained with atraditional router core had greater challenges to growbecause of th e la te delivery and poor perfor mance ofOC-3/STM-1 SONET/SDH int erfaces for rout ers. In

th e next several secti ons, we'll discuss th e advanta gesand disadvantages of each of these choices.

Metric-Based Traffic Control in a Routed Core

As discussed earlier, routing metric manipulationprovided a basic tool for traffic control in the early1990 s. H owever, as the magnit ud e and intri cacy ofcarr ier n etwork s increased, metr i c-based t raffic cont r olbeca me mor e and mor e compli cat ed, t o th e poin twhere it was si mply not a viable opti on. N etw orkadministrators could still adjust link metrics to avoidcongestion, but it became more difficult to ensure

tha t a metr ic adjust ment in one par t of an enor mousnetwork didn't create a new problem in another partof the network.

Absence of "Traffic Engineering" across aRouted Core

If the only method of traffic control is to manipulateIGP metr i cs, it is possible for some of a network' slinks to be lightly used and other links heavilycongested. This state is not cost-effective for the ISP

because all trunks cost money even if they are

underutilized.

There ar e several potential paths betw een t he SanFrancisco P OP and t he Washingt on, DC P OP.Assume that the "shortest path" selected by therouting protocol for traffic between San Francisco andWa shin gton, DC is th e SF-to-Chicago-to-DC r out e[see Fi gure 19 a bove] . Also assume t hat th er e is alarge amount of traffic goin g from San Fran cisco toChica go and a lso a large a moun t of tra ffic going fr omChicago to Washington, DC. The result of this is thatthe traffic from San Francisco to Washington, DC hasto compete against both the San Francisco-to-Chicago

and Chi ca go-t o-W ashingt on, D C t raffic.

H owever, if th e net work is only ca pable of selecti nglinks based on the IGP metrics, situations like thiswill occur often. Reliance on IGP metrics createspaths that become traffic magnets. The result iscongestion and poor performan ce that does not exploitthe economies of the bandwidth provisioned across theentire WAN.

Advantages and Disadvantages of a RoutedCoreThere are a number of benefits gained by remaining

with a routed core when compared to migrating to anATM-based core:

" In a routed core, the physical topology and thelogical topology are identical. This eliminates the "n-squared" problem associated with ATM networks.This "n-squared" problem, discussed in the nextsection, is manifest in the complexity of adding newedge nodes and the stress that a full-mesh topologyplaces on routing protocols.

SanFrancisco

Salt Lake

ChicagoDetroit

New York

Washington D.C.

Atlanta

New Orleans

Dallas

Denver

Phoenix

I GP shortest p ath rou te S.F. to D.C.

Fi gure 19 : I G P Shortest P ath between SF and D C


13/20

13

" Th ere is no "cell tax" in a rout ed core. If you assume20% overhead for ATM when factoring in framingand realistic distribution of packets sizes, this meansthat on a 155-Mbps OC-3 link, 124 Mbps isavailable for data while 31Mbps is consumed by theATM overh ead. H owever, if you consider a2.488-G bps OC-48 link, 1.990 G bps isavailable for data and 498 Mbps is requiredfor the ATM overhead (almost a full OC-12!). The lack of a cell tax in a rout ed coremeans that the available bandwidth is usedmuch more efficiently.

" Routed cores, by virtue of theirconnectionless operation, are more resilient infailure modes. In an ATM circuit-basednetwork, backup Permanent Virtual Circuits(PVCs) must be designed and installed in theswitches before a failure occurs. Because failures havethe potential of occurring at any point in a network,it is extremely difficult to design secondary PVCsthat can provide the same degree of resiliency as IProuting inherently provides.

Despite these advantages, traditional routed coreshave a few significant disadvantages:

" In a routed core, the traffic load is not equallydistributed across the network's links, causinginefficient use of network resources. Some of thelinks can become congested, while other linksremain underutilized. This may be satisfactory in asparsely connected network, but in a richly-connected network it is necessary to control the pathsthat traffic takes in order to load the links relativelyequally.

" Metric-based traffic control does not offer anadequat e soluti on for traffic engineering. As ISPnetworks become more richly connected, it isdifficult t o ensure that a metric adjust ment in one

part of the network doesn't cause problems inanother part of the network.

PVC-Based Traffic Control in an ATM Core

When IP runs over an ATM network, routers circlethe edge of the ATM cloud. Each routercommunicates with every other router by a set ofPVCs configured acr oss the ATM physical topol ogy.The rout ers d o not have direct a ccess to informat ionconcerning the physical topology of the underlyingnetwork; they have knowledge only of theindividual PVCs that appear t o them as si mple

point-to-point circuits between two routers. Figure 20

below illustrates how the physical topology across theATM core differs from the logical topology across theATM core.

Traffic Engineering Across an ATM CoreFor an ISP with an ATM core, the paths that thePVCs take through the network are typicallycal culat ed by an off-line configurati on ut ili ty. SomeATM switch vendors offer proprietary techniques forrouting PVCs on-line while taking some trafficengin eeri ng concern s in to account. H owever, t hesefeatures are immature, and an ISP frequently has toresort to full off-line path calculation. After the PVC

mesh has been calculated, the supportingconfigurations are downloaded into the routers andthe ATM switches to implement the full-mesh logicaltopology.

For some ISPs, each router not only participates in afull mesh of PVCs with the other routers, but alsoparticipates in a full-mesh of backup PVCs with everyoth er rout er. Figur e 21 Bel ow depicts the logi caltopology for an ISP network with an ATM core. [Notethat only the primary PVCs are illustrated, not thesecondary PVCs].

S

S

S

S

S

R

RR

PVC # 1

PVC # 2PVC # 3

Physical Topology

R

R

Logical Topology

F i gure 2 0: P hysi cal vs. L ogical T opology

Router

Rout er Rout er

Router

RouterATM

Core

London

Oslo

F

Stockholm

Paris

Fi gure 21 : Ful l M esh of PV Cs in an A T M N etwork


14/20

14

ATM PVCs provide a tool for supporting precision

traffic engineering. The ISP determines the path forthe PVCs based on measured traffic patterns so thattraffic flows are distributed across different physicallinks. Each PVC is provisioned so that it is able toaccommodate the anticipated load. As the network'straffic matrix evolves over time, the underlyingphysical path supporting a particular PVC can bemodifi ed t o accommodat e shifting t raffic loads acrossthe physical links.

After the PVCs are installed in the switchedinfrastructure, they are merged into the IP network byrunning IGP across each PVC. Between any two

routers, the IGP metric for the primary PVC is setsuch that it is more preferred than the backup PVC.This guarantees that the backup PVC is used onlywhen t he pri mary PVC is not a vailable.

The "N-Squared" Problem over ATM CoresOne of ATM's limitations is that it requires a full-mesh overlay of PVCs to provide Layer 3 connectivity.This full- mesh of PVCs is the source of th e "n-squared" problem. The "n-squared" effect makes itlaborious to add new routers to the network andplaces excessive stress on routing protocols.

Figure 22 below illustrates the "n-squared" problem by the requirement to increase the number of PVCswhen a new router is added to the network. Forexample, when growing the network from five to sixrouters, the ISP is required to increase the number ofPVCs from 20 to 30. The addition of a single newrouter requires ten additional PVCs. The new PVCsneed to be positioned across the physical topology sothat they have minimal impact on the existing PVCs.The task of adding a new router becomes even morechallenging when the number of routers increasesfrom 50 t o 51. T his requir es the additi on of 100 newPVCs.

The "n-squar ed" problem also manifests it self in t he

stress that a full-mesh of PVCs places on routingprotocols. Routing with a full-mesh of PVCs worksover small er n etwork s. H owever, wi th lar ge netw ork sthere are significant scaling problems. The flooding ofLSPs becomes inefficient; each router has too manyadjacencies with logical neighbors, and the Dijkstracalculation becomes inefficient because of the largenumber of logical links.

Advantages and Disadvantages of an ATMCoreDespite the "n-squared" problem, there are a numberof advanta ges t o depl oyin g an ATM-based cor e in a n

ISP network:

" An ATM-based core fully supports trafficengin eerin g via PVC configuration, permit tin g theISP to precisely distribute traffic across all of theirlinks so that the trunks are evenly used. Thiseli minates the traffic magnet effect of least-costrouting, which creates over-utilized andunderutilized links. Traffic engineering makes theISP more competitive within its market, allowinglower costs and better service to its customers.

" In an ATM-based core, the per-PVC statisticsprovided by the switches facilitate the monitoring of

traffic patterns.

" N etwork designers provision each PVC to supportspecific traffic-engineering objecti ves. T heyconstantly monitor traffic on the PVCs. If a givenPVC begins to experience congestion, the ISP has allth e infor mation it needs to remedy the situati on.

Yet despite the significant advantage of supportingtraffic engineering, ATM-based cores still have anu mber of substantial li mitat ions:

" The full-mesh of ATM PVCs exhibits the "n-squared" problem.

" The ATM cell tax can consume a significant amountof bandwidth. As discussed earlier, the cell tax on anOC-48 can be as much as a full OC-12. Theelimination of the cell tax in a routed core means thatbandwidth is used as efficiently as possible and notwasted on unnecessary overhead.

" ATM-based cores, by virtue of their connection-ori ent ed operation, are less resilient in failure modes.In a routed core, alternate paths are calculated ondemand whenever a link or peer fails. In an ATM-based core, backup paths have to be calculated in

5 Border Rout ers

5(4) = 20

6 Border Rout ers

6(5) = 30

Fi gure 22 : T he "n-squared" P roblem


15/20

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 alogical IP overlay. The task of managing any givennetwork has a specific amount of associat ed cost. Byrunning an IP network over an ATM network, anISP doubles its overhead because it needs to managetwo separate networks.

" Routing and traffic engineering occur on differentsets of boxes (that is, routing happens on the routersand traffic engineering happens on the ATMswitches). As a result, there are two configura tion

processes to design, operat e, and debug.

Traditional Router Cores vs. ATM Cores

Back in 1994, ISPs were simply looking to obtainmore bandwidth so they could handle increasingamounts of network traffic. ISPs that decided topursue an ATM-based core quickly discovered thatthe ATM core provided them with two criticalfeatures: the ability to perform traffic engineering toequalize th e traffic loads across th e network, and per-PVC statistics to count traffic. ISPs have become verycomfortable with the level of control that ATM-based

cores provide when compared to traditional routedcor es. Today, ISPs are not willin g to give up t hecontrol that ATM provides. Despite the numerouslimitation of ATM (i.e., the cell tax, the "n-squared"problem, and the cost of managing two separatenetworks), ISPs understand that they require traffic-engineering capabilities similar to ATM in order tosuccessfully run t heir n et works.

The following table provides a summary of thebenefits and limitations of traditional routed cores andATM-based cores. As we enter the age of the opticalInternet, any emerging traffic engineering solution

must combine th e advanta ges of rout ed cor es andATM-based cores while eliminating theirdisadvantages.

Advantages Disadvantages

TraditionalRouter Cores

Physical topologymatches logical topology

N o n-squared problem

N o cell tax

Resilient i n failure modes

Underutilized l inks

Overutilized links

Engineering byrouting metrics iscomplex

ATM Cores Traffic Engineerin gsupported through PVCconfiguration

Per-PVC statistics

monitor traffic patternsand provide feedback totraffic engineering

ATM cell tax

Full mesh of ATMPVCs;n-squared problem

Less resilient in failumodes

Requir es managemeof two separatenetworks

Multiprotocol Label Switching (MPLS) provides thesolution to support traffic engineering in large serviceprovider networks. It combines the advantages ofrouter-based and ATM-based cores, while eliminatingthe disadvantages. A few of the benefits offered by

MPLS include: Ability to precisely control the use of valuable

resources during periods of rapid gr owth

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 thenetwork's border routers. In the context of trafficengineering, the border routers are called the ingressand egress points to and from the network. Trafficengineering is accomplished with MPLS byesta blishing LSPs between ingress poin ts and egr esspoints [see Figure 23 on the following page].


16/20

16

Recall that the essence of traffic engineering ismapping traffic onto a physical topology. This meanstha t the crux of th e issue is det er minin g th e pat h forLSPs. Ericsson' s impl ementati on of MPLS in it sInternet routers supports a number of different wayst o rout e an LSP:

" Calculate the full path for th e LSP off-line andstatically configure all LSRs in the LSP with thenecessary forwarding stat e. T his is analogous to how

some ISPs are currently using ATM.

" Calculate the full path for th e LSP off-line andstatically configure the head-end LSR with the fullpath. The head-end LSR then uses the ResourceReservation Setup Protocol (RSVP) as a dynamicsignaling protocol to install forwarding state in eachLSR. Note that RSVP is being used only to installthe forwarding state, and it does not reservebandwidth or provide any assurance of minimaldelay or jit ter (i. e. no quali ty-of-service guarantees).

" Calculate a partial path for the LSP off-line andstatically configure the head-end LSR with a subsetof the LSRs in the path. The partial path that isspecified can include any combination of strict andloose rout es. For example, imagine an ISP has atopology that includes two east-west paths across thecount ry: one in the nort h through Chicago and onein the south thr ough Dallas. N ow imagine that theISP wants to establish an LSP between a router inN ew York and a rout er in San Francisco. T he ISPcould configure the partial path for the LSP toinclude a single loose-r out ed hop of an LSR in Dallasand the result is that the LSP will be routed alongthe southern path. The head-end LSR uses RSVP to

install the forwarding state along the LSP just as

above." Configure the head- end LSR with just t he

identification of the tail end LSR. In this case,normal IP routi ng is used to deter mine th e path ofthe LSP. This configuration doesn't provide anyvalue in terms of traffic engineering, though theconfiguration is easy and it might be useful insituations where services like Virtual PrivateN etworks (VPNs) are needed.

In all these cases, any number of LSPs can be specifiedas backups for the primary LSP. If a circuit on whichth e primary LSP is rout ed fails, th e head-end LSR willnotice because it will stop hearing RSVP messagesfrom the remote end. If this happens, the head-endLSR can call on RSVP to create forwarding state forone of the backup LSPs.

MPLS Benefits

Previously, it was suggested that any emergingsolution providing traffic engineering across theoptical Internet must combine the advantages of ATMand routed cores while eliminating the disadvantages.Let's conclud e by exa mining how well MPLS meetsthi s chall enge.

" An MPLS core fully supports traffic engineering viaLSP configurati on. This per mits the ISP t o preciselydistribute traffic across all of their links so the trunksare evenly used, or important traffic goes over themost reliable links.

" In an MPLS core, the per-LSP statistics reported bythe LSRs provid e exactly the type of informationrequired for configuring new traffic engineeringpaths and also for deploying new physical topologies.

" In an MPLS core, the physical topology and thelogical topology are identical. This eliminates the "n-

squared" problem associated with ATM networks.

" The lack of a cell tax in an MPLS core means that theprovisioned bandwidth is used much more efficientlythan in an ATM core.

" An MPLS core converges the Layer 2 and Layer 3networks required in an ATM-based core. Themanagement of a single network reduces costs, andpermits routin g and traffic engin eering t o occur onth e same platfor m. This simplifies the design,configurati on, operati on, and debugging of th e entir enetwork.

EgressLSR

LSR

LSR

LSR

LSR

LSRLSR

LSR

I ngressLSR

LSP bet w een I ngr ess LSR and Egress LSR

F i gure 23 : L SP betw een I ngress L SR an d E gress L SR


17/20

17

" MPLS support for a dynamic protocol, such as RSVP,simplifies the deployment of traffic engineered LSPsacross th e network.

" MPLS provides the foundation for ISPs to offer value-added services.

" Future MPLS support for constraint-based routingachieves th e sa me contr ol as more-manual trafficengin eerin g but with less human interventionbecause the network itself participates in LSPcalculation.

" Both IP- over-ATM networks and pure IP r out ernetworks can evolve into IP/MPLS networks, sinceMPLS is supported over ATM and point-to-point IP.

MPLS is strategically significant for traffic engineeringbecause it can provide most of the functionalityavailable from the overlay model in an integrated andscalable manner and at lower cost than competingalternatives.

IP LAYER 3 QOS

BACKGROUND

A netw ork servi ce is a cont ract between a networkprovid er and it s customer, outl inin g th echara ct eri stics and behavior of n etw ork conn ecti vityoffered by the provider to the customer. A ServiceLevel Agreement (SLA) may specify different aspectsof network behavior, such as constraints on the typeand amount of data that can be sent on the network,and t he performan ce aspects of commun icat ion. T heSLA would t ypically also in clude a billing scenari o aswell as th e performan ce aspect s expected wit h t heassociated contract.

Traditionally, network providers have tended to

provide all of their customers with the same type ofperfor mance (a best-effort servi ce). H owever, withincreasing competition among network providers,there is a need to offer different types or grades ofperformance to customers, with network providersoffering bett er performan ce to cust omers who ar ewilling to pay more.

In order to provide the notion of differentiatedservices, the network provider needs to be able tocategorize traffic entering its network into multiplecat egori es or classes of service. Th e nu mber of classes

of servi ce must, in the immortal words of Mike

O'Dell

3

, be "more than three, less than nine, andprobably a power of two."

ARCHITECTURE

Th e IETF Differentia t ed Servi ces archit ectur e is basedon a si mple model wher e traffic ent ering a netw ork i sconditioned at the edges of the network, and assignedto different behavior aggregates or class of service. Thearchitecture achieves scalability by implementingcomplex conditioning functions only at network edgenodes, and by applying per-hop behaviors toaggregates of traffic which have been appropriately

marked using the DS field in the IP header.

Traffic Conditioning

A traffic condi ti oner may conta in t he foll owingelements: classifier, meter, marker, and shaper [see Figure24 bel ow]. T he classifier and the meter select thepackets within a traffic stream4 and measure thestrea m against a traffic pr ofile. T he mark er and shaperperfor m cont r ol actions on th e pa ckets dependi ng onwheth er t he traffic strea m is within i ts associat edprofile.

A packet st rea m normally passes to a classifier first,and then a meter measures matched packets againstthe profile as defined in the SLA. The packets withinthe profile may leave the traffic conditioner or may bemarked by the marker. The packets that are out-of-profile may be either marked or shaped according tothe rules specified in the SLA.

3 Mike O'D ell is responsible for overall network architecture and t echnical

strategic direction for UUNET.4 A traffic stream is an administratively significant set of one or more application-

to-application flows.

Classifier

Marker

Shaper

Meter

Packets

Traffic Conditi oner

Fi gure 24 : T raff ic Condit i oner


18/20

18

Scheduling

A per-h op behavior i s defined as the forwardingbehavior a packet receives at a given network node.Per-hop behaviors are implemented in nodes by queuemanagement and packet scheduling mechanisms [seeFigure 25 below].

W eight ed Fair Queuing (WF Q) provides bandwidthallocation and delay bounds to traffic by segregatingthe traffic into a number of queues, and then servesth ese qu eues in a non first-in/first-out fashion,where an assigned weight per queue is consid er ed [ seeFigure 26]. The weight represents how much thequ eue is serviced by the schedul er, compar ed t o the

other queues. If a queue is empty, the other queueswill be given a share of the total available capacityaccording to their respective weights. WFQ ensuresthat queues do not starve of bandwidth, and thattraffic gets predictable service.

Congestion Control

A congestion-handling scheme is also needed toensure that higher value traffic receives preferentialtreatment during congestion situations and as lowervalu e traffic is discarded earli er and, potentia lly, moreaggressively.

Random Early Detection (RED) is a congestionavoidance mechani sm. Inst ead of waitin g for t hequeues to fill and then drop all incoming packets (taildrop), congestion control intelligence monitors theaverage queue size and performs early discard onrandomly selected packets. Rather then drop allarriving packets, packets are dropped with a low, butincreasing probable, risk instead of waiting until thequeue is full. Of course, RED is only a solution forcongested nodes/links and not a solu ti on foroverl oad ed network s.

In addition, RED statistically drops more packetsfrom large users than small. Therefore, traffic sourcesthat generate the most traffic are more likely to beslowed down than traffic sources that generate littletraffic.

W ei ght ed RED (W RED) generally drops packetsselectively based on IP precedence (or DiffServ labelvalue). WRED provides separate thresholds andweights for different IP precedence, allowing you toprovide different qualities of service for differenttraffic. Standard traffic may be dr opped more

frequently than premium traffic during periods ofcongestion. WRED is usually used in the core routersof a network, rather than the edge. Edge routersassign IP precedence t o packets as they ent er t henetw ork. W RED uses thi s precedence t o det er minehow the core treats different types of traffic.

An enhancement to RED, is the consideration ofIn/Out of profile marking of packets called RandomEarly D et ecti on In/ Out (RIO). RI O is in principl etw o RED algorit h ms operatin g at t he sa me ti me, onefor packets marked In-profile and one for packets

queues

congestion

handling

packets outpackets in

scheduling

Figure 25: Scheduling of Packets

queues

packets outpackets in

weighted

scheduling

queue

selection

based on

DS field

75

2

50

10

Fi gure 26 : W eighted Fai r Queuing (W FQ)

Queue length

Drop probability

100%

0%

min max

Fi gure 27 : Random Ear ly D etect ion (RE D )


19/20

19

marked Out - of-profile. Th e Out algorith m starts

dropping at a much shorter average queue length, anddrops much more aggressively than the In algorithm.With proper setting of parameters, the Out of profiletraffic can be controlled before the queue grows to thepoint that any In traffic is dropped [see Figure 28below].

IP OVER SONET/SDH

The demand for bandwidth is skyrocketing in data-service networks. With this demand comes the needfor efficient bandwidth utilization, higherperformance, and simplicity.

These trends have brought about the birth of a newIP-centric network model. Th e IP-centr ic networkinfrastructure is an IP-based, full-service network thattak es advanta ge of IP Layer 3 QoS and such inh er entIP characteristi cs as scala bility, simpli cit y, andmult icasting. In an IP-centri c network, IP packets are

mapped dir ectl y to the SONET/SDH layer using

"Packet over SON ET" or P OS.

According to the OSI reference model, theSONET /SDH protocol i s th e physical la yer (Layer 1)and IP is a network la yer protocol (Layer 3). A datalink layer (Layer 2) is requir ed t o in t erface theSONET/SDH pr ot ocol wit h IP. T he IETF hasstandardized on th e P oint- t o-P oint Pr ot ocol (PPP) t operfor m thi s functi on. The applica ble Request forComments are:

" RFC 1619 - "PPP over SONET and SDH Circuits"." RFC 1549- "PPP in HDLC Framing"." RFC 1548 - Point-to-Point Protocol (PPP)The format of IP packets in the SONET/SDHsynchronous payload envelope is simple. One byte isdedicated to the packet flag at the beginning of thestring and four bytes are dedicated to the PPP header(one address byte, one control byte and two forprotocol bytes). The IP packets are serially placed inthe SONET/SDH frame, and a cyclic redundancycheck i s add ed at th e end.

What About IP Over ATM?

ISPs delivering pure data services are concerned withget ti ng every possible dr op of perfor mance out of th eirW AN infrastru ctur e. Wi th no r eal-ti me traffic loadin t heir netw ork s (i.e., no base of circuit-swit chedtelephony subscribers), ISPs don't benefit from ATM'sexcellent multiplexing and jitter managementca pabiliti es. The cell stru ctur e of ATM r esponsiblefor these characteristics is seen only as a "cell tax"consuming 20-30% of the WANs bandwidth withoutgenerating any value.

Queue lengt

Drop probability

100%

0%

minIN

maxIN

maxOUT

minOUT

Fi gure 28 : Random Ear ly D etect i on In/ Out (RI O)


20/20

20

Consideration of IP over SONET/SDH when abusiness model is IP-centric is essential. Packet overSONET in combination with gigabit routers leveragesexisting SONET/SDH technology and delivers simpleand effici ent bandwid th use, Layer 3 QoS, andscala bili ty. H owever, carri ers with a significant baseof traditional circuit-switched services will still

benefit from the unique capabilities of ATM, and canjustify t he "cell tax" for IP data services (at least unti lIP QoS technology is sufficiently mature to provideperformance equivalent to ATM).

WIRESPEED ROUTERS

Traditionally, routing has been performed by softwarerunning on one or more microprocessors containedwithin a r outi ng pr oduct. These so call ed softwar e

based routers were relatively slow and expensive.

The new generation of rout ers perfor ms IP r outi ng inspecialized hardware, using shared memory or crossbarswitching fabrics combined with routing in ASICs.This new breed of routers can route packets at multi-giga bit speeds, with l ow latency, t o tens of milli ons ofpackets per second. They support a wide range ofW AN int erfaces includi ng T1/E1, T 3/E3, OC-3/STM-1, OC-12/STM-4 and OC-48/STM-16directly over SONET/SDH or over ATM. They also

support IP QoS, IP Multicast, and MPLS for traffic

engineering.

Ericsson's AXI 520 IP C or e Rout er and AX I 540Edge Aggregation Router are both examples of thisnew generat ion of wirespeed rout ers. T hese platf or ms,together with Ericsson's advanced IP networkmanagement solutions, deliver a highly effective andint egrat ion soluti on for carr ier-class IP net work s [ seeFigure 30 below].

This new class of wirespeed routers changes manyassumptions that organizations have been using todesign their networks. No longer does routing need tobe avoided due to the perfor man ce degradati on itintroduces. These ASIC-based wirespeed routers canforwar d IP at th e same perfor mance levels as Layer 2switches.

Ericsson Inc.Data com Networks

77 Sout h B edford StreetBurlington, MA 01803

www.ericsson.com/datacom

I P over SONET OC-3 vs. I P over ATM SONET OC-3

0

20

40

60

80

100

120

140

160

46 110 238 494 1006 1500

Bytes per I P Packet

Mbps

IP over SONET

IP over ATM (AAL5SNAP)

OC-3 Payload

F i gure 2 9: I P over SON ET vs. I P over A T M (source: Ci sco Systems, I nc.)

High SpeedLocal Access

xDSL /CableModems

xDSL/CableModem

Cable/xDSLAccess Mux

AggregationRouter

Residential Customers

Access POP

Backbone POP

Business Customers

High-CapacityAccessRouter

VariableRate

(up to OC-3)

OC-3

xDSL/Cable

Modem

CoreRouter

OC-12OC-48

IPBackbone

OC-12

F i gur e 3 0 : T he W i respeed R outer a s th e C ornerstone of the Ba ckbone POP

Date post:	14-Apr-2018
Category:	Documents
Upload:	madinah-100
View:	214 times
Download:	0 times

Ip Routers1

Documents