Tuesday, March 9, 2010

Service Assurance: IP Quality of Service

This week I will be attending the EFIPSANS technical review in Brussels. One aspect of this project is mechanisms for delivering QoS for IP networks which coincidentally was the subject matter of my very first research project called EUROBRIDGE, a EU funded RACEII project, back in 1993 when I worked for Broadcom Eireann Research! I remember clearly a conversation I had with a colleague of mine while walking down the street in Aveiro, Portugal coming from a project meeting in November of that year. We were talking about how the Internet needed a killer application and we were at pains trying to think of what that could be. I had yet to see a web browser, which followed soon after and how things have change since! At that time IP networks were used for data networks and data services only and circuit switched networks was what was required for serious business.

Despite IP having since becoming ubiqitious, somethings have never changed. IP is fundamentally a "best-effort" technology which makes assuring IP services difficult and while DiffServ and IntServ provided technical ways of achieving this, the business case for doing so was weak. ISPs generally competed for customers based on two variables: price and bandwidth. In recent years, through convergence and new market entrants, competitive pressures have seen a decline in revenues from bandwidth which was sold effectively as "dumb pipes" and operators now seek to restore revenue growth through the provisioning of premium services such as triple play (Phone, TV and Internet). Therefore the need for assuring services delivered on IP networks is of renewed importance. The business environment has changed.

Research projects, like EFIPSANS, is defining an autonomic architecture for the self-management of IPv6 networks. One of the most important functions of such a system is the ability to continuously 'sense' how its performing within its environment. Telecoms networks do this by continuously collecting and analysing performance statisitics - millions of them 24/7, 365 days a year. From an end-user or customer perspective however, their main concern is of course that the services they use and pay for are performing end-to-end to the level that is expected. Our research in EFIPSANS is taking a customer-centric or path-based view for performance monitoring rather than a network-centric view.

The first challenge is to gather the most relevant performance data that will tell us something about the performance along the path. One thing that's clear is that there is no one tool that fits all. The following is a list of some key tools or techniques that can be used:
  • traceroute - discovers IP addresses along a path including the round-trip delay
  • hello - can be used to detect link failures along a path
  • pathchar - used to estimate link bandwidth and estimated available bandwidth
  • IPMP - used for measuring one-way delay
  • IPFIX - used to export IP flow information from an single observation point
  • Probes - used to mimic the experience of user data
  • SNMP - provides a more device-centric view on performance
The above may help an operator to identify or confirm that there is a problem with a specific path in the network, although it might be difficult to identify where on the path or why there is a problem. In EFIPSANS we are working on an IETF Internet Draft proposal for helping do just that by defining a new protocol that can be used to retrieve management information from each node along a path that will facilitate more targetted monitoring and diagnosis for fault recovery, fault mitigation as well as optimisation.

While its one thing to gather performance data using some or all of the above, its what you do with it that really counts. This is where vendors of service assurance solutions can differentiate themselves by offering functionality that offers capabilities that can add real value to their customers. Where these solutions can really make a difference is by identifing potential problems before they result in an outage or service degradation so that preventative measures can be taken resulting smooth operation of revenue generating services.

No comments:

Post a Comment