top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

e2e and h2h identifier in diameter

+2 votes

What is the significance of "Hop-by-Hop identifier" & "End-to-End identifier" in Diameter ? As per RFC3588, "Hop-by-Hop id" helps in matching requests & replies and "End-to-End" helps in detecting duplicate packets... However, I couldn't understand why a single identifier can't be used to handle both detecting duplicate packets & matching request and replies. As per the identifier names, I thought "Hop-by-Hop" helps when there are agents involved during diameter routing... Does it matter when there is only Client & Server and there is no Agent/Relay in between the diameter client and server ?

posted Aug 27, 2013 by Deepankar Dubey

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

1 Answer

+1 vote
Best answer

It is true that in case of a client-to-server single-hop deployment, e2eid can server the purpose, but since Diameter protocol supports multi-hop scenario, it uses hop-by-hop id to uniquely associate an answer to the request. A peer stamps a unique (for that peer) hop-id while sending the request, and when the answer comes back (carrying the same hop-id), it is able to extract the required information like the source of the request as well as its 'original' hop-id.
The protocol has to support the general deployment (which would involve relays between agent and server). It can't do separate processing for the special case of single hop deployment. Note that e2eid is required to be unique only for that 'originating host', so at the server (and at relays) there could be multiple requests with the same e2eid from different clients.

In your own case, even though today you have a single hop deployment, as the network grows, you may need a relay in between. With the right implementation, you can achieve that without any change to the application or protocol implementation, just by a configuration change.

answer Aug 27, 2013 by Rathnakumar Kayyar
Similar Questions
+1 vote

From the RFC 6733, it is clear that diameter session is identified bases on session-id, which has to be globally unique. Also in section 2.5 (Connections vs Sessions), its clearly mentioned that one connection can be used to multiplex multiple diameter sessions.

I have following questions related to diameter session -
Is there any implicit correlation between diameter session and origin-host? Does diameter standard allow different requests for the same session to have different origin-host value? Is there any possible problem if the value of Diameter Identity (part of recommended format for session-id) is different from those present in the request (like origin-host/origin-realm)?

+1 vote

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