One document matched: draft-calhoun-diameter-res-mgmt-07.txt
Differences from draft-calhoun-diameter-res-mgmt-06.txt
Individual Contribution Pat R. Calhoun
Internet-Draft Sun Microsystems, Inc.
Category: Standards Track February 2001
<draft-calhoun-diameter-res-mgmt-07.txt>
Diameter
Resource Management Extensions
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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 document is an individual contribution for consideration by the
AAA Working Group of the Internet Engineering Task Force. Comments
should be submitted to the diameter@diameter.org mailing list.
Distribution of this memo is unlimited.
Copyright (C) The Internet Society 1999. All Rights Reserved.
Calhoun expires July 2001 [Page 1]
Internet-Draft February 2001
Abstract
Diameter is an authentication, authorization and accounting (AAA)
protocol used for network access services, such as dial-up (NASREQ)
and Mobile IP. Some Diameter servers maintain state information of
active sessions on the access servers, which is used mostly to
enforce some local policy decisions. This extension describes an
extension to the Diameter protocol that allows the server to query
for active session state information from access servers in order to
rebuild state information should it be lost for any reason.
Table of Contents
1.0 Introduction
1.1 Specification of Requirements
1.2 State synchronization
2.0 Command-Code Values
2.1 Session-Resource-Query
2.2 Session-Resource-Reply
3.0 Mandatory AVPs
3.1 Query-Index AVP
3.2 Resource-Token AVP
3.3 Resource-Bag AVP
4.0 IANA Considerations
5.0 Security Considerations
6.0 Acknowledgements
7.0 References
8.0 Authors' Addresses
9.0 Full Copyright Statement
1.0 Introduction
Diameter [1] is an authentication, authorization and accounting (AAA)
protocol used for network access services, such as dial-up (NASREQ)
[2] and Mobile IP [3].
The NASREQ AAA requirements [6] require that AAA servers maintain
session state information. This is typically used to enfore a local
policy decision, such as limiting the number of simultaneous sessions
for a specific user, maintaining IP address pools, etc. The AAA WG's
network access requirements [5] require that an AAA protocol be able
to query for session state information, in the event that this
information is lost.
This extension describes an extension to the Diameter protocol that
allows a Diameter node to query for active session state information
Calhoun expires July 2001 [Page 2]
Internet-Draft February 2001
from its peers in order to rebuild state information. Although it is
envisioned that this would be used when state information was lost,
and needed to be rebuilt, it is possible for a node to periodically
query for state information in order to ensure that its state is
current.
This document only concerns itself with the ability to query for
session state information. Resources are actually reserved when a
user is successfully authorized. Therefore, relevant application-
specific extensions, such as [2] and [3], MUST define what resources
are to be managed, by specifying what AVPs MUST be present in the
Resource-Token AVP.
The Extension number for this draft is three (3). Diameter nodes
conforming to this specification MUST include an Extension-Id AVP
with a value of three in the Device-Reboot-Ind Command [1].
1.1 Specification of Requirements
In this document, the key words "MAY", "MUST", "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [7].
1.2 State synchronization
When a Diameter node determines that it is has lost all state
information it had for a specific peer, it SHOULD issue a Session-
Resource-Query message to the peer. The node in question MAY postpone
all authorization messages from the peer until state has been
restored.
Upon receipt of the Session-Resource-Query, all Resource-Token AVPs
for the requested sessions, indicated via one or more Session-Id AVP,
MUST be returned in a Session-Resource-Reply. The absence of any
Session-Id AVP is an indication that all active sessions are to be
returned.
If the node is unable to send all of the information within a single
message, it MUST include the Query-Index AVP, with a value that has
local significance. A node that receives a Session-Resource-Reply
with a Query-Index AVP SHOULD issue another Session-Resource-Query
message with the Query-Index AVP intact, requesting the rest of the
state information.
Calhoun expires July 2001 [Page 3]
Internet-Draft February 2001
+----------+ SRQ (no Query-Index AVP) ---> +----------+
| | <--- SRR (Query-Index AVP = x) | |
| Diameter | SRQ (Query-Index AVP = x) ---> | Diameter |
| Node A | <--- SRR (Query-Index AVP = y) | Node B |
| | SRQ (Query-Index AVP = y) ---> | |
+----------+ <--- SRR (no Query-Index AVP) +----------+
Figure 1: Session State Exchange
The above example depicts Diameter Node a issuing an SRQ to Node B.
Upon replying with an SRR, node B determines that it is unable to
include all of the Resource-Token AVPs in a single reply, and
therefore includes the Query-Index AVP with a value of x.
Upon receipt of the response, node A processes all Resource-Token
AVPs and issues a subsequent SRQ with the Query-Index AVP set to x.
Node B receives the SRQ, and using the Query-Index AVP determines
which sessions need to be included in the corresponding SRR.
This exchange continues until node B returns an SRR that does not
include the Query-Index AVP, indicating that there is no further
session state information to be returned.
2.0 Command-Code Values
This section defines Command-Code [1] values that MUST be supported
by all Diameter implementations conforming to this specification.
The following Command Codes are defined in this specification:
Command-Name Abbrev. Code Reference
--------------------------------------------------------
Session-Resource-Query SRQ 277 2.1
Session-Resource-Reply SRR 278 2.2
2.1 Session-Resource-Query (SRQ)
The Session-Resource-Query (SRQ), indicated by the Command-Code field
set to 277, MAY be sent by a Diameter node to any of its peer to
request a state update. The presence of one or more Session-Id AVPs
in the Session-Resource-Query message indicates that the server only
wants to receive the Resource-Token for the specified session(s).
Message Format
Calhoun expires July 2001 [Page 4]
Internet-Draft February 2001
<Session-Resource-Query> ::= < Diameter Header: 277 >
{ Host-Name }
* [ Session-Id ]
[ Destination-NAI ]
0*1[ Query-Index ]
* [ AVP ]
* [ Proxy-State ]
* [ Route-Record ]
* [ Routing-Realm ]
0*1< Integrity-Check-Value >
2.2 Session-Resource-Reply (SRR)
The Session-Resource-Reply (SRR), indicated by the Command-Code field
set to 278, is sent in response to a SRQ message. The SRR message
contains a Resource-Token for each active session that was requested
via the Session-Id AVP. The absence of any Session-Id AVP in the SRQ
implies that Resource-Tokens for all active sessions MUST be
returned.
In the event that all of the state information cannot be sent at
once, the SRR message MUST include the Query-Index AVP.
Message Format
<Session-Resource-Reply> ::= < Diameter Header: 278 >
{ Host-Name }
{ Result-Code }
[ Destination-NAI ]
0*1[ Query-Index ]
* [ Resource-Token ]
* [ AVP ]
* [ Proxy-State ]
* [ Route-Record ]
* [ Routing-Realm ]
0*1< Integrity-Check-Value >
3.0 Mandatory AVPs
The following table describes the Diameter AVPs defined in the
Resource Management extension, their AVP Code values, types, possible
flag values and whether the AVP MAY be encrypted.
Calhoun expires July 2001 [Page 5]
Internet-Draft February 2001
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
Query-Index 500 3.1 Unsigned32 | M | P | | V | Y |
Resource-Bag 502 3.3 OctetString| M | P | | V | Y |
Resource-Token 501 3.2 Grouped | M | P | | V | Y |
3.1 Query-Index AVP
The Query-Index AVP (AVP Code 500) is of type Unsigned32 and MUST
only be present in the Session-Resource-Query and the Session-
Resource-Reply messages. The Query-Index AVP has local significance
to the issuer of the Session-Resource-Reply message, and is used to
identify the state information that remains to be sent in a
subsequent SRR message.
3.2 Resource-Token AVP
The Resource-Token AVP (AVP Code 501) is of type Grouped. The value
is a set of AVPs used to track state information that is pertinent to
an active session. The issuer of the SRR message is responsible for
creating a Resource-Token AVP for all active sessions requested.
The following describes the minimum number of AVPs that MUST be
present in a Resource-Token AVP. Service-specific AVPs MAY also be
present, as defined in the appropriate service extension document.
The Resource-Token Grouped value has the following grammar:
resource-token = sid host user timestamp extension-id optional
sid = Session-Id AVP ; See [1], Section 3.1.
host = Host-Name AVP ; See [1], Section 2.3.1.
user = User-Name AVP ; See [1], Section 3.3.
timestamp = Timestamp AVP ; See [1], Section 7.3.
extension-id = Extension-Id AVP ; See [1], Section 2.6.3.
optional = Resource-Bag AVP ; See Section 3.3
The Host-Name AVP contains the NAI of the access router that is
servicing the user, while the timestamp AVP contains the time at
which the successful Diameter authorization response was received,
and the service was initiated.
Calhoun expires July 2001 [Page 6]
Internet-Draft February 2001
3.3 Resource-Bag AVP
This AVP allows encapsulation of arbitrarily many AVPs to be included
in a Resource-Token. These AVPs are defined in service specific
extensions to Diameter. The only restrictions to the AVPs is that
they MUST NOT be interpreted so as to conflict with the other fields
of the Resource-Token Group value, namely, the Session-Id, Host-Name,
User-Name, Timestamp or Extension-Id AVPs.
The Resource-Bag AVP (AVP Code = 502) is of type OctetString. The
AVP encapsulates an arbitrary of AVPs, each with its own header and
value.
4.0 IANA Considerations
The command codes defined in Section 2.0 are values taken from the
Command-Code [1] address space and extended in [2], [4] and [8].
IANA should record the values as defined in Section 2.0.
The AVPs defined in section 3.0 were alllocated from from the AVP
numbering space defined in [1], and extended in [2], [4] and [8].
IANA should record the values as defined in Section 3.0.
5.0 Security Considerations
This Diameter extension assumes that the Resource Management data is
secured either through a hop-by-hop authentication mechanism, as
described in [1], or using a strong authentication mechanism as
defined in [9].
6.0 Acknowledgements
The authors wish to thank Erik Guttman for providing some very useful
proposed text to handle the change in data types.
7.0 References
[1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "Diameter Base
Protocol", draft-calhoun-diameter-17.txt, IETF work in progress,
September 2000.
[2] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ
Extension", draft-calhoun-diameter-nasreq-05.txt, IETF work in
Calhoun expires July 2001 [Page 7]
Internet-Draft February 2001
progress, September 2000.
[3] Calhoun, Zorn, Pan, Akhtar, "Diameter Framework", draft-calhoun-
diameter-framework-07.txt, IETF work in progress, April 2000.
[4] P. Calhoun, C. Perkins, "Diameter Mobile IP Extensions", draft-
calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep-
tember 2000.
[5] Aboba et al, "Network Access AAA Evaluation Criteria", draft-
ietf-aaa-na-reqts-07.txt, IETF work in progress, August 2000.
[6] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access
Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work
in progress, June 2000.
[7] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[8] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "Diameter Accounting
Extension", draft-calhoun-diameter-accounting-08.txt, IETF work
in progress, September 2000.
[9] P. Calhoun, W. Bulley, S. Farrell, "Diameter Strong Security
Extension", draft-calhoun-diameter-strong-crypto-05.txt, IETF
work in progress, September 2000.
8.0 Authors' Addresses
Questions about this memo can be directed to:
Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: +1 650-786-7733
Fax: +1 650-786-6445
E-mail: pcalhoun@eng.sun.com
9.0 Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
Calhoun expires July 2001 [Page 8]
Internet-Draft February 2001
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this docu-
ment itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English. The lim-
ited permissions granted above are perpetual and will not be revoked
by the Internet Society or its successors or assigns. This document
and the information contained herein is provided on an "AS IS" basis
and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS-
CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
10.0 Expiration Date
This memo is filed as <draft-calhoun-diameter-res-mgmt-07.txt> and
expires in July 2001.
Calhoun expires July 2001 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 04:11:39 |