© xchangepoint 2001 overview sla credibility in the isp market applying slas to inter-isp...
TRANSCRIPT
© XchangePoint 2001
Overview
SLA Credibility in the ISP Market
Applying SLAs to Inter-ISPInterconnect & Peering
XchangePoint’s Interconnect Service Platform
XchangePoint’s Approach to SLAs
Inter-ISP SLA Issues and Futures
© XchangePoint 2001
SLA Credibility in the ISP Market
© XchangePoint 2001
© XchangePoint 2001
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
© 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
© 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
© 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
© XchangePoint 2001
Applying SLAs to Inter-ISPInterconnect & Peering
© 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
© 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
© 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
© 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
© XchangePoint 2001
The Importance of Cross-ISPend-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
© 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
© 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
© XchangePoint 2001
XchangePoint’s Interconnect Service Platform
© 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
© XchangePoint 2001
Ethernet Switches
2Black 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
© 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
© 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
© 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
© 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
© 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
© XchangePoint 2001
XchangePoint's Approach to SLAs
© 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
© 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%
© 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
© 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
© 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
© XchangePoint 2001
Realtime Traffic Data as an Availability Tool
© 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
© 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
© XchangePoint 2001
Interaction Between an SLA andAcceptable 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
© 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
© XchangePoint 2001
Contact Details
CTO: Keith Mitchell
Web: www.xchangepoint.net
E-mail: [email protected]
Phone: +44 20 7592 0370
Presentation: http://www.xchangepoint.net/info/Xchange-IIR-SLA.ppt