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 ::= < 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 ::= < 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 ::= < 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 ::= < 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]