One document matched: draft-ietf-dime-realm-based-redirect-02.txt
Differences from draft-ietf-dime-realm-based-redirect-01.txt
Internet Engineering Task Force T. Tsou
Internet-Draft T. Taylor, Ed.
Updates: RFC 3588 Huawei Technologies
(if approved) October 27, 2009
Intended status: Standards Track
Expires: April 30, 2010
Realm-Based Redirection In Diameter
draft-ietf-dime-realm-based-redirect-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 30, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
RFC 3588 allows a Diameter redirect agent to specify one or more
Tsou & Taylor Expires April 30, 2010 [Page 1]
Internet-Draft Realm-Based Redirection In Diameter October 2009
individual hosts to which a Diameter message may be redirected by an
upstream Diameter node. However, in some circumstances an operator
may wish to redirect messages to an alternate domain without
specifying individual hosts. This document specifies the means by
which this can be achieved. It also defines a new application by
means of which support for this capability can be advertised.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Realm-Based Routing Application . . . . . . . . . . . . . . . . 3
3. Realm-Based Redirection . . . . . . . . . . . . . . . . . . . . 3
3.1. Behaviour of Diameter Nodes . . . . . . . . . . . . . . . . 4
3.1.1. Behaviour at the Redirect Agent . . . . . . . . . . . . 4
3.1.2. Behaviour of Other Diameter Nodes . . . . . . . . . . . 4
3.2. The Redirect-Realm AVP . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
Tsou & Taylor Expires April 30, 2010 [Page 2]
Internet-Draft Realm-Based Redirection In Diameter October 2009
1. Introduction
The usual redirect indication as described in Section 6.1.7 and
Sections 6.12-6.14 of [RFC3588] returns one or more individual host
names to the upstream Diameter node. However, consider the case
where an operator has offered a specific service but no longer wishes
to do so. The operator has arranged for an alternative domain to
provide the service. To aid in the transition to the new
arrangement, the original operator maintains a redirect server to
indicate the alternative destination to upstream nodes. However, the
original operator has no interest in configuring a list of hosts in
the alternative operator's domain, and would prefer simply to provide
redirect indications to the domain as a whole.
Within this specification, the term "realm-based redirection" is used
to refer to a mode of operation where the redirect indication
specifies a realm and the upstream Diameter node reroutes the message
to the realm rather than an individual host.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Realm-Based Routing Application
Because realm-based redirection is not part of base Diameter
behaviour, support for realm-based redirection by the client cannot
be guaranteed without advertisement at the application level. This
document therefore specifies a new application, Realm-Based Routing
(code TBD), for that purpose.
3. Realm-Based Redirection
This section specifies an extension to [RFC3588] to achieve realm-
based routing. The elements of this solution are:
o a new result code, DIAMETER_REALM_REDIRECT_INDICATION (3011);
o one new attribute-value pair (AVP), Redirect-Realm; and
o associated behaviour at Diameter nodes implementing this
specification.
Tsou & Taylor Expires April 30, 2010 [Page 3]
Internet-Draft Realm-Based Redirection In Diameter October 2009
3.1. Behaviour of Diameter Nodes
3.1.1. Behaviour at the Redirect Agent
This specification modifies Section 2.7 of [RFC3588] to permit
REDIRECT routing table entries to contain an alternative realm
instead of individual home server identities.
This specification modifies Section 6.1.7 of [RFC3588]. If the
realm-based routing table for a request contains a realm rather than
one or more home server identities, the redirect agent MUST set the
Result-Code AVP to DIAMETER_REALM_REDIRECT_INDICATION rather than
DIAMETER_REDIRECT_INDICATION. Furthermore, the redirect agent MUST
insert a Redirect-Realm AVP containing the realm from the routing
table entry in its answer message instead of one or more Redirect-
Host AVPs. It SHOULD insert a Redirect-Max-Cache-Time AVP to
indicate the scope and persistence of the redirection in upstream
Diameter nodes' routing caches. To prevent confusion at Diameter
nodes receiving the answer message, the Result-Code AVP MUST include
the Error-Reporting-Host AVP if the host setting the Result-Code AVP
is different from the identity encoded in the Origin-Host AVP, in
conformity with Section 7.1 of [RFC3588]. All other aspects of
Section 6.1.7 remain the same as for host-based redirection.
3.1.2. Behaviour of Other Diameter Nodes
A Diameter node conforming to this specification which receives an
answer with the result code value DIAMETER_REALM_REDIRECT_INDICATION
SHOULD attempt to reroute the request to the indicated realm using
normal discovery procedures to find an appropriate destination host.
The receiving Diameter node SHOULD update its cache of routing
entries according to the direction provided by the Redirect-Max-
Cache-Time AVP, if present. The cache entry SHOULD be associated
with a redirect usage of ALL_REALM.
3.2. The Redirect-Realm AVP
The Redirect-Realm AVP (code TBD) is of type DiameterIdentity. It
specifies a realm to which a node receiving a redirect indication
containing the result code value DIAMETER_REALM_REDIRECT_INDICATION
and the Redirect-Realm AVP SHOULD route the original request. The M
and V flags for the Redirect-Realm AVP MUST NOT be set.
Section 6.14 of [RFC3588] is modified to permit the Redirect-Max-
Cache-Time AVP to be used also to specify the persistence of cache
entries created by the Redirect-Realm AVP.
Tsou & Taylor Expires April 30, 2010 [Page 4]
Internet-Draft Realm-Based Redirection In Diameter October 2009
4. Security Considerations
Because real-based redirection implies a change in business
relationships, the node acting on the redirect indication SHOULD
verify that the new realm is authorized to perform the requested
service. Similarly the originator of the request SHOULD perform an
authorization check of the path as described in Section 2.10 of
[RFC3588].
5. IANA Considerations
This specification adds a new AVP code [286???] Redirect-Realm in
the AVP Code registry under Authentication, Authorization, and
Accounting (AAA) Parameters.
This specification allocates a new Result-Code value
DIAMETER_REALM_REDIRECT_INDICATION (3011) in the Result-Code AVP
Values (code 268) - Protocol Errors registry under Authentication,
Authorization, and Accounting (AAA) Parameters.
This specification defines a new Diameter application, Realm-Based
Routing, in the Standards Track portion of the Diameter application
identifier registry.
6. Acknowledgements
Glen Zorn, Sebastien Decugis, Wolfgang Steigerwald, Mark Jones, and
Victor Fajardo contributed comments that helped to shape this
document.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
Tsou & Taylor Expires April 30, 2010 [Page 5]
Internet-Draft Realm-Based Redirection In Diameter October 2009
Authors' Addresses
Tina Tsou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: tena@huawei.com
Tom Taylor (editor)
Huawei Technologies
1852 Lorraine Ave
Ottawa
Canada
Email: tom111.taylor@bell.net
Tsou & Taylor Expires April 30, 2010 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-24 04:31:36 |