top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Diameter request routing clarification

0 votes
164 views

I need clarification about Diameter request routing.

Consider the use-case:

host: pcef, realm: example.com
  |      A
  |CCR   |RAR
  V      |
host: relay, realm: example.com
  |      A
  |CCR   |RAR
  V      |
host: ocs, realm: example.com

RFC6733 says that request routing should be controlled by routing table.

Host `ocs' has to consume CCR requests to realm example.com of application 4, so it should have route

  (example.com, 4) -> (LOCAL)

Host `ocs' also has to send locally generated RAR requests to realm example.com of application 4, so it should have route

  (example.com, 4) -> (RELAY, relay)

How `ocs' host should operate to select correct route?

Does it mean that Diameter host should maintain two routing tables, one for handling of incoming requests, and one another for handling locally generated requests?

posted Jun 4, 2014 by Sridharan

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

Similar Questions
+4 votes
Clarification on diameter Sy Interface?

Scenario:
For one subscriber with MSISDN 1234567:

Provisioning in PCRF SPR: Policy_A, Policy_B, Policy_C
OCS active Services: Service_A, Service_B, Service_C

Each PCRF Policy corresponds to OCS Service respectively.

When PCRF requests counters status from OCS in SLR(initial), it does not explicitly specify which counters it needs. PCRF sends MSISDN in [ Subscription-Id ] AVP in SLR(initial). OCS sends all available counters in SLA.

How PCRF will identify which counter(s) is for which policy? How this mapping will be done ?

+3 votes
DIAMETER: Why does Device Watchdog Request/Answer messages used at application level, even SCTP is being used ?

When SCTP layer itself takes care of heartbeat ack-nack then why does diameter watchdog mechanism is required at the application layer ?

...