doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc7501.txt b/doc/rfc/rfc7501.txt
new file mode 100644
index 0000000..411f9f2
--- /dev/null
+++ b/doc/rfc/rfc7501.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         C. Davids
+Request for Comments: 7501              Illinois Institute of Technology
+Category: Informational                                       V. Gurbani
+ISSN: 2070-1721                        Bell Laboratories, Alcatel-Lucent
+                                                             S. Poretsky
+                                                    Allot Communications
+                                                              April 2015
+
+
+Terminology for Benchmarking Session Initiation Protocol (SIP) Devices:
+                  Basic Session Setup and Registration
+
+Abstract
+
+   This document provides a terminology for benchmarking the Session
+   Initiation Protocol (SIP) performance of devices.  Methodology
+   related to benchmarking SIP devices is described in the companion
+   methodology document (RFC 7502).  Using these two documents,
+   benchmarks can be obtained and compared for different types of
+   devices such as SIP Proxy Servers, Registrars, and Session Border
+   Controllers.  The term "performance" in this context means the
+   capacity of the Device Under Test (DUT) to process SIP messages.
+   Media streams are used only to study how they impact the signaling
+   behavior.  The intent of the two documents is to provide a normalized
+   set of tests that will enable an objective comparison of the capacity
+   of SIP devices.  Test setup parameters and a methodology are
+   necessary because SIP allows a wide range of configurations and
+   operational conditions that can influence performance benchmark
+   measurements.  A standard terminology and methodology will ensure
+   that benchmarks have consistent definitions and were obtained
+   following the same procedures.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7501.
+
+
+
+
+Davids, et al.                Informational                     [Page 1]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 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
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davids, et al.                Informational                     [Page 2]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   5
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
+   3.  Term Definitions  . . . . . . . . . . . . . . . . . . . . . .   7
+     3.1.  Protocol Components . . . . . . . . . . . . . . . . . . .   7
+       3.1.1.  Session . . . . . . . . . . . . . . . . . . . . . . .   7
+       3.1.2.  Signaling Plane . . . . . . . . . . . . . . . . . . .   8
+       3.1.3.  Media Plane . . . . . . . . . . . . . . . . . . . . .   8
+       3.1.4.  Associated Media  . . . . . . . . . . . . . . . . . .   9
+       3.1.5.  Overload  . . . . . . . . . . . . . . . . . . . . . .   9
+       3.1.6.  Session Attempt . . . . . . . . . . . . . . . . . . .  10
+       3.1.7.  Established Session . . . . . . . . . . . . . . . . .  10
+       3.1.8.  Session Attempt Failure . . . . . . . . . . . . . . .  11
+     3.2.  Test Components . . . . . . . . . . . . . . . . . . . . .  11
+       3.2.1.  Emulated Agent  . . . . . . . . . . . . . . . . . . .  11
+       3.2.2.  Signaling Server  . . . . . . . . . . . . . . . . . .  12
+       3.2.3.  SIP Transport Protocol  . . . . . . . . . . . . . . .  12
+     3.3.  Test Setup Parameters . . . . . . . . . . . . . . . . . .  13
+       3.3.1.  Session Attempt Rate  . . . . . . . . . . . . . . . .  13
+       3.3.2.  Establishment Threshold Time  . . . . . . . . . . . .  13
+       3.3.3.  Session Duration  . . . . . . . . . . . . . . . . . .  14
+       3.3.4.  Media Packet Size . . . . . . . . . . . . . . . . . .  14
+       3.3.5.  Codec Type  . . . . . . . . . . . . . . . . . . . . .  15
+     3.4.  Benchmarks  . . . . . . . . . . . . . . . . . . . . . . .  15
+       3.4.1.  Session Establishment Rate  . . . . . . . . . . . . .  15
+       3.4.2.  Registration Rate . . . . . . . . . . . . . . . . . .  16
+       3.4.3.  Registration Attempt Rate . . . . . . . . . . . . . .  17
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
+   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
+     5.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
+     5.2.  Informative References  . . . . . . . . . . . . . . . . .  18
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  19
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20
+
+1.  Introduction
+
+   Service Providers and IT organizations deliver Voice Over IP (VoIP)
+   and multimedia network services based on the IETF Session Initiation
+   Protocol (SIP) [RFC3261].  SIP is a signaling protocol originally
+   intended to be used to dynamically establish, disconnect, and modify
+   streams of media between end users.  As it has evolved, it has been
+   adopted for use in a growing number of services and applications.
+   Many of these result in the creation of a media session, but some do
+   not.  Examples of this latter group include text messaging and
+   subscription services.  The set of benchmarking terms provided in
+   this document is intended for use with any SIP-enabled device
+
+
+
+Davids, et al.                Informational                     [Page 3]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+   performing SIP functions in the interior of the network, whether or
+   not these result in the creation of media sessions.  The performance
+   of end-user devices is outside the scope of this document.
+
+   A number of networking devices have been developed to support SIP-
+   based VoIP services.  These include SIP servers, Session Border
+   Controllers (SBCs), and Back-to-back User Agents (B2BUAs).  These
+   devices contain a mix of voice and IP functions whose performance may
+   be reported using metrics defined by the equipment manufacturer or
+   vendor.  The Service Provider or IT organization seeking to compare
+   the performance of such devices will not be able to do so using these
+   vendor-specific metrics, whose conditions of test and algorithms for
+   collection are often unspecified.
+
+   SIP functional elements and the devices that include them can be
+   configured many different ways and can be organized into various
+   topologies.  These configuration and topological choices impact the
+   value of any chosen signaling benchmark.  Unless these conditions of
+   test are defined, a true comparison of performance metrics across
+   multiple vendor implementations will not be possible.
+
+   Some SIP-enabled devices terminate or relay media as well as
+   signaling.  The processing of media by the device impacts the
+   signaling performance.  As a result, the conditions of test must
+   include information as to whether or not the Device Under Test
+   processes media.  If the device processes media during the test, a
+   description of the media must be provided.  This document and its
+   companion methodology document [RFC7502] provide a set of black-box
+   benchmarks for describing and comparing the performance of devices
+   that incorporate the SIP User Agent Client and Server functions and
+   that operate in the network's core.
+
+   The definition of SIP performance benchmarks necessarily includes
+   definitions of Test Setup Parameters and a test methodology.  These
+   enable the Tester to perform benchmarking tests on different devices
+   and to achieve comparable results.  This document provides a common
+   set of definitions for Test Components, Test Setup Parameters, and
+   Benchmarks.  All the benchmarks defined are black-box measurements of
+   the SIP signaling plane.  The Test Setup Parameters and Benchmarks
+   defined in this document are intended for use with the companion
+   methodology document.
+
+
+
+
+
+
+
+
+
+
+Davids, et al.                Informational                     [Page 4]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+1.1.  Scope
+
+   The scope of this document is summarized as follows:
+
+   o  This terminology document describes SIP signaling performance
+      benchmarks for black-box measurements of SIP networking devices.
+      Stress conditions and debugging scenarios are not addressed in
+      this document.
+
+   o  The DUT must be network equipment that is RFC 3261 capable.  This
+      may be a Registrar, Redirect Server, or Stateful Proxy.  This
+      document does not require the intermediary to assume the role of a
+      stateless proxy.  A DUT may also act as a B2BUA or take the role
+      of an SBC.
+
+   o  The Tester acts as multiple Emulated Agents (EAs) that initiate
+      (or respond to) SIP messages as session endpoints and source (or
+      receive) associated media for established connections.
+
+   o  Regarding SIP signaling in presence of media:
+
+      *  The media performance is not benchmarked.
+
+      *  Some tests require media, but the use of media is limited to
+         observing the performance of SIP signaling.  Tests that require
+         media will annotate the media characteristics as a condition of
+         test.
+
+      *  The type of DUT dictates whether the associated media streams
+         traverse the DUT.  Both scenarios are within the scope of this
+         document.
+
+      *  SIP is frequently used to create media streams; the signaling
+         plane and media plane are treated as orthogonal to each other
+         in this document.  While many devices support the creation of
+         media streams, benchmarks that measure the performance of these
+         streams are outside the scope of this document and its
+         companion methodology document [RFC7502].  Tests may be
+         performed with or without the creation of media streams.  The
+         presence or absence of media streams MUST be noted as a
+         condition of the test, as the performance of SIP devices may
+         vary accordingly.  Even if the media is used during
+         benchmarking, only the SIP performance will be benchmarked, not
+         the media performance or quality.
+
+   o  Both INVITE and non-INVITE scenarios (registrations) are addressed
+      in this document.  However, benchmarking SIP presence or
+      subscribe-notify extensions is not a part of this document.
+
+
+
+Davids, et al.                Informational                     [Page 5]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+   o  Different transport -- such as UDP, TCP, SCTP, or TLS -- may be
+      used.  The specific transport mechanism MUST be noted as a
+      condition of the test, as the performance of SIP devices may vary
+      accordingly.
+
+   o  REGISTER and INVITE requests may be challenged or remain
+      unchallenged for authentication purposes.  Whether or not the
+      REGISTER and INVITE requests are challenged is a condition of test
+      that will be recorded along with other such parameters that may
+      impact the SIP performance of the device or system under test.
+
+   o  Re-INVITE requests are not considered within the scope of this
+      document since the benchmarks for INVITEs are based on the dialog
+      created by the INVITE and not on the transactions that take place
+      within that dialog.
+
+   o  Only session establishment is considered for the performance
+      benchmarks.  Session disconnect is not considered within the scope
+      of this document.  This is because our goal is to determine the
+      maximum capacity of the device or system under test, that is, the
+      number of simultaneous SIP sessions that the device or system can
+      support.  It is true that there are BYE requests being created
+      during the test process.  These transactions do contribute to the
+      load on the device or system under test and thus are accounted for
+      in the metric we derive.  We do not seek a separate metric for the
+      number of BYE transactions a device or system can support.
+
+   o  Scenarios that are specific to the IP Multimedia Subsystem (IMS)
+      are not considered, but test cases can be applied with 3GPP-
+      specific SIP signaling and the Proxy-Call Session Control Function
+      (P-CSCF) as a DUT.
+
+   o  The benchmarks described in this document are intended for a
+      laboratory environment and are not intended to be used on a
+      production network.  Some of the benchmarks send enough traffic
+      that a denial-of-service attack is possible if used in production
+      networks.
+
+2.  Terminology
+
+   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 BCP 14, RFC2119
+   [RFC2119].  RFC 2119 defines the use of these key words to help make
+   the intent of Standards Track documents as clear as possible.  While
+   this document uses these keywords, this document is not a Standards
+   Track document.
+
+
+
+
+Davids, et al.                Informational                     [Page 6]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+   For the sake of clarity and continuity, this document adopts the
+   template for definitions set out in Section 2 of RFC 1242 [RFC1242].
+
+   The term "Device Under Test (DUT)" is defined in Section 3.1.1 of RFC
+   2285 [RFC2285].
+
+   Many commonly used SIP terms in this document are defined in RFC 3261
+   [RFC3261].  For convenience, the most important of these are
+   reproduced below.  Use of these terms in this document is consistent
+   with their corresponding definition in the base SIP specification
+   [RFC3261] as amended by [RFC4320], [RFC5393], and [RFC6026].
+
+   o  Call Stateful: A proxy is call stateful if it retains state for a
+      dialog from the initiating INVITE to the terminating BYE request.
+      A call stateful proxy is always transaction stateful, but the
+      converse is not necessarily true.
+
+   o  Stateful Proxy: A logical entity, as defined by [RFC3261], that
+      maintains the client and server transaction state machines during
+      the processing of a request.  (Also known as a transaction
+      stateful proxy.)  The behavior of a stateful proxy is further
+      defined in Section 16 of RFC 3261 [RFC3261] .  A transaction
+      stateful proxy is not the same as a call stateful proxy.
+
+   o  Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a
+      logical entity that receives a request and processes it as a user
+      agent server (UAS).  In order to determine how the request should
+      be answered, it acts as a user agent client (UAC) and generates
+      requests.  Unlike a proxy server, it maintains dialog state and
+      must participate in all requests sent on the dialogs it has
+      established.  Since it is a concatenation of a UAC and a UAS, no
+      explicit definitions are needed for its behavior.
+
+3.  Term Definitions
+
+3.1.  Protocol Components
+
+3.1.1.  Session
+
+   Definition:
+      The combination of signaling and media messages and associated
+      processing that enable a single SIP-based audio or video call, or
+      SIP registration.
+
+   Discussion:
+      The term "session" commonly implies a media session.  In this
+      document the term is extended to cover the signaling and any media
+      specified and invoked by the corresponding signaling.
+
+
+
+Davids, et al.                Informational                     [Page 7]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+   Measurement Units:
+      N/A.
+
+   Issues:
+      None.
+
+   See Also:
+      Media Plane
+      Signaling Plane
+      Associated Media
+
+3.1.2.  Signaling Plane
+
+   Definition:
+      The plane in which SIP messages [RFC3261] are exchanged between
+      SIP agents [RFC3261].
+
+   Discussion:
+      SIP messages are used to establish sessions in several ways:
+      directly between two User Agents [RFC3261], through a Proxy Server
+      [RFC3261], or through a series of Proxy Servers.  The Session
+      Description Protocol (SDP) is included in the Signaling Plane.
+
+   Measurement Units:
+      N/A.
+
+   Issues:
+      None.
+
+   See Also:
+      Media Plane
+      Emulated Agent
+
+3.1.3.  Media Plane
+
+   Definition:
+      The data plane in which one or more media streams and their
+      associated media control protocols (e.g., RTCP [RFC3550]) are
+      exchanged between User Agents after a media connection has been
+      created by the exchange of signaling messages in the Signaling
+      Plane.
+
+   Discussion:
+      Media may also be known as the "bearer channel".  The Media Plane
+      MUST include the media control protocol, if one is used, and the
+      media stream(s).  Examples of media are audio and video.  The
+      media streams are described in the SDP of the Signaling Plane.
+
+
+
+
+Davids, et al.                Informational                     [Page 8]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+   Measurement Units:
+      N/A.
+
+   Issues:
+      None.
+
+   See Also:
+      Signaling Plane
+
+3.1.4.  Associated Media
+
+   Definition:
+      Media that corresponds to an 'm' line in the SDP payload of the
+      Signaling Plane.
+
+   Discussion:
+      The format of the media is determined by the SDP attributes for
+      the corresponding 'm' line.
+
+   Measurement Units:
+      N/A.
+
+   Issues:
+      None.
+
+3.1.5.  Overload
+
+   Definition:
+      Overload is defined as the state where a SIP server does not have
+      sufficient resources to process all incoming SIP messages
+      [RFC6357].
+
+   Discussion:
+      The distinction between an overload condition and other failure
+      scenarios is outside the scope of black-box testing and of this
+      document.  Under overload conditions, all or a percentage of
+      Session Attempts will fail due to lack of resources.  In black-box
+      testing, the cause of the failure is not explored.  The fact that
+      a failure occurred for whatever reason will trigger the tester to
+      reduce the offered load, as described in the companion methodology
+      document [RFC7502].  SIP server resources may include CPU
+      processing capacity, network bandwidth, input/output queues, or
+      disk resources.  Any combination of resources may be fully
+      utilized when a SIP server (the DUT) is in the overload condition.
+      For proxy-only (or intermediary) devices, it is expected that the
+      proxy will be driven into overload based on the delivery rate of
+      signaling requests.
+
+
+
+
+Davids, et al.                Informational                     [Page 9]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+   Measurement Units:
+      N/A.
+
+3.1.6.  Session Attempt
+
+   Definition:
+      A SIP INVITE or REGISTER request sent by the EA that has not
+      received a final response.
+
+   Discussion:
+      The attempted session may be either an invitation to an audio/
+      video communication or a registration attempt.  When counting the
+      number of session attempts, we include all requests that are
+      rejected for lack of authentication information.  The EA needs to
+      record the total number of session attempts including those
+      attempts that are routinely rejected by a proxy that requires the
+      UA to authenticate itself.  The EA is provisioned to deliver a
+      specific number of session attempts per second.  But the EA must
+      also count the actual number of session attempts per given time
+      interval.
+
+   Measurement Units:
+      N/A.
+
+   Issues:
+      None.
+
+   See Also:
+      Session
+      Session Attempt Rate
+
+3.1.7.  Established Session
+
+   Definition:
+      A SIP session for which the EA acting as the UA has received a 200
+      OK message.
+
+   Discussion:
+      An Established Session may be either an invitation to an audio/
+      video communication or a registration attempt.  Early dialogs for
+      INVITE requests are out of scope for this work.
+
+   Measurement Units:
+      N/A.
+
+   Issues:
+      None.
+
+
+
+
+Davids, et al.                Informational                    [Page 10]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+   See Also:
+      None.
+
+3.1.8.  Session Attempt Failure
+
+   Definition:
+      A session attempt that does not result in an Established Session.
+
+   Discussion:
+      The session attempt failure may be indicated by the following
+      observations at the EA:
+
+      1.  Receipt of a SIP 3xx-, 4xx-, 5xx-, or 6xx-class response to a
+          Session Attempt.
+      2.  The lack of any received SIP response to a Session Attempt
+          within the Establishment Threshold Time (cf. Section 3.3.2).
+
+   Measurement Units:
+      N/A.
+
+   Issues:
+      None.
+
+   See Also:
+      Session Attempt
+
+3.2.  Test Components
+
+3.2.1.  Emulated Agent
+
+   Definition:
+      A device in the test topology that initiates/responds to SIP
+      messages as one or more session endpoints and, wherever
+      applicable, sources/receives Associated Media for Established
+      Sessions.
+
+   Discussion:
+      The EA functions in the Signaling and Media Planes.  The Tester
+      may act as multiple EAs.
+
+   Measurement Units:
+      N/A.
+
+   Issues:
+      None.
+
+
+
+
+
+
+Davids, et al.                Informational                    [Page 11]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+   See Also:
+      Media Plane
+      Signaling Plane
+      Established Session
+      Associated Media
+
+3.2.2.  Signaling Server
+
+   Definition:
+      Device in the test topology that facilitates the creation of
+      sessions between EAs.  This device is the DUT.
+
+   Discussion:
+      The DUT is a network intermediary that is RFC 3261 capable such as
+      a Registrar, Redirect Server, Stateful Proxy, B2BUA, or SBC.
+
+   Measurement Units:
+      N/A.
+
+   Issues:
+      None.
+
+   See Also:
+      Signaling Plane
+
+3.2.3.  SIP Transport Protocol
+
+   Definition:
+      The protocol used for transport of the Signaling Plane messages.
+
+   Discussion:
+      Performance benchmarks may vary for the same SIP networking device
+      depending upon whether TCP, UDP, TLS, SCTP, websockets [RFC7118],
+      or any future transport-layer protocol is used.  For this reason,
+      it is necessary to measure the SIP Performance Benchmarks using
+      these various transport protocols.  Performance Benchmarks MUST
+      report the SIP Transport Protocol used to obtain the benchmark
+      results.
+
+   Measurement Units:
+      While these are not units of measure, they are attributes that are
+      one of many factors that will contribute to the value of the
+      measurements to be taken.  TCP, UDP, SCTP, TLS over TCP, TLS over
+      UDP, TLS over SCTP, and websockets are among the possible values
+      to be recorded as part of the test.
+
+   Issues:
+      None.
+
+
+
+Davids, et al.                Informational                    [Page 12]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+   See Also:
+      None.
+
+3.3.  Test Setup Parameters
+
+3.3.1.  Session Attempt Rate
+
+   Definition:
+      Configuration of the EA for the number of sessions per second
+      (sps) that the EA attempts to establish using the services of the
+      DUT.
+
+   Discussion:
+      The Session Attempt Rate is the number of sessions per second that
+      the EA sends toward the DUT.  Some of the sessions attempted may
+      not result in a session being established.
+
+   Measurement Units:
+      Session Attempts per second
+
+   Issues:
+      None.
+
+   See Also:
+      Session
+      Session Attempt
+
+3.3.2.  Establishment Threshold Time
+
+   Definition:
+      Configuration of the EA that represents the amount of time that an
+      EA client will wait for a response from an EA server before
+      declaring a Session Attempt Failure.
+
+   Discussion:
+      This time duration is test dependent.
+
+      It is RECOMMENDED that the Establishment Threshold Time value be
+      set to Timer B or Timer F as specified in RFC 3261, Table 4
+      [RFC3261].
+
+   Measurement Units:
+      seconds
+
+   Issues:
+      None.
+
+
+
+
+
+Davids, et al.                Informational                    [Page 13]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+   See Also:
+      None.
+
+3.3.3.  Session Duration
+
+   Definition:
+      Configuration of the EA that represents the amount of time that
+      the SIP dialog is intended to exist between the two EAs associated
+      with the test.
+
+   Discussion:
+      The time at which the BYE is sent will control the Session
+      Duration.
+
+   Measurement Units:
+      seconds
+
+   Issues:
+      None.
+
+   See Also:
+      None.
+
+3.3.4.  Media Packet Size
+
+   Definition:
+      Configuration on the EA for a fixed number of frames or samples to
+      be sent in each RTP packet of the media stream when the test
+      involves Associated Media.
+
+   Discussion:
+      This document describes a method to measure SIP performance.  If
+      the DUT is processing media as well as SIP messages the media
+      processing will potentially slow down the SIP processing and lower
+      the SIP performance metric.  The tests with associated media are
+      designed for audio codecs, and the assumption was made that larger
+      media packets would require more processor time.  This document
+      does not define parameters applicable to video codecs.
+
+      For a single benchmark test, media sessions use a defined number
+      of samples or frames per RTP packet.  If two SBCs, for example,
+      used the same codec but one puts more frames into the RTP packet,
+      this might cause variation in the performance benchmark results.
+
+   Measurement Units:
+      An integer number of frames or samples, depending on whether a
+      hybrid- or sample-based codec is used, respectively.
+
+
+
+
+Davids, et al.                Informational                    [Page 14]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+   Issues:
+      None.
+
+   See Also:
+      None.
+
+3.3.5.  Codec Type
+
+   Definition:
+      The name of the codec used to generate the media session.
+
+   Discussion:
+      For a single benchmark test, all sessions use the same size packet
+      for media streams.  The size of packets can cause a variation in
+      the performance benchmark measurements.
+
+   Measurement Units:
+      This is a textual name (alphanumeric) assigned to uniquely
+      identify the codec.
+
+   Issues:
+      None.
+   See Also:
+      None.
+
+3.4.  Benchmarks
+
+3.4.1.  Session Establishment Rate
+
+   Definition:
+      The maximum value of the Session Attempt Rate that the DUT can
+      handle for an extended, predefined period with zero failures.
+
+   Discussion:
+      This benchmark is obtained with zero failure.  The Session Attempt
+      Rate provisioned on the EA is raised and lowered as described in
+      the algorithm in the accompanying methodology document [RFC7502],
+      until a traffic load over the period of time necessary to attempt
+      N sessions completes without failure, where N is a parameter
+      specified in the algorithm and recorded in the Test Setup Report.
+
+   Measurement Units:
+      sessions per second (sps)
+
+   Issues:
+      None.
+
+
+
+
+
+Davids, et al.                Informational                    [Page 15]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+   See Also:
+      Session Attempt Rate
+
+3.4.2.  Registration Rate
+
+   Definition:
+      The maximum value of the Registration Attempt Rate that the DUT
+      can handle for an extended, predefined period with zero failures.
+
+   Discussion:
+      This benchmark is obtained with zero failures.  The registration
+      rate provisioned on the Emulated Agent is raised and lowered as
+      described in the algorithm in the companion methodology document
+      [RFC7502], until a traffic load consisting of registration
+      attempts at the given attempt rate over the period of time
+      necessary to attempt N registrations completes without failure,
+      where N is a parameter specified in the algorithm and recorded in
+      the Test Setup Report.
+
+      This benchmark is described separately from the Session
+      Establishment Rate (Section 3.4.1), although it could be
+      considered a special case of that benchmark, since a REGISTER
+      request is a request for a session that is not initiated by an
+      INVITE request.  It is defined separately because it is a very
+      important benchmark for most SIP installations.  An example
+      demonstrating its use is an avalanche restart, where hundreds of
+      thousands of endpoints register simultaneously following a power
+      outage.  In such a case, an authoritative measurement of the
+      capacity of the device to register endpoints is useful to the
+      network designer.  Additionally, in certain controlled networks,
+      there appears to be a difference between the registration rate of
+      new endpoints and the registering rate of existing endpoints
+      (register refreshes).  This benchmark can capture these
+      differences as well.
+
+   Measurement Units:
+      registrations per second (rps)
+
+   Issues:
+      None.
+
+   See Also:
+      None.
+
+
+
+
+
+
+
+
+Davids, et al.                Informational                    [Page 16]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+3.4.3.  Registration Attempt Rate
+
+   Definition:
+      Configuration of the EA for the number of registrations per second
+      that the EA attempts to send to the DUT.
+
+   Discussion:
+      The Registration Attempt Rate is the number of registration
+      requests per second that the EA sends toward the DUT.
+
+   Measurement Units:
+      registrations per second (rps)
+
+   Issues:
+      None.
+
+   See Also:
+      None.
+
+4.  Security Considerations
+
+   Documents of this type do not directly affect the security of the
+   Internet or corporate networks as long as benchmarking is not
+   performed on devices or systems connected to production networks.
+   Security threats and how to counter these in SIP and the media layer
+   are discussed in RFC 3261 [RFC3261], RFC 3550 [RFC3550], and RFC 3711
+   [RFC3711].  This document attempts to formalize a set of common
+   terminology for benchmarking SIP networks.  Packets with unintended
+   and/or unauthorized DSCP or IP precedence values may present security
+   issues.  Determining the security consequences of such packets is out
+   of scope for this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davids, et al.                Informational                    [Page 17]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              June 2002, <http://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC5393]  Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B.
+              Campen, "Addressing an Amplification Vulnerability in
+              Session Initiation Protocol (SIP) Forking Proxies", RFC
+              5393, December 2008,
+              <http://www.rfc-editor.org/info/rfc5393>.
+
+   [RFC4320]  Sparks, R., "Actions Addressing Identified Issues with the
+              Session Initiation Protocol's (SIP) Non-INVITE
+              Transaction", RFC 4320, January 2006,
+              <http://www.rfc-editor.org/info/rfc4320>.
+
+   [RFC6026]  Sparks, R. and T. Zourzouvillys, "Correct Transaction
+              Handling for 2xx Responses to Session Initiation Protocol
+              (SIP) INVITE Requests", RFC 6026, September 2010,
+              <http://www.rfc-editor.org/info/rfc6026>.
+
+   [RFC7502]  Davids, C., Gurbani, V., and S. Poretsky, "Terminology for
+              Benchmarking Session Initiation Protocol (SIP) Devices:
+              Basic Session Setup and Registration", RFC 7502, April
+              2015, <http://www.rfc-editor.org/info/rfc7502>.
+
+5.2.  Informative References
+
+   [RFC2285]  Mandeville, R., "Benchmarking Terminology for LAN
+              Switching Devices", RFC 2285, February 1998,
+              <http://www.rfc-editor.org/info/rfc2285>.
+
+   [RFC1242]  Bradner, S., "Benchmarking Terminology for Network
+              Interconnection Devices", RFC 1242, July 1991,
+              <http://www.rfc-editor.org/info/rfc1242>.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, July 2003,
+              <http://www.rfc-editor.org/info/rfc3550>.
+
+
+
+Davids, et al.                Informational                    [Page 18]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, March 2004,
+              <http://www.rfc-editor.org/info/rfc3711>.
+
+   [RFC6357]  Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design
+              Considerations for Session Initiation Protocol (SIP)
+              Overload Control", RFC 6357, August 2011,
+              <http://www.rfc-editor.org/info/rfc6357>.
+
+   [RFC7118]  Baz Castillo, I., Millan Villegas, J., and V. Pascual,
+              "The WebSocket Protocol as a Transport for the Session
+              Initiation Protocol (SIP)", RFC 7118, January 2014,
+              <http://www.rfc-editor.org/info/rfc7118>.
+
+Acknowledgments
+
+   The authors would like to thank Keith Drage, Cullen Jennings, Daryl
+   Malas, Al Morton, and Henning Schulzrinne for invaluable
+   contributions to this document.  Dale Worley provided an extensive
+   review that lead to improvements in the documents.  We are grateful
+   to Barry Constantine, William Cerveny, and Robert Sparks for
+   providing valuable comments during the documents' last calls and
+   expert reviews.  Al Morton and Sarah Banks have been exemplary
+   working group chairs; we thank them for tracking this work to
+   completion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davids, et al.                Informational                    [Page 19]
+
+RFC 7501              SIP Benchmarking Terminology            April 2015
+
+
+Authors' Addresses
+
+   Carol Davids
+   Illinois Institute of Technology
+   201 East Loop Road
+   Wheaton, IL  60187
+   United States
+
+   Phone: +1 630 682 6024
+   EMail: davids@iit.edu
+
+
+   Vijay K. Gurbani
+   Bell Laboratories, Alcatel-Lucent
+   1960 Lucent Lane
+   Rm 9C-533
+   Naperville, IL  60566
+   United States
+
+   Phone: +1 630 224 0216
+   EMail: vkg@bell-labs.com
+
+
+   Scott Poretsky
+   Allot Communications
+   300 TradeCenter, Suite 4680
+   Woburn, MA  08101
+   United States
+
+   Phone: +1 508 309 2179
+   EMail: sporetsky@allot.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davids, et al.                Informational                    [Page 20]
+