This report takes Light Reading into somewhat contentious, but increasingly important, territory: IP-based services control and who does what in it.
It’s slightly contentious because, despite the niftiness of the phrase and the increasing frequency of its occurrence, it’s extraordinarily hard to nail down what counts as an IP-based services control product within a neat short list of types. It’s important because these are the products that are going to make fancy, IP-based, next-generation network services work and, it is to be hoped, deliver lots of new cash for carriers.
IP-based services control is needed for many reasons, but essentially it is to be able to have many different services running over a single universal IP network – as is done today over different networks, but more so, with the addition of new, complicated types of services. A very significant aspect of this is that many of these services (such as VOIP or IPTV) need sophisticated performance guarantees (such as high security and low latency and jitter), and these have to be set up and controlled for each service instance, since the underlying general-purpose IP network does not offer them by default. Also, of course, telcos want to extract revenues by creating ranges of different higher-value services and controlling customer access to them. So IP-based services control is very broad in scope, ranging from network to OSS/BSS aspects.
Part of the problem is that still-evolving technologies and network/service philosophies and standards are colliding with products for existing IP networks and services, with an inevitably rather messy result. In the past, service control has been single-service related, provided by the service supplier and locked into the service supplier's network equipment. As operators move to an NGN world with a single network supporting multiple services over multi-vendor network technology, they will be constrained by this silo approach to service control, which will make it very difficult to get all the right bits of service control to talk to one another.
Inevitably, this looming problem has led to the rise of standards to define what the constituent functions of service control are, what they should do, and how they should talk to one another across services and vendor equipment. Unfortunately, the subject can be properly discussed only in terms of abstract functional and software service architectures, making it largely incomprehensible to non-specialists. This report is thus purposely not very deep technically, but takes a pragmatic approach aimed at producing a workable initial view of product classification.
As with previous Who Makes What reports, we’ve done our best to create meaningful and useful product categories, and to identify as many vendors as we can within them – but we’re bound to have overlooked some, particularly as this is a new, difficult, and rapidly evolving area. So please feel free to point out omissions, by either posting a note on the message board linked to this article (our preferred method) or by sending an email to [email protected]. Please include IP-Based Services Control in the subject field to help us find messages. We will update the report, if necessary adding and refining product categories and names, as we receive comments from readers.
Here’s a hyperlinked list of contents:
IP-Based Services Control Overview
IP Service Characteristics
Bandwidth Management & Network Resource Control
Enhanced & Converged Routing
Packet Inspection/Analysis
Service/Policy Creation & Management
Session & Session Border Control
Traffic Management & Configuration
— Tim Hills is a freelance telecommunications writer and journalist. He's a regular author of Light Reading reports.
Acknowledgements
Particular thanks are due to Caroline Chappell of Services Software Insider; Donya Ekstrand, until recently with Operax AB , now with Ericsson AB (Nasdaq: ERIC); Antoine Guy of Allot Ltd. (Nasdaq: ALLT); and John Longo of Heavy Reading for their considerable help in providing material for this report.
A good way in to IP-based services control is to consider some of the things that it can do, and why they matter to carriers. Allot Communications, for example, says that its service control solutions can:
Manage oversubscription to enable carriers to serve more subscribers over a given infrastructure
Offer premium or new services to increase revenues, numbers of subscribers, and ARPU
Implement advanced billing models based on actual use of network services and reconciliation of network service offerings with subscribers’ actual network usage
Control and contain security threats to subscribers and the carrier network
Monitor network traffic to understand user- and application-level network use for troubleshooting, analysis, and long-term planning
This is, of course, the view of one particular vendor, but it does emphasize the wide-ranging nature of the subject and, despite the theoretical complexities, its very practical and financially important outcomes. It also emphasizes IP service control’s key role in new services, which Allot lists as including controlling peer-to-peer (P2P) traffic, tiered services for home and SOHO users, and SLAs to businesses for triple-play service packages that combine voice, video and data, and for ensuring acceptable performance for business-critical applications such as CRM, ERP, and VOIP.
For a more detailed look at some of the possibilities, see IP-Based Services Characteristics.
Architectures Again
Service control, whether IP-based or otherwise, involves a huge number of requirements and tasks. Those with memories long enough to recall the Advanced Intelligent Network (AIN) will score here because AIN’s Service Logic Execution Environments (SLEEs), Service Creation Environments (SCEs), and the like all reappear in an IP NGN guise because, fundamentally, many of the same (or similar) things have to be done. But IP NGNs add a lot of extra requirements because, unlike the PSTN, they have to handle multiple services simultaneously over an unreliable (in the QOS sense) network with no natural security over users.
This is all being done through a developing series of interrelated, standards-based, functional architectures that specify how a vast range of services can be offered over fixed and mobile IP NGNs. It’s a huge and ongoing task, and the standards groups involved include the 3rd Generation Partnership Project (3GPP) , 3rd Generation Partnership Project 2 (3GPP2) , European Telecommunications Standards Institute (ETSI) , Internet Engineering Task Force (IETF) , CableLabs , International Telecommunication Union, Standardization Sector (ITU-T) , and the MultiService Forum . But there are a lot of others, such as the IPsphere Forum (a carrier initiative looking at issues of end-to-end QOS over multiple carrier networks), the Open Mobile Alliance (OMA) , and the TM Forum , which is defining a next-generation OSS architecture to support an enhanced Telecom Operations Map – eTOM – business-process model.
A key concept to emerge is the service policy, seen as the long-term and universal method of providing IP-based services control. Service policy is essentially a set of formal software rules that define the characteristics and govern the operation of a service for each user/subscriber. Figure 1 gives a high-level view of what an evolved NGN policy control architecture might look like. The basic idea is to use a common application infrastructure to deliver services across different kinds of access infrastructure. Applications do this by plugging in to a top-level policy server that communicates with access-specific policy servers to provide seamless mobility of the applications across different access networks.
Figure 2 shows in more detail the position of the policy server in terms of providing endpoint management and control, and orchestrating the various network and application processes, for broadband services. It should be obvious that the policy server is central to a large number of control flows with a wide range of different devices and processes.
(Figures 1 and 2 are taken from the recent Light Reading report on Broadband Policy Servers, where there is a fuller discussion of policy architectures and their role in supporting converged broadband and triple-play services.)
IMS and Tispan Architectures
A big, basic, underlying thing for much of this standards work – and which defines the framework within which policies act – is the IP Multimedia Subsystem (IMS), which very much ties up many of the network aspects of service policy control. IMS defines an open functional architecture, implemented through standardized software interfaces, for a managed IP-based network to offer a wide range of converged, multimedia services. Although conceived originally for mobile networks by the 3GPP group, IMS has quickly been taken up – and further developed – by the fixed-telecom community as well.
However, although IMS is highly important and influential, it has to be said that not everyone is convinced that it will be able to handle all aspects of policy control. Also, some vendors view IMS as being more oriented towards session control than to network resource control, for example, which is potentially a wider field. Certainly, IMS has now become a part of another major architecture – ETSI’s Tispan (Telecommunications and Internet Services and Protocols for Advanced Networking) NGN architecture, which has become one of the major drivers behind the formalization of the global next-generation network functional architecture.
The key points of IMS for this report are that it divides the network infrastructure into standardized functions that communicate over standardized (hence open) interfaces. These functions are grouped into three main types, called planes and visualized as forming a stack. (See Figure 3 and the Light Reading report, The Role of IMS in PSTN-to-VOIP Migration, for more details.)
User or Transport Plane: Provides a core QOS-enabled IPv6 network that customers access through various kinds of user equipment – DSL broadband, WLAN, mobile, or whatever. So this plane provides the end-to-end media and data transport that services and applications need. It is treated as the bottom-level plane.
Service or Application Plane: Provides and manages services and applications by implementing appropriate server logic. This covers both the specific requirements of individual services and applications (such as video calls), and also common requirements, such as configuration storage and management, identity management, user status (such as presence and location), and charging and billing. It is treated as the top-level plane.
Control or Signaling Plane: Mediates between the User and Service Planes by routing call signaling, handling basic call setup, and controlling what traffic is allowed in the User Plane. This plane is complex and has many defined functional entities.
As already implied, IMS does not specify how all these functions are to be combined into real products. This is a matter for vendor design approaches, network scale, type of services being offered, and so on. Further, it is possible to make further subdivisions – Operax, for example, divides the Control Layer into two parts: Network Control and Service Control, as shown in Figure 4. This makes clear the distinction between the policy rules governing the service subscriber and the control of network resources to support them.
ETSI’s Tispan is a layered architecture as is IMS, but more elaborate. Tispan uses IMS for what ETSI defines as conversational services – essentially any call session of the SIP type. Tispan also adds a series of subsystems that better meet the broader needs of those transitioning to NGNs, such as incumbent telcos running PSTN and broadband DSL services.
While IMS remains crucial to what ETSI is trying to achieve with NGNs, Tispan introduces some new elements, as shown in Figure 5. In the middle is the Resources and Admission Control Function (RACS), which controls the capacity available for the different services. There is also the Network Attachment Subsystem (NASS) for user authentication and location data for emergency calls, and so on.
From the point of view of controlling services (that is, defining, providing, monitoring, limiting, and managing what the user gets and can do – largely the policy side – rather than handling all the multifarious enabling tasks), some of the larger functions within IMS and Tispan are:
Home Subscriber Server (HSS)
Call Session Control Function (CSCF, but split into several subfunctions)
Resource and Admission Control Subsystem (RACS)
Network Attachment Subsystem (NASS)
Various Border Gateway and Control Functions (such as BGFs or BCFs in control and user planes)
These functions interwork to support the operation of service control via specified policies. For example, the RACS contains a Policy Decision Function (PDF), which implements local policy on resource usage, while the HSS contains the high-level subscriber and service policy information that controls the some of the workings of the CSCF. The IMS core network enforces policies via Border Control in the access (GGSN/PDG/BAS IMS functions), and the Interconnect BCF works with the RACS to set up the necessary transport resources for a call. Policies are acted on at Policy Enforcement Points (PEPs), which can be located in different types of network equipment and servers.
Categorization Issues
A simple definition of IP-based services control would be that it covers all the hardware and software products that sit in the control layer between services and the underlying IP infrastructure.
A major problem with devising a classification scheme for IP service control is product functional integration and the consequent overlapping of simple categories based on a few fundamental tasks. Since IP-based services control is inherently very wide-ranging and complex, and is realized usually through software/hardware combinations, the gains in cost and manageability from integration tend to be enormous in many network applications. Further, there is a general trend for industry-standard service architectures not to specify how functional elements should be combined into larger units and realized products. The result, especially for a relatively new area like IP-based services control, is a bit of a confusing mush. Hence this report.
Obviously, particular functional groups do prove to be particularly useful, and these tend to form the basis of recognizable product types. But, even here, vendors – ever keen to seek differentiation – will add bells and whistles, which may make similar-seeming products not directly comparable.
A second major difficulty with classification is the split between products that are oriented towards the new service architectures and those that are not (yet). Currently, in many practical networks, IP-based services control is implemented in an ad hoc, limited, and vendor-dependent manner, without an overriding standardized framework. Pragmatism seems to be pushing some vendors towards offering products oriented towards particular network applications (for example, triple-play services or VOIP/broadband combinations) of perceived importance.
The result is that it becomes necessary to include products that may not fit strictly into standards-based categories.The terminology used by vendors is somewhat elastic and open to different interpretations (as is often the case). For example, it is possible to distinguish, as Operax does, between off-line products/applications and real-time ones. So traffic management is a high-level, off-line task (the carrier has to work out in advance how to dimension its network and then do so at an appropriate time), whereas bandwidth management is a real-time task (as it keeps the network running properly given its current state). However, some vendors seem to conflate both of these aspects under the single term bandwidth management. Similarly, for some vendors policy control may also embrace the off-line aspect of full service creation – that is, in addition, the assembly of service logic.
Operax uses a 2x2 matrix classification of IP-based services policy management, as shown in Table 1. This shows very clearly a second fundamental division – between control of the subscriber and control of the network.
Table 1: Classification of IP-Based Services Policy Management
This report adopts some of these categories, but within a wider-ranging list to reflect existing products. These are (in alphabetical order):
Bandwidth Management and Network Resource Control
Enhanced and Converged Routing
Packet Inspection/Analysis
Service/Policy Creation and Management
Session and Session Border Control
Traffic Management and Configuration.
It would be possible to view these categories as falling under a smaller number of broad headings to reflect very wide areas of interest, for example:
Service/Policy Management = Service/Policy Control + Service/Policy Creation and Management
Traffic Analysis = Packet Inspection Analysis + QOS/SLA Monitoring
Traffic Management = Bandwidth Management and Network Resource Control + Enhanced and Converged Routing + Session and Session Border Control + Traffic Management and Configuration
However, this could bring together some very disparate products. Equally, it would be possible to add further types of product, such as subscriber and SLA database managers, and portal editors. This has not been done because it seems to expand the subject away from the specifics of IP-based services and into the general area of OSS.
Practical Products
Quite a few of the products in the vendor/product lists are composed of functional modules, and these may have different names from the overall product name. For example, Leapstone’s serviceBROKER comprises three modules, with different functions: Service Controller module, Service Manager module, and Service Integrator module. For simplicity, products that fall under more than one category are listed under their overall name, even though it might be more accurate to indicate the particular module that provides the category’s functions.
It’s possible to argue, as Allot Communications does, that in a general sense IP-based services control refers to any IP technologies or features that bring added value to a subscriber over and above pure IP connectivity. So, on this view, access is a simple service, but not an IP-based service – although it is the foundation on which everything else is built.
IP-based services are inherently abstract and have to be mediated to produce network effects, such as an MPLS traffic tunnel of given bandwidth. Viewed as abstractions, IP-based services can be related to, for example,
These can obviously be combined in various ways.
Content-related services could include:
Anything that can prioritize for a single user different flows to and from themselves as the result of their activities. For example, sending an email and playing on-line gaming, with the game given the higher priority.
Anything that can prioritize a certain subscriber compared some others. For example, the user has a gold rating, and thus their video Skype connection will be always more important than a bronze messenger connection.
Anything that can provision, for a specific user, access to some content and not for others. For example, Skype is permitted, but e-Donkey is not.
Enabling complex triple-play services. For example, ensuring predictable quality for IPTV.
Volume-related services could include:
Pricing the service per megabyte transmitted.
All the possible ways of billing for a certain volume of data. This can be combined with content. For example, a monthly service to upload 20 Gbytes of video and to transmit 1 Gbyte of email and other file transfers.
Various forms of discounting, such as uploading 10 Gbytes that are chargeable and receiving 1 Gbyte free on the bill.
Time-related services could include:
Pricing the service per minute.
Charging user activity at a different price depending on the time of the day, the day of the week, and so on.
Promotions, such as VOIP being free during, say, national holidays.
Bandwidth-related services could include:
The old burst concept from Frame Relay, so that a user might subscribe for a 1-Mbit/s data rate, but can burst up to 2 Mbit/s.
The user can order extra bandwidth during a certain period for some special activity.
These examples refer primarily to residential services; enterprise examples could include:
IP directory service and management
Ability to define communities of remote or mobile users, irrespective of location
MPLS class management for matching applications with classes
VLAN VPN management, such as creation, monitoring, and sizing
Traffic-monitoring services and application discovery
Security alerts, such as attack detection and mitigation
Readiness assessment for deploying new applications
Irrespective of any particular architecture or implementation, an IP-based services control system providing such services would need at least the following broad capabilities or components:
A directory/OSS system to store the subscribers and their profiles and SLAs (the subscriber database)
An application directory and discovery engine (providing deep packet inspection and an application database)
A sets of counters (of some type) to measure volumes and times
Service portals accessible by subscribers to offer online SLA modifications and provisioning
A service enforcement function or device to handle the network (such as for bandwidth management, priorities, flow contention resolution, and fairness)
A central policy definition/creation server to glue all of these components together, where the policy provides the service software to pilot the network in response to events. For example, "IF traffic is coming from that user, from that VLAN, from that subnet, with that content, with that volume, at this time... THEN perform this bandwidth allocation action, this tagging action, this redirection action, this encryption action, this tunneling action..."
This page lists all the vendors so far included in the various categories of the taxonomy. It is an initial list only, and we know that it cannot be complete. So please alert Light Readingto any missing names (and don’t be upset if your company has been omitted inadvertently!) – by either posting a note on the message board linked to this article or by sending an email to [email protected]. Please include IP-Based Services Controlin the subject field to help us find messages. We will update the report, if necessary adding and refining product categories and names, as we receive comments from readers.
Acme Packet Inc. (Nasdaq: APKT)
Agilent Technologies Inc. (NYSE: A)
Alcatel (NYSE: ALA; Paris: CGEP:PA)
Allot Ltd. (Nasdaq: ALLT)
BEA Systems Inc. (Nasdaq: BEAS)
Bridgewater Systems Corp. (Toronto: BWC)
C-COR Corp. (Nasdaq: CCBL)
Cisco Systems Inc. (Nasdaq: CSCO)
CloudShield Technologies Inc.
Data Connection Ltd. (DCL)
Ditech Networks Inc. (Nasdaq: DITC)
Emergent Network Solutions Inc.
Ericsson AB (Nasdaq: ERIC)
Fujitsu Ltd. (Tokyo: 6702; London: FUJ; OTC: FJTSY)
Huawei Technologies Co. Ltd.
Juniper Networks Inc. (NYSE: JNPR)
Lucent Technologies Inc. (NYSE: LU)
MetaSolv Software Inc. (Nasdaq: MSLV)
Newport Networks plc (London: NNG)
NexTone Communications Inc.
Quintum Technologies Inc.
Redknee Inc. (Toronto TSX: RKN)
Shenick Network Systems Ltd.
Sonus Networks Inc. (Nasdaq: SONS)
Telcordia Technologies Inc.
Veraz Networks Inc. (Nasdaq: VRAZ)
magicJack VocalTec Ltd. (Nasdaq: VOCL)
Bandwidth management is one of the most fundamental aspects of IP-based services control – if bandwidth were infinite and free, a lot of control and QOS issues would disappear. But it isn’t, and so a lot of effort is going into ways of minimizing and optimizing bandwidth usage, and of incorporating bandwidth management very tightly into service control generally. In very broad terms bandwidth management can be static (concerned with users’ pre-allocated bandwidth), dynamic (concerned with millisecond-by-millisecond adjustments on the fly to keep the network and user SLAs going), or somewhere in between.
Bandwidth management is perhaps the prime example of the broader topic of network resource control, which is concerned with the allocation and control of network resources so as to ensure the required QOS end-to-end for each service instance. In the new and evolving NGN service architectures such as IMS and Tispan, network resource control resides in a unified QOS control plane between networks (the switches and routers) and applications (the application and session controllers). Increasing numbers of products are now becoming available for this generalized role as the new architectures are realized.
In contrast, there are products with more limited goals and more focused on existing networks and specific applications – for example, controlling bandwidth utilization by specific protocols so as to avoid congestion by excessive P2P file sharing.
On the Operax scheme, bandwidth management covers the real-time tasks of:
Authorizing service requests based on network resource availability and service policies
Mapping service request to bandwidth request based on policy
Admission control, call admission control
Standard NGN architecture functions: Bandwidth Management (BM), Resource and Admission Control Subsystem (RACS), Resource and Admission Control Function (RACF)
Per session, per service, aggregates
Table 2: Vendors for Bandwidth Management & Network Resources Control
This category covers products that are either basically IP edge routers or have IP routing capabilities, but which also offer various IP-based services control features beyond those normally offered by a basic IP router – for example, traffic management, bandwidth control, QOS – and are specifically intended for operation in a converged multiservice edge environment. These products often combine a wide range of standard IP packet-processing functions (based on the IP header information) with additional technologies (such as flow-based routing based on deep packet inspection, as used by Caspian Networks and Ellacoya) to provide enhanced service control.
Redback Networks’ SmartEdge 800 platform, for example, has packet classification or filtering based on ingress port/circuit, source/destination IP address and/or TCP port or protocol. Packets can be marked per the DiffServ specification, or the type-of-service bits can be set. Access control lists are supported to permit or deny packets based on the same filter criteria. QOS functions include ingress policing and egress shaping of traffic profiles. This shaping is combined with queuing and scheduling to manage bandwidth.
Table 3: Vendors for Enhanced & Converged Routing
This category covers products that provide or use real-time data and analysis of packet contents for such purposes as stateful protocol identification, flow monitoring, application monitoring, session monitoring, policy enforcement, use and usage control, QOS, security, traffic management, and the like. Although such deep packet inspection is a fundamental technique of service control that can be applied in many types of product, this category is intended for products where packet inspection and analysis are emphasized.
Table 4: Vendors for Packet Inspection/Analysis
Quality of Service (QOS) and the wider remit of Service Level Agreements (SLAs) are intimately bound up with service control. However, some vendors specifically aim products or subsystems at the task of QOS/SLA monitoring, which can be viewed as the final part of service control – feedback on the end result – although it begins to trespass on the wider OSS/BSS area. This category also includes systems for aiding the general reporting and analysis of factors affecting service quality, and systems that provide subscriber and service demographic monitoring.
See the earlier Light Readingreport, Who Makes What: Test & Measurement Gear for Next-Generation Networks – Service T&Mfor a more detailed list of vendors with products relevant to this area (especially for VOIP services).
Table 5: Vendors for SOS/SLA Monitoring
Service/policy control covers a very wide range of functions, and consequently this category contains many types of product, differing in both scope and scale. The essential point is the real-time management and control of the policy aspects of services as they are used. This involves things such as identifying users, authenticating them, responding to their service requests according to their service profiles, monitoring what they are doing, and enforcing restrictions when appropriate. Wider considerations include such functions as policy-based charging.
Effectively, products in this category range from those dedicated to specific and limited functional tasks at particular network points to full-blown service execution and control platforms that implement complex control logic across widely distributed network and service elements. Some products are focused on specific service combinations and network environments, such as triple-play services in broadband access networks.
On the Operax scheme, policy control covers the real-time tasks of:
Authorizing service requests based on subscriber policies
Policy-based admission control
Policy engine, policy server
Per session, per service, aggregates
Table 6: Vendors for Service/Policy Control
Products in this category are concerned mainly with the creation and management of appropriate services and policies for subscriber, application, and network resource control – either before a customer begins to receive service or in an offline manner after service has begun (for changes, maintenance, and so on). So this category covers the phases of service creation, provisioning, and activation, and the ongoing relations among service, network, and subscription policies.
This category inevitably overlaps with OSSs and various aspects of back-office control, such as subscriber profiles, service accounting, usage metering, and SLA monitoring and management.
On the Operax scheme, service creation covers the off-line tasks of:
Managing policies from service creation provisioning and activation
Translation of services into network policies
Definition of subscriptions in terms of policies
Table 7: Vendors for Service/Policy Creation & Management
Session control is fundamental to real-time IP-based services, such as VOIP. For example, carriers will need stateful application- and session-based classification and control of application-level IP traffic on a per subscriber basis. This can be used for such purposes as QOS reporting and control, and security applications, such as virus and intrusion detection.
A session border controller (SBC) is a piece of network equipment or a collection of functions that control real-time session traffic at the signaling, call-control, and packet layers as they cross a notional packet-to-packet border between networks or between network segments. SBCs are critical to the deployment of VOIP networks, because they address the inability of real-time session traffic to cross network address translation (NAT) device or firewall boundaries. SBCs also play a vital role in providing security (for example, in protecting against denial-of-service attacks), QOS (for example, in protecting against bandwidth theft), and other session-related functions – such as charging – between different carrier networks.
According to a recent Heavy Readingreport, session border controllers fall into several types:
Intercarrier peering SBCs
Distributed SBC signaling controllers
Distributed SBC media proxies
For an analysis of the role of SBCs in the broader context of session management and the arrival of NGNs, IMS, and the Tispan standards, see the Heaving Readingreport Session Management, IMS, and the Future of Session Border Controllers.
Table 8: Vendors for Session & Session Border Control
This category is concerned essentially with all aspects of bandwidth and capacity control that do not have to be done in real time as each service instance is executed. On the Operax scheme, this is referred to as traffic planning/engineering, and covers the off-line tasks of:
Managing the allocation of bandwidth to services
Creating service policies to define service mappings to traffic classes and so on
Changing queue configurations
Driving MPLS tunnels with traffic engineering
Table 9: Vendors for Traffic Management & Configuration