Internet DRAFT - draft-zhangtao-aaa-compression
draft-zhangtao-aaa-compression
AAA Working Group Zhangtao
Internet Draft Rajith R
Document: draft-zhangtao-aaa-compression-00.txt Huawei Technologies
Expires: February 2006 August 2005
Diameter Compression
draft-zhangtao-aaa-compression-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 document is an individual submission to the Authentication,
Authorization and Accounting (AAA) Working Group of the Internet
Engineering Task Force (IETF). Comments are welcome should be
submitted to the mailing list aaa-wg@merit.edu.
Abstract
This document describes the negotiation of compression algorithm
between two Diameter peers and the indication of data compression
using a new AVP [Attribute Value Pair] flag.
Zhangtao et al. Expires - February 2006 [Page 1]
Internet-Draft Diameter Compression August 2005
The compression negotiation commands and the compression-indication
AVP flag specified in this document are in addition to that specified
in the Diameter base. In this sense, this document extends the Base
Diameter protocol.
Conventions used in this document
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 [ii].
Table of Contents
1. Introduction.................................................2
2. Compression Algorithm negotiation............................3
2.1 Compression-Negotiate-Request............................4
2.2 Compression-Negotiate-Answer.............................4
2.3 Compression-Info AVP.....................................5
2.4 Compressed-AVP-Info AVP..................................6
2.5 Compression-Arithmetic AVP...............................6
2.6 AVP-Info AVP.............................................7
2.7 Application Id...........................................7
2.8 Result Codes.............................................7
2.9 AVP occurrence table.....................................7
3. Compression Indication û The 'C' AVP Flag....................8
4. IANA Considerations..........................................9
4.1 Command Codes............................................9
4.2 AVP Codes................................................9
4.3 Result Code AVP values...................................9
4.4 Application Id...........................................9
5. Security Considerations......................................9
6. References..................................................10
6.1 Normative References....................................10
Acknowledgments................................................10
Author's Addresses.............................................10
1. Introduction
The application specific DIAMETER messages usually carry some AVPs
which are of very large length. Some examples are the User-Data AVP
(which contains the profile of a user in XML format) carried by some
3GPP Cx-Dx interface DIAMETER messages OR the SDP information carried
by the 3GPP Accounting interface messages. In these cases, it is
desirable to compress the AVPs so as to reduce the size of the
DIAMETER message.
Zhangtao et al. Expires - February 2006 [Page 2]
Internet-Draft Diameter Compression August 2005
This specification describes the negotiation of compression algorithm
between DIAMETER peers using a new DIAMETER command û the
Compression-Negotiate-Request (CNR) and its associated response û the
Compression-Negotiate-Answer (CNA). The specification also describes
the indication of data compression using a new flag û the 'C' flag;
in the AVP header of the compressed AVP.
2. Compression Algorithm negotiation
The DIAMETER peers that wish to negotiate compression algorithms MUST
exchange the Compression-Negotiate messages. These messages allow the
discovery of the compression algorithms a peer support.
The DIAMETER peer that wishes to use some compression algorithm with
another peer MUST send a Compression-Negotiate-Request (CNR) with the
desired compression algorithm(s) indicated in the Compression-Info
AVP.
The DIAMETER peer that receives the Compression-Negotiate-Request
(CNR) and supporting one or many of the compression algorithms
specified in the request MUST return a Compression-Negotiate-Answer
(CNA) with the Result Code set to DIAMETER_SUCCESS and the supported
compression algorithms indicated in the Compression-Info AVP.
The DIAMETER peer that receives the CNR with the Compression-Info AVP
having one or more Compressed-AVP-Info AVPs and/or one or more
Compression-Arithmetic AVPs MUST return a CNA with DIAMETER_SUCCESS
if it supports at least one of the generic or AVP specific
compression arithmetic. The peer MUST add only one Compression-
Arithmetic AVP to the Compression-Info AVP in the CNA indicating the
selected generic compression algorithm that the peer supports. The
peer MUST add only one Compression-Arithmetic AVP to the Compressed-
AVP-Info AVP in the Compression-Info AVP indicating the selected AVP
specific compression algorithm that the peer supports.
If a DIAMETER peer receives a CNR with non-zero instances of
Compressed-AVP-Info AVP and non-zero instances of Compression-
Arithmetic AVP in the Compression-Info AVP and
- if it supports only one or more of the listed generic compression
arithmetic and not any of the listed AVP specific compression
arithmetic, the peer MUST return a CNA with Result Code as
DIAMETER_SUCCESS and the Compression-Info AVP having one instance of
the Compression-Arithmetic AVP indicating the chosen generic
compression arithmetic and zero instances of Compressed-AVP-Info AVP.
- if it supports only one or more of the listed AVP specific
compression arithmetic and not any of the listed generic compression
Zhangtao et al. Expires - February 2006 [Page 3]
Internet-Draft Diameter Compression August 2005
arithmetic, the peer MUST return a CNA with Result Code as
DIAMETER_SUCCESS and the Compression-Info AVP having one or many
instances of the Compressed-AVP-Info AVP indicating the chosen AVP
specific compression arithmetic and zero instances of the
Compression-Arithmetic AVP. However, each Compressed-AVP-Info AVP
MUST have only one instance of Compression-Arithmetic AVP.
The DIAMETER peer that receives the Compression-Negotiate-Request
(CNR) and supporting no compression algorithms specified in the
request MUST return a Compression-Negotiate-Answer (CNA) with the
Result Code set to DIAMETER_NO_COMMON_COMPRESSION.
The CNR and CNA messages MAY be proxied, redirected or relayed.
2.1 Compression-Negotiate-Request
The Compression-Negotiate-Request (CNR), indicated by the command
code XXX (to be defined by IANA) and the æRÆ and æPÆ bits set in the
command flag, is sent to negotiate the compression algorithms.
Message Format
<CNR> ::= < Diameter Header: XXX, REQ, PXY >
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ Auth-Application-Id }
{ Compression-Info }
* [ Proxy-Info ]
* [ Route-Record ]
2.2 Compression-Negotiate-Answer
The Compression-Negotiate-Answer (CNA), indicated by the command code
XXX (to be defined by IANA), the æRÆ bit cleared and the æPÆ bit set
in the command flag, is sent in response to a CNR message.
Message Format
<CNA> ::= < Diameter Header: XXX, PXY >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Application-Id }
[ Compression-Info ]
[ Error-Message ]
[ Error-Reporting-Host ]
Zhangtao et al. Expires - February 2006 [Page 4]
Internet-Draft Diameter Compression August 2005
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Failed-AVP ]
* [ Proxy-Info ]
2.3 Compression-Info AVP
The Compression-Info AVP (AVP code XXX to be assigned by IANA) is of
type Grouped and is used to advertise support of compression
algorithms.
The CNR message and the CNA message with Result Code as
DIAMETER_SUCCESS MUST contain exactly one instance of this AVP.
The CNA message with a non-successful Result Code MUST not contain
any instance of this AVP (except the case where this AVP is added to
the Failed-AVP AVP).
The Compression-Info AVP MUST have at least one instance of either
Compressed-AVP-Info AVP or Compression-Arithmetic AVP.
If a peer desires to use a specific compression algorithm for an AVP,
a Compressed-AVP-Info AVP corresponding to this AVP MUST be added to
the Compression-Info AVP in the CNR. For example, a Compressed-AVP-
Info AVP corresponding to a User Profile (XML) containing AVP which
uses the WBXML compression algorithm and another Compressed-AVP-Info
AVP corresponding to an SDP information (SDP) containing AVP which
uses an SDP compression algorithm MAY be both present in a
Compression-Info AVP in the CNR.
The Compression-Arithmetic AVP(s) added to the Compression-Info AVP
indicate the generic compression algorithm(s) used to compress AVPs
which are not specified using the Compressed-AVP-Info AVP.
A CNR MAY list many generic Compression-Arithmetic AVPs in a
Compression-Info AVP. A CNR MUST list the generic Compression-
Arithmetic AVPs in a Compression-Info AVP in the order of preference;
i.e. AVP indicating the most preferred arithmetic closest to the
Compression-Info AVP header.
A peer receiving a CNR with a list of generic Compression-Arithmetic
AVPs in the Compression-Info AVP and supporting one or more of the
compression arithmetic listed MUST choose only one generic
compression arithmetic. If the peer supports more than one of the
listed compression arithmetic, it MUST choose supported compression
arithmetic in the order or preference specified by the Compression-
Info AVP in the CNR i.e. the Compression-Arithmetic AVP nearer to the
Compression-Info AVP header MUST be chosen. The peer MUST add only
Zhangtao et al. Expires - February 2006 [Page 5]
Internet-Draft Diameter Compression August 2005
one generic Compression-Arithmetic AVP (containing the chosen generic
compression arithmetic) to the Compression-Info AVP in the CNA.
AVP Format
<Compression-Info> ::= < AVP Header: XXX >
* [ Compressed-AVP-Info ]
* [ Compression-Arithmetic ]
2.4 Compressed-AVP-Info AVP
The Compressed-AVP-Info AVP (AVP code XXX to be assigned by IANA) is
of type Grouped and is used to advertise support of AVP specific
compression algorithms. The Vendor Id and the value of the AVP-Info
AVP identify the AVP which supports the specified compression
arithmetic(s).
A CNR MAY list many Compression-Arithmetic AVPs in a Compressed-AVP-
Info AVP. A CNR MUST list the Compression-Arithmetic AVPs in a
Compressed-AVP-Info AVP in the order of preference; i.e. AVP
indicating the most preferred arithmetic closest to the Compressed-
AVP-Info AVP header.
A peer receiving a CNR with a list of Compression-Arithmetic AVPs in
the Compressed-AVP-Info AVP added to the Compression-Info AVP and
supporting one or more of the compression arithmetic listed MUST
choose only one compression arithmetic. If the peer supports more
than one of the listed compression arithmetic, it MUST choose the
compression arithmetic in the order or preference specified by the
Compressed-AVP-Info AVP in the CNR i.e. the Compression-Arithmetic
AVP nearer to the Compressed-AVP-Info AVP header MUST be chosen. The
peer MUST add only one Compression-Arithmetic AVP (containing the
chosen compression arithmetic) to the Compressed-AVP-Info AVP added
to the Compression-Info AVP in the CNA. However a peer MAY add more
than one Compressed-AVP-Info AVP to the Compression-Info AVP in the
CNA.
AVP Format
<Compressed-AVP-Info> ::= < AVP Header: XXX >
{ AVP-Info }
[Vendor-Id]
* { Compression-Arithmetic }
2.5 Compression-Arithmetic AVP
The Compression-Arithmetic AVP (AVP code XXX to be assigned by IANA)
is of type Enumerated and is used to indicate the compression
algorithm.
Zhangtao et al. Expires - February 2006 [Page 6]
Internet-Draft Diameter Compression August 2005
Currently the following values are supported, but there is ample room
to support more values.
WBXML 0
WAP Binary XML format is used to compact the parsed physical
XML format.
2.6 AVP-Info AVP
The AVP-Info AVP (AVP code XXX to be assigned by IANA) is of type
Unsigned32 and has the AVP code of the AVP which supports the
specified compression arithmetic(s). The AVP code MAY belong to the
IANA IETF namespace or the vendor specific namespace [BASE].
2.7 Application Id
Diameter nodes conforming to this specification MAY advertise support
by including the value of XXX (to be assigned by IANA) in the Auth-
Application-Id of the Capabilities-Exchange-Request and Capabilities-
Exchange-Answer command [BASE].
2.8 Result Codes
This section defines a new Result-Code [BASE] value that MUST be
supported by all Diameter implementations that conform to this
specification.
DIAMETER_NO_COMMON_COMPRESSION 5XXX (to be assigned by
IANA)
This error code is returned when the DIAMETER peer that received a
CNR supports no compression algorithm indicated in the request.
2.9 AVP occurrence table
The table in this section presents the AVPs defined in this document,
and specifies in which Diameter messages they MAY, or MAY NOT be
present. Note that AVPs that can only be present within a Grouped
AVP are not represented in this table.
The table uses the following symbols:
0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the
message.
0-1 Zero or one instance of the AVP MAY be present in the
message.
1 One instance of the AVP MUST be present in the message.
1+ At least one instance of the AVP MUST be present in the
message.
Zhangtao et al. Expires - February 2006 [Page 7]
Internet-Draft Diameter Compression August 2005
+------------+
|Command-Code|
|-----+-----+
Attribute Name | CNR | CNA |
------------------------------|-----+-----+
Auth-Application-Id | 1 | 1 |
Compression-Info | 1 | 0-1 |
Destination-Host | 0-1 | 0 |
Destination-Realm | 1 | 0 |
Error-Message | 0 | 0-1 |
Error-Reporting-Host | 0 | 0-1 |
Failed-AVP | 0 | 0+ |
Origin-Host | 1 | 1 |
Origin-Realm | 1 | 1 |
Proxy-Info | 0+ | 0+ |
Redirect-Host | 0 | 0+ |
Redirect-Host-Usage | 0 | 0-1 |
Redirect-Max-Cache-Time | 0 | 0-1 |
Result-Code | 0 | 1 |
Route-Record | 0+ | 0 |
------------------------------|-----+-----+
3. Compression Indication û The 'C' AVP Flag
This specification introduces a new AVP flag, the 'C' bit indicating
compression. If the 'C' bit is set, it indicates that the AVP data is
compressed.
The new format of the AVP header with the introduction of the 'C' bit
is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M P C r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
A diameter peer receiving a DIAMETER request with an (/some) AVP(s)
with 'C' bit in the AVP header set MUST use the (de)compression
algorithm negotiated with the request originating peer. The peer will
Zhangtao et al. Expires - February 2006 [Page 8]
Internet-Draft Diameter Compression August 2005
first check if any AVP specific compression algorithm was negotiated
and if so, MUST use the same. If not, the peer MUST use the generic
compression algorithm negotiated.
A DIAMETER peer receiving a DIAMETER request with an (/some) AVP(s)
having the 'C' bit set MUST send a response with Result Code as
DIAMETER_INVALID_AVP_BITS (3009) if it does not support compression
or if no compression algorithm has been successfully negotiated with
the request originating peer.
4. IANA Considerations
4.1 Command Codes
IANA is to assign a new Command Code for the Compression-Negotiation
messages.
4.2 AVP Codes
IANA is to assign new AVP codes for the following new AVPs specified
by this document:
- Compression-Info
- Compressed-AVP-Info
- Compression-Arithmetic
- AVP-Info
4.3 Result Code AVP values
IANA is to assign a new result code [BASE] corresponding to the
permanent failure DIAMETER_NO_COMMON_COMPRESSION.
4.4 Application Id
IANA is to assign a new application id for the Compression
Negotiation application. This application id will be used in the
command header and Auth-Application-Id AVP fields of the Compression-
Negotiation messages.
5. Security Considerations
This document does not contain a security protocol; it describes an
addition to the existing Diameter protocol. All security issues of
DIAMETER protocol must be considered in implementing this
specification. This extension does not add any unique concerns.
Zhangtao et al. Expires - February 2006 [Page 9]
Internet-Draft Diameter Compression August 2005
6. References
6.1 Normative References
i Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
ii Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[BASE]
P. Calhoun, et.al, "Diameter Base Protocol", RFC 3588,
Sept 2003.
Acknowledgments
None
Author's Addresses
Zhangtao
Huawei Technologies
Bangalore, India
Email: zhangtao_hw@huawei.com
Rajith R
Huawei Technologies
Bangalore, India
Email: rajithr@huawei.com
Zhangtao et al. Expires - February 2006 [Page 10]
Internet-Draft Diameter Compression August 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhangtao et al. Expires - February 2006 [Page 11]
