Validating Inter-Domain SLAs with a Programmable Traffic Control System

1
Validating Inter-Domain SLAs with a Programmable
Traffic Control System

• Elisa Boschi elisa.boschi_at_hitachi-eu.com
• Matthias Bossardt bossardt_at_tik.ee.ethz.ch
• Thomas Dübendorfer duebendorfer_at_tik.ee.ethz.ch

IWAN 2005
2
MOTIVATION

• Services (VoIP, multimedia streaming) require a
  minimum level of performance
• Negotiated in Service Level Agreements
• When Service Level Agreements cross ISP
  boundaries
• how to validate the compliance of network
  services to the guarantees in an SLA
• Problems
• ISPs have minimal information about
  characteristics and performance of other networks
• Performance of specific path portions

3
SCENARIO (jitter measurement)

• ? Requires dynamic configuration of devices
  located in different domains
• Major security concerns

4
HOW CAN WE ACHIEVE THIS

• Deploying measurement logic on distributed
  programmable Traffic Processing Devices (TPDs)
• Attached to routers
• Located in several Autonomous Systems
• Almost abitrary service logic (flexibility)
• Configuration on-demand of TPDs on the end-to-end
  path
• Delegation of partial management capabilities to
  network users
• Security against misuse...

5
GOLDEN RULES

• TRAFFIC OWNERSHIP traffic control is restricted
  to the owner of source IP address or
  destination IP address
• Source and destination IP addresses cannot be
  modified
• The TTL field of IP packets cannot be modified
• The packet rate must not increase.
• The amount of traffic leaving the TPD must be
  equal or less than the amount of traffic entering
  it.

6
TRAFFIC CONTROL SYSTEM (TCS)

• A user registers with the Traffic Control Service
  Provider (TCSP)
• The TCSP manages the Traffic Control services
• Checks users identity
• Verifies the IP Addresses ownership with Internet
  Number Authorities
• Sets up contracts with ISPs
• ISPs attach Traffic Processing Devices to (some
  of) their routers
• Enable their network management system to program
  and configure them

7
NODE ARCHITECTURE

• The router is extended with a programmable
  Traffic Processing Device (TPD)

8
DEPLOYMENT PROCESS

• The deployment process is subdivided in layers
• For each service a layer offers, a service
  descriptor specifies
• The mapping to sub-services
• Mandatory and optional parameters
• Restrictions
• Deployment logic on each layer maps the service
  request to services provided by the layer below
• Based on service descriptors

9
SERVICE REQUEST
10
DELAY VARIATION DEPLOYMENT (1/2)

• The service offered by the TCSP and the required
  parameters are described in a service descriptor
• The service request contains
• User identification
• Parameter values
• src and dest address
• Uplink I/F of A to ISP1
• Downlink I/F from ISPn to Z
• Collector address
• .

11
DELAY VARIATION DEPLOYMENT (2/2)

• The TCSP
• selects the ISPs according to the Restrictions
• BGP path from A to Z
• AS numbers are taken from the Context Database
• Maps the request to sub-services

• The ISPs
• select the Traffic Processing Devices
• Only on egress routers from prevAS to next AS
  and on uplink and downlink I/Fs

12
SERVICE COMPONENTS

• deployed on all TPDs
• Timestamp, packet ID, paket size are exported to
  the collector

13
CONCLUSIONS

• Guarantees given in an inter-domain SLA can be
  validated
• Measurement services are executed on a
  programmable TCS
• The TCS safely delegates partial control over
  TPDs to network user
• Measurement logic is deployed to TPDs in
  different ASs
• Highly modular (? reusability of components)
• Secure against misuse (golden rules)
• Other metrics possible
• Other services possible (DDoS mitigation)

14
SCALABILITY CONSIDERATIONS

• Scaling factors
• service subscribers
• ISPs deploying the service
• service components installed / user
• Bandwidth
• ? Service logic and state per TPD
• Memory needed is modest
• ? Signalling effort
• Small messages to few thousands ISPs not a
  bottleneck
• ? Traffic processing capacity
• HW solutions (FPGA) allow packet filtering at
  10Gbps

15
STATE OF THE ARTin inter-domain measurement

• NIMI SW system for building measurement
  infrastructures. Tools can be added (wrapper)
• IPMP Active measurement protocol based on packet
  probes suited to measure delay at router level
• 6QM Measurements are configured by sending an
  XML-based document to controllers on the
  end-to-end path
• Generally missing
• Flexible system to automatically deploy the
  service to the appropriate device
• Adequate guarantees for network data privacy and
  against misuse

16
INTER-DOMAIN QoS MODELS

• BILATERAL
• 2 providers interconnect at one or more points
  and agree on a set of metrics, methods...
• Just 2, no reausability
• COOPERATIVE
• Set of rules a cooperating group of ISPs has to
  follow
• Standards needed
• THIRD-PARTY
• Composes end-to-end results, responsible for
  site-to-site measurement
• More flexible

17
OUTLINE

• Motivation
• Scenario inter-domain jitter measurement
• Traffic Control System
• Node Architecture
• Deployment process
• Conclusions

18
BACK TO THE SCENARIO JITTER MEASUREMENT
19
components
20
SERVICE REQUEST
21
5 GOLDEN RULES (explaination)

• Such rerouting could wreak havoc easily (causing
  routing loops, interference with other routing
  mechanisms, transparent source spoofing, or
  forwarding of attack traffic).
• as it aims to set an upper bound of network
  resources a packet is able to use.
• we need to prevent that the service can cause
  amplifying network-like effects.
• The amount of the network traffic leaving the
  traffic processing device must be equal or less
  compared to the amount of traffic entering it.
  I.e. packet size may only stay the same or become
  smaller.