top button
Flag Notify
    Connect to us
      Facebook Login
      Site Registration Why to Join

Facebook Login
Site Registration
Print Preview

origin-host scope for diameter overload control

+1 vote

There are use cases for Diameter overload control where it would be useful for a server to be able to throttle traffic from a specific source. When the source is adjacent to the server, this can be accomplished easily enough by the server just sending the overload control information directly to the source in question.

However, when there are intermediaries between the server and the source (client), the current mechanism a way to do this. Adding a scope for origin-host would solve this issue. The way this would work would be for the server to construct the overload control information and attach the origin-host scope to it that matches the specific source of overload it wants to target. The information would be ignored by any other recipients as they would not have an origin-host that matches that scope when sending messages.

I think this could be an optional scope as it wouldn't be needed for all applications that may use Diameter overload control.

posted Jun 26, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button Google+ Share Button LinkedIn Share Button Multiple Social Share Button

1 Answer

0 votes

I agree it should be optional for agents. I'm on the fence for clients, but optional is probably okay there. If people specify application specific behavior for certain applications, they could always mandate it there.

answer Jun 27, 2013 by anonymous
Similar Questions
+3 votes

I am trying to clarify the allowed naming convention for the host and realm of a diameter node. This relates to the values used in the Origin-Host AVP (AVP Code 264) and Origin-Realm AVP (AVP Code 296). I have reviewed the Diameter RFCs and cannot find a definitive answer to this issue.

The reason for asking this question is that I am in discussion with a vendor of a Diameter Routing Agent (DRA) which claims that the host of a diameter node has to be in the format host.realm.
(1) Example of the only allowed format according to the vendor:Origin-Realm:
I want to clarify if multiple subdomains are allowed to be added in the host without being present in the realm.(2) Example:Origin-Realm:

According to the vendor, the example 2 is not allowed. To have the host as in example 2, the realm will have to be
Could someone please clarify this naming issue or point me to the standard where this is defined.

+3 votes

I have a query regarding usage of Origin-State-Id AVP in Diameter. The Diameter Base Protocol RFC 3588 says that Origin-State-Id AVP MAY be included in any diameter message.

Now, some diameter based application (like a 3GPP defined application) defines new commands and in those commands’ ABNF Origin-State-Id AVP is not present.

Then does this imply that Origin-State-Id AVP MUST not be sent in these commands or it can be sent because RFC 3588 says it can be sent in any diameter message?

+1 vote

I was going through rfc3588 and could not understand when a Diameter Server/Agent adds Error-Reporting -Host AVP within the answer message.

+1 vote

Can someone please explain why few "request" message contains Destination-Host and Destination-Realm AVPs and few of them not ?

+5 votes

State the difference between Diameter Credit Control Applications and Ro applications with reference to Diameter protocol?

Useful Links with Similar Problem
Contact Us
+91 9880187415
#470/147, 3rd Floor, 5th Main,
HSR Layout Sector 7,
Bangalore - 560102,
Karnataka INDIA.