top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Diameter questions regarding RFC 3539

+1 vote

I am studying RFC 3539. While I have some difficulties to understand "Appendix A - Detailed Watchdog Algorithm". Please provide some help.

1) Does AAA client or AAA Server (direct connection scenario) need to follow the algorithm?
In section 3.4 we have: "The watchdog is used in order to enable a AAA client or agent to determine when to resend on another connection." Does it mean the algorithm is only required in AAA client? Without following the algorithm AAA server would utilize the newly connected link earlier than AAA client, which would cause some AAA server initiated procedures, such as RAR, result in failure.

2) If the algorithm is required in AAA server, how to avoid the infinite loop when both AAA client and AAA server enter "REOPEN" phase?
If the "connection up" event indicates to AAA client and AAA server, both of them would send DWR to verify the link and enter "REOPEN" phase. While in this phase only DWA is allowed to be a signal to trigger the state machine going forward. It seems to me that both sides would discard the DWR sent by their peer and run into an infinite loop.

3) If the DWR was out of the scope of Non-DWA, how to avoid the inconsistent states between 2 AAA peers?
The total link verification time by the algorithm would be 2 x Tw + 3 x (time of DWA - time of DWR). If one side sets its Tw much longer than the other, it would run into the similar consequence of my question 1) - one side would utilize the newly connected link earlier than the other.

4) Is RFC 3539 so strictly binding to RFC 3588?
RFC 3588 has many statements referring to RFC 3539, especially in its transport description. I am quite confused about the coordination between the state machine logic in the Section 5.6 of RFC 3588 and that in the Appendix A of RFC 3539. I am wondering the strong binding is necessary to the application of AAA or very diameter application.

posted Jun 11, 2013 by anonymous

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button LinkedIn Share Button

Similar Questions
+3 votes

Both the RFCs are referred for Diameter protocol. I want to know why two RFCs are defined for same Diameter protocol ? Difference between these two RFCs in term of contents ?

+3 votes

I have a query on SCTP guidelines for Diameter base protocol specified in section 2.1.1 of RFC 6733 as :

"A Diameter agent SHOULD use dedicated payload protocol identifiers (PPIDs) for clear text and encrypted SCTP DATA chunks instead of only using the unspecified payload protocol identifier (value 0). For this purpose, two PPID values are allocated: the PPID value 46 is for Diameter messages in clear text SCTP DATA chunks, and the PPID value 47 is for Diameter messages in protected DTLS/SCTP DATA chunks."

RFC doesn't specify the behavior if the connected diameter peer doesn't use PPID as 46/47 for diameter message transport over SCTP or DTLS/SCTP. What if diameter messages are received with PPID set to value other than 46/47 or default 0 value? Should the messages be ignored or respond with error diameter message back to peer with same PPID set ? Please comment on this behavior.

+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)?

+3 votes

I was reading 6696 and 6942 (it's been awhile) and I need clarification:

1) It appears that 6942 does not support transportation of DSRK key. Only rRK and rMSK. Is that correct?

2) According to RFC 6696 - section 4.2:

RFC 6696: Section 4.2:

"The rRK MUST remain on the peer and the server that derived it and MUST NOT be transported to any other entity."

So why is 6942 transporting the rRK around?

0 votes

In Diameter S6a specification (3GPP 29.272), it is indicated that the full procedure for Delete-Subscriber-Data from the HSS should be described in the 3GPP 23.401
However, I don't see any clear reference there.
Do you know where I can find it, especially for the deletion of one of the APN-configuration in the MME