Transcript No Slide Title

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
© 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-ISP
Interconnect & 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 colocation 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-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 missioncritical 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



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
© 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:
 MetroXP 100:
Gigabit Ethernet
100baseT Ethernet
 MetroXP 10:
10baseT Ethernet &
Private Switched Peering (VLAN):
 MetroXP vConnect 100:
Virtual Private Interconnect
 MetroVPX:
Virtual Private eXchange
Private Interconnect:
 MetroXP iConnect:
 MetroXP Connect 1000:
 MetroXP Connect 622, 2400:
© XchangePoint 2001
In-site wiring PPI
Gigabit inter-site  OPI
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 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 supersophisticated 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 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
© 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:
Web:
E-mail:
Phone:
Keith Mitchell
www.xchangepoint.net
[email protected]
+44 20 7592 0370
Presentation:

http://www.xchangepoint.net/info/Xchange-IIR-SLA.ppt
© XchangePoint 2001