Load balancing has been almost a mandatory component to successfully provide high availability and nearly transparent scalability to web-based applications in the last 20 years.
Unlike HTTP and other web application protocols (SMTP, FTP, etc.), which are synchronous and stateless, the Diameter protocol is not only asynchronous but also do not abide by to a single request/reply communication sequence like web based communication protocols. This makes it more difficult to distribute Diameter because traditional web based load balancers are designed to operate best in a synchronous messaging environment in which a single request is made and responded to before another is processed.
In traditional load balancing, the load balancing is achieved in layer 4 (TCP/UDP), unlike this in Diameter the load balancing need to be message based, which means it has to be done in the Diameter level, above the TCP (and SCTP in Diameter case) level, since sessions are long lived and can outlive the relating layer 4 signaling.
More than this Diameter, due to its dynamic nature and the ability to add almost infinite amount of standard and vendor specific AVP’s and Grouped AVP’s in almost any combination, is a challenge to traditional web based load balancers, which cannot support the complex structure of Diameter and cannot fully use the Diameter AVP’s dictionary in order to perform dynamic load balancing of Diameter messages (for example try to configure iRules for Diameter, not a pleasant experience, I can assure you, make sure you got a few weeks of spare time)
To meet Diameter load balancing demands the Diameter load balancer needs to be a real native Diameter entity, this means it has to be a Diameter proxy in order to successfully use the entire set of AVP’s for load balancing decisions.
Being a native Diameter entity also enables the Load Balancer to offer many other benefits which are crucial for service providers, such as stateful configuration, Diameter masquerading, the ability to work dynamically with SCTP and TCP per the same session and to engage in Diameter over TLS in different scenarios.
To act in a stateful mode, is important requirement for Diameter load balancers due to the nature of the information inside the Diameter messages and service provider’s assurance needs.
Another related issue affecting service providers launch of new services is the complexity, cost and time associated with new network functionalities introduction. With the wide adoption of Diameter by service providers, every new network component is either a Diameter server or client, and needs to communicate with the other Diameter servers and clients around, this result in vast configuration and management burden and slow introduction of new services.
Having a Diameter native load balancer masquerades the need for this slow configuration, and services can be integrated and launched smoothly and faster, all the Diameter introduction/routing handling can be done in the native Diameter load balancer.
The ability to load balance Diameter requires a unique understanding of the way
in which the applications that use Diameter behave. Protocols such as Diameter that are
asynchronous and communicate bi-directionally are challenging to scale, hence rise the need for a native Diameter load balancer that has the ability to be stateful, extract and route requests at the Diameter message level and can load balance based on connections.
Dec 10, 2009
Nov 7, 2009
Some interesting Diameter legacy connectivity issues
At Traffix we come across many requests to connect Diameter to other legacy protocols.
We have the common familiar Gateway needs which usually involve two of the following:
LDAP, RADIUS, Diameter, Web Services, CAMEL.., but from time to time we got some other interesting requests, here are two that we recently had
Diameter GTP` connectivity
GTP` (GPRS Tunneling Protocol Prime) is used within GSM and GPRS networks, for transfer of charging data from GGSN’s to the charging function.
In MANY networks on the migration path to NGN, the GGSN’s are using GTP’ while the OCS (Online charging System) is already upgraded and using Diameter for charging connectivity, thus there is a need to convert GTP` messages into Diameter (Ro) and vice versa. We had an interesting case recently where we helped a service provider that had implemented a new charging system with all the goodies and with Diameter and needed to connect GTP` based charging interfaces from his GGSN’s to the new charging system.
Diameter CORBA connectivity
The Common Object Request Broker Architecture is a standard that enables software components written in multiple computer languages and running on multiple computers to work together, i.e. it supports multiple platforms. CORBA is widely used within NMS solutions, that are connected to different AAA Databases. With the migration to NGN, the AAA DB’s are migrating to Diameter, and a connectivity issue between existing CORBA interfaces and new Diameter interfaces arises. On a number of occasions recently we came across CORBA Diameter connectivity issues and with Traffix Diameter Gateway helped to bridge this gap.
We have the common familiar Gateway needs which usually involve two of the following:
LDAP, RADIUS, Diameter, Web Services, CAMEL.., but from time to time we got some other interesting requests, here are two that we recently had
Diameter GTP` connectivity
GTP` (GPRS Tunneling Protocol Prime) is used within GSM and GPRS networks, for transfer of charging data from GGSN’s to the charging function.
In MANY networks on the migration path to NGN, the GGSN’s are using GTP’ while the OCS (Online charging System) is already upgraded and using Diameter for charging connectivity, thus there is a need to convert GTP` messages into Diameter (Ro) and vice versa. We had an interesting case recently where we helped a service provider that had implemented a new charging system with all the goodies and with Diameter and needed to connect GTP` based charging interfaces from his GGSN’s to the new charging system.
Diameter CORBA connectivity
The Common Object Request Broker Architecture is a standard that enables software components written in multiple computer languages and running on multiple computers to work together, i.e. it supports multiple platforms. CORBA is widely used within NMS solutions, that are connected to different AAA Databases. With the migration to NGN, the AAA DB’s are migrating to Diameter, and a connectivity issue between existing CORBA interfaces and new Diameter interfaces arises. On a number of occasions recently we came across CORBA Diameter connectivity issues and with Traffix Diameter Gateway helped to bridge this gap.
Oct 6, 2009
Next Generation Networks Control Plane Challenges
The Challenge
The introduction of NGN elements into the telecom network present opportunities to utilize technological advancements to reliably and cost effectively provide a broad array of all IP based services (mobile data, streaming video, advertisements, stock-market quotes,…) to an ever-expanding customer-base, in real time. Yes, we all know NGN is not happening overnight, nor is it happening all over the network at one time. But it is clear to the telecom observer that certain NGN elements are making their appearance in the telecom network, at times as a new Diameter-based OCS node and at other times as a newly introduced NGN element such as a PCRF.
But to make this efficient, manageable and cost effective, the telco must adopt an overall NGN strategy. This NGN strategy needs to take into account both the opportunities that NGN presents to them as well as deal with the challenges presented by the new architecture. An NGN strategic view is especially important because an NGN network doesn't happen overnight. The last thing a telecom operator would like is to have an evolving NGN introduction without a real vision of the final goal. Were NGN an easy short term effort, the coherent implementation would be a simple part of the NGN project implementation; but NGN introduction is slow, at times very local to a specific area within the network (such as the interface between the GGSN and the OCS). Especially under these conditions the challenge of having an overall NGN strategy is crucial to the telecom operator.
Of the many opportunities and challenges that NGN strategy presents to the telco, I would like to focus on those related to the NGN Control Plane. Unlike legacy networks, in which the control plane was primarily the proprietary domain of the Network Equipment Provider, the new NGN control plane is more open and standard. It benefits from well defined interfaces and functionalities and a new broad and flexible enhanced AAA signaling protocol –Diameter - which replaces the existing variety of legacy signaling protocols.
Information that in the past was very difficult to retrieve from the network is now easily obtained. Interfaces requiring long and cumbersome integration are now replaced by standardized connectivity. NGN signaling enables new, fast, easy and cost effective service launches, translating into more services to the customer.
However, this new NGN architecture faces some critical challenges (especially since more and more services will be, over time, launched based on this architecture):
· How to roll out and activate new real time services.
· How to handle the rapidly increasing signaling volume from the new services (which are typically more signaling-intensive than common in the past. Most legacy protocols that are UDP based, Diameter is TCP-based, with an ACK for each transaction – this alone doubles the amount of signaling),
· How to deal with the unavoidably greater fragmentation and amount of network components needed for real time and new multimedia services introduced by NGN.
Thus, load balancing (LB) becomes a key issue, - specifically the control plane load balancing.
This is the challenge of the Control Plane – ensuring that the network is able to optimize the signaling load according to individual telco-defined network, subscriber needs and business operations parameters.
The introduction of NGN elements into the telecom network present opportunities to utilize technological advancements to reliably and cost effectively provide a broad array of all IP based services (mobile data, streaming video, advertisements, stock-market quotes,…) to an ever-expanding customer-base, in real time. Yes, we all know NGN is not happening overnight, nor is it happening all over the network at one time. But it is clear to the telecom observer that certain NGN elements are making their appearance in the telecom network, at times as a new Diameter-based OCS node and at other times as a newly introduced NGN element such as a PCRF.
But to make this efficient, manageable and cost effective, the telco must adopt an overall NGN strategy. This NGN strategy needs to take into account both the opportunities that NGN presents to them as well as deal with the challenges presented by the new architecture. An NGN strategic view is especially important because an NGN network doesn't happen overnight. The last thing a telecom operator would like is to have an evolving NGN introduction without a real vision of the final goal. Were NGN an easy short term effort, the coherent implementation would be a simple part of the NGN project implementation; but NGN introduction is slow, at times very local to a specific area within the network (such as the interface between the GGSN and the OCS). Especially under these conditions the challenge of having an overall NGN strategy is crucial to the telecom operator.
Of the many opportunities and challenges that NGN strategy presents to the telco, I would like to focus on those related to the NGN Control Plane. Unlike legacy networks, in which the control plane was primarily the proprietary domain of the Network Equipment Provider, the new NGN control plane is more open and standard. It benefits from well defined interfaces and functionalities and a new broad and flexible enhanced AAA signaling protocol –Diameter - which replaces the existing variety of legacy signaling protocols.
Information that in the past was very difficult to retrieve from the network is now easily obtained. Interfaces requiring long and cumbersome integration are now replaced by standardized connectivity. NGN signaling enables new, fast, easy and cost effective service launches, translating into more services to the customer.
However, this new NGN architecture faces some critical challenges (especially since more and more services will be, over time, launched based on this architecture):
· How to roll out and activate new real time services.
· How to handle the rapidly increasing signaling volume from the new services (which are typically more signaling-intensive than common in the past. Most legacy protocols that are UDP based, Diameter is TCP-based, with an ACK for each transaction – this alone doubles the amount of signaling),
· How to deal with the unavoidably greater fragmentation and amount of network components needed for real time and new multimedia services introduced by NGN.
Thus, load balancing (LB) becomes a key issue, - specifically the control plane load balancing.
This is the challenge of the Control Plane – ensuring that the network is able to optimize the signaling load according to individual telco-defined network, subscriber needs and business operations parameters.
Aug 27, 2009
RADIUS Diameter Gateway
We come across many issues involving RADIUS to Diameter connectivity with requests to assist with our Diameter-RADIUS Gateway.
It’s really became a very common scenario, the System Integrator is deploying NGN infrastructure that comes equipped with Diameter connectivity and in is network he has legacy equipment that is sitting there for many years (and will stay for many years more) and supports only legacy connectivity (i.e. RADIUS) and now the System Integrator needs to connect the two protocols.
And of course Diameter and RADIUS are different protocols and cannot be bridged.
I stumbled across an initial work by the IETF Dime group- draft-zorn-dime-radia-gate-00.txt, really in early stages, not even a draft yet, driven by Lionel Morend and Glen Zorn.
Glen is really one of the major forces behind Diameter for many years (I still don’t understand why the blessed CMS related work driven by him wasn’t standardized)
It’s an interesting case where the standard bodies (the technical guys, flying in the air with no commercial weights to reality ) are behind the network adoption and the market need. Usually it’s the other way, for example LTE was standardized and until we will see real deployments it will be a few more years.
But in this case the standard bodies are behind, maybe because we live in a non standard world and the migration to NGN is evolution and not revolution, and RADIUS and Diameter need to co-exist for many years. Anyway this is blessed and very important work, and is based on real market need.
It’s really became a very common scenario, the System Integrator is deploying NGN infrastructure that comes equipped with Diameter connectivity and in is network he has legacy equipment that is sitting there for many years (and will stay for many years more) and supports only legacy connectivity (i.e. RADIUS) and now the System Integrator needs to connect the two protocols.
And of course Diameter and RADIUS are different protocols and cannot be bridged.
I stumbled across an initial work by the IETF Dime group- draft-zorn-dime-radia-gate-00.txt, really in early stages, not even a draft yet, driven by Lionel Morend and Glen Zorn.
Glen is really one of the major forces behind Diameter for many years (I still don’t understand why the blessed CMS related work driven by him wasn’t standardized)
It’s an interesting case where the standard bodies (the technical guys, flying in the air with no commercial weights to reality ) are behind the network adoption and the market need. Usually it’s the other way, for example LTE was standardized and until we will see real deployments it will be a few more years.
But in this case the standard bodies are behind, maybe because we live in a non standard world and the migration to NGN is evolution and not revolution, and RADIUS and Diameter need to co-exist for many years. Anyway this is blessed and very important work, and is based on real market need.
Jul 14, 2009
Diameter Routing Agent
I want to discuss today a new network function introduced by 3GPP in its Release 8 standards.
The Diameter Routing Agent (DRA), the DRA is a functional element that ensures that all Diameter sessions established over the Gx, S9, Gxx and Rx reference points for a certain IP-CAN session reach the same PCRF when multiple and separately addressable PCRFs have been deployed in a Diameter realm.
What this means in plain English, is that the DRA helps to sort out the Diameter spaghetti in the network.
Routing of Diameter messages from a network element towards the right Diameter realm in a PLMN is based on standard Diameter realm-based routing, as specified in IETF RFC 3588.
The DRA keeps status of the assigned PCRF for a certain UE and IP-CAN session across all reference points (e.g. Gx, Gxx, S9 and Rx interfaces)
The DRA supports the functionality of a proxy agent and a redirect agent as defined in RFC 3588 . The mode in which it operates (i.e. proxy or redirect) shall be based on the operator’s requirements.
Diameter clients of the DRA (i.e. AF, PCEF, BBERF and PCRF) in roaming scenarios shall support all procedures required to properly interoperate with the DRA in both the proxy and redirect modes.
After all this technical flood, I think that the main importance of DRA from Diameter perspective is that it’s the first time that the 3GPP standard body is supporting and backing an “in between” Diameter component.
Those components known as agents are part of Diameter in its IETF base, but were never used and adopted by the telecom standard bodies that adopted Diameter and headed by 3GPP, it was always a client server game. A DRA is really a Diameter Redirect Agent or a Diameter Proxy Agent as defined by the IETF.
In my opinion the adoption and backing of the DRA, is the final stamp of approval to the IETF Diameter work and to the embracement of Diameter as the main signaling protocol for telecommunication networks. I suspect we will see more and more Diameter agents either packaged as DRA or in other names in the coming years with the continuing migration to NGN and the growing amount of signaling.
The Diameter Routing Agent (DRA), the DRA is a functional element that ensures that all Diameter sessions established over the Gx, S9, Gxx and Rx reference points for a certain IP-CAN session reach the same PCRF when multiple and separately addressable PCRFs have been deployed in a Diameter realm.
What this means in plain English, is that the DRA helps to sort out the Diameter spaghetti in the network.
Routing of Diameter messages from a network element towards the right Diameter realm in a PLMN is based on standard Diameter realm-based routing, as specified in IETF RFC 3588.
The DRA keeps status of the assigned PCRF for a certain UE and IP-CAN session across all reference points (e.g. Gx, Gxx, S9 and Rx interfaces)
The DRA supports the functionality of a proxy agent and a redirect agent as defined in RFC 3588 . The mode in which it operates (i.e. proxy or redirect) shall be based on the operator’s requirements.
Diameter clients of the DRA (i.e. AF, PCEF, BBERF and PCRF) in roaming scenarios shall support all procedures required to properly interoperate with the DRA in both the proxy and redirect modes.
After all this technical flood, I think that the main importance of DRA from Diameter perspective is that it’s the first time that the 3GPP standard body is supporting and backing an “in between” Diameter component.
Those components known as agents are part of Diameter in its IETF base, but were never used and adopted by the telecom standard bodies that adopted Diameter and headed by 3GPP, it was always a client server game. A DRA is really a Diameter Redirect Agent or a Diameter Proxy Agent as defined by the IETF.
In my opinion the adoption and backing of the DRA, is the final stamp of approval to the IETF Diameter work and to the embracement of Diameter as the main signaling protocol for telecommunication networks. I suspect we will see more and more Diameter agents either packaged as DRA or in other names in the coming years with the continuing migration to NGN and the growing amount of signaling.
Jun 12, 2009
The forces behind increasing Diameter signaling
I want to discuss some of the issues pushing the amount of signaling and Diameter.
We see growing amount of Diameter traffic in the networks, presenting Service providers with new challenges of managing Diameter traffic, scalability and confronting bottlenecks in their networks.
Here are some of the reasons for the growing amount of Diameter signaling
- Subscriber growth and subscribers migration to Next Gen. Networks
- Flat rate plans for data services
- Growing amount of Converged networks
- Diameter maturity with growing amount of interfaces and connectivity
- Continuing network migration to NGN
- Growing number of enforcement (DPI/PCEF) and policy (PDF/PCRF) functions, which are major source of Diameter signaling
- Increase in new services
- Continuing migration from 2G/2.5G to 3G, NGN and beyond (e.g. LTE)
- New interface speeds
Another important affect to take into consideration is that with the increase in network and signaling complexity and traffic of Diameter signaling in NGN, the network management becomes a growing concern, with new issues (surprisingly familiar from the days of SS7 based networks) related to identifying, analyzing and solving network related issues.
All those signaling and Diameter related issues can result in growing maintenance and management costs, increasing downtime, QoS issues, customer satisfaction and of course Service providers revenues.
To confront those issues, Services providers need to add and scale NGN infrastructure capacity, and to take into account Diameter and network design, scalability, signaling balancing and routing when charting new NGN related RFP’s.
Here at Traffix we offer them a set of products to confront those issues, from Diameter Gateways to confront vendor and standard interoperability issues, through Diameter load balancers and up to advanced contextual signaling and Diameter management solutions.
We see growing amount of Diameter traffic in the networks, presenting Service providers with new challenges of managing Diameter traffic, scalability and confronting bottlenecks in their networks.
Here are some of the reasons for the growing amount of Diameter signaling
- Subscriber growth and subscribers migration to Next Gen. Networks
- Flat rate plans for data services
- Growing amount of Converged networks
- Diameter maturity with growing amount of interfaces and connectivity
- Continuing network migration to NGN
- Growing number of enforcement (DPI/PCEF) and policy (PDF/PCRF) functions, which are major source of Diameter signaling
- Increase in new services
- Continuing migration from 2G/2.5G to 3G, NGN and beyond (e.g. LTE)
- New interface speeds
Another important affect to take into consideration is that with the increase in network and signaling complexity and traffic of Diameter signaling in NGN, the network management becomes a growing concern, with new issues (surprisingly familiar from the days of SS7 based networks) related to identifying, analyzing and solving network related issues.
All those signaling and Diameter related issues can result in growing maintenance and management costs, increasing downtime, QoS issues, customer satisfaction and of course Service providers revenues.
To confront those issues, Services providers need to add and scale NGN infrastructure capacity, and to take into account Diameter and network design, scalability, signaling balancing and routing when charting new NGN related RFP’s.
Here at Traffix we offer them a set of products to confront those issues, from Diameter Gateways to confront vendor and standard interoperability issues, through Diameter load balancers and up to advanced contextual signaling and Diameter management solutions.
May 18, 2009
May 2, 2009
Diameter implementations – not for the faint of heart
I want to share with you a few horror stories about some of the Diameter implementations we see out there.
We recently came across an implementation by one of the main network vendors where Diameter server is sending Diameter client messages – of course that the clients in the other end could not respond and some of them where getting quite mixed up with the unexpected message.
This is really the tip of the iceberg, Diameter is very flexible and in NGN the applications are still very young – a destructive combination it seems, so the way the standards are translated and implemented varies across different vendors.
It’s not only the network equipment providers, some of the operators have also joined the party, with in-house Diameter standards and requirements that have already gained quite a “notorious reputation” in where they taken the standards and their non conformance, I don’t want to name and shame anyone, but I’m sure some of you are nodding their heads with called sweat.
Is it becoming better ? well not really, LTE/SAE is being developed today, new cable standards, new ETSI TISPAN equipment, and there things aren’t better, development is starting before the interfaces are finalized, so sorry no good end to this post, I believe the interoperability issues will keep accompany us in the recent future and will affect the dream of open plug & play no silo networks.
We recently came across an implementation by one of the main network vendors where Diameter server is sending Diameter client messages – of course that the clients in the other end could not respond and some of them where getting quite mixed up with the unexpected message.
This is really the tip of the iceberg, Diameter is very flexible and in NGN the applications are still very young – a destructive combination it seems, so the way the standards are translated and implemented varies across different vendors.
It’s not only the network equipment providers, some of the operators have also joined the party, with in-house Diameter standards and requirements that have already gained quite a “notorious reputation” in where they taken the standards and their non conformance, I don’t want to name and shame anyone, but I’m sure some of you are nodding their heads with called sweat.
Is it becoming better ? well not really, LTE/SAE is being developed today, new cable standards, new ETSI TISPAN equipment, and there things aren’t better, development is starting before the interfaces are finalized, so sorry no good end to this post, I believe the interoperability issues will keep accompany us in the recent future and will affect the dream of open plug & play no silo networks.
Apr 20, 2009
Some thoughts about Diameter
Is there a need in Diameter cards ? I looked at some SS7 and Sigtran projections a few days ago, there is a market for SS7 and Sigtran cards, this is a market along the stack market and actually even bigger.
I’m personally not sure there is a need for Diameter cards, I think IP based protocols market behave differently, but time will tell.
I’m personally not sure there is a need for Diameter cards, I think IP based protocols market behave differently, but time will tell.
Apr 4, 2009
The amount of Diameter signaling
I come across more and issues regarding the amount of Diameter signaling and how it affects service providers networks.
Diameter is coming out of the labs, and when it’s moving to working environment the real network issues are starting to emerge.
So why Diameter is creating so much signaling, I believe the main issues are:
- Diameter is TCP/SCTP based compared to legacy signaling protocols like RADIUS that where mostly UDP based.
Diameter is coming out of the labs, and when it’s moving to working environment the real network issues are starting to emerge.
So why Diameter is creating so much signaling, I believe the main issues are:
- Diameter is TCP/SCTP based compared to legacy signaling protocols like RADIUS that where mostly UDP based.
- Network fragmentation - in NGN like architectures, the number of network components is increasing, and many components were divided (for example the softswitch was divided to three different CSCF functionalities)
- Nature of new services – many of the services and applications (AS) are heavy signaling generators – like Presence and Location servers that create heavy signaling load or Policy servers (PDF/PCRF/RACS) that are creating heavy policy and enforcement Diameter traffic.
- Direct connectivity – in NGN connectivity between the components was defined directly, point to point - from functionality to functionality, at the time the standard bodies didn’t believe “in-between” components are needed, well I guess they skipped the history lessons especially the chapters about routers, STP’s and SBC’s – this is also contributing to the heavy load, complexity and lack of ability to balance and manage the Diameter signaling.
- New charging models and closer integration of BSS and network, which create heavier network load, in both the network side (Diameter signaling) and the BSS (CDR’s).
I believe this is only the tip of the iceberg, Diameter today is really still mainly in testing and within the labs, I think the amount of signaling issues will only increase in the coming years directly with Diameter adoption. It’s defiantly going to be interesting.
Subscribe to:
Posts (Atom)
