top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

When the Hop-by-Hop Id increases in big steps rather than monotonically increasing number, the HSS suffers. Why?

+2 votes
533 views

The DRA is between e.g. MME and HSS or SGSN and HSS and maybe between HSS and IMS S-CSCF/I-CSCF. In the IETF Spec RFC3588 you can read the following: IETF - RFC3588

The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in network byte order) and aids in matching requests and replies. The sender MUST ensure that the Hop-by-Hop identifier in a request is unique on a given connection at any given time, and MAY attempt to ensure that the number is unique across reboots. The sender of an Answer message MUST ensure that the Hop-by-Hop Identifier field contains the same value that was found in the corresponding request. The Hop-by-Hop identifier is normally a monotonically increasing number, whose start value was randomly generated. An answer message that is received with an unknown Hop-by-Hop Identifier MUST be discarded.

--> for me it sounds like that the HbHid must not jump in numbers but rather increase step by step sequential – is that also your experience?

Issue: I wonder if that Hop-by-Hop Identifier really increases the number sequentially as it seems to be a similar Parameter like the Local Reference in SS7 (DLR, SLR). I do not recall that in SS7 the Source/Destination Local Reference Numbers have to be increased sequentially.
If the Hop-by-Hop ID jumps too much, the other side may not be able to follow and Signalling errors occur? Have you seen problems on HSS or MME when that Hop-by-Hop Identifier increases in big steps rather than sequential?

posted Dec 5, 2014 by Stefan Blomeier

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

Stefan, I worked close to 1 year for the DRA/Diameter product line and never seen hop-by-hop identifier increases randomly, having said that if we read the following statement "The Hop-by-Hop identifier is normally a monotonically increasing number, whose start value was randomly generated." then it is saying normally not must so peer should accept even if it is a random increment. (That is my interpretation)

answer Dec 6, 2014 by Salil Agrawal
many thanks for your feedback. I agree with you!
commented Dec 10, 2014 by Stefan Blomeier
My pleasure :)
commented Dec 10, 2014 by Salil Agrawal
Similar Questions
+2 votes
Why does 2nd HSS FE send Dia Error 3002 when DRA addesses the 2nd HSS FE Destination Host of the 1st HSS FE?

3GPP TS 29.272 says in section 7.1.6/ Routing considerations the following sentence:
If an MME or SGSN knows the address/name of the HSS for a certain user, and the associated home network domain name, both the Destination-Realm and Destination-Host AVPs shall be present in the request......

In Diameter Base Protocol RFC 6733 you can read the following :
6.1.4. Processing Local Requests
A request is known to be for local consumption when one of the following conditions occurs:
o The Destination-Host AVP contains the local host’s identity;
o The Destination-Host AVP is not present, the Destination-Realm AVP contains a realm the server is configured to process locally, and the Diameter application is locally supported; or
o Both the Destination-Host and the Destination-Realm are not present.

Following erroneous Scenario:
1) The MME sends a Request to the Destination Host e.g. HSS_ABC01.xxx via the DRA. The Request contains Destination-Host and Destination-Realm…
2) But what happens when this HSS_ABC01.xxx is unavailable (out of order)? Would the DRA send/forward the Request from MME to a second HSS (front end)?, e.g. hssDEF01.xxx?
3) Would the 2nd HSS Frontend “hssDEF01.xxx” complain that the Destination Host does not match as DRA sent to 2nd HSS frontend the Request with Destination-Host = HSS_ABC01.xxx
-->should the DRA be smarter when the 1st HSS Frontend is unavailable ? my question is what can DRA do in such case when the original destination is out of order?

FYI:
DIAMETER_UNABLE_TO_DELIVER 3002
This error is given when Diameter cannot deliver the message to the destination, either because no host within the realm supporting the required application was available to process the request or because the Destination-Host AVP was given without the associated Destination-Realm AVP.

...