Hi Hannes, It was in
3.2. Redirect Indication based on realm
Consider an Operator; say Operator_A offering some service to
Diameter client in its Realm; say Realm_A. For business/maintenance
reasons, the operator wants to discontinue the service. However the
operator has asked another Operator; say Operator_B (serving Realm_B)
to provide the service to the clients. In this case, all the clients
should be configured to contact Realm_B instead of Realm_A for the
service.
For smooth transition, agents may be employed in Realm_A which could
answer with a redirect indication suggesting that the service
requests may be sent to another realm; Realm_B in this case, so as to
be served ... 4. Problem Statements ... 4.3. Redirect Indication based on realm
This is the statement of the problem posed by the case presented in
Section 3.2.
1. Existing Diameter message routing behaviour: Redirect indication
is provided at host level. It provides a list of servers that
may be contacted for the request to be served.
2. Undesirable behaviour in the existing method: Redirect indication
is not provided at the realm level. There is no option to
provide a (list of) realm(s) that may be contacted for the
request to be served.
3. Desired behaviour: Redirect indication could be provided at the
realm level also. The indication may specify a (list of)
realm(s) which could be contacted for the request to be served.
On Jun 5, 2009, at 5:05 PM, Hannes Tschofenig wrote: Could you send the link to the draft around? Could the redirect at realm level be included?
On Jun 3, 2009, at 7:13 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: Based on the feedback I have updated the text.
<<dime-recharter.pdf>>
DiME mailing list
DiME at ietf.org
https://w ww.ietf.
|
