Routing in the Future Internet - fing.edu.uy

Routing in the Future Internet

Marcelo Yannuzzi

Graduate Course (Slideset 2)Institute of Computer Science

University of the Republic (UdelaR)

August 20th 2012, Montevideo, Uruguay

Research Topics and Ongoing Activities

Marcelo Yannuzzi and Xavi Masip

July 10, 2008

Marcelo Yannuzzi and Xavi Masip CRAAX — UPC

Department of Computer Architecture Institute of Computer Science

Technical University of Catalonia (UPC), Spain University of the Republic (UdelaR), Uruguay

Outline

1 Intradomain aspectsA look inside carrier-grade networks, and their dataand control planes

Marcelo Yannuzzi Routing in the Future Internet: Graduate Course, INCO, Montevideo, Uruguay, 2012. 2

Multi-layer Data Planes


The Multi-layer Structure

Carrier Ethernet Transport – Requirements and

Multilayer Network Architecture with PBB-TE

Claus Gruber, [email protected] - 20080104

21

Optical Transport

Service Access IP/AggregationEdge

CoreAggregation

DWDM Metro

Routing

BRAS

3P-PE

CIS PE

Application

IMS

CISCustomer IP Service

3Play VDSL

CESCustomer Ethernet Service

COSCustomerOptical Service

DSLAM

IP Edge

DWDM Core

3Play FTTH

Access

Switch

Ethernet

IP/MPLS Core

Carrier Ethernet TransportCarrier Ethernet

Carrier Ethernet TransportNetwork Architecture Model


The Multi-layer Structure (cont.)

IEEE Communications Magazine • June 2008 79

In light of the above, comprehensive multido-main/multilayer optical standards and algorithmsare required for a distributed operation with lim-ited global visibility, namely, resource dissemina-tion, traffic engineering (TE) path computation,and survivability. These solutions must be scal-able and achieve a level of optimality, whereoptimality can be inferred as the TE path chosenin the idealized case of a “flat” network, that is,no partitioning with a global state [3]. Typically,these objectives can be conflicting. Currently,although multidomain data networks were wellstudied, optical networks pose very differentresource/link constraints and have an inherentgrooming aspect due to multiple granularities.This article addresses this challenging area andis organized as follows. We first present a surveyof existing standards. Next, we describe relatedresearch work and highlight key open challenges.Then, a sample multidomain DWDM study ispresented along with conclusions.

MULTIDOMAIN OPTICALNETWORKING STANDARDS

Various optical standards were developed withinthe IETF, ITU-T, and OIF. In this section, wesurvey these efforts, with a particular focus ontheir multidomain capabilities; see also Table 1.

ITU-TThe ITU-T has been maturing its multidomain-capable ASTN framework for several years(G.8080, formerly G.ason) [1]. The referencearchitecture here defines a hierarchical set up ofrouting areas (RAs). At the lowest hierarchicallevel, an RA represents a domain comprised ofphysical nodes and links. At higher levels, an RArepresents multiple “abstract” nodes and links.Note that asynchronous transfer mode (ATM)

also defined a hierarchical design with peergroups, namely, private network-to-network inter-face (PNNI) protocol. However, ASTN furtherdefines component groups to set up, maintain,and release connections; for example, an RA canhave one or more routing controller (RC) enti-ties. Associated component functions also areoutlined for tasks such as auto-discovery, auto-provisioning, restoration, and so on. In ASTN,network topology is not made visible to the clientlayer, and hence, connections are treated as sub-network point pool (SNPP) links. Overall, ASTNis quite flexible because each lower-layer controlplane can be tailored to the particular type ofequipment (layer). Nevertheless, because ASTNdefines only architectures, its liaison efforts withthe IETF and OIF are of crucial importance.

OIFThe OIF has largely focused on optical interfac-ing protocols, including a client-network UNIand a network-network NNI [2]. UNI definesbandwidth signaling for client devices (i.e.,IP/MPLS routers) to request/release optical con-nections from carrier SONET/SDH or DWDMdomains, namely, “optical dial-tone.” Becausethere is no trust relationship here, theresource/topology state is not propagated toclients, that is, the overlay model [1]. The latestversion, UNI 2.0, features much-improved capa-bilities for security, bandwidth modification, andso on. The NNI implements inter-domain func-tionality for reachability/resource exchange andset-up signaling and features two variants, inter-nal NNI (I-NNI) and external-NNI (E-NNI).The former interfaces nodes within the sameadministrative area, whereas the latter servesadjacent (possibly multicarrier) areas. Namely,E-NNI relegates all interfacing to domainboundaries, thereby removing restrictions ondomain internal control and equipment interop-

! Figure 1. Multidomain/multilayer optical networks.

Large tributary services(direct mappings)

Subrate services(grooming)

Network (client) layers(layers 2,3)

Core IP/MPLS routers,SAN switches

Vertical(layers, granularities)

Horizontal(domains)

Wavelength lightpathrouting mesh

Subrate tributary grooming(multiple granularities)

UNI

DCSNGS mesh

NGS/MSPP mesh

MSPPnode

NNINNI

NNI

NNINNI - Transparent

- Opaque- Translucent

ROADMOXC

OXC

OXC

Optical DWDM layer (layer 1)regional and long-haul cores

• n x OC-48/STM-16• n x OC-192/STM-64

DWDM regional

DWDM mesh core

DWDM mesh core

1 Gig, 10 Gig Ethernet1, 2 Gig Fibre Channel

Next-gen, SONET/MSP layer (layer 1.5)metro, edge networks

• VCAT STS-nC• T1/T3, DSn• OC-3/STM-1• OC-12/STM-4• OC-48/STM-16

Edge routers,legacy TDM 10/100 Ethernet

1 Gig Ethernet

ASTN is quite flexiblebecause each

lower-layer controlplane can be tailoredto the particular typeof equipment (layer).

Nevertheless,because ASTNdefines only

architectures, its liaison efforts withthe IETF and OIF

are of crucial importance.

GHANI LAYOUT 5/22/08 2:26 PM Page 79

Source: N. Ghani, et al, “Control Plane Design in Multidomain/Multilayer Optical Networks,” IEEECommunications Magazine, Vol. 46, No. 6, June 2008, pp. 78-87.


The Optical Layer and itsData and Control Plane


Translucent Optical Transport Network (OTN)

7

Advanced Network Architectures Lab

Technical Univ.of Catalonia

• Full transparency is not always possible in long distance networks• In translucent OTNs, routes are divided into transparent sub-routes

between signal regenerators

Translucent OTN Model

Winput W

DM

channels

WDM demuxer WDM muxer

EDFA(line amplifier)

EDFA(booster)

Amplifier span

Winput W

DM

channels

Woutput W

DM

channels

DWDM link

WDM demuxer

EDFA (booster)

EDFA(line amplifier)

Amplifier span

Woutput W

DM

channels

WDM muxer

Tunable transmitters/receivers

Local traffic (tributaries)

Regenerator pool

All-optical switching fabric

Source: M. Yannuzzi et al., “Performance of translucent optical networks under dynamic traffic anduncertain physical-layer information,” in Proceedings of the 13th IFIP/IEEE Conference on Optical NetworkDesign and Modelling (ONDM 2009), Braunschweig, Germany, February 2009.


Protocol Stack Zoo

FP7-ICT-2009-4 STREP proposal X-AGON

Proposal Part B: page [12] of [98]

Figure 3: The hexagon with the research challenges in multi-domain and multi-carrier optical networks

X-AGON’s Challenges

Security

Robustness

Effective TrafficEngineering functionalities

Cost-effective andenergy efficient routingand traffic forwarding

Addressing

Routing Policies

Scalability

1.1.2 X-AGON network scenario The reference network scenario in X-AGON is depicted in Figure 4 (a). The presented scenario is not intended to be comprehensive, and its variations and possible alternatives shall be comprehensively studied as part of the early activities within the project. Figure 4 (a) highlights the different roles a carrier can play, where carriers are ranked as Tier 1, Tier 2 and Tier 3 at the IP layer. Figure 4 (a) shows that while some carriers operate networks that span all layers (e.g., carriers A and B), other carriers are more IP service oriented (e.g., ISPs like carriers C and F), which operate only at the IP level. In addition, other carriers may only own photonic networks (e.g., carrier D) or only operate IP networks and connection oriented packet networks, such as carrier E. In this context, X-AGON will deal with both single carrier and multi-carrier scenarios, since multi-domain issues can exist in both cases. In general terms, single carrier networks are typically layered into a data layer and a transport layer that might encompass one or more switching capabilities. Both the data and transport layers are typically partitioned into many metro/regional networks linked by a backbone network. In this context, X-

(a)

IP Layer

T-MPLS

Eth.

Eth. Phy

MPLS

Eth.

Eth. Phy

T-MPLS

MPLS

Eth.

Eth. Phy

Pseudo W

Eth. Phy

PBB-TE

MPLS

Pseudo W

DWDM photonic network

MPLS DWDM Photonic network

DWDM Photonic network

IP Layer

T-MPLS

Eth.

Eth. Phy

MPLS

Eth.

Eth. Phy

T-MPLS

MPLS

Eth.

Eth. Phy

Pseudo W

Eth. Phy

PBB-TE

MPLS

Pseudo W

DWDM photonic network

MPLS DWDM Photonic network

DWDM Photonic network

Figure 4: (a) Multi-carrier, multi-domain, multi-layer network scenario in X-AGON; (b) Potential network stacks that shall be considered in X-AGON.

Multi-Layer Peering Model

Photonic transportnetworks

IP networks

Connectionoriented packet

networks

Tier 2Tier 1

Tier 3 Tier 2

Tier 3

F

B

B

B A

A

A E

E

C

D

C

VNO domain

D

Photonic Transportdomain

E

ISP domain

Physical linkLogical link

carrier Acarrier Bcarrier C

carrier Dcarrier Ecarrier F

Differentkinds ofverticalpeering

X-AGON’sScope and Reach


Drivers for more optics: 1) The cost per-bit

2 © Nokia Siemens Networks ONDM2009 / Dominic Schupke / 2009-02-19

Voice dominated Data dominated

Traffic

Revenue

Revenues and Traffic decoupled

Tra

ffic

volu

me

Time

Network cost

Profitability

Reduction of network cost necessary to remain profitable

Decoupling of revenues and traffic requires low cost per bit technology

Source: Lightreading 2007, adapted

� Total Cost of Ownership (TCO) challengeSource: Dominic Schupke, Nokia Siemens Networks, “Options and Opportunities for Optical NetworkResilience,” invited talk at IFIP/IEEE ONDM 2009, Braunschweig, Germany, February 2009.”


Drivers for more optics: 2) Energy Efficiency

7 © Nokia Siemens Networks

Energy efficiency development of transport equipment

0.01 kW /100Gbit/s at 40Gbit/s in 50 GHz

spacing

<0.2 kW / 100Gbit/s

<0.6 kW / 100Gbit/s

Next generation equipment

0.5 kW / 100Gbit/sL2 Switch

0.04 kW / 100Gbit/s at 10Gbit/s in 50 GHz

spacingROADM

/PXC Node

1 kW / 100Gbit/s IP/MPLS Router

Implemented current equipment

Energy efficiency of equipment is improving across all technology categories

ROADM/PXC: Remote Optical Add/Drop Multiplexer/Photonic Cross Connect

Source: Nokia Siemens Networks, “Greener Networks to Exploit Multilayer Interworking.”



Power requirements:

© 2009 ADVA Optical Networking. All rights reserved. ADVA confidential.17

Non-technical InfluencesEnergy demand will exceed supply

Average access rate [Mbit/s]

Pow

er [

MW

/10

6use

rs]

Metro +Access

Core

WDM links

Total

0

100

200

300

0 200 400 600 800 10000

2

4

6

10

12

% o

f el

ectr

icity

supply

8

14Dominated bycore routers

Bal

iga

et a

l.,

CO

IN/A

CO

FT,

June,

2007

If 33% of the world’s population were to obtain broadband access:

Need to reduce total power consumption !

50%5%Percentage of world’s 2007 electricity supply

1TW100GWPower consumption

10Mbit/s1Mbit/sAccess rate

50%5%’s

Source: Christoph Glingener, ADVA Optical Networking, keynote at IFIP/IEEE ONDM 2009, Braunschweig,Germany, February 2009.”



© 2009 ADVA Optical Networking. All rights reserved. ADVA confidential.18

Source: G. Epps, Cisco, 2007

Buffers, 5%

IP look-up andforwarding engine,

32%

Power / Heat management,

35%

I/O, 7%

ControlPlane, 11%

Switchfabric,

10%

Power driver : IP look-up/forwarding engine

I/O – optical transport: is lower in power consumption than switch fabric

Wireless access power consumption: 10-20 times higher than wired solutions

Concentrate L3+ in high density routers/switches (data centers)

Use wired (optical) access/backhaul incl. point-to-multipoint solutions (PON)

Bandwidth is not the issue !

Non-technical InfluencesEnergy efficiency

Source: Christoph Glingener, ADVA Optical Networking, keynote at IFIP/IEEE ONDM 2009, Braunschweig,Germany, February 2009.”


Drivers for more optics: 3) Distributing Traffic


How to build greener transport networks usingmultilayer optimization

Optimize energy efficiency of the networkwith multilayer optimization

1 kW for100 Gigabit/s

0.5 kW for100 Gigabit/s

0.04kW for100 Gigabit/s

Rebalancing the traffic in L1/L2/L3 network processing layers toachieve optimal connectivity architecture

L3/IP

L1/WDM

L2/Ethernet



Drivers for more optics: 4) Multi-layer Optimization


Achieve significant savings in the backbone network with multilayer optimization

Significant power consumption savings up to 55% and CAPEX reduction up to 69%

Non OptimizedIP/DWDM

Power consumption savings with MLO

OptimizedIP/DWDM

IP/DWDM andCET optimization

MLO: Multilayer Optimization CET: Carrier Ethernet Transport

European operator case study, 2008

1,4 Mio Kwh

0.8 Mio Kwh

0.63 Mio Kwh

25%

43% 55% 53%

CAPEX savings with MLO

Non OptimizedIP/DWDM

OptimizedIP/DWDM

IP/DWDM andCET optimization

69%

100 47 31

35%



Overall....reducing the number of IP routers

DSLAM

section OAM

path OAM

BTS

packet transport metroOLT

ONT

ONU

FE/GE

IP/ETHDSLAM

OLT

ONT

ONU

FE/GE

FE/GE

resi

dent

ial

trip

le p

lay

mob

ileS

OH

Otr

iple

pla

ybu

sine

ss

end-to-end OAM

control planediscovery

routing

signaling

resilience

OTN/lambda switching

Packet transport switching

section OAM + FEC

path OAM

packet transport and switching integration

packet transport metro

section OAM

path OAM

Internet

edge servicenode

Routers minimization

IP routers are exclusively used in those points were IP packet inspection is needed (e.g BRAS and ISP interconnection).

IP interconnection

Integration of packet and OTN

Routers minimization

The number of IP edge nodes (BRAS) is reduced by using long reach-regional aggregation networks based on packet and optical technologies (e.gLRPON,OBS).

CallAdmission

Control

STONGEST global architecture: main assumptions

Source: STRONGEST, FP7, ICT EU project.


Control Plane: Advances in standardization

IEEE Communications Magazine • June 200880

erability. Recently, the OIF also detailed routingand signaling functionalities for E-NNI. Specifi-cally, a hierarchical routing set up is defined(ASTN G.8080), based upon open shortest pathfirst traffic engineering (OSPF-TE). However,the inter-carrier case has not been fullyaddressed yet. Overall, UNI and NNI can auto-mate circuit setups across multiple optical layers,both DWDM and SONET/SDH. Note that theuse of link state routing in multidomain opticalsettings is quite germane as the number ofdomains will be drastically lower than the num-ber of autonomous systems (ASs) in the widerInternet (which uses distance-vector routing).

IETFInternet Protocol (IP) networks feature a maturemultidomain setup comprised of a hierarchy ofASs and areas (domains). Within areas, routersrun interior gateway protocols (IGPs) such asOSPF or intermediate system-to-intermediatesystem (IS-IS) to maintain link state databases(LSDBs) [1]. The inter-AS level uses exteriorgateway protocols (EGPs), most notably distancevector border gateway protocol (BGP), forreachability exchange. However, BGP representsa very high level of state aggregation and is gen-erally insufficient for TE circuit routing, whichrequires link/path state [4]. Here, instead, OSPF-TE can provide an added inter-domain routingcapability. However, with growing quality of ser-vice (QoS) requirements, OSPF has defined TEextensions (OSPF-TE, RFC 2676) for newopaque link state attributes (LSAs). Namely,these entities can disseminate QoS-related stateto support advanced constraint-based routing(CBR). Note that QoS destination extensionsalso were proposed for BGP.

In recent years, the IETF also extended con-trol provisioning to optical domains by augment-ing its MPLS suite, namely, generalized MPLS(GMPLS) [1]. For routing, this includes newOSPF-TE opaque LSA definitions for DWDMand SONET/SDH links, enabling TE databases

(TEDBs) to store wavelengths/usages,timeslots/usages, shared risk link groups(SRLGs), and so on. For signaling, extendedResource Reservation Protocol with Traffic Engi-neering (RSVP-TE) now supports hard state cir-cuit set up/takedown, recovery, and so on. A newlink management protocol (LMP) also is definedfor resource discovery and fault localization. Nowit is important to consider the applicability ofGMPLS in multidomain settings. From a routingangle, OSPF-TE can suffice as a unified inter-domain link-state solution because it supportsmultiple link granularities (and is also beingadopted in the OIF). RSVP-TE offers manysaliencies for multidomain circuit signaling via itsloose route (LR) feature. Namely, partial skele-ton routes can be specified, and subsequentexplicit route (ER) expansion can be used toresolve full label switched paths (LSPs) [1].RSVP-TE also defines mechanisms for LSP setup across domain boundaries — contiguous,stitched, and nested [3]. Carefully note that proxydevices also can be used to incorporate propri-etary domains under the GMPLS framework, forexample, see the network-aware resource broker(NARB) in a DRAGON network.

Another recent IETF multidomain standard isthe path computation element (PCE) framework[4], which decouples TE path computation fromsignaling. In this set up, a domain can have oneor more logical (standalone or co-located) PCEentities that communicate with path computationclients (PCC) to resolve connection paths. AllPCC-PCE communication is performed via a newPCE protocol (PCEP) [4]. Although a PCE hasaccess to local domain resource/policy databases,its inter-domain visibility may vary [3]. In thesimplest case, a PCE may have knowledge onlyof its domain egress, namely, local visibility (low-trust, inter-carrier). Alternatively, a PCE mayhave knowledge of physical inter-domain linksand even resources in external domains, namely,partial visibility (high-trust, intra-carrier). Accord-ingly, two distributed path computation schemes

! Table 1. Multidomain optical networking standards.

Body Framework Routing Signaling TE path comp.

ITU-T

Automaticallyswitchedtransportnetwork (ASTN),formerly ASON(G.8080)

• G.7713.1/Y.1704: distributed calland connection management (PNNI-based)• G.7714/Y.1705: generalized auto-matic discovery• G.7715/Y.1706: architecture andrequirements for routing

• G.7713.2/Y.1704: distributed calland connection management(GMPLS RSVP-TE-based)• G.7713.3/Y.1704: distributed calland connection management(GMPLS CR-LDP-based)

• None specified

IETF

Generalizedmultiprotocollabel switching(GMPLS)

• RFC 4258 (requirements for GMPLSfor ASON)• IGP routing extensions for discoveryof TE node capabilities• OSPF extensions in support of inter-AS MPLS and GMPLS• Virtual connection aggregation

• RFC 4208 GMPLS UNI• RSVP-TE for overlay model• Interdomain MPLS and GMPLS TEextensions for RSVP-TE

• Policy-enabled PCEframework• PCE protocol (PCEP)• Per-domain pathcomputation for inter-domain TE LSP setup

OIF

User-networkinterface (UNI),network-networkinterface (NNI)

• OIF UNI 2.0• E-NNI-OSPF-01.0• E-NNI OSPF-based routing 1.0 intra-carrier implementation areement

• OIF-E-NNI-Sig-2.0: intracarrierE-NNI signaling• OIF-UNI-01.0-R2-RSVP: RSVPextensions for UNI 1.0

• None specified




Control Plane: Research topics


are envisioned, per-domain and PCE-based [3].The former computes paths in a domain-domainmanner and is suitable for limited visibility.Namely, PCE entities (or border nodes) iterative-ly compute TE paths across their domains toingress nodes in the next domain. The latteroperates with increased inter-domain visibility,and two strategies have been presented: multi-PCE path computation with/without inter-PCE sig-naling [4], which will be discussed later. Note thatthe PCE framework also allows policy control atdomain boundaries — a crucial requirement inmulticarrier settings, on par with TE objectives.Specifically, an ingress PCE can enforce policiesto determine the requests that it will supportalong with applicable TE constraints/algorithms.

RESEARCH SURVEYDespite standards progress, the overall area ofmultidomain (multilayer) optical networking hasnot seen significant research focus. Althoughsome results can be reported, most wireline mul-tidomain efforts have focused largely on homo-geneous packet networks. To get a better senseof the key challenges herein, it is important tosurvey the related areas, a generic taxonomy ofwhich is shown in Fig. 2.

MULTIDOMAINPACKET-SWITCHING NETWORKS

Many multidomain studies have looked at topol-ogy abstraction schemes for multidomain routingin IP and ATM networks, for example, [5, 6].These schemes use graph transformations tocondense resource state via virtual graphs withfewer abstract vertices and edges. Typically, thisis performed by a designated domain-level enti-ty; for example, an automatically switched opti-cal network (ASON) routing controller (RC) [1],which propagates the abstract link state to otherdomains to build a global aggregated graph. Earli-

er studies in ATM networks using peer groupsummarization showed very good state reduc-tion, order magnitude in nature. Subsequentefforts extended these concepts to IP networksas well. For example, [5] applies topologyabstraction in multidomain IP QoS networksusing star, mesh, tree, and spanner graphs. Theseschemes are tested with various path computa-tion strategies (widest-shortest, shortest-dis-tance) and show strong improvements in routingscalability and route fluctuation reduction. Fur-ther work in [6] studied aggregation in directedgraphs with delay and bandwidth metrics usinginformation-theoretic and line segmentationtechniques. Overall results here showed goodgains with aggregation, that is, higher success,lower crankback, and so on.

Apart from routing, other efforts also studiedsignaling crankback in multidomain IP/MPLS net-works. For example, recently [3] detailed a com-pute while switching (CWS) scheme in whichper-domain computation is used to set up an ini-tial feasible route. Although data transmission isstarted on this initial route, crankback is used tosearch for more optimal routes (requiring newRSVP-TE attributes). Results show very high set-up success, on a par with global state. Others alsohave looked at multidomain survivability. Forexample, most early schemes used per-domain pri-mary/back-up LSP routing using BGP routingtables. However, this approach is very suboptimaland can easily overload heavily-traversed inter-domain links. To address these limitations, [7]develops a more advanced scheme to capturedomain-level diversity. Commensurate dedicatedprotection schemes also are developed using Sur-balle’s algorithm for trap topologies. However,generated state is quadratic in nature, that is,O(N4) for N border nodes, and must be flooded atthe inter-domain level. Moreover, detailed perfor-mance results are not presented. In [8] multido-main shared-path protection is studied, namely, anaggregated graph is defined with (full-mesh) virtu-

! Figure 2. Overview of research topic areas (wireline networks).

Extensive sub-rate grooming studies, survivable grooming as well(static ILP, dynamic, distributed)

IP-SONET/SDH, Eth-SONE/SDH, IP-DWDM, SONET/SDH-DWDM

Extensive QoS routing,survivability studies

Extensive multdomainIP/MPLS QoS routing,

TE, survivability studies

Some multidomainRWA, routing,

survivability studies

Distributed multidomain, multi-layer grooming, TE, survivability

(largely open areas)

Intercarrier settings pose addedresource exchange and policy constraints

Extensive RWA and survivabilitystudies (static ILP, dynamic)

Extensive legacy ring/mesh TDM provisioning studies

IP/MPLS

Loca

lity

Inte

rdom

ain

Intr

adom

ain

Optical DWDMSONET/SDH, NGS

Technology layers

Despite standardsprogress, the overallarea of multidomain(multilayer) optical

networking has notseen significantresearch focus.Although someresults can be reported, most

wireline multidomainefforts have focused

largely onhomogeneous

packet networks.




Control Plane: Open challenges


graphs [14]; see Fig. 3. Note that here inter-domain TEDBs must maintain multiple linktypes, for example, via different OSPF-TEopaque LSA types. Nevertheless, maintainingpartial visibility presents several challenges. Fore-most, it mandates the design of effective resourceaggregation schemes to support TE objectives (asthese directly impact the trade-off between rout-ing scalability and blocking). A promisingapproach is to leverage the topology abstractionsdeveloped for IP, and more recently DWDM,networks, as shown in the aggregated graph viewin Fig. 3. However, specific considerations arerequired for heterogeneous optical domains, par-ticularly for multiple switching granularities.Additional efforts also must look at summarizingsurvivability state, such as SRLG, fiber/span pro-tection, and so on. Finally, the aggregation ofinter-domain lightpath connections also can beperformed as these entities can be treated as vir-tual connection grooming links (i.e., hierarchicalLSP) between SONET/SDH domains; see Fig. 3.Although this step can boost grooming efficien-cies, very scalable algorithms are requiredbecause connection counts can grow with thesquare of nodes. Note that policy constraints playa key role in determining what TE constraintsand aggregation schemes are allowed acrossdomain boundaries. Also, re-optimization (trafficre-routing) may be required to further maintainefficiency on such virtual connection links.

Finally, resource dissemination requires effec-tive inter-domain update triggering strategies [17].Various routing policies are available here, such astimer-based, absolute change, relative change, andhysteresis-based. All of these schemes — except forthe former — are threshold-based, and extensivefindings show that such strategies yield the lowestrouting overheads and good sensitivity [5]. Hence,physical inter-domain link state can readily bepropagated accordingly. Conversely, aggregatedlink state propagation is more complicated as itpertains to “non-existing” computed entities. Here,using fixed intervals to compute abstractions andpropagate updates can yield high messaging/com-pute loads (short intervals) or high inaccuracy(long intervals). Ideally, hybrid periodic/threshold-based strategies must be developed [14, 17].

TE PATH COMPUTATION AND SIGNALINGThe main objective of path computation is to setup feasible end-to-end circuit routes that meetrequired TE and policy objectives, preferablywith some degree of global optimality. Given thedistributed nature of the problem, requisite sig-naling — RSVP-TE and PCEP — will play acrucial role. Herein, two broad strategies arepossible for optical domains, per-domain andPCE-based computation [3].

Per-Domain Strategies — Per-domain compu-tation is suited for low inter-domain visibility sce-narios. However, it is very difficult to select anext-hop domain to meet inter-domain TE objec-tives in a local manner. As such, the only viableoption may be to choose predetermined or ran-dom egress points, yielding low resource efficien-cy/high blocking, particularly for multigranularitygrooming. To address these limitations,crankback signaling can be used to reattempt

setups at intermediate domain boundaries. Thetrade-off here is in terms of set-up delay andmessaging. Recent findings in multidomainMPLS networks show that crankback gives signif-icantly lower blocking when using active (failed)path state [3]. Hence, further studies can developmultilayer optical crankback schemes to incorpo-rate wavelength selection and even virtual con-nection (grooming) state. Periodic/event-drivenreoptimization of connections (or connectionsgroups) also was suggested in [4]; albeit in-depthanalyses are required to devise effective algo-rithms such as graph, theoretic, or ILP schemes.Nevertheless, reoptimization can be very costly toimplement across domains, particularly if clientsdemand hitless switchovers.

PCE-Based Strategies — As mentioned earlier,two PCE strategies are possible: multi-PCE com-putation with or without inter-PCE signaling.The latter assumes partial visibility and requiresa source PCE to compute a skeleton LR to thedestination domain. In practice, this is best per-formed via modified graph-theoretic searchesrunning over the aggregated network graphs.However, detailed multidomain groomingschemes are lacking. To address this gap, two-step schemes can be considered, akin to single-domain grooming. Namely, an initial LR can besearched on the aggregated graph using onlylinks with the same granularity as the sourcenode. Various TE objectives can be studiedhere, including minimum hops/cost, load balanc-ing, and so on [5]. Pending failure at this “high-er” level, subsequent virtual connectionlightpaths can be set up between border nodes.However, it is not clear how to identify the bestborder node end-points; for example, [14] usesexhaustive search. Overall, PCE-based LRschemes will be more effective than basic per-domain computation, but more studies arerequired to assess the impact of aggregation onglobal optimality.

! Table 2. Summary of research challenges.

Focus area Open challenges

Statedissemination

State aggregation• Multigranularity topology aggregation (mesh, tree, etc.)• Virtual connection link aggregation schemesUpdate generation• Scalable update policies for aggregated state• Scalable update policies for virtual connection links

TE pathcomputation

Per-domain strategies• Crankback signaling across domains/granularities• Re-optimization/re-grooming of circuit routesPCE-based strategies• Novel TE-based loose route (LR) algorithms• Diversity state in aggregated graphs

Survivability

Protection strategies• Novel TE-based LR primary/back algorithms• Multilayer SLA support (dedicated, shared)• Serial/parallel setup signaling schemesRestoration strategies• Crankback signaling across domains/granularities• Priority/preemption for multi-SLA support




Control Plane: State dissemination models

IEEE Communications Magazine • June 200884

Path computation with inter-PCE signalingrequires a source PCE to request other PCEentities to resolve explicit or loose source-desti-nation routes. This approach is amenable to lowtrust inter-carrier settings and mimics per-domaincomputation (except that signaling occurs on thePCE plane). Along these lines, a specializedbackward recursive PCE-based computation(BRPC) was presented for IP/MPLS PCE-net-works [16], expanding strict hops backwards fromthe destination domain using a pre-defined virtu-al shortest path tree (VSPT). This set up assumesa-priori specification of end-to-end domainsequences and extensions to PCEP messaging.However, detailed analyses and/or DWDM net-work adaptations are lacking as of now.

Note that PCE-based computation requiresfollow-up RSVP-TE signaling, which in turnrequires considerations for differing link types.For example, ingress border nodes must resolveLR hops (abstract links) with traversing intra-domain sequences. Metric translation at domainboundaries may be required here becausedomain TE objectives will vary versus globalinter-domain TE objectives. Furthermore, if aningress border node runs at a lower granularitythan the incoming request, for example, SONETover DWDM, grooming will be required overexisting and/or new intra-domain lightpaths,namely, hierarchical/nested LSP mapping. In thiscase, a wide range of existing (intra-domain)grooming schemes can be reapplied.

SURVIVABILITYSurvivability schemes can generally be classifiedas either pre-configured protection or post-faultrestoration. The former are best suited for strin-gent demands, whereas the latter are more ger-mane for delay-tolerant traffic. In extending

these paradigms to heterogeneous optical set-tings, a simplifying assumption can be to runonly inter-domain recovery for inter-domainfaults. Namely, intra-domain failures can be rele-gated to domain-specific techniques, yielding lessdisruption and faster recovery. Regardless, mul-tidomain optical survivability is a complex prob-lem owing to differing mechanisms andgranularities. This disparity will require protec-tion SLA translation between domains and willinevitably complicate support for multitiered ser-vices, for example, dedicated/shared protection,restoration, preemption, and so on.

Protection Schemes — Most multidomainSONET/SDH networks use dual/multihomingprotection between border nodes. Althoughrobust, these schemes are costly and resourceinefficient as they relegate primary and backuproutes to the same domain sequences. Hence,new protection strategies with domain diversitycan be developed to improve resiliency, usingeither per-domain or PCE-based computation.These schemes can be further coupled withsequential or simultaneous (parallel) set-up strate-gies [16]. For example, sequential per-domainprotection can first resolve primary paths and usethe returned explicit routes to avoid overlaps onthe back-up paths, for example, via the RSVP-TE explicit, record, and exclude route objects(ERO, RRO, and XRO). However, this likelywill yield sub-optimal routes and higher blocking(also susceptible to “trap” topologies). Toaddress these concerns, again, crankback andreoptimization can be performed [4]. Note thatinter-carrier confidentiality can restrict the shar-ing of explicit routes between domains.Workarounds can include the use of path keysindexing or pre-established traversing paths [16].

! Figure 3. Interdomain state dissemination models: local, partial.

Local visibility

Domain 1 view Interdomain links graph(simple node)

Aggregated graph(full mesh abstraction)

Partial (global) visibility

Aggregated graph(star abstraction + virtual links)

Domain 1 Domain 3

Domain 2

Physical interdomainlink

3 egress

Domain 3 view

3 egress

Domain 1(SONET)

2 border nodes3 interior nodes6 internal links



Interdomain lightpath(i.e., virtual connectiongrooming link) Border

node

MSPP

MSPP

DCS

OXC

Domain 3(MSPP)

Domain 3(DWDM core)

5 interdomain links

Domain 2 view

4 egress

Domain 1 Domain 3 Domain 3Domain 1

Domain 2

Physical multidomain/multilayer network

Domain 2

Virtualnode

Aggregated/abstractlink

Virtual connectionlink

Survivability schemescan generally be

classified as eitherpre-configured pro-tection or post-fault

restoration. The former are bestsuited for stringentdemands, whereasthe latter are moregermane for delay-

tolerant traffic.




The IP Layer and itsData and Control Plane


Routing and Forwarding

Router’s architecture

ZHAO et al.: ROUTING SCALABILITY: AN OPERATOR’S VIEW 1263

Fig. 1. An illustration of a typical modern router architecture

to meet the stringent performance requirements of high-speedline rate operations (currently at over 100Gbps per line card).Because of such special requirements, the line cards are themost expensive component in a router. Besides ASICs, a linecard also has its own CPU and memory, usually running anembedded OS for control and management purposes.Based on such a design, there are normally three copies of

the routing table inside one router. First, the control enginemaintains a large routing table called Routing InformationBase (RIB) to store all network prefixes, including multiplepossible paths for these destinations. The control engineselects the best routes from the RIB and installs them in amaster forwarding table. Second, every line card maintains alocal copy of the forwarding table in its own memory whichmirrors the master forwarding table through real-time syn-chronization. Third, each forwarding ASIC chip maintains ahighly compressed routing table in its built-in memory, usuallyimplemented using a tree-based data structure to achieve fastIP routing lookup during packet forwarding process. This datastructure inside ASIC chip is the ultimate source for a routerto make the forwarding decision on which interface to forwardthe traffic out.To achieve the optimal performance-cost ratio, different

types of memory hardware are used to store different routingtables, depending on hardware capacity, speed, and cost.Because the routing information in the RIB is not directlyused for packet forwarding, RIB memory normally uses larger,cheaper, and slower memory such as DRAM. On the other end,ASIC forwarding chip on a line card uses much faster but alsomore expensive and smaller memory such as SRAM. Line cardmemory hardware is somewhere in between. In most cases, thememory module is not a Field Replaceable Unit (FRU), thus itis not upgradable by users themselves; it will break the supportcontract if a user chose to do so. To expand memory capacity,vendors recommend to upgrade a routing engine or a line cardas a whole. In this regard, it does not make a difference wheneither line card memory or ASIC built-in memory needs tobe upgraded. With this in mind, we use a rather general butpopular term, Forwarding Information Base (FIB) to refer to

the routing table stored in either line card memory or ASICmemory.

Comparatively, a routing engine is much easier to upgradethan a line card in terms of cost and process. Unlike speciallybuilt line cards, a routing engine is often built using commer-cial off-the-shelf (COTS) hardware as long as it is capableto handle routing engine’s functionality. In addition, a routeris usually designed with redundant routing engines. A routingengine can be replaced during operation with almost no impacton traffic forwarding. On the other hand, replacing a linecard has direct impacts on traffic, thus such activity must beplanned and carried out carefully. Overall, RIB memory is a loteasier and cheaper to upgrade than FIB memory. Even beyondthe physical difficulties of upgrading components, vendors arecontinually challenged to scale memory components withoutadversely impacting the cost. Continuing to add memory ata rate greater than Moore’s Law has many challenges: powerbudget for the router, heat dissipation/cooling required andthe diminishing return on air cooling, as well as the restrictedfootprint of the device due to the fact that components havea silicon landscape budget as well.

Different routers, depending on their capacity, functionalityand cost, play different roles within an ISP. Typically, a routermay play any of the following three main kinds of roles: 1) acore router is usually located at a major Point-of-Presence(POP) connecting to one or more core routers located atdistant POPs to provide domestic or international long-haultransportation; 2) an edge router directly connects to customernetworks to provide them the Internet connectivity; and 3)an aggregation router aggregates traffic from edge routersand then either sends the packets to core routers or loopsthem back to other edge routers within the same metropolitanarea. Because a core router handles the aggregated traffic,it is often equipped with the high-speed and expensive linecards. Once a core router is unable to handle the ever-growingtraffic or is about to be depreciated 2, it will be replaced by anewer model with the latest and greatest line cards. In mostsuch cases, the old core router is still functional, so it makesperfect economical sense to keep it and turn it into either anaggregation router or an edge router. As time passes by, moreand more legacy routers are gradually moved to the edge.

To a typical ISP, it is generally true that the number of itsedge routers is proportional to the size of its customer base,while the number of the core routers is proportional to thenumber of POPs the ISP has a presence. The exact ratio ofedge routers to core routers varies from network to network,but it is usually in the range of 4:1 to 10:1. Because of the largeinstallation base of edge routers, upgrading all of them at onetime is unlikely, if not impossible. Upgrades of edge devicesare mainly driven by customers. When new customers requiremore ports to terminate them, or existing customers demandgreater bandwidth, it is time to upgrade an edge router to anewer model with greater port density and faster interfaces.

2In terms of router replacement cycles, ISPs generally depreciate theirequipment over a five year window. Add to that a six-month certificationeffort, and a one and a half year deployment time line, one may end up witha seven-year router replacement cycle.

Source: X. Zhao, J. D. Pacella, and J. Schiller, “Routing Scalability: An Operator’s View,” in IEEEJournal on Selected Areas in Communications, Vol. 28, no. 8, pp. 1262-1270, October 2010.


The intra/inter-domain split

4

� � � � � � �� Intra-domain: use link state or distance vector protocols� Inter-domain: use path vector protocol

AS-1

AS-2

AS-3

Interior router

BGP router � � � � � � ��

� � � � � � � � � � �� !" # � � � $ � %& ' ( ) * + , - . / + 0 '1 2 3 / 4 ' 5 6 , - 7 / - 3 ( 8 ). / + 0 ' 1 2 3 / 4 ' 5

9 : ; < = > ? @ A B : A C D E FInternet

……

2128.15.11.xxx

3128.15.xxx.xxx

1

2

16.82.100.xxx

2

Router

Forwarding table

16.25.31.10 128.15.11.12data 10 7

G At each router the packet destination address1. Is matched according to longest prefix matching rule

2. Packet is forwarded to the corresponding output port

H D E < I > : > = J K @ E > A @ L M A : N N D ;O Each node floods its local information to every other node in the networkO Each node ends up knowing the entire network topology P use Dijkstra to compute the shortest path to every other node

Host A

Host BHost E

Host D

Host C

N1 N2

N3

N4

N5

N7N6

Q R S T U V W V X Y Z [ \ X U V W V XHost A

Host BHost E

Host D

Host C

N1 N2

N3

N4

N5

N7N6

A

BE

DC

A

B E

DC A

BE

DC

A

BE

DC

A

BE

DC

A

BE

DC

A

BE

DC

] R ^ V W S _ X ` X _ V [ a Y b [ S V a [ c d a W e e R _f When the routing table of a node changes, the node sends its table to its neighborsf A node updates its table with information received from its neighbors

Host A

Host BHost E

Host D

Host C

N1 N2

N3

N4

N5

N7N6

N4,N4,1

N4,N1,2

N4,N1,2

N4,N2,3

N4,N3,4

Source: University of Pennsylvania (CIS)


Two families of intra-domain routing protocols (IGPs)

(1) Link-State Routing

The principle of link-state routing is that all the routers within an area build a mapof the network connectivity in the form of a topological graph.

The network topology is maintained by each node in a link-state database, andthe basic information consists of:

Interface identifierLink numberInformation regarding the state of the link

The overall goal is that all the nodes in a routing area maintain an identical copyof the network topology.

Then, each router can independently compute the best path from to everypossible destination in the network (Dijkstra’s SPF algorithm).

The collection of best paths will then form the node’s routing table.

Link-state protocols flood all the routing information when they first becomeactive in Link-State Advertisements (LSAs).

Once the network converges, nodes only exchange incremental updates viaLSAs.


(1) Link-State Routing (cont.)

What Is a Routing Protocol? 53

Armed with that information, each router can quickly compute the shortest path from itself to all other routers.

The SPF algorithm determines how the various pieces of the puzzle fit together. Figure 2-3 illustrates all of these pieces put together in operation.

Figure 2-3 Link-State Operation

Link-state protocols such as OSPF flood all the routing information when they first become active in link-state packets. After the network converges, they send only small updates via link-state packets.

OSPF CharacteristicsOSPF is a link-state protocol in which all routers in the routing domain exchange infor-mation and thus know about the complete topology of the network. Because each router knows the complete topology of the network, the use of the SPF algorithm creates an extremely fast convergence. Other key characteristics of OSPF are as follows:

• Provides routing information to the IP section of the TCP/IP protocol suite, the most commonly used alternative to RIP.

• Sends updates to tables only, instead of entire tables, to routers.

• Is a more economical routing protocol than RIP over time because it involves less network traffic.

��

��

��

��

�

�

�

��

��

�� ! �� "

�� !�� ! �� "

0323FMf.book Page 53 Wednesday, March 12, 2003 9:41 AM

Source: Thomas M. Thomas, “OSPF Network Design Solutions,” 2nd. Ed., Cisco Press, 2003.


(1) Link-State Routing (Source: University of Calgary, CPSC 441)

2

Link-State (LS) Routing AlgorithmDijkstra’s algorithm

� topology and link costs known to all nodes

� accomplished via “link state broadcast”

� all nodes have same info

� computes least cost paths from one node (source) to all other nodes

� gives forwarding table for that node

� iterative: after k iterations, know least cost path to k destination nodes

Notation:

� c(x,y): link cost from node x to y; set to ∞ if a and y are not direct neighbors

� D(v): current value of cost of path from source to dest. v

� p(v): v’s predecessor node along path from source to v

� N': set of nodes whose least cost path is definitively known



3

Dijsktra’s Algorithm1 Initialization (u = source node):2 N' = {u} /* path to self is all we know */3 for all nodes v 4 if v adjacent to u 5 then D(v) = c(u,v) /* assign link cost to neighbours */ 6 else D(v) = ∞7 8 Loop9 find w not in N' such that D(w) is a minimum 10 add w to N'11 update D(v) for all v adjacent to w and not in N' : 12 D(v) = min( D(v), D(w) + c(w,v) ) 13 /* new cost to v is either old cost to v or known 14 shortest path cost to w plus cost from w to v */ 15 until all nodes in N'



4

Textbook – Problem 4.21 – x is source

∞6,x1,x3,x∞∞∞x0D(z),p(z)D(y),p(y)D(w),p(w)D(v),p(v)D(u),p(u)D(t),p(t)D(s),p(s) N’Step

w

t

s39

13

2

4

14

2

11

14

61

y

xv

u

z

Initialization: - Store source node x in N’- Assign link cost to neighbours (v,w,y)- Keep track of predecessor to destination node



5


∞6,x2,w4,w∞∞xw1∞6,x1,x3,x∞∞∞x0D(z),p(z)D(y),p(y)D(w),p(w)D(v),p(v)D(u),p(u)D(t),p(t)D(s),p(s) N’Step

w

t

s39

13

2

4

14

2

11

14

61

y

xv

u

zNode and its minimum cost are colour-coded in each step

Loop – step 1: - For all nodes not in N’, find one that has minimum cost path (1)- Add this node (w) to N’- Update cost for all neighbours of added node that are not in N’repeat until all nodes are in N’



6


7,txwvuyts67,t6,txwvuyt517,y5,u7,uxwvuy4∞3,v5,u7,uxwvu3∞3,v3,v11,v∞xwv2∞6,x2,w4,w∞∞xw1∞6,x1,x3,x∞∞∞x0D(z),p(z)D(y),p(y)D(w),p(w)D(v),p(v)D(u),p(u)D(t),p(t)D(s),p(s) N’Step

w

t

s39

13

2

4

14

2

11

14

61

y

xv

u

zNode and its minimum cost are colour-coded in each step



7


7,txwvuyts67,t6,txwvuyt517,y5,u7,uxwvuy4∞3,v5,u7,uxwvu3∞3,v3,v11,v∞xwv2∞6,x2,w4,w∞∞xw1∞6,x1,x3,x∞∞∞x0D(z),p(z)D(y),p(y)D(w),p(w)D(v),p(v)D(u),p(u)D(t),p(t)D(s),p(s) N’Step

w

t

s39

13

2

4

14

2

11

14

61

y

xv

u

zWe can now build x’sforwarding table. E.g. the entry to s will be constructed by looking at predecessors along shortest path: 6,t � 5,u �3,v � 2,w (direct link)So forward to s via w


The second family of intra-domain routing protocols

(2) Distance Vector Routing

Distance vector means that the information sent from router to router is based onan entry in a routing table that consists of the distance and vector to thedestination:

Distance being what it “costs” to get thereVector being the “direction” to get there — direction strictly means thenext hop address and exit interface to which packets must be forwarded.

Distance vector algorithms call for each router to send its entire routing table, butonly to its neighbors.

The neighbor then forwards its entire routing table to its neighbors, and so on.

Notice that the routers using a distance vector protocol do not have knowledge ofthe entire path to a destination.


(2) Distance Vector Routing (cont.)

What Is a Routing Protocol? 55

Distance Vector Routing ProtocolsDistance vector means that information sent from router to router is based on an entry in a routing table that consists of the distance and vector to destination—distance being what it “costs” to get there and vector being the “direction” to get to the destination.

Distance vector protocols are often referred to as Bellman-Ford protocols because they are based on a computation algorithm described by R. E. Bellman; the first description of the distributed algorithm is attributed to Ford and Fulkerson. Distance vector algorithms (also known as Bellman-Ford algorithms) call for each router to send its entire routing table, but only to its neighbors. The neighbor then forwards its entire routing table to its neighbors, and so on. Figure 2-4 illustrates this routing table forwarding process.

Figure 2-4 Distance Vector Operation

As Figure 2-4 illustrates, whenever a change to the network occurs, this causes the entire routing table to be sent from neighbor to neighbor in order for the network to reconverge in response to the network event (network down). What is not shown is the periodic sending of the routing table between neighbors—a mechanism that double-checks that the routing information each router has is valid.

�

�

�

�

��

��

��

��

��

��

��

��

�� !�� " �# �� "��$

0323FMf.book Page 55 Wednesday, March 12, 2003 9:41 AM

Source: Thomas M. Thomas, “OSPF Network Design Solutions,” 2nd. Ed., Cisco Press, 2003.


(2) Distance Vector Routing (cont.)

Based on Bellman-Ford distance

dx(y): cost of least-cost path from node x to node yc(x , v): cost of the direct link from node x to node vThen, ∀ node v that is a neighbor of node x do

dx(y) = minv

{c(x , v) + dv (y)}


(2) Distance Vector Routing (Source: U. of Calgary, CPSC 441)

9

Bellman-Ford Equation Example

u

yx

wv

z2

2

13

1

1

2

53

5

Consider a path from u to zBy inspection, dv(z) = 5, dx(z) = 3, dw(z) = 3

du(z) = min { c(u,v) + dv(z),c(u,x) + dx(z),c(u,w) + dw(z) }

= min {2 + 5,1 + 3,5 + 3} = 4

Node that achieves minimum is nexthop in shortest path ➜ entry in forwarding table

B-F equation says:



10

Distance Vector AlgorithmBasic idea:� Nodes keep vector (DV) of

least costs to other nodes� These are estimates, Dx(y)

� Each node periodically sends its own DV to neighbors

� When node x receives DV from neighbor, it keeps it and updates its own DV using B-F:

Dx(y) ← minv{c(x,v) + Dv(y)} for each node y � N

� Ideally, the estimate Dx(y) converges to the actual least cost dx(y)

On each node:

wait for (change in local link cost or msg from neighbor)

recompute estimates

if DV has changed, notifyneighbors



117 1 0 time

x z12

7

y

x y zxyz0 2 7∞∞ ∞∞∞ ∞fr

omcost to

from

from

x y zxyz

∞ ∞

∞∞ ∞

cost to

x y zxyz ∞ ∞ ∞

cost to

∞2 0 1

∞ ∞ ∞

node x table

node y table

node z table

Step 1: InitializationInitialize costs of direct links

Set to ∞ costs from neighbours



127 1 0 time

x z12

7

y

Dx(y) = min{c(x,y) + Dy(y), c(x,z) + Dz(y)} = min{2+0 , 7+1} = 2 Dx(z)=min{c(x,y)+Dy(z), c(x,z)+Dz(z)}

= min{2+1 , 7+0} = 3

x y zxyz0 2 7∞∞ ∞∞∞ ∞fr

omcost to

from

from

x y zxyz0 2 3

from

cost to

x y zxyz

∞ ∞

∞∞ ∞

cost to

x y zxyz ∞ ∞ ∞

cost to

∞2 0 1

∞ ∞ ∞

2 0 17 1 0

node x table

node y table

node z table

Step 2: Exchange DV and iterate-In first iteration, node x saves neighbours’ DVs-Then, it checks path costs to all nodes using received DVs-E.g. new cost Dx(z) is obtained by adding costs marked red



137 1 0 time

x z12

7

y

In similar fashion, algorithm proceeds until all nodes have updated tables

x y zxyz0 2 7∞∞ ∞∞∞ ∞fr

omcost to

from

from

x y zxyz0 2 3

from

cost tox y zxyz0 2 3

from

cost to

x y zxyz

∞ ∞

∞∞ ∞

cost tox y z

xyz0 2 7

from

cost tox y z

xyz0 2 3

from

cost to

x y zxyz0 2 3

from

cost tox y z

xyz0 2 7

from

cost tox y z

xyz ∞ ∞ ∞

cost to

∞2 0 1

∞ ∞ ∞

2 0 17 1 0

2 0 17 1 0

2 0 13 1 0

2 0 13 1 0

2 0 1

3 1 02 0 1

3 1 0

node x table

node y table

node z table


One family of inter-domain routing protocols (EGPs)

(3) Path Vector Routing: the basics

For scalability and confidentiality reasons, the routing information managed andexchanged among ASs is highly condensed.

Differently from link-state routing protocols, which maintain the topological stateof the network, path routing protocols only handle AS-level paths for any possibledestination.

An AS-level path is composed of a set of attributes, including an orderedsequence of AS numbers (a vector of ASs) that need to be traversed to reach adestination. This routing paradigm is thus called path vector routing.

The two main goals of path vector routing

To distribute reachability information among domains in a “highly scalableway”.

To find loop-free paths among domains.


(3) Path Vector Routing

[0]

[1 0]

[0]

[2 0]

10.0.0.0/8

10.0.0.0/8

1

0

[0]

[2 0] [2 0] [3 2 0]

[0]

[1 0]

10.0.0.0/8

[2 0]

10.0.0.0/8

[3 2 0]

10.0.0.0/8

2 3 4


(3) Path Vector Routing (cont.)

Similarities between distance and path Vector Routing

Distance vector protocols choose routes according to the shortest distance to adestination (e.g., the least number of routers to be traversed)

Path vector protocols will generally choose the route that traverses the leastnumber of ASs

The term “generally” is because the AS-path length (a rough sense of distance)is the attribute that is typically considered during the route selection process, butis not the only one.

Route selection in path vector protocols is much more complex than in distancevector routing.

Path vector routers can filter routes based on multiple and elaborated criteria.

They can change the preference of a route and override the AS hop count, andeven change the attributes of the routes they use and advertise to other devicesbased on commercial interests and the policies locally configured on each router.

The combination of these features allows domains to enforce their routingpolicies, enabling control over their traffic according to their criteria.


Relationships between ASs (Myth)

There are three types of relationships ...

... which correspond to the different traffic exchange agreements betweenneighboring domains

customer-provider : applies when a domain buys Internet connectivity from aprovider.

peer-peer : applies when two providers that exchange a significant amount oftraffic, agree to connect directly to each other to avoid transiting through, andthus pay, a third-party provider. Peers share the costs of the connection betweenthem, so there is no customer-provider relationship in this case.

sibling-sibling: this relationship is quite infrequent, and are sometimes usedbetween merging companies. According to data from CAIDA’s AS RelationshipsDataset, less than 0.3% of the total number of relationships between Internetdomains were siblings in March of 2010.


Tiered Hierarchy of Autonomous Systems (Myth)

MultihomedStub Domain Stub

Domain

MultihomedStub Domain

Transit Domain

Transit Domain

Transit Domain

Transit DomainTransit Domain

$

$

$

$

$

$

$

$

$


(3) Path Vector Routing: path selection process

Are there customerroutes available?

Prefer peer routes over provider routesindependently of the AS-path length

Are there peerroutes available?

Is there more thanone possible route?

Prefer customer routes over peeror provider routes independently

of the AS-path length

Yes

No

Yes

No

Yes

No

No

Return no_route

Input: A set of candidate routes to reach dOutput: The best route to reach d

1: Choose the route with the highest preferenceaccording to the outbound policy locallyconfigured

2: If the outbound preferences are equal, choosethe route with the shortest AS-path (i.e., theshortest path vector)

3: If the AS-paths lengths are equal, choose theroute with the highest preference according tothe inbound traffic policies advertised by theneighbors

4: If the neighbors’ inbound preferences areequal, prefer external routes over internalroutes

5: If the routes are still equally preferred, choosethe one with the lowest metric to the next-hoprouter according to the internal routing cost

6. Run tie-breaking rules

Decision Process of a Path Vector Protocol

Yes

Return best_route

Are there providerroutes available?


(3) Path Vector Routing: inside the router ...

NeighborAS

NeighborAS

Inbound filtersfor the neighbor

Inbound filtersfor the neighbor

NeighborAS

NeighborAS

Outbound filtersfor the neighbor

Outbound filtersfor the neighbor

Pathcomputation

RoutingInformationBase (RIB)

ForwardingInformationBase (FIB)


The Border Gateway Protocol (BGP): RFC 4271, 2006

IEEE Network • November/December 200550

The two types of stub ASes crowd together mostly mediumand large enterprise customers, content service providers (CSPs),and small network service providers (NSPs). These two groupscorrespond to the largest fraction of ASes present in the Inter-net. The third type includes most Internet service providers(ISPs) in the Internet.

In today’s Internet, there is a hierarchy of transit ASes [5]. Thishierarchical structure is rooted in the two different types of rela-tionships that could exist between ASes (i.e., customer-provideror peer-to-peer). Thus, for each transit AS any directly connectedAS is either a customer or peer. At the top of this hierarchy wefound the largest ISPs, which are usually referred to as Tier-1ISPs. There are about 20 Tier-1s at present [5], which representsless than 0.1 percent of the total number of ASes in the Internet[4]. These Tier-1s are directly interconnected in almost a fullmesh and compose the Internet core. In the core all relationshipsbetween Tier-1s are peer-to-peer, so a Tier-1 is any ISP lackingan upstream provider. The second level of the hierarchy is com-posed of Tier-2 ISPs. A Tier-2 is any transit AS that is a customerof one or more Tier-1 ISPs. A representative example of a Tier-2ISP is a national service provider. Tier-2 ISPs tend to establishpeer-to-peer relationships with other neighboring Tier-2s for botheconomical and performance reasons. This is typically the case forgeographically close Tier-2 ISPs that exchange large amounts oftraffic. There are also Tier-3 ISPs, which are those transit ASes inthe hierarchy that are customers of one or more Tier-2 ISP, suchas regional ISPs within a country. Stub ASes are non-transit ASesthat are customers of any ISP (Tier-1, Tier-2, or Tier-3). In Fig. 1ISPs such as AS11, AS12, AS21, AS23, and AS31 would be classi-fied as Tier-2 ISPs, while AS22 represents a Tier-3 ISP. Animportant corollary of this hierarchical structure is that the diame-ter of the Internet is very small in terms of AS hops.

The Border Gateway Protocol (BGP) is currently the defacto standard interdomain routing protocol in the Internet.Its current official2 release is BGP-4, which was specified in[6] on March of 1995. BGP is used to exchange reachabilityinformation throughout the Internet, and it is mainly an inter-AS routing protocol. However, the reachability information anAS learns from the exterior needs to be distributed within theAS so that every router in the AS could properly reach desti-nations outside the AS. When reachability information isexchanged between two BGP routers located in differentASes, the protocol is referred to as external BGP (eBGP). Onthe other hand, when reachability information is exchangedbetween BGP routers located inside the same AS, the proto-col is referred to as internal BGP (iBGP).

For instance, in AS1 the reachability information R11 learnsfrom AS11 is received over eBGP. This information is passed

from R11 to the routers inside AS1 (i.e., R12 and R13) so thatthey are able to reach the routes advertised by AS11. Thisexchange of reachability information between R11 and the inter-nal routers in AS1 is done by means of iBGP. The same occursfor the external routes R12 learns from AS12.

For scalability reasons BGP does not try to keep track of theentire Internet’s topology. Instead, it only manages the end-to-end AS path of one route in the form of an ordered sequence ofAS numbers. For this reason BGP is known as a path vectorrouting protocol, to reflect the fact that it is essentially a modi-fied distance vector protocol. While a typical distance vector pro-tocol like RIP chooses a route according to the least number ofrouters traversed (router hops), BGP generally chooses the routethat traverses the least number of ASes (AS hops). For example,the BGP process running in router R21 will typically choose toreach AS1 via the ASes AS21 and AS12. Thus, the AS path cho-sen by R21 is {AS21, AS12, AS1} (please notice that the Inter-net core accounts for at least one AS hop more in the AS path ifonly one Tier-1 ISP is traversed while reaching AS1).

The term generally mentioned before is due to the fact thatthe AS path length is one of the steps of the BGP decision pro-cess, but not the only one. This decision process is used for routeselection each time a BGP router has at least two differentroutes for the same destination. Thus, BGP routing is more com-plex than simply minimizing the number of AS hops. BGProuters have built-in features to override the AS hop count, andto tiebreak if two or more routes have the same AS path length.The sequence of steps in Fig. 2 represents a simplified version ofthe BGP decision process.

In this process each subsequent step is used to break ties whenthe routes being compared were equally good in the previousstep. The local preference (LOCAL_PREF) in step 1 and themulti-exit discriminator (MED) in step 3 are two BGP attributesthat are used by BGP routers for controlling how traffic flowsfrom and into an AS, respectively. A detailed explanation of thisprocess can be found in [7].

After this short description of the main components and theirroles in interdomain routing, we follow with some of the mainopen issues in this area.

Research Challenges in Interdomain RoutingIn the last years the Internet has largely expanded in several ways.First, the number of ASes connected to the Internet has increasedenormously [2]. Second, the number of connections per AS to thenetwork has also significantly augmented [8]. Third, the numberand diversity of the applications supported in the Internet haveremarkably increased as well. This tendency has increased thedemands on the scale of the network, and hence is placing signifi-cant pressure on the scalability and convergence of BGP.

In addition, the current interdomain routing structure is notprecisely prepared to handle the service characteristics severalapplications are demanding from the network. In effect, the end-to-end performance of these applications is not only affected bythe limitations of BGP, but also by the diversity of interests andlack of cooperation between the ASes composing the Internet.Therefore, several issues remain to be solved in the area of inter-domain routing. This section analyzes several significant chal-lenges faced by researchers in the area today. The methodologywe follow is first to introduce the problem. Next, we survey sev-eral proposals addressing the issue, and try to discriminate whichare in fact operational palliatives. After that, we discuss whydespite these efforts each issue remains largely open.

The order in which the issues are presented is chosen so as togradually introduce the distinct aspects of BGP and the interdo-main routing paradigm, as well as to link how the initial set ofissues influences the subsequent ones.

n Figure 1. A simplified interdomain scenario.

R13

AS1

AS12

AS3

AS31

AS23

AS2R22

R21AS21

BGP router

Internetcore

AS11iBGP

eBGP

eBGP

R12R11

R31 R32

AS22

2 The IDR working group of the IETF has finalized the revision of [6].This revision documents the currently deployed code.

YANNUZZI LAYOUT 11/3/05 12:07 PM Page 50

eBGP: External Border Gateway Protocol

iBGP Internal Border Gateway Protocol


The intra/inter-domain merge: Transit Providers

3RIPE 51

Interaction between IGP and BGP

San Francisco

Dallas

New York

ISP network

9 10

destination prefixmultiple egress points

Hot-potato routing = select closest egress point when there is more than one route to destination

Source: R. Texeira, “Hot Potatoes Heat Up BGP Routing,” RIPE 51, Amsterdam, Netherlands, October2005.



4RIPE 51

Impact of Internal Routing Changes

San Francisco

Dallas

New York

ISP network

destination prefix

9 10- failure- planned maintenance- traffic engineering

11

Routes to thousands of prefixes switch

egress points!!!Consequences:

Transient forwarding instabilityTraffic shiftInterdomain routing changes

11




9RIPE 51

BGP Impact of an OSPF Change

router Arouter B

Vast majority of OSPF changeshave no impact on these routers

… but few havea very big impact




22RIPE 51

Comparison of Network Designs

NY

10SF

Dallas

NY

1000SF

dstdst

Dallas

Small changes will make Dallas switch egress points to dst More robust to intradomain

routing changes

NY

109

SF

Dallas

dst

910

19



The intra/inter-domain merge: Non-transit domains


Questions?


Routing in the Future Internet - fing.edu.uy

Documents

Transcript of Routing in the Future Internet - fing.edu.uy