summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7501.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7501.txt')
-rw-r--r--doc/rfc/rfc7501.txt1123
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]
+