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.
8/27/09
7/14/09
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.
6/12/09
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.
5/18/09
5/2/09
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.
4/20/09
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.
4/4/09
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.
3/20/09
Diameter adoption and network geography
Diameter is used everywhere in the NGN core network – it is in the mobile, wireline, WiMax, Cable, from the ASN’s, GGSN’s and BRAS up to Application Servers. There isn’t a network core entity without at least Diameter interfaces, and some of them network functionalities have up to 4 different Diameter interfaces.
There are dozens of Diameter interfaces defined, over 110 interfaces are actually defined for Mobile, Wireline, Cable and WiMax and it seems also that the number is growing rapidly, new interfaces are introduced all the time, either for LTE (dozen of new interfaces), Lawful interception, interoperability, Roaming, IPTV, advanced policy and other needs.
But in reality most of those interfaces are still on the drawing boards or in the R&D labs, and not deployed and used yet in operators networks.
So what we see in the market, what places have the highest Diameter maturity, here is my view, top to bottom
I believe that the highest maturity is around the Charging and Billing systems ( what is called Rf, Ro, Gy, Gz, CCA interfaces)
It could be the connection from the Application to the Charging system, or from the GGSN to the Billing, or other network functionality, but it seems always to involve some charging component.
2nd place is given to the AAA servers and subscribers databases area, either HSS, NASS or other AAA Server, (interfaces like Sh, Dh, Cx, Dx), it could be CSCF connectivity to HSS, HSS to Application Server or one of many other scenarios of connecting to a AAA and subscriber databases using Diameter.
The 3rd place closely behind is taken by the policy and enforcement area. Policy is a spaghetti of Diameter with more than 9 Diameter interfaces (Gx, Rx, Gq, Gq’, Tx,Ty…) and we see almost any combination you can imagine of those policy related Diameter interfaces nd sometimes requests for all of them.
The rest of the network Diameter interfaces are defiantly behind, we see growing number of requests for almost all the 100+ defined interfaces, but they are still tailoring behind and you can find them today mainly in the vendors and operators labs and not in deployed operational networks.
Actually one of the emerging areas is the LTE related Diameter interfaces, although not finalized yet, and bearing a temporary name those Diameter interfaces are in high demand with strong interest by vendors starting to developing and testing LTE related equipment.
3/3/09
LTE and Diameter
It seems LTE is moving to the manufacturing halls.
The industry has aligned behind it (leaving far behind some potential alternatives such as Mobile WiMax), and in recent weeks we saw some new announcements on first deployments in Tier-1’s in 2010.
What place does Diameter take in LTE architecture ? well it seems much bigger than in the past, even compared to IMS.
There are about 15 new Diameter interfaces (on top of the existing 30 inherited from previous 3GPP versions and that are also used in LTE), and Diameter is getting out of the network core, closer to the edge and to the interconnectivity and roaming connections between operators.
However there are some warning signs – LTE standards are still work in progress, and the same for the LTE Diameter interfaces – so the potential for interoperability, connectivity and vendor lock-in issues is stronger than ever before.
Here in Traffix we supplied a number of network equipment vendors with LTE Diameter interfaces – and surprisingly each one wanted a different version of the still forming LTE (3GPP Rel. 8) specifications.
In some places where the standards and the Diameter interfaces are still too young to do the job, the equipment vendors are using earlier Diameter interfaces – again this wont contribute to connectivity.
So what’s the conclusion – well that the interoperability issues that operators are facing today won’t disappear with LTE, actually I believe they will be even bigger than in the past, especially in the first 2-3 years of LTE deployments.
I believe this might also slow LTE adoption – operators will understand the immaturity and that the “dream” is far from reality, and the related costs and will prefer to wait a bit until LTE will be more mature.
Actually it sounds a bit like IMS all over again (just replace LTE with IMS in the lines above :-) )
The industry has aligned behind it (leaving far behind some potential alternatives such as Mobile WiMax), and in recent weeks we saw some new announcements on first deployments in Tier-1’s in 2010.
What place does Diameter take in LTE architecture ? well it seems much bigger than in the past, even compared to IMS.
There are about 15 new Diameter interfaces (on top of the existing 30 inherited from previous 3GPP versions and that are also used in LTE), and Diameter is getting out of the network core, closer to the edge and to the interconnectivity and roaming connections between operators.
However there are some warning signs – LTE standards are still work in progress, and the same for the LTE Diameter interfaces – so the potential for interoperability, connectivity and vendor lock-in issues is stronger than ever before.
Here in Traffix we supplied a number of network equipment vendors with LTE Diameter interfaces – and surprisingly each one wanted a different version of the still forming LTE (3GPP Rel. 8) specifications.
In some places where the standards and the Diameter interfaces are still too young to do the job, the equipment vendors are using earlier Diameter interfaces – again this wont contribute to connectivity.
So what’s the conclusion – well that the interoperability issues that operators are facing today won’t disappear with LTE, actually I believe they will be even bigger than in the past, especially in the first 2-3 years of LTE deployments.
I believe this might also slow LTE adoption – operators will understand the immaturity and that the “dream” is far from reality, and the related costs and will prefer to wait a bit until LTE will be more mature.
Actually it sounds a bit like IMS all over again (just replace LTE with IMS in the lines above :-) )
Ben
Subscribe to:
Posts (Atom)
