Imagine, if a small town consisting of one main road, a few arterial roads, with the traditional system of traffic lights, one day woke up to a new reality. Overnight its town residents were shocked to see thousands of new business moving in, bringing with them many more residents, constant commercial activity and of course, higher volume of traffic.
Well, if you think that the first tactic the town should take is to add more houses and streets, think again. Just adding these elements without the necessary infrastructure would just burden the congestion and confusion, and slow down the efficiency of the town.
It’s the same in a network. Just adding bandwidth or spectrum can’t solve today’s sudden surge of more activity of thousands or hundreds of thousands of smartphone subscribers using their mobile data for most of their awake hours.
The town needs to revamp its traffic light system just as the network – now filled with new elements and fragmented from the data strain and new services, needs to upgrade its signaling – and in 4G this means its Diameter signaling.
And what does upgrade mean? Well let’s go back to our town. If once upon a time, the town’s planners would have simply added more streets and traffic lights, today, they would consider a wireless traffic management system that operates according to the traffic flow for maximum optimization. So too, network architects must include Diameter solutions such as DRAs for intelligent, dynamic routing, load balancers for unlimited scalability and network control, and Diameter gateways for instant connectivity with legacy elements.
You wouldn’t want to live in a town whose infrastructure hasn’t kept up with its growth would you? Well, why would you subscribe to a carrier whose network hasn’t kept up with your needs for reliable and fast service?
6/7/11
Diameter for the Technically Challenged
"Diameter for the Technically Challenged" or what should you know about Diameter signaling protocol even if you are not a telecom engineer
During your average day how many times do you speak and text on your smartphone, browse on your tablet, or work on your laptop? In the evenings you may read ebooks, message from your mobile, or check your Facebook. You go on vacation and watch videos while waiting for the plane, take pictures with your phone and send them to friends back home. You leave your Skype or instant messenger open on your tablet so you can always see who among your contacts are available for a quick chat. In short, you are always connected to the network, meaning that the mobile operator's processing behind the scenes to support all your data communications is always on, and has now become a critical factor in the performance of the mobile network. And the trend to use the mobile network for data is growing in leaps and bounds.
Your Mobile Network is Moving to IP
To support your constant use of the Internet through your cellular network, many mobile operators are beginning to empower networks with Internet Protocol (IP) using technologies generally referred to as 4G such as IMS, LTE and others. These technologies require systems to communicate with each other using what is known as a signaling protocol that can support millions of subscribers accessing the Internet all the time. The particular signaling protocol selected by the telecommunication industry is known as Diameter.
Diameter: The Chosen Standard
The organizations who set international standards in the telecommunications industry (such as 3GPP and ETSI) have selected Diameter as the signaling protocol to enable operators to support 4G services. Why is that? Because Diameter is the only signaling protocol that is capable of managing the constant flow of core network signaling in an environment that has become far more complex with many more network elements needed to fulfill the promises of 4G.
Fulfilling the Promises of LTE Mobile Technology
Today's mobile network operator growth is fueled by data traffic; voice has become secondary. On paper, LTE and other IP-based technologies have made amazing promises to provide you with high quality mobile broadband, sophisticated services, tiered charging plans, better roaming schemes, and much more. However, the implementation of all these promised services takes place in the core network and requires signaling that will tackle the challenges for cost-effective connectivity, scalability and control in the section of the network known as the control plane.
Data Brings Complexity
In fact, your mobile operator's focus on data will only increase in time as the initiatives of voice over LTE (VoLTE) take hold, introducing a network where everything is data. Access to data, meaning the web, video, SMS, MMS, presence, and VoIP, requires constant Diameter signaling with a spaghetti of network nodes and interfaces. Network operators need a configuration of Diameter solutions such as gateways to connect the new elements to the old ones, load balancers for scalability meaning to grow the network easily, and routers that ensure the messages from each subscriber go to the right places – in short, to support communications that are becoming increasingly complicated.
Using Diameter to Control the Complexity
Once upon a time, network signaling was activated when a phone call began and ended when the speakers hung up. Now this scenario is no longer relevant, and your mobile operator has far greater challenges to solve. The only way for your mobile operator to successfully manage its network is to focus on its control plane with the right signaling products that provide cost effective, robust and intelligent solutions.
You may not be a telecom engineer, but you want to know that your network will respond rapidly to your request the next time you pick up your tablet or mobile device. Whether you want to send a message home, check your train's timetable or download an app, you want fast communications. In summary, it doesn’t take a telecom engineer to understand that almost everything you do with your mobile device depends on data communications, and that the right Diameter solution is the key ingredient for high performance, excellent quality of service, and advanced service enablement.
** The above was written by Susan Becker Traffix Marketing manager, I thought it’s a very good “Diameter for dummies” articale
During your average day how many times do you speak and text on your smartphone, browse on your tablet, or work on your laptop? In the evenings you may read ebooks, message from your mobile, or check your Facebook. You go on vacation and watch videos while waiting for the plane, take pictures with your phone and send them to friends back home. You leave your Skype or instant messenger open on your tablet so you can always see who among your contacts are available for a quick chat. In short, you are always connected to the network, meaning that the mobile operator's processing behind the scenes to support all your data communications is always on, and has now become a critical factor in the performance of the mobile network. And the trend to use the mobile network for data is growing in leaps and bounds.
Your Mobile Network is Moving to IP
To support your constant use of the Internet through your cellular network, many mobile operators are beginning to empower networks with Internet Protocol (IP) using technologies generally referred to as 4G such as IMS, LTE and others. These technologies require systems to communicate with each other using what is known as a signaling protocol that can support millions of subscribers accessing the Internet all the time. The particular signaling protocol selected by the telecommunication industry is known as Diameter.
Diameter: The Chosen Standard
The organizations who set international standards in the telecommunications industry (such as 3GPP and ETSI) have selected Diameter as the signaling protocol to enable operators to support 4G services. Why is that? Because Diameter is the only signaling protocol that is capable of managing the constant flow of core network signaling in an environment that has become far more complex with many more network elements needed to fulfill the promises of 4G.
Fulfilling the Promises of LTE Mobile Technology
Today's mobile network operator growth is fueled by data traffic; voice has become secondary. On paper, LTE and other IP-based technologies have made amazing promises to provide you with high quality mobile broadband, sophisticated services, tiered charging plans, better roaming schemes, and much more. However, the implementation of all these promised services takes place in the core network and requires signaling that will tackle the challenges for cost-effective connectivity, scalability and control in the section of the network known as the control plane.
Data Brings Complexity
In fact, your mobile operator's focus on data will only increase in time as the initiatives of voice over LTE (VoLTE) take hold, introducing a network where everything is data. Access to data, meaning the web, video, SMS, MMS, presence, and VoIP, requires constant Diameter signaling with a spaghetti of network nodes and interfaces. Network operators need a configuration of Diameter solutions such as gateways to connect the new elements to the old ones, load balancers for scalability meaning to grow the network easily, and routers that ensure the messages from each subscriber go to the right places – in short, to support communications that are becoming increasingly complicated.
Using Diameter to Control the Complexity
Once upon a time, network signaling was activated when a phone call began and ended when the speakers hung up. Now this scenario is no longer relevant, and your mobile operator has far greater challenges to solve. The only way for your mobile operator to successfully manage its network is to focus on its control plane with the right signaling products that provide cost effective, robust and intelligent solutions.
You may not be a telecom engineer, but you want to know that your network will respond rapidly to your request the next time you pick up your tablet or mobile device. Whether you want to send a message home, check your train's timetable or download an app, you want fast communications. In summary, it doesn’t take a telecom engineer to understand that almost everything you do with your mobile device depends on data communications, and that the right Diameter solution is the key ingredient for high performance, excellent quality of service, and advanced service enablement.
** The above was written by Susan Becker Traffix Marketing manager, I thought it’s a very good “Diameter for dummies” articale
8/4/10
Diameter over SCTP
I want to discuss today one of the issues we had elaborated on in the Diameter technical group (http://www.linkedin.com/groups?mostPopular=&gid=1787697 )
This is the trend towards Diameter SCTP
We see more and more Diameter running over SCTP in some major operators, really everywhere – APAC, EU and US.
This is still a very small percentage of Diameter (which in itself is still in early adoption days) but this is certainly a trend.
This creates some new issues:
- Vendors support for SCTP is limited – so connectivity problem is an issues
- Connectivity between Diameter SCTP/Diameter TCP requires mediation (Diameter SCTP to Diameter TCP gateways)
- Testing is problematic – many in between entites (routers/switches/load balancer…) have problems with SCTP and it takes time to understand this is not a problem related directly to your product, so you only test your product you test all the transport layer in between (something that works with no problem with TCP)
- Need for through testing – the product beaves completely different with none TCP layer 3 stack
I really don’t know what the future hold, will Diameter over SCTP trend increase and it will become the common path ?
I personally don’t think so, there were many initiative to improve TCP over the years (e.g WTCP) and although they had great advantages over TCP they never won, so I’m afraid SCTP will follow the same route. But still there is Diameter over SCTP trend on the rise. Well we’ll need to wait and see.
This is the trend towards Diameter SCTP
We see more and more Diameter running over SCTP in some major operators, really everywhere – APAC, EU and US.
This is still a very small percentage of Diameter (which in itself is still in early adoption days) but this is certainly a trend.
This creates some new issues:
- Vendors support for SCTP is limited – so connectivity problem is an issues
- Connectivity between Diameter SCTP/Diameter TCP requires mediation (Diameter SCTP to Diameter TCP gateways)
- Testing is problematic – many in between entites (routers/switches/load balancer…) have problems with SCTP and it takes time to understand this is not a problem related directly to your product, so you only test your product you test all the transport layer in between (something that works with no problem with TCP)
- Need for through testing – the product beaves completely different with none TCP layer 3 stack
I really don’t know what the future hold, will Diameter over SCTP trend increase and it will become the common path ?
I personally don’t think so, there were many initiative to improve TCP over the years (e.g WTCP) and although they had great advantages over TCP they never won, so I’m afraid SCTP will follow the same route. But still there is Diameter over SCTP trend on the rise. Well we’ll need to wait and see.
6/18/10
Improving Diameter protocol
This time I want to discuss one of the problems we see with Diameter and introduce a work being done to overcome this problem.
Capabilities exchange is one of the fundamental and most important mechanisms in Diameter, it is taking place in the beginning of each session, and allows peers to define the basic parameters/capabilities for the session (version number, supported Diameter apps, security mechanisms, etc…)
But what if the capabilities on one of the sides change during the session ? what if the sessions are being kept open for long time
and in this time an upgrade or configuration change in one of the clients/servers involved takes place ?
The way Capabilities exchange is defined in RFC 3588 is that it can take place only in the inception of a session, so if there is a change
during the session it means we need to tear down all the existing sessions involved and restarted in order for the updated capabilities to be taken into account – not very efficient you’ll agree.
But worry no more, the cure is on the way, a new IETF Diameter draft is here to help - The Diameter Capabilities Update Application.
A work led by Glen Zorn, whom is one of the driving forces behind Diameter since his Cisco days.
This work defines a new Diameter application intended to allow the dynamic update of a subset of Diameter peer capabilities over an
existing connection.
Because the new proposed Capabilities Update application operates over an existing transport connection, modifications of certain capabilities is prohibited.
There are a lot of heated discussions going on in the Diameter swamp around this new work – some security issues have being raised, but I think those will be handled also.
This is a blessed and important work (I can see all of you with Gx interface related work scars nodding your heads) and let’s hope we will have this draft approved soon.
I personally believe with service providers complaining on the amount of signaling in Diameter and the delays involved in some of sessions set up times – this new work is very important and sheds bright healthy light into one of the dark corners of the Diameter 3588 RFC.
Capabilities exchange is one of the fundamental and most important mechanisms in Diameter, it is taking place in the beginning of each session, and allows peers to define the basic parameters/capabilities for the session (version number, supported Diameter apps, security mechanisms, etc…)
But what if the capabilities on one of the sides change during the session ? what if the sessions are being kept open for long time
and in this time an upgrade or configuration change in one of the clients/servers involved takes place ?
The way Capabilities exchange is defined in RFC 3588 is that it can take place only in the inception of a session, so if there is a change
during the session it means we need to tear down all the existing sessions involved and restarted in order for the updated capabilities to be taken into account – not very efficient you’ll agree.
But worry no more, the cure is on the way, a new IETF Diameter draft is here to help - The Diameter Capabilities Update Application.
A work led by Glen Zorn, whom is one of the driving forces behind Diameter since his Cisco days.
This work defines a new Diameter application intended to allow the dynamic update of a subset of Diameter peer capabilities over an
existing connection.
Because the new proposed Capabilities Update application operates over an existing transport connection, modifications of certain capabilities is prohibited.
There are a lot of heated discussions going on in the Diameter swamp around this new work – some security issues have being raised, but I think those will be handled also.
This is a blessed and important work (I can see all of you with Gx interface related work scars nodding your heads) and let’s hope we will have this draft approved soon.
I personally believe with service providers complaining on the amount of signaling in Diameter and the delays involved in some of sessions set up times – this new work is very important and sheds bright healthy light into one of the dark corners of the Diameter 3588 RFC.
5/20/10
RFC 3588 vs 3588bis, what will the market adopt
RFC 3588, the Diameter base protocol RFC was officially introduced in 2003 by the IETF.
Over the last couple of years there was a lot of work done to introduce a new Diameter base, this was led by people like Glen Zorn and Victor Fajardo, was named RFC 3588bis.
RFC 3588bis is set to replace the original RFC 3588 with fixes to some of the Diameter base issues, mainly in the areas of session, security (TLS) and some improvements and clean up (IPSec..)
I have a few concerns how It will affect the adoption of Diameter, which is today mainly in the telecom field (and not the Internet)
There are a few questions that come to mind (and my own personal bet)
- Will the market move to RFC 3588 bis? (yes, the big question is in what rate)
- Will it create interoperability issues ? (yes of course)
- Will it create confusion ? (you bet)
- Will it help to establish Diameter position as the AAA/Control protocol of the next decade ? (maybe)
- Is it needed ? (I prefer not to answer this one )
One thing for sure it’s going to be interesting in the Diameter scene, with continuing adoption, growing amount of Diameter signaling, Diameter spreading out of the mobile core to the wireline, booming amount of Diameter interfaces, LTE (which should be renamed to Diameter TE due to the amount of Diameter signaling there) and of course new Diameter base.
Over the last couple of years there was a lot of work done to introduce a new Diameter base, this was led by people like Glen Zorn and Victor Fajardo, was named RFC 3588bis.
RFC 3588bis is set to replace the original RFC 3588 with fixes to some of the Diameter base issues, mainly in the areas of session, security (TLS) and some improvements and clean up (IPSec..)
I have a few concerns how It will affect the adoption of Diameter, which is today mainly in the telecom field (and not the Internet)
There are a few questions that come to mind (and my own personal bet)
- Will the market move to RFC 3588 bis? (yes, the big question is in what rate)
- Will it create interoperability issues ? (yes of course)
- Will it create confusion ? (you bet)
- Will it help to establish Diameter position as the AAA/Control protocol of the next decade ? (maybe)
- Is it needed ? (I prefer not to answer this one )
One thing for sure it’s going to be interesting in the Diameter scene, with continuing adoption, growing amount of Diameter signaling, Diameter spreading out of the mobile core to the wireline, booming amount of Diameter interfaces, LTE (which should be renamed to Diameter TE due to the amount of Diameter signaling there) and of course new Diameter base.
4/6/10
Diameter Routing Agent – some open questions
I want to share with you, some thoughts from discussion I recently had about DRA.
Diameter Routing Agent (DRA) was defined in 3GPP Release 8 and onwards to manage PCRF interaction in LTE networks.
PCRF’s are becoming more advanced, with more and more Diameter interfaces, more and more traffic – and pretty soon you need someone to manage this Diameter signaling Spaghetti – this is where DRA comes into the picture – putting some order and management.
We come across some first implementations of DRA’s (and yes we in Traffix have one also, and it’s fully 3GPP Kosher) in the market this days.
Some questions that come to mind from some first glimpse in DRA implementations:
DRA – Standalone / or part of the PCRF
We see both scenarios in the market, some of the DRA’s out there are part of the PCRF, maybe it’s because they were rolled out by the PCRF vendors, I personally believe there is a huge advantage for a standalone installation, separate from the PCRF.
DRA – Diameter Proxy agent / Redirect agent
DRA was defined to act as both Proxy or Redirect agent, there was a big argument if both functionalities are needed, and eventually it was decided not to decide.
I personally think giving the DRA the flexibility to act as both Proxy or Redirect is great, and makes sure that networks could be tuned and set with much less limitations.
DRA - Interconnectivity
Policy in 3GPP is all about freedom – either in roaming scenarios or in interconnectivity between different technologies.
However with DRA being supported only by 3GPP for mobile networks, how will it integrate to the RACS in the TISPAN wireline networks for example ? will it affect fixed mobile convergence scenarios ?
Diameter Routing Agent is still new functionality, both in the specifications and much more in the market, with first glimpses mainly in LTE labs and with half backed products that only resemble DRA from a far.
I personally believe DRA will become a central component in LTE and future telecom networks, getting more and more responsibility and functionality, but this days are still far and many standardization open issues need to be closed before that.
Diameter Routing Agent (DRA) was defined in 3GPP Release 8 and onwards to manage PCRF interaction in LTE networks.
PCRF’s are becoming more advanced, with more and more Diameter interfaces, more and more traffic – and pretty soon you need someone to manage this Diameter signaling Spaghetti – this is where DRA comes into the picture – putting some order and management.
We come across some first implementations of DRA’s (and yes we in Traffix have one also, and it’s fully 3GPP Kosher) in the market this days.
Some questions that come to mind from some first glimpse in DRA implementations:
DRA – Standalone / or part of the PCRF
We see both scenarios in the market, some of the DRA’s out there are part of the PCRF, maybe it’s because they were rolled out by the PCRF vendors, I personally believe there is a huge advantage for a standalone installation, separate from the PCRF.
DRA – Diameter Proxy agent / Redirect agent
DRA was defined to act as both Proxy or Redirect agent, there was a big argument if both functionalities are needed, and eventually it was decided not to decide.
I personally think giving the DRA the flexibility to act as both Proxy or Redirect is great, and makes sure that networks could be tuned and set with much less limitations.
DRA - Interconnectivity
Policy in 3GPP is all about freedom – either in roaming scenarios or in interconnectivity between different technologies.
However with DRA being supported only by 3GPP for mobile networks, how will it integrate to the RACS in the TISPAN wireline networks for example ? will it affect fixed mobile convergence scenarios ?
Diameter Routing Agent is still new functionality, both in the specifications and much more in the market, with first glimpses mainly in LTE labs and with half backed products that only resemble DRA from a far.
I personally believe DRA will become a central component in LTE and future telecom networks, getting more and more responsibility and functionality, but this days are still far and many standardization open issues need to be closed before that.
2/25/10
Telecom Analytics - the advantages of Diameter
Service Providers today are looking for new ways to increase revenues. One of the main paths towards achieving this goal is the use of analytics for targeted customer approach and for personalized, tuned, advanced and combined service offering. The above require real-time analysis of subscriber behavior and other information known to the service provider. This information should be analyzed per subscriber or a group of subscribers and used in order to tune customer service offering and user experience.
This information is available and encapsulated inside Diameter, some of the advantage of using Diameter compared to traditional Data path methods are:
Granularity of information – the information that flows in the control plane contains the most valuable and strategic information in the network – the location of the subscribers, their buddies (IM friends) list, their phone number, the kind of technology they use to connect to the network, their charging scheme, their IP Address, services they are using, etc.
Most of this information is not available in the in the service and the data domain.
Smaller amount of traffic – extracting information from the signaling flows can be done efficiently with software based solutions using off the shelf servers and is much more cost effective – the amount of traffic is typically 1/1,000 of the data path traffic.
Synchronization and correlation – the signaling flows in the control plane enable synchronization between different transactions and extraction of information according to pre-configured definitions. For example: extraction of all information related to a specific subscriber, a specific services, a group of users or even a specific location.
Pre-defined routes - extracting information from the data domain is not simple.
For example: messages might go through one route, and come back via another, this is the nature of IP environments, and thus a large scale implementation covering all possible routes is required. Furthermore, the amount of data that should be processed for the large amount of available applications and proprietary protocols is enormous. In the signaling domain on the other hand, traffic is controlled, interactions and routing is fixed, the implementation effort is therefore several scales smaller and the correlation of information is easier.
Information that can be extracted from Diameter:
• Accounting-Record-Type
• WLAN-Information // used in WLAN access//
• Unit-Cost
• Traffic-Data-Volumes
• Time-Usage
• Tariff-Information
• Supplementary-Service // info on additional supported services //
• Charging-Rule-Base-Name
• QoS-Information
• Rating-Group
• Time-First-Usage
• Time-Last-Usage
• Time-Usage
• 3GPP-User-Location-Info
• SDP-Media-Name //file name //
• SDP-Media-Description // type, size,format …////
• Authorized-QoS
• SDP-Type
• 3GPP-Charging-Id
• 3GPP-PDP-Type
• PDP-Address
• QoS-Information
• GGSN-Address
• 3GPP-IMSI-MCC-MNC // Mobile Network Identifer //
• 3GPP-Charging-Characteristics
• Traffic-Data-Volumes
• User-Equipment-Info // terminal related information – vendor, model….//
• Terminal-Information
• Number-Of-Participants //for multi participent services //
• Participants-Involved //for multi participent services //
• Participant-Group //for multi participent services //
• LCS-Client-ID //Location info//
• Location-Type
• Location-Estimate
• Positioning-Data
• Calling-Party-Address //the call participents info//
• Called-Party-Address //the call participents info//
• Low-Balance-Indication
• Remaining-Balance
• MSISDN
• Service-Indication
• Service-area-ID
• Global-Cell-ID
• Location-area-ID
• Bearer-Identifier
• Guaranteed-Bitrate-DL //QoS//
• Guaranteed-Bitrate-UL //QoS//
• QoS-Information
• RAT-Type AVP // Radio Access WLAN (0) UTRAN (1000) /GERAN (1001)/GAN (1002)/ HSPA(1003) ..//
• Termination-Cause
• User-Name
Summary
The signaling transactions through the control plane in telecom networks are the perfect enabler for network intelligence, analysis and user behavior monitoring. In Internet based networks over the top services model is the only model, the signaling is minimal and differentiation hardly exists. The common (and maybe best) way to extract user-related information is extracting it from the data path using DPI like products. The telecom market, however, offers a much richer and granular source of information which is encapsulated in the signaling path.
Using the signaling as the main source for network intelligence offers several advantages:
o Signaling is easier to collect - smaller in size, routes are predictable
o Signaling is much richer in information compared to the data path
o Signaling could be correlated easily
o In converged networks and roaming scenarios signaling is the only source of intelligence
o Cost efficient – no need for large scale deployment of expensive super processors, signaling domain – 1/1,000 of the usual amount of traffic, in predictable routes.
This information is available and encapsulated inside Diameter, some of the advantage of using Diameter compared to traditional Data path methods are:
Granularity of information – the information that flows in the control plane contains the most valuable and strategic information in the network – the location of the subscribers, their buddies (IM friends) list, their phone number, the kind of technology they use to connect to the network, their charging scheme, their IP Address, services they are using, etc.
Most of this information is not available in the in the service and the data domain.
Smaller amount of traffic – extracting information from the signaling flows can be done efficiently with software based solutions using off the shelf servers and is much more cost effective – the amount of traffic is typically 1/1,000 of the data path traffic.
Synchronization and correlation – the signaling flows in the control plane enable synchronization between different transactions and extraction of information according to pre-configured definitions. For example: extraction of all information related to a specific subscriber, a specific services, a group of users or even a specific location.
Pre-defined routes - extracting information from the data domain is not simple.
For example: messages might go through one route, and come back via another, this is the nature of IP environments, and thus a large scale implementation covering all possible routes is required. Furthermore, the amount of data that should be processed for the large amount of available applications and proprietary protocols is enormous. In the signaling domain on the other hand, traffic is controlled, interactions and routing is fixed, the implementation effort is therefore several scales smaller and the correlation of information is easier.
Information that can be extracted from Diameter:
• Accounting-Record-Type
• WLAN-Information // used in WLAN access//
• Unit-Cost
• Traffic-Data-Volumes
• Time-Usage
• Tariff-Information
• Supplementary-Service // info on additional supported services //
• Charging-Rule-Base-Name
• QoS-Information
• Rating-Group
• Time-First-Usage
• Time-Last-Usage
• Time-Usage
• 3GPP-User-Location-Info
• SDP-Media-Name //file name //
• SDP-Media-Description // type, size,format …////
• Authorized-QoS
• SDP-Type
• 3GPP-Charging-Id
• 3GPP-PDP-Type
• PDP-Address
• QoS-Information
• GGSN-Address
• 3GPP-IMSI-MCC-MNC // Mobile Network Identifer //
• 3GPP-Charging-Characteristics
• Traffic-Data-Volumes
• User-Equipment-Info // terminal related information – vendor, model….//
• Terminal-Information
• Number-Of-Participants //for multi participent services //
• Participants-Involved //for multi participent services //
• Participant-Group //for multi participent services //
• LCS-Client-ID //Location info//
• Location-Type
• Location-Estimate
• Positioning-Data
• Calling-Party-Address //the call participents info//
• Called-Party-Address //the call participents info//
• Low-Balance-Indication
• Remaining-Balance
• MSISDN
• Service-Indication
• Service-area-ID
• Global-Cell-ID
• Location-area-ID
• Bearer-Identifier
• Guaranteed-Bitrate-DL //QoS//
• Guaranteed-Bitrate-UL //QoS//
• QoS-Information
• RAT-Type AVP // Radio Access WLAN (0) UTRAN (1000) /GERAN (1001)/GAN (1002)/ HSPA(1003) ..//
• Termination-Cause
• User-Name
Summary
The signaling transactions through the control plane in telecom networks are the perfect enabler for network intelligence, analysis and user behavior monitoring. In Internet based networks over the top services model is the only model, the signaling is minimal and differentiation hardly exists. The common (and maybe best) way to extract user-related information is extracting it from the data path using DPI like products. The telecom market, however, offers a much richer and granular source of information which is encapsulated in the signaling path.
Using the signaling as the main source for network intelligence offers several advantages:
o Signaling is easier to collect - smaller in size, routes are predictable
o Signaling is much richer in information compared to the data path
o Signaling could be correlated easily
o In converged networks and roaming scenarios signaling is the only source of intelligence
o Cost efficient – no need for large scale deployment of expensive super processors, signaling domain – 1/1,000 of the usual amount of traffic, in predictable routes.
1/22/10
Diameter on going work
Diameter is rapidly gaining momentum, breaking the mobile network implementations boundaries.
But still Diameter is young and misses some important capabilities and applications needed in order to “fulfill its destiny” and become the signaling protocol for telecommunications – taking full responsibility over control, policy, QoS and AAA and replacing over a dozen legacy protocols that are used today in both wireless and wireline networks and of course the Internet (don’t forget the IETF is the main sponsor of Diameter)
I wanted to share with you some of the important work that is being done by the good people at IETF DIME to add those missing capabilities.
Here are some examples of work that is being standardized:
draft-ietf-dime-diameter-base-protocol-mib
Defines the Management Information Base (MIB) module needed to manage an implementation of the Diameter protocol.
draft-ietf-dime-local-keytran
Some AAA applications require the transport of cryptographic keying material; this work specifies a set of AVP’s providing native Diameter support of cryptographic key delivery.
draft-ietf-dime-nat-control
The Diameter NAT Control Application allows external devices to configure and manage a Large Scale NAT (LSN) device - expanding the existing Diameter-based AAA and policy control capabilities with a NAT control component
draft-ietf-dime-capablities-update
The Capabilities Update application is intended to allow the dynamic update of Diameter peer capabilities while the peer-to-peer connection is in the open state.
draft-ietf-dime-ikev2-psk-diameter
Specifies the interaction between the Access Gateway and Diameter server for the IKEv2 based on pre-shared secrets.
draft-ietf-dime-extended-naptr
Describes an extended format for the NAPTR service fields used in dynamic Diameter agent discovery.
draft-ietf-dime-realm-based-redirect
RFC 3588 allows a Diameter redirect agent to specify one or more individual hosts to which a Diameter message may be redirected. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This work defines an application by which this can be achieved.
draft-wu-dime-pmip6-lr
Support for Proxy Mobile IPv6 Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) routing.
draft-ietf-dime-qos-attributes
Defines a number of Diameter AVP’s for traffic classification with actions for filtering and Quality of Service (QoS) treatment.
draft-ietf-dime-diameter-cc-appl-mib
Defines the Management Information Base (MIB) module needed to manage an implementation of the Diameter Credit Control application.
But still Diameter is young and misses some important capabilities and applications needed in order to “fulfill its destiny” and become the signaling protocol for telecommunications – taking full responsibility over control, policy, QoS and AAA and replacing over a dozen legacy protocols that are used today in both wireless and wireline networks and of course the Internet (don’t forget the IETF is the main sponsor of Diameter)
I wanted to share with you some of the important work that is being done by the good people at IETF DIME to add those missing capabilities.
Here are some examples of work that is being standardized:
draft-ietf-dime-diameter-base-protocol-mib
Defines the Management Information Base (MIB) module needed to manage an implementation of the Diameter protocol.
draft-ietf-dime-local-keytran
Some AAA applications require the transport of cryptographic keying material; this work specifies a set of AVP’s providing native Diameter support of cryptographic key delivery.
draft-ietf-dime-nat-control
The Diameter NAT Control Application allows external devices to configure and manage a Large Scale NAT (LSN) device - expanding the existing Diameter-based AAA and policy control capabilities with a NAT control component
draft-ietf-dime-capablities-update
The Capabilities Update application is intended to allow the dynamic update of Diameter peer capabilities while the peer-to-peer connection is in the open state.
draft-ietf-dime-ikev2-psk-diameter
Specifies the interaction between the Access Gateway and Diameter server for the IKEv2 based on pre-shared secrets.
draft-ietf-dime-extended-naptr
Describes an extended format for the NAPTR service fields used in dynamic Diameter agent discovery.
draft-ietf-dime-realm-based-redirect
RFC 3588 allows a Diameter redirect agent to specify one or more individual hosts to which a Diameter message may be redirected. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This work defines an application by which this can be achieved.
draft-wu-dime-pmip6-lr
Support for Proxy Mobile IPv6 Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) routing.
draft-ietf-dime-qos-attributes
Defines a number of Diameter AVP’s for traffic classification with actions for filtering and Quality of Service (QoS) treatment.
draft-ietf-dime-diameter-cc-appl-mib
Defines the Management Information Base (MIB) module needed to manage an implementation of the Diameter Credit Control application.
12/10/09
The need for Native Diameter Load Balancing
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.
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.
Subscribe to:
Posts (Atom)
