© xchangepoint 2001 overview sla credibility in the isp market applying slas to inter-isp...

© 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


SLA Credibility in the ISP Market


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


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


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


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


Applying SLAs to Inter-ISPInterconnect & Peering


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


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


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


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


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


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


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’s Interconnect Service Platform


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


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


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


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


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


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


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's Approach to SLAs


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


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%


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


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


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


Realtime Traffic Data as an Availability Tool


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


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


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


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


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

© xchangepoint 2001 overview sla credibility in the isp market applying slas to inter-isp...

Documents

isp market slide

isp slas

futures slide

complex service parameters

slas interisp sla issues

bear market market contraction

competitive market

users service perception