1. 1 June 2015 Validating Inter-Domain SLAs with a Programmable Traffic Control System Elisa Boschi elisa.boschi@hitachi-eu.comelisa.boschi@hitachi-eu.com Matthias Bossardt bossardt@tik.ee.ethz.chbossardt@tik.ee.ethz.ch Thomas Dübendorfer duebendorfer@tik.ee.ethz.chduebendorfer@tik.ee.ethz.ch IWAN 2005

2. 1 June 2015 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. 1 June 2015 SCENARIO (jitter measurement)  Requires dynamic configuration of devices located in different domains –Major security concerns

4. 1 June 2015 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. 1 June 2015 „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. 1 June 2015 TRAFFIC CONTROL SYSTEM (TCS) A user registers with the Traffic Control Service Provider (TCSP) The TCSP manages the Traffic Control services –Checks user‘s 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. 1 June 2015 NODE ARCHITECTURE The router is extended with a programmable Traffic Processing Device (TPD)

8. 1 June 2015 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. 1 June 2015 SERVICE REQUEST

10. 1 June 2015 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. 1 June 2015 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. 1 June 2015 SERVICE COMPONENTS deployed on all TPDs Timestamp, packet ID, paket size are exported to the collector

13. 1 June 2015 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. 1 June 2015 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. 1 June 2015 STATE OF THE ART in 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. 1 June 2015 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. 1 June 2015 OUTLINE Motivation Scenario: inter-domain jitter measurement Traffic Control System Node Architecture Deployment process Conclusions

18. 1 June 2015 BACK TO THE SCENARIO: JITTER MEASUREMENT

19. 1 June 2015 components

20. 1 June 2015 SERVICE REQUEST

21. 1 June 2015 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.