1. © XchangePoint 2001 Overview  SLA Credibility in the ISP Market  Applying SLAs to Inter-ISP Interconnect & Peering  XchangePoint’s Interconnect Service Platform  XchangePoint’s Approach to SLAs  Inter-ISP SLA Issues and Futures

2. © XchangePoint 2001 SLA Credibility in the ISP Market

3. © XchangePoint 2001

4. Are ISP SLAs taken seriously ?  There seems to be a cultural gulf in applying SLAs  engineering types don’t like getting involved in contractual details  commercial end-users have trouble understanding technically complex service parameters  There are different attitudes to SLAs amongst customers  some see them as essential supplier due diligence  others believe they are worthless pieces of paper which will be cynically ignored

5. © XchangePoint 2001 SLA Measurability and Credibility  There is little point in having SLA commitments in a contract unless:  all applicable the service parameters are measured  reports on conformance levels with the targets are easily available to both customer and supplier  the parameters are well understood by both customer and supplier  the supplier takes meeting the targets seriously  Abuse of the above principles has been a cause of SLA cynicism in the ISP marketplace  Better to have a small number of well-understood parameters which meet the above criteria than a long list which only do so partially

6. © XchangePoint 2001 Carrier Service Quality in a Bear Market  Market contraction is causing widespread deterioration in users’ service perception  Reduced help desk staff  Inflexible and over-zealous credit checking  Excessive lead times  Services being withdrawn  Contact points in state of flux  Which company is my invoice from this month ?  Uncertainty about financial stability of providers

7. © XchangePoint 2001 Carrier Service Quality in a Bear Market  My evidence is anecdotal, but does any of this sound familiar ?  Key to survival and success in current market conditions is to address users’ service requirements  This does not need to be complex  Important to focus on core subset of service parameters that are important to users, and uphold levels for these

8. © XchangePoint 2001 Applying SLAs to Inter-ISP Interconnect & Peering

9. © XchangePoint 2001 Internet Interconnect Architecture  Multiple ISPs locate backbone nodes in single building operated by co-location provider  In-building connections  to shared interconnect fabric using ethernet LAN switching technology  over point-to-point private interconnections  Routing information exchanged bi-laterally between ISPs using BGP  Interconnect operator need not be same organisation as co- location provider  CoLo will generally have other customers:  carriers, hosting, ASPs, content distributors

10. © XchangePoint 2001 IPP Advantages  Reduced bandwidth costs  Improved throughput and latency performance  Economies of scale  Single large pipes to one IPP more efficient than many small private interconnects to many ISPs  Better resilience and availability  Critical mass of ISPs in single location creates competitive market in provision of capacity, transit and services

11. © XchangePoint 2001 Peering and Transit  Peering: Two ISPs agree to provide access to each others’ customers  commonly no money changes hands: “settlement free”  barter of perceived equal value  simple commercial agreements  traditionally across public peering points, no SLA  Transit: One ISP agrees to give another’s customers access to the whole Internet  they always charge for this !  usually volume and/or capacity based  typically across private interconnects, with SLA  Other models exist

12. © XchangePoint 2001 Types of Interconnect  Public Peering  Virtual Interconnect  VPI - Virtual Private Interconnect  VPX - Virtual Private eXchange  VPH - Virtual Private Hub  VPN - Virtual Private Network  Private Interconnect  WPI - WAN circuit (SDH/SONET) Private Interconnect  OPI - Optical Private Interconnect  PPI - Physical Private Interconnect

13. © XchangePoint 2001 The Importance of Cross-ISP end-to-end SLAs  Users will often need VPN or extranet requirements to be serviced by more than one ISP  Clearly the interconnection path between the ISPs is as mission- critical as the ISP’s individual backbones  The user will ideally want an end-to-end SLA for this, but most ISPs can only guarantee their SLA over their own infrastructure  An SLA for the Internet as a whole is impossible, but user requirements can usually be met by back-to-backing SLAs through inter-ISP transit/peering contracts  This requires SLA agreements to be contracted to by all parties along all paths between ISPs, including the transit/peering interconnect provider

14. © XchangePoint 2001 What SLA Parameters are Applicable in Peering/Transit Agreements  Availability  Packet Loss  Delay/Latency  Service installation lead time  Throughput  Jitter  Fault response and resolution paths and timescales  Service credits are only meaningful for paid (normally transit or settlement-based) arrangements

15. © XchangePoint 2001 Difficulties of Implementing SLAs in an Interconnect Point Environment  At present, only XchangePoint in Europe, and a small number of operators in the USA even offer SLAs for their IPP services  Hard to distinguish between failure of customer router equipment and failure of service to customer  Hard to measure end-to-end packet loss and delay from middle when there is no access to customer router equipment at ends  almost no traffic terminates on IPP operator’s own network  Many traditional IPPs have multiple parties responsible for different aspects of their operations  lack of ownership and demarcation of responsibilities  Membership-owned traditional IPPs have tended to duck liability issues

16. © XchangePoint 2001 XchangePoint’s Interconnect Service Platform

17. © XchangePoint 2001 Architecture Overview  Present at multiple co-location sites per city  Dark fibre metro ring connecting all sites in city  Ethernet switches at all sites  DWDM equipment at major sites  Gigabit Ethernet between switches and sites  10-Gigabit capable

18. © XchangePoint 2001 Ethernet Switches  2 Black Diamond/Alpine Ethernet switches at each site  All switches are non-blocking  Each switch at each site connected to one of two separate wavelength overlay networks

19. © XchangePoint 2001 DWDM Configuration  system supports 32 protected wavelengths ( ) per fibre ring  Initial configuration 8  3 for backbone  5 for customer OPIs  Remaining can be used to increase backbone or OPI capacity in 1Gb/s or 10Gb/s increments

20. © XchangePoint 2001 Optical Private Interconnect  For customers with requirements for:  high traffic volumes  dedicated capacity  additional security/resilience  Uses dedicated DWDM /channel  Gigabit Ethernet  STM-4, STM-16  T3, STM-1, STM-64 options during 2002  Protected and unprotected options

21. © XchangePoint 2001 VLAN-based Services  Demand in market for:  Point-to-Point Virtual Private interconnects using 100Mb/s Ethernet  “Closed User Group” Virtual Private Exchanges  e.g. for:  connecting transit customers to wholesaler  higher levels of security and robustness  peering communities with particular requirements  Lower cost than optical private interconnect, easy migration path  Can mix these services with public peering on same port  Can be used as a VPN service, but not main target audience

22. © XchangePoint 2001 Service Offerings  Copper & fibre in-building connection to node:  MetroXP Install  Public Switched Peering:  MetroXP 1000:Gigabit Ethernet  MetroXP 100:100baseT Ethernet  MetroXP 10:10baseT Ethernet &  Private Switched Peering (VLAN):  MetroXP vConnect 100:Virtual Private Interconnect  MetroVPX:Virtual Private eXchange  Private Interconnect:  MetroXP iConnect: In-site wiring PPI  MetroXP Connect 1000: Gigabit inter-site OPI  MetroXP Connect 622, 2400: SDH inter-site OPI

23. © XchangePoint 2001 Service Status  London network has been live for over 9 months  Service trial completed successfully  Now 23 customers, generating revenue  Peaking >110Mb/s traffic  Have met SLA targets throughout  Paris and Frankfurt planned during 2002

24. © XchangePoint 2001 XchangePoint's Approach to SLAs

25. © XchangePoint 2001 Keep it Simple, Measurable, Credible  Our background is from an ISP and IPP culture rather a carrier one - taking SLAs seriously has been slightly alien to us !  Today’s market conditions:  do not allow vast amounts of money to be piled into super- sophisticated network management/monitoring systems  require that quality of service provision to the customer adheres to the highest competitive standards  So our approach is one of: Have a small number of simple and well-understood parameters which we measure, report, commit to and exceed consistently  Our network architecture helps with this

26. © XchangePoint 2001 What we measure: Availability  Measure availability of our equipment and network  Infer service availability of service to customer from this  by “ping”ing customer router interface  by checking up/down state of switch port to router  Meet 99.9% on any single port to a customer  Our network is highly resilient, but full service redundancy can only be achieved:  for switched services, if customer takes >1 port on >1 switch per site  for OPI service, if customer opts for optical protection option  these allow higher availability level of 99.97%

27. © XchangePoint 2001 What we Measure: Responsiveness  These are mainly management process issues, not technical ones  Service lead time within 10 days  very important in a market where lead times for traditional interconnect circuits in high demand metro areas can be 45-90 days  Customer support requests  initial response within 5 minutes  escalate after 4 hours  resolve within 8 hours  24x7 NOC

28. © XchangePoint 2001 What we don't measure and why  Throughput: our network is designed to be non-blocking, customer can utilise port at 65% capacity guaranteed  Delay:  network is metro area only  round-trip times will only ever be a few milliseconds unless there is a more fundamental problem  Jitter: see above  Packet Loss:  see above re Throughput  we would like to be able to measure this better, however  more sophisticated tools needed  >1% packet loss is counted is availability failure meantime

29. © XchangePoint 2001 What we commit to and deliver  http://www.xchangepoint.net/custinfo/SLA.html  Service provision within 10 days of order  Response to 24x7 customer support requests  Availability: 99.97%  Packet loss:  0% within single site  0.05% between sites  Rebates for failure to perform

30. © XchangePoint 2001 Realtime Traffic Data as an Availability Tool

31. © XchangePoint 2001 Realtime Traffic Data as an Availability Tool  Very simple principle:  publish traffic shipped through network in real-time  MRTG is “industry-standard” tool for this  Multi Router Traffic Grapher  http://www.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg.html  Demonstrates not just traffic levels, but availability as well  Good practice to put aggregate statistics in public domain  but keep per-customer statistics private to customer  MRTG can record many network metrics, not just bits per second

32. © XchangePoint 2001 Acceptable Use Policy  http://www.xchangepoint.net/custinfo/AUP.html  Designed to:  be minimally restrictive  protect customers and infrastructure from malice/accidents  Main principles:  nature of traffic and commercial terms are purely bi-lateral matter for peers  don’t do anything that affects other customers adversely  More constraints for public peering than private interconnect  e.g. AS number and PI address space needed for public peering

33. © XchangePoint 2001 Interaction Between an SLA and Acceptable Use Policy  Use SLA as a way of encouraging customers to make best use of services  e.g. If customer utilises port >65% and risks congestion, full SLA no longer guaranteed  incentive to upgrade service capacity  Encourage multi-homing on >1 port for higher 99.97% rather than 99.9% availability level  “Non-standard” traffic addressed in SLA rather than AUP  grey area between what is prohibited by AUP, and what services can be fully supported by SLA  gives customer flexibility while protecting network

34. © XchangePoint 2001 Future SLA challenges at Internet Peering Points  Multicast  how to measure packet loss when one packet goes to many destinations ?  Data gathered at peering points can be a very useful measure of network health, e.g.  Measurement boxes: unidirectional & round trip-times, packet loss  Routing Tables: route flap, average AS-path length  middle-to-middle rather than end-to-end, though  IPv6, 10Gb/s ethernet  no new challenges in principle, but tools will need updating

35. © XchangePoint 2001 Contact Details CTO:Keith Mitchell Web:www.xchangepoint.net E-mail:info@xchangepoint.net Phone:+44 20 7592 0370 Presentation:  http://www.xchangepoint.net/info/Xchange-IIR-SLA.ppt