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

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/