Using Measurement Data to Construct a Network-Wide

View

Jennifer RexfordAT&T Labs—Research

Florham Park, NJ

http://www.research.att.com/~jrex

Motivating Applications

• Basic usage reporting and trending– Application mix (P2P, Web, DNS, etc.)– Characterization per customer, per peer, etc.

• Network troubleshooting– Detect, diagnose, and fix problems in real time– Traffic: flash crowds, DDoS attacks, new hot apps– Routing: route flaps, blackholes, highjacked prefixes

• Traffic engineering and capacity planning– Tuning routing configuration to the prevailing traffic– Deciding where to add new links, new peers, etc.– Predicting the effects of the changes in advance

Need: network-wide view of topology, traffic, and routing

Measure, Model, and Control

Topology/configuratio

n

Changes tothe network

Operational network

Network-wide“what if”

tools

measure control

Offeredtraffic

Routeupdates

model

Network-Wide View

• Topology and configuration– Up routers, links, and routing sessions– Current IGP weights and BGP policies

• Offered traffic– Load between ingress and egress points– Traffic per destination prefix per ingress– Slice and dice by IP prefixes, port #s, etc.

• Routing advertisements– Routes learned via each eBGP session– All routes, before any import processing

Need: ubiquitous support for traffic and route monitoring

Traffic: Packet Sampling

• IETF working group on packet sampling (psamp)– http://www.ietf.org/html.charters/psamp-charter.html– Minimal functionality for packet-level measurement– Suitable for implementation in high-speed line cards– Tunable trade-offs between overhead and accuracy

• Basic idea: parallel filter/sample banks– Filter on header fields (src/dest, port #s, protocol)– 1-out-of-N sampling (random, periodic, or hash-

based)– Extract key header fields, output link, IP prefix, etc.– Send bundled group of records to a collection system

filter sample extract exportpacket record

Routing: BGP and IGP Monitoring

• Limitations of today’s approaches– Periodic table dumps

• Pro: all of the routes (best and alternate)• Con: coarse timescale and high router overhead

– BGP session with operational router(s)• Pro: continuous feed and limited overhead• Con: only the best routes, after import processing

• Onboard support for route monitoring– Special monitoring session with the router– Continuous export of received routing

messages– Different data format for higher efficiency– Omission of redundant info (e.g., refresh LSAs)

Conclusion

• Control requires a network-wide view– Topology, traffic, and routing

• Ubiquitous views require vendor support– Traffic statistics and routing data

• Onboard support must be very lightweight– Operation on high-speed links and routers

• Traffic measurement with packet sampling– Parallel filter/sample/extract/export banks

• Routing data via special monitoring session– Relaying of received routing updates/LSAs