doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc5624.txt b/doc/rfc/rfc5624.txt
new file mode 100644
index 0000000..d4a42e1
--- /dev/null
+++ b/doc/rfc/rfc5624.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                   J. Korhonen, Ed.
+Request for Comments: 5624                                 H. Tschofenig
+Category: Standards Track                         Nokia Siemens Networks
+                                                               E. Davies
+                                                        Folly Consulting
+                                                             August 2009
+
+
+         Quality of Service Parameters for Usage with Diameter
+
+Abstract
+
+   This document defines a number of Quality of Service (QoS) parameters
+   that can be reused for conveying QoS information within Diameter.
+
+   The defined QoS information includes data traffic parameters for
+   describing a token bucket filter, a bandwidth parameter, and a per-
+   hop behavior class object.
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korhonen, et al.            Standards Track                     [Page 1]
+
+RFC 5624                     QoS Parameters                  August 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Terminology and Abbreviations  . . . . . . . . . . . . . . . .  3
+   3.  QoS Parameter Encoding . . . . . . . . . . . . . . . . . . . .  4
+     3.1.  TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . .  4
+       3.1.1.  Token-Rate AVP . . . . . . . . . . . . . . . . . . . .  4
+       3.1.2.  Bucket-Depth AVP . . . . . . . . . . . . . . . . . . .  4
+       3.1.3.  Peak-Traffic-Rate AVP  . . . . . . . . . . . . . . . .  4
+       3.1.4.  Minimum-Policed-Unit AVP . . . . . . . . . . . . . . .  4
+       3.1.5.  Maximum-Packet-Size AVP  . . . . . . . . . . . . . . .  4
+     3.2.  TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.3.  Bandwidth AVP  . . . . . . . . . . . . . . . . . . . . . .  5
+     3.4.  PHB-Class AVP  . . . . . . . . . . . . . . . . . . . . . .  5
+       3.4.1.  Case 1: Single PHB . . . . . . . . . . . . . . . . . .  5
+       3.4.2.  Case 2: Set of PHBs  . . . . . . . . . . . . . . . . .  5
+       3.4.3.  Case 3: Experimental or Local Use PHBs . . . . . . . .  6
+   4.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . .  6
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
+     8.2.  Informative References . . . . . . . . . . . . . . . . . .  9
+   Appendix A.  ABNF Code Fragment  . . . . . . . . . . . . . . . . . 11
+
+1.  Introduction
+
+   This document defines a number of Quality of Service (QoS) parameters
+   that can be reused for conveying QoS information within the Diameter
+   protocol [RFC3588].  The current set of QoS parameters defined in
+   this document are a core subset determined to be useful for a wide
+   range of applications.  Additional parameters may be defined in
+   future documents as the need arises and are for future study.  The
+   parameters are defined as Diameter-encoded Attribute Value Pairs
+   (AVPs), which are described using a modified version of the Augmented
+   Backus-Naur Form (ABNF), see [RFC3588].  The data types are also
+   taken from [RFC3588].
+
+   The traffic model (TMOD) AVPs are containers consisting of four AVPs
+   and provide a way to describe the traffic source.
+
+   o  token rate (r)
+
+   o  bucket depth (b)
+
+   o  peak traffic rate (p)
+
+
+
+
+Korhonen, et al.            Standards Track                     [Page 2]
+
+RFC 5624                     QoS Parameters                  August 2009
+
+
+   o  minimum policed unit (m)
+
+   o  maximum packet size (M)
+
+   The encoding of the <TMOD-1> and the <TMOD-2> AVPs can be found in
+   Sections 3.1 and 3.2.  The semantics of these two AVPs are described
+   in Section 3.1 of [RFC2210] and in Section 3.6 of [RFC2215].
+
+   The <TMOD-2> AVP is, for example, needed by some DiffServ
+   applications.
+
+      It is typically assumed that DiffServ expedited forwarding (EF)
+      traffic is shaped at the ingress by a single-rate token bucket.
+      Therefore, a single TMOD parameter is sufficient to signal
+      DiffServ EF traffic.  However, for DiffServ assured forwarding
+      (AF) traffic, two sets of token bucket parameters are needed: one
+      token bucket for the average traffic and one token bucket for the
+      burst traffic.  [RFC2697] defines a Single Rate Three Color Marker
+      (srTCM), which meters a traffic stream and marks its packets
+      according to three traffic parameters -- Committed Information
+      Rate (CIR), Committed Burst Size (CBS), and Excess Burst Size
+      (EBS) -- to be either green, yellow, or red.  A packet is marked
+      green if it does not exceed the CBS, yellow if it does exceed the
+      CBS but not the EBS, and red otherwise.  [RFC2697] defines
+      specific procedures using two token buckets that run at the same
+      rate.  Therefore, two TMOD AVPs are sufficient to distinguish
+      among three levels of drop precedence.  An example is also
+      described in the appendix of [RFC2597].
+
+   Resource reservations might refer to a packet processor with a
+   particular DiffServ per-hop behavior (PHB) (using the <PHB-Class>
+   AVP).  A generic description of the DiffServ architecture can be
+   found in [RFC2475], and the Differentiated Services Field is
+   described in Section 3 of [RFC2474].  Updated terminology can be
+   found in [RFC3260].  Standardized per-hop behavior is, for example,
+   described in [RFC2597] ("Assured Forwarding PHB Group") and in
+   [RFC3246] ("An Expedited Forwarding PHB").
+
+   The above-mentioned parameters are intended to support basic
+   integrated and differentiated services functionality in the network.
+   Additional parameters can be defined and standardized if required to
+   support specific services in the future.
+
+2.  Terminology and Abbreviations
+
+   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 RFC2119 [RFC2119].
+
+
+
+Korhonen, et al.            Standards Track                     [Page 3]
+
+RFC 5624                     QoS Parameters                  August 2009
+
+
+3.  QoS Parameter Encoding
+
+3.1.  TMOD-1 AVP
+
+   The TMOD-1 AVP is obtained from [RFC2210] and [RFC2215].  The
+   structure of the AVP is as follows:
+
+     TMOD-1  ::= < AVP Header: 495 >
+                 { Token-Rate }
+                 { Bucket-Depth }
+                 { Peak-Traffic-Rate }
+                 { Minimum-Policed-Unit }
+                 { Maximum-Packet-Size }
+
+3.1.1.  Token-Rate AVP
+
+   The Token-Rate AVP (AVP Code 496) is of type Float32.
+
+3.1.2.  Bucket-Depth AVP
+
+   The Bucket-Depth AVP (AVP Code 497) is of type Float32.
+
+3.1.3.  Peak-Traffic-Rate AVP
+
+   The Peak-Traffic-Rate AVP (AVP Code 498) is of type Float32.
+
+3.1.4.  Minimum-Policed-Unit AVP
+
+   The Minimum-Policed-Unit AVP (AVP Code 499) is of type Unsigned32.
+
+3.1.5.  Maximum-Packet-Size AVP
+
+   The Maximum-Packet-Size AVP (AVP Code 500) is of type Unsigned32.
+
+3.2.  TMOD-2 AVP
+
+   A description of the semantics of the parameter values can be found
+   in [RFC2215].  The coding for the TMOD-2 AVP is as follows:
+
+     TMOD-2  ::= < AVP Header: 501 >
+                 { Token-Rate }
+                 { Bucket-Depth }
+                 { Peak-Traffic-Rate }
+                 { Minimum-Policed-Unit }
+                 { Maximum-Packet-Size }
+
+
+
+
+
+
+Korhonen, et al.            Standards Track                     [Page 4]
+
+RFC 5624                     QoS Parameters                  August 2009
+
+
+3.3.  Bandwidth AVP
+
+   The Bandwidth AVP (AVP Code 502) is of type Float32 and is measured
+   in octets of IP datagrams per second.  The Bandwidth AVP represents a
+   simplified description of the following TMOD setting whereby the
+   token rate (r) = peak traffic rate (p), the bucket depth (b) = large,
+   and the minimum policed unit (m) = large when only bandwidth has to
+   be expressed.
+
+3.4.  PHB-Class AVP
+
+   The PHB-Class AVP (AVP Code 503) is of type Unsigned32.
+
+   A description of the semantics of the parameter values can be found
+   in [RFC3140].  The registries needed for usage with [RFC3140] already
+   exist and hence a new registry is not required for this purpose.  The
+   encoding requires that three cases be differentiated.  All bits
+   indicated as "reserved" MUST be set to zero (0).
+
+3.4.1.  Case 1: Single PHB
+
+   As prescribed in [RFC3140], the encoding for a single PHB is the
+   recommended Differentiated Services Code Point (DSCP) value for that
+   PHB, left-justified in the 16-bit field with bits 6 through 15 set to
+   zero.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | DSCP      |0 0 0 0 0 0 0 0 0 0|            (Reserved)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.4.2.  Case 2: Set of PHBs
+
+   The encoding for a set of PHBs is the numerically smallest of the set
+   of encodings for the various PHBs in the set, with bit 14 set to 1.
+   (Thus, for the AF1x PHBs, the encoding is that of the AF11 PHB, with
+   bit 14 set to 1.)
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | DSCP      |0 0 0 0 0 0 0 0 1 0|            (Reserved)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Korhonen, et al.            Standards Track                     [Page 5]
+
+RFC 5624                     QoS Parameters                  August 2009
+
+
+3.4.3.  Case 3: Experimental or Local Use PHBs
+
+   PHBs may not be defined by standards actions i.e., experimental or
+   local use PHBs as allowed by [RFC2474].  In this case, an arbitrary
+   12-bit PHB identification code, assigned by the IANA, is left-
+   justified in the 16-bit field.  Bit 15 is set to 1, and bit 14 is
+   zero for a single PHB or 1 for a set of PHBs.  Bits 12 and 13 are
+   zero.
+
+   Bits 12 and 13 are reserved either for expansion of the PHB
+   identification code or for other, future use.
+
+   In both cases, when a single PHBID is used to identify a set of PHBs
+   (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB
+   Scheduling Class (i.e., use of PHBs from the set MUST NOT cause
+   intra-microflow traffic reordering when different PHBs from the set
+   are applied to traffic in the same microflow).  The set of AF1x PHBs
+   [RFC2597] is an example of a PHB Scheduling Class.  Sets of PHBs that
+   do not constitute a PHB Scheduling Class can be identified by using
+   more than one PHBID.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      PHD ID CODE      |0 0 1 0|            (Reserved)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.  Extensibility
+
+   This document is designed with extensibility in mind, given that
+   different organizations and groups are used to defining their own
+   Quality of Service parameters.  This document provides an initial QoS
+   profile with a common set of parameters.  Ideally, these parameters
+   should be used whenever possible, but there are cases where
+   additional parameters might be needed or where the parameters
+   specified in this document are used with different semantics.  In
+   that case, it is advisable to define a new QoS profile that may
+   consist of new parameters in addition to parameters defined in this
+   document or an entirely different set of parameters.  Finally, it is
+   also possible to register a specific QoS profile that defines a
+   specific set of QoS values rather than parameters that need to be
+   filled with values in order to be used.
+
+   To enable the definition of new QoS profiles, an 8-octet registry is
+   defined as a field that is represented by 4-octet vendor and 4-octet
+   specifier fields.  The vendor field contains an Enterprise Number as
+   defined in [RFC2578], taken from the values maintained in the IANA
+   Enterprise Numbers registry.  If the four octets of the vendor field
+
+
+
+Korhonen, et al.            Standards Track                     [Page 6]
+
+RFC 5624                     QoS Parameters                  August 2009
+
+
+   are 0x00000000 (reserved value for IANA), then the value in the
+   specifier field MUST be registered with IANA (see Section 5.2).  If
+   the vendor field is other than 0x00000000, the value of the specifier
+   field represents a vendor-specific value, where allocation is the
+   responsibility of the enterprise indicated in the vendor field.
+
+5.  IANA Considerations
+
+5.1.  AVP Codes
+
+   IANA allocated AVP codes in the IANA-controlled namespace registry
+   specified in Section 11.1.1 of [RFC3588] for the following AVPs that
+   are defined in this document.
+
+   +------------------------------------------------------------------+
+   |                                       AVP  Section               |
+   |AVP Name                               Code Defined   Data Type   |
+   +------------------------------------------------------------------+
+   |TMOD-1                                 495  3.1       Grouped     |
+   |Token-Rate                             496  3.1.1     Float32     |
+   |Bucket-Depth                           497  3.1.2     Float32     |
+   |Peak-Traffic-Rate                      498  3.1.3     Float32     |
+   |Minimum-Policed-Unit                   499  3.1.4     Unsigned32  |
+   |Maximum-Packet-Size                    500  3.1.5     Unsigned32  |
+   |TMOD-2                                 501  3.2       Grouped     |
+   |Bandwidth                              502  3.3       Float32     |
+   |PHB-Class                              503  3.4       Unsigned32  |
+   +------------------------------------------------------------------+
+
+5.2.  QoS Profile
+
+   The QoS profile refers to a 64-bit field that is represented by
+   4-octet vendor and 4-octet specifier fields.  The vendor field
+   indicates the type as either standards-specified or vendor-specific.
+
+   If the four octets of the vendor field are 0x00000000, then the value
+   is standards-specified and a registry will be created to maintain the
+   QoS profile specifier values.  The specifier field indicates the
+   actual QoS profile.  Depending on the value requested, the action
+   needed to request a new value is:
+
+      0 to 511: Standards Action
+
+      512 to 32767: Specification Required
+
+      32768 to 4294967295: Reserved
+
+
+
+
+
+Korhonen, et al.            Standards Track                     [Page 7]
+
+RFC 5624                     QoS Parameters                  August 2009
+
+
+   Standards action is required to add, depreciate, delete, or modify
+   QoS profile values in the range of 0-511, and a specification is
+   required to add, depreciate, delete, or modify existing QoS profile
+   values in the range of 512-32767.
+
+   IANA created such a registry and allocated the value zero (0) for the
+   QoS profile defined in this document.
+
+   Alternative vendor-specific QoS profiles can be created and
+   identified with an Enterprise Number taken from the IANA registry
+   created by [RFC2578] in the vendor field, combined with a vendor-
+   specific value in the specifier field.  Allocation of the specifier
+   values is the responsibility of the vendor.
+
+6.  Security Considerations
+
+   This document does not raise any security concerns as it only defines
+   QoS parameters and does not yet describe how they are exchanged in an
+   Authentication, Authorization, and Accounting (AAA) protocol.
+   Security considerations are described in documents using this
+   specification.
+
+7.  Acknowledgements
+
+   The authors would like to thank the NSIS working group members
+   Cornelia Kappler, Jerry Ash, Attila Bader, and Dave Oran; the former
+   NSIS working group chairs John Loughney and Martin Stiemerling; and
+   the former Transport Area Directors Allison Mankin and Jon Peterson
+   for their help.
+
+   We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt,
+   Francois Le Faucheur, John Loughney, An Nguyen, Dave Oran, James
+   Polk, Martin Dolly, Martin Stiemerling, and Magnus Westerlund for
+   their feedback regarding some of the parameters in this documents.
+
+   Jerry Ash, Al Morton, Mayutan Arumaithurai, and Xiaoming Fu provided
+   help with the semantics of some QSPEC parameters.
+
+   We would like to thank Dan Romascanu for his detailed Area Director
+   review comments and Scott Bradner for his Transport Area Directorate
+   review.  Chris Newman, Adrian Farrel, and Pasi Eronen provided
+   feedback during the IESG review.
+
+
+
+
+
+
+
+
+
+Korhonen, et al.            Standards Track                     [Page 8]
+
+RFC 5624                     QoS Parameters                  August 2009
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2210]  Wroclawski, J., "The Use of RSVP with IETF Integrated
+              Services", RFC 2210, September 1997.
+
+   [RFC2215]  Shenker, S. and J. Wroclawski, "General Characterization
+              Parameters for Integrated Service Network Elements",
+              RFC 2215, September 1997.
+
+   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
+              "Definition of the Differentiated Services Field (DS
+              Field) in the IPv4 and IPv6 Headers", RFC 2474,
+              December 1998.
+
+   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
+              Schoenwaelder, Ed., "Structure of Management Information
+              Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
+
+   [RFC3140]  Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
+              "Per Hop Behavior Identification Codes", RFC 3140,
+              June 2001.
+
+   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
+              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
+
+8.2.  Informative References
+
+   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
+              and W. Weiss, "An Architecture for Differentiated
+              Services", RFC 2475, December 1998.
+
+   [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
+              "Assured Forwarding PHB Group", RFC 2597, June 1999.
+
+   [RFC2697]  Heinanen, J. and R. Guerin, "A Single Rate Three Color
+              Marker", RFC 2697, September 1999.
+
+   [RFC3246]  Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
+              J., Courtney, W., Davari, S., Firoiu, V., and D.
+              Stiliadis, "An Expedited Forwarding PHB (Per-Hop
+              Behavior)", RFC 3246, March 2002.
+
+
+
+
+
+Korhonen, et al.            Standards Track                     [Page 9]
+
+RFC 5624                     QoS Parameters                  August 2009
+
+
+   [RFC3260]  Grossman, D., "New Terminology and Clarifications for
+              Diffserv", RFC 3260, April 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korhonen, et al.            Standards Track                    [Page 10]
+
+RFC 5624                     QoS Parameters                  August 2009
+
+
+Appendix A.  ABNF Code Fragment
+
+   Copyright (c) 2009 IETF Trust and the persons identified as authors
+   of the code.  All rights reserved.
+
+   Redistribution and use in source and binary forms, with or without
+   modification, are permitted provided that the following conditions
+   are met:
+
+   o  Redistributions of source code must retain the above copyright
+      notice, this list of conditions and the following disclaimer.
+
+   o  Redistributions in binary form must reproduce the above copyright
+      notice, this list of conditions and the following disclaimer in
+      the documentation and/or other materials provided with the
+      distribution.
+
+   o  Neither the name of Internet Society, IETF or IETF Trust, nor the
+      names of specific contributors, may be used to endorse or promote
+      products derived from this software without specific prior written
+      permission.
+
+   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+   'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+   A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT
+   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+     TMOD-1  ::= < AVP Header: 495 >
+                 { Token-Rate }
+                 { Bucket-Depth }
+                 { Peak-Traffic-Rate }
+                 { Minimum-Policed-Unit }
+                 { Maximum-Packet-Size }
+
+
+     TMOD-2  ::= < AVP Header: 501 >
+                 { Token-Rate }
+                 { Bucket-Depth }
+                 { Peak-Traffic-Rate }
+                 { Minimum-Policed-Unit }
+                 { Maximum-Packet-Size }
+
+
+
+Korhonen, et al.            Standards Track                    [Page 11]
+
+RFC 5624                     QoS Parameters                  August 2009
+
+
+Authors' Addresses
+
+   Jouni Korhonen (editor)
+   Nokia Siemens Networks
+   Linnoitustie 6
+   Espoo  02600
+   Finland
+
+   EMail: jouni.korhonen@nsn.com
+
+
+   Hannes Tschofenig
+   Nokia Siemens Networks
+   Linnoitustie 6
+   Espoo  02600
+   Finland
+
+   Phone: +358 (50) 4871445
+   EMail: Hannes.Tschofenig@gmx.net
+   URI:   http://www.tschofenig.priv.at
+
+
+   Elwyn Davies
+   Folly Consulting
+   Soham
+   UK
+
+   Phone: +44 7889 488 335
+   EMail: elwynd@dial.pipex.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korhonen, et al.            Standards Track                    [Page 12]
+