From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7501.txt | 1123 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1123 insertions(+) create mode 100644 doc/rfc/rfc7501.txt (limited to 'doc/rfc/rfc7501.txt') 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, + . + + [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, . + + [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, + . + + [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the + Session Initiation Protocol's (SIP) Non-INVITE + Transaction", RFC 4320, January 2006, + . + + [RFC6026] Sparks, R. and T. Zourzouvillys, "Correct Transaction + Handling for 2xx Responses to Session Initiation Protocol + (SIP) INVITE Requests", RFC 6026, September 2010, + . + + [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, . + +5.2. Informative References + + [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN + Switching Devices", RFC 2285, February 1998, + . + + [RFC1242] Bradner, S., "Benchmarking Terminology for Network + Interconnection Devices", RFC 1242, July 1991, + . + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003, + . + + + +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, + . + + [RFC6357] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design + Considerations for Session Initiation Protocol (SIP) + Overload Control", RFC 6357, August 2011, + . + + [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, + . + +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] + -- cgit v1.2.3