doc: Add RFC documents

1 files changed, 2019 insertions, 0 deletions

diff --git a/doc/rfc/rfc4710.txt b/doc/rfc/rfc4710.txt
new file mode 100644
index 0000000..ebf1f1b
--- /dev/null
+++ b/doc/rfc/rfc4710.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Network Working Group                                        A. Siddiqui
+Request for Comments: 4710                                  D. Romascanu
+Category: Standards Track                                          Avaya
+                                                           E. Golovinsky
+                                                             Alert Logic
+                                                            October 2006
+
+
+               Real-time Application Quality-of-Service
+                     Monitoring (RAQMON) Framework
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   There is a need to monitor end-devices such as IP phones, pagers,
+   Instant Messaging clients, mobile phones, and various other handheld
+   computing devices.  This memo extends the remote network monitoring
+   (RMON) family of specifications to allow real-time quality-of-service
+   (QoS) monitoring of various applications that run on these devices
+   and allows this information to be integrated with the RMON family
+   using the Simple Network Management Protocol (SNMP).  This memo
+   defines the framework, architecture, relevant metrics, and transport
+   requirements for real-time QoS monitoring of applications.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. RAQMON Functional Architecture ..................................4
+   3. RAQMON Operation in Congestion-Safe Mode .......................11
+   4. Measurement Methodology ........................................14
+   5. Metrics Pre-Defined for the BASIC Part of the RAQMON PDU .......14
+   6. Report Aggregation and Statistical Data processing .............28
+   7. Keeping Historical Data and Storage ............................29
+   8. Security Considerations ........................................30
+   9. Acknowledgements ...............................................32
+   10. Normative References ..........................................33
+   11. Informative References ........................................34
+
+
+
+Siddiqui, et al.            Standards Track                     [Page 1]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+1.  Introduction
+
+   With the growth of the Internet and advancements in embedded
+   technologies, smart IP devices (such as IP phones, pagers, instant
+   message clients, mobile phones, wireless handhelds, and various other
+   computing devices) have become an integral part of our day-to-day
+   operations.  Enterprise operators, information technology (IT)
+   managers, application service providers, network service providers,
+   and so on, need to monitor these application and device types in
+   order to ensure that end user quality-of-service (QoS) objectives are
+   met.  This memo describes a monitoring solution for these
+   environments, extending the remote network monitoring (RMON) family
+   of specifications [RFC2819].  These extensions support real-time QoS
+   monitoring of typical applications that run on end-devices mentioned
+   above, and they allow this information to be integrated using the
+   familiar RMON family of specifications via SNMP [RFC3416].
+
+   The Real-time Application QoS Monitoring Framework (RAQMON) allows
+   end-devices and applications to report QoS statistics in real time.
+   Many real-time applications (as well as non-real-time applications
+   managed within the RMON family of specifications) can report
+   application-level QoS statistics in real time using the RAQMON
+   Framework outlined in this memo.  Some possible applications
+   scenarios include applications such as Voice over IP, Fax over IP,
+   Video over IP, Instant Messaging (IM), Email, software download
+   applications, e-business style transactions, web access from handheld
+   computing devices, etc.
+
+   The user experience of an application running on an IP end-device
+   depends upon the type of application the user is running and the
+   surrounding resources available to that application.  An end-to-end
+   application QoS experience is a compound effect of various
+   application-level transactions and available network and host
+   resources.  For example, the end-to-end user experience of a Voice
+   over IP (VoIP) call depends on the total time required to set up the
+   call as much as on media-related performance parameters such as end-
+   to-end network delay, jitter, packet loss, and the type of codec used
+   in a call.  The performance of a VoIP call is also influenced by
+   behavior of network protocols like the Reservation Protocol (RSVP),
+   explicit tags in differentiated services (DiffServ) [RFC2475] or IEEE
+   802.1 [IEEE802.1D] along with available host resources such as device
+   CPU or memory utilized by other applications while the call is
+   ongoing.
+
+   The end-to-end application quality of service (QoS) experience is
+   application context sensitive.  For example, the kinds of parameters
+   reported by an IP telephony application may not really be needed for
+   other applications such as Instant Messaging.  The RAQMON Framework
+
+
+
+Siddiqui, et al.            Standards Track                     [Page 2]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   offers a mechanism to report the end-to-end QoS experience
+   appropriate for a specific application context by providing
+   mechanisms to report a subset of metrics from a pre-defined list.
+
+   In order to facilitate a complete end-to-end view, RAQMON correlates
+   statistics that involve:
+
+      i.   "User, Application, Session"-specific parameters (e.g.,
+            session setup time, session duration parameters based on
+            application context).
+
+      ii.  "IP end-device"-specific parameters during a session (e.g.,
+            CPU usage, memory usage).
+
+      iii. "Transport network"-specific parameters during a session
+            (e.g., end-to-end delay, one-way delay, jitter, packet loss
+            etc).
+
+   At any given point, the applications at these devices can correlate
+   such diverse data and report end-to-end performance.  The RAQMON
+   Framework specified in this memo offers a mechanism to report such
+   end-to-end QoS view and integrate such a view into the RMON family of
+   specifications.  In particular, the RAQMON Framework specifies the
+   following:
+
+      a. A set of basic metrics sent as reports between the RAQMON
+         entities using for transport existing Internet Protocols such
+         as TCP or SNMP.
+
+      b. Requirements to be met by the underlying transport protocols
+         that carry the RAQMON reports.
+
+      c. A portion of the Management Information Base (MIB) as an
+         extension of the RMON MIB Modules for use with network
+         management protocols in the Internet community.
+
+   This memo provides the RAQMON functional architecture, RAQMON entity
+   definitions and requirements, requirements for the transport
+   protocols, a set of metrics, and an information model for the RAQMON
+   reports.
+
+   Supplementary memos will describe the mapping of the basic RAQMON
+   metrics onto different transport protocols.  For example, the RAQMON
+   PDU [RFC4712] memo provides definitions of syntactical PDU structure
+   and use case scenarios of transmission of such PDUs over the
+   Transmission Control Protocol (TCP) and the Simple Network Management
+   Protocol (SNMP).
+
+
+
+
+Siddiqui, et al.            Standards Track                     [Page 3]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   The RAQMON MIB [RFC4711] memo describes the Management Information
+   Base (MIB) for use with the SNMP protocol in the Internet community.
+   The document proposes an extension to the Remote Monitoring MIB
+   [RFC2819] to accommodate RAQMON solutions.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  RAQMON Functional Architecture
+
+   The RAQMON Framework extends the architecture created in the RMON MIB
+   [RFC2819] by providing application performance information as
+   experienced by end-users.  The RAQMON architecture is based on three
+   functional components named below:
+
+      -  RAQMON Data Source (RDS)
+
+      -  RAQMON Report Collector (RRC)
+
+      -  RAQMON MIB Structure
+
+   A RAQMON Data Source (RDS) is a functional component that acts as a
+   source of data for monitoring purposes.  End-devices like IP phones,
+   cell phones, and pagers, and application clients like instant
+   messaging clients, soft phones in PCs, etc., are envisioned to act as
+   RDSs within the RAQMON Framework.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Siddiqui, et al.            Standards Track                     [Page 4]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+
+   +----------------------+        +---------------------------+
+   |    IP End-Device     |        |    IP End-Device   >----+ |
+   |+--------------------+|        |+--------------------+   | |
+   || APPLICATION        ||        || APPLICATION        |   | |
+   ||  -Voice over IP   <----(1)----> -Voice over IP    >- + | |
+   ||  -Instant Messaging||        ||  -Instant Messaging| | 3 |
+   ||  -Email            ||        ||  -Email            | 2 | |
+   |+--------------------+|        |+--------------------+ | | |
+   |                      |        |                       | | |
+   |                      |        | +------------------+  | | |
+   +----------------------+        | |RAQMON Data Source|<-+ | |
+                                   | |    (RDS)         |<---+ |
+                                   | +------------------+      |
+                                   +-----------|---------------+
+                                               |
+                                 (4) RAQMON PDU transported
+                               over TCP or SNMP Notifications
+                                               |
+                  +----------------------------+
+                  |                            |
+                  |/                           |/
+     +------------------+      +------------------+       +------------+
+     |RAQMON Report     |  ..  |RAQMON Report     |       | Management |
+     |Collector (RRC) #n|      |Collector (RRC) #1|<--5-->| Application|
+     +------------------+      +------------------+       +------------+
+
+
+                       Figure 1 - RAQMON Framework.
+
+      (1) Communication Session between real-time applications
+
+      (2) Context-Sensitive Metrics
+
+      (3) Device State Specific Metrics
+
+      (4) Reporting session - RAQMON metrics transmitted over  specified
+          interfaces (Specific Protocol Interface, IP Address, port)
+
+      (5) Management Application - RRC interaction using the RAQMON MIB
+
+   A RAQMON Report Collector (RRC) collects statistics from multiple
+   RDSs, analyzes them, and stores such information appropriately.  RRC
+   is envisioned to be a network server, serving an administrative
+   domain defined by the network administrator.  The RRC component of
+   the RAQMON architecture is envisioned to be computationally
+   resourceful.  Only RRCs should implement the RAQMON MIB module.
+
+
+
+
+Siddiqui, et al.            Standards Track                     [Page 5]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   The RAQMON Management Information Base (RAQMON MIB) extends the
+   Remote Monitoring MIB [RFC2819] to accommodate the RAQMON Framework
+   and exposes End-to-End Application QoS information to Network
+   Management Applications.
+
+2.1.  RAQMON Data Source (RDS)
+
+2.1.1.  RAQMON Data Source (RDS) Functional Architecture
+
+   A RAQMON Data Source (RDS) is a source of data for monitoring
+   purposes.  The RDS monitoring function is performed in real time
+   during communication sessions.  The RDS entities capture QoS
+   attributes of such communication sessions and report them within a
+   RAQMON "reporting session".
+
+   An RDS is primarily responsible for abstracting IP end-devices and
+   applications within the RAQMON architecture.  It gathers the
+   parameters for a particular communication session and forwards them
+   to the appropriate RAQMON Report Collector (RRC).  Since it is
+   envisioned that the RDS functionality will be realized by writing
+   firmware/software running on potentially small, low-powered end-
+   devices, the design of the RDS element is optimized towards that end.
+   Like the implementations of routing and management protocols, an
+   implementation of RDS in an end-device will typically execute in the
+   background, not in the data-forwarding path.
+
+   RDSs use a PUSH mechanism to report QoS parameters.  While the
+   applications running on the RDS decide about the content of the PDU
+   appropriate for an application context, an RDS asynchronously sends
+   out reports to RRC.
+
+   The rate at which PDUs are sent from RDSs to RRCs is controlled by
+   the applications' administrative domain policy.  While this mechanism
+   provides flexibility to gather a detailed end-to-end experience
+   required by IT managers and system administrators, certain steps
+   should be followed to operate RAQMON in congestion-safe manner.
+   Section 3 addresses steps required for congestion-safe operation.
+
+   An RDS reports QoS statistics for simplex flows.  At a given
+   instance, a report from RDS is logically viewed as a collection of
+   QoS parameters associated with a communication session as perceived
+   by the reporting RDS.  For example, if two IP phone users, Alice and
+   John, are involved in a communication session, the end-to-end delay
+   experienced by the IP phone user Alice could be different from the
+   one experienced by the IP phone user John for a variety of reasons.
+   Hence, a report from Alice's IP phone represents the QoS performance
+   of that call as perceived by the RDS that resides in Alice's IP
+   phone.
+
+
+
+Siddiqui, et al.            Standards Track                     [Page 6]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+2.1.2.  RAQMON Data Source (RDS) Requirements
+
+      1. RAQMON Data Sources SHALL gather reports from multiple
+         applications residing in that device and SHALL send out
+         compound QoS reports associated with multiple communication
+         sessions at a given moment.
+
+         Examples include a conference bridge hosting several different
+         conference calls or a two-party video call consisting of
+         audio/video sessions.  In each case an RDS could send out one
+         single RAQMON report that consists of multiple sub-reports
+         associated with audio and video sessions or sub-reports for
+         each conference call.
+
+      2. RAQMON Data Sources MUST implement the TCP transport and MAY
+         implement the SNMP transport.
+
+2.1.3.  Configuring RAQMON Data Sources
+
+   In order to report statistics to RAQMON Report Collectors, RDSs will
+   need to be configured with the following parameters:
+
+      1. The time interval between RAQMON PDUs.  This parameter MUST be
+         configured such that overflow of any RAQMON parameter within a
+         PDU between consecutive transmissions is avoided.
+
+      2. The IP address and port of target RRC.
+
+   An RDS may use manual configuration for the RDS configuration
+   parameters using command line interface (CLI), Telephone User
+   Interface (TUI), etc.
+
+   One of the following mechanisms to gain access to configuration
+   parameters can also be considered:
+
+      -  RDS acts as a trivial file transfer protocol (TFTP) client and
+         downloads text scripts to read the parameters.
+      -  RDS acts as a Dynamic Host Configuration Protocol (DHCP) Client
+         and gets RRC addressing information as a DHCP option.
+      -  RDS acts as a DNS client and gets target collector information
+         from a DNS Server.
+      -  RDS acts as a LDAP Client and uses directory look-ups.
+
+   Identifying the DHCP option and structure to use, defining the
+   structure of the configuration information in DNS, or defining a LDAP
+   schema could be explored as items of future work.
+
+
+
+
+
+Siddiqui, et al.            Standards Track                     [Page 7]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   Compliance to the RAQMON specification does not require usage of any
+   specific configuration mechanisms mentioned above.  It is left to the
+   implementers to choose appropriate provisioning mechanisms for a
+   system.
+
+2.2.  RAQMON Report Collector (RRC)
+
+2.2.1.  RAQMON Report Collector (RRC) Functional Architecture
+
+   A RAQMON Report Collector (RRC) receives RAQMON PDUs from multiple
+   RDSs and analyzes and stores the information in the RAQMON MIB.  The
+   RRC is envisioned to be computationally resourceful, providing a
+   storage and aggregation point for a set of RDSs.
+
+   Since RDSs can belong to separate administrative domains, the RAQMON
+   Framework allows RDSs to report QoS parameters to separate RRCs.
+   Vendors can develop a management application to correlate information
+   residing in different RRCs across multiple administrative domains to
+   represent one communication session.  However, such an application-
+   level specification is beyond the scope of this memo.
+
+2.2.2.  RAQMON Report Collector (RRC) Requirements
+
+      1. RAQMON Report Collectors MUST support the mandatory mapping
+         over TCP of the RAQMON information model defined in [RFC4712]
+         with the purpose of receiving RAQMON reports from RAQMON Data
+         Sources (RDS).
+
+      2. RAQMON Report Collectors MAY support the optional mapping over
+         SNMP notifications of the RAQMON information model defined in
+         [RFC4712].
+
+      3. RAQMON Report Collectors MUST implement session timeout
+         mechanisms to assume end of reporting for RDSs that have been
+         out of reporting for a reasonable duration of time.  Such
+         timeout parameters SHOULD be configurable in vendor
+         implementations, as programmable parameters at deployment.
+
+      4. RAQMON Report Collectors MUST support the RAQMON-MIB module and
+         meet the compliance requirements of the raqmonCompliance
+         MODULE-COMPLIANCE definition as described in [RFC4711].  The
+         population of the RAQMON MIB with performance monitoring
+         information is independent of the transport protocol, or
+         protocols used to carry the information between RDSs and RRCs.
+
+
+
+
+
+
+
+Siddiqui, et al.            Standards Track                     [Page 8]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+2.3.  Information Model and RAQMON Protocol Data Unit (PDU)
+
+2.3.1.  RAQMON Information Model
+
+   RAQMON defines a set of basic metrics that characterize the QoS of
+   applications, as reported by RAQMON Data Sources.  This basic set of
+   metrics is defined in Section 5 of this memo.  There is no minimal
+   requirement for a mandatory set of metrics to be supported by an RDS.
+
+   Specific applications, new types of network appliances or new methods
+   to measure and characterize the QoS of applications lead to the
+   requirement for the information model to be extensible.  To answer
+   this need, the information model is designed so that vendors can
+   extend it by adding new metrics.
+
+   Although NOT REQUIRED for RAQMON conformance, extensions of the
+   information model can offer useful information for specific
+   applications.  An example of metrics that can extend the basic RAQMON
+   information model are the detailed metrics for VoIP media monitoring
+   and call quality included in the VoIP Metrics Report Block defined in
+   [RFC3611].
+
+   The RAQMON Information model is expressed by defining a conceptual
+   RAQMON Protocol Data Unit (PDU).
+
+2.3.2.  RAQMON Protocol Data Unit
+
+   A RAQMON Protocol Data Unit (PDU) is a common data format understood
+   by RDSs and RRCs.  A RAQMON PDU does not transport application data
+   but rather occupies the place of a payload specification at the
+   application layer of the protocol stack.  Different transport
+   mappings may be used to carry RAQMON PDU between RDSs and RRCs.
+   Transport protocol requirements are being defined in Section 2.4 of
+   this memo.
+
+   Though architected conceptually as a single PDU, the RAQMON PDU is
+   functionally divided into two different parts.  They are the BASIC
+   part, and the Application-Specific Extensions, required for
+   application-, vendor-, and device-specific extensions.
+
+   The BASIC part of the RAQMON PDU:
+      The BASIC part of the RAQMON PDU follows the SMI Network
+      Management Private Enterprise Code 0, indicating an IETF standard
+      construct.  The RAQMON PDU BASIC part offers an entry-type from a
+      pre-defined list of QoS parameters defined in Section 5 and allows
+      applications to fill in appropriate values for those parameters.
+      Application developers also have the flexibility to make an RDS
+      report built only of a subset of the parameters listed in
+
+
+
+Siddiqui, et al.            Standards Track                     [Page 9]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+      Section 5.  There is no need to carry all metrics in every PDU;
+      moreover, it is RECOMMENDED that static or pseudo-static metrics
+      that do not change or seldom change for a given session or
+      application will be send only when the session or application are
+      initiated, and then at large time intervals.
+
+   The Application part of RAQMON PDU:
+      Since it is difficult to structure a BASIC part that meets the
+      needs of all applications, RAQMON provides extension capabilities
+      to convey application-, vendor-, and device-specific parameters
+      for future use.  Additional parameters can be defined within
+      payload of the APP part of the PDU by the application developers
+      or vendors.  The owner of the definition of the application part
+      of the RAQMON PDU is indicated by a vendor's SMI Network
+      Management Private Enterprise Code defined in
+      http://www.iana.org/assignments/enterprise-numbers.  Such
+      application-specific extensions should be maintained and published
+      by the application vendor.
+
+   Though RDSs and RRCs are designed to be stateless for an entire
+   reporting session, the framework requires an indication for the end
+   of the reporting.  For this purpose, an RDS MUST send a RAQMON NULL
+   PDU.  A NULL PDU is a RAQMON PDU containing ALL NULL values (i.e.,
+   nothing to report).
+
+2.4.  RDS/RRC Network Transport Protocol Requirements
+
+   The RAQMON PDUs rely on the underlying protocol(s) to provide
+   transport functionalities and other attributes of a transport
+   protocol, e.g., transport reliability, re-transmission, error
+   correction, length indication, congestion safety,
+   fragmentation/defragmentation, etc.  The maximum length of the RAQMON
+   data packet is limited only by the underlying protocols.
+
+   The following requirements MUST be met by the transport protocols:
+
+      1. The transport protocol SHOULD allow for RDS lightweight
+         implementations.  RDSs will be implemented on low-powered
+         embedded devices with limited device resources.
+
+      2. Scalability - Since RRCs need to interact with a very large
+         number (many tens, many hundreds, or more) of RDSs, scalability
+         of the transport protocol is REQUIRED.
+
+      3. Congestion safety - as per [RFC2914].  See also Section 3.
+
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 10]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+      4. Security - Since RAQMON statistics may carry sensitive system
+         information requiring protection from unauthorized disclosure
+         and modification in transit, a transport protocol that provides
+         strong secure modes or allows for data encryption and integrity
+         to be applied is REQUIRED.
+
+      5. NAT-Friendly - The transport protocol SHOULD comply with
+         [RFC3235], so that an RDS could communicate with an RRC through
+         a Firewall/Network Address Translation device.
+
+      6. The transport protocol MAY implement session timeout mechanisms
+         to assume end of reporting for RDSs that have been out of
+         reporting for a reasonable duration of time.  Such timeout
+         parameters SHOULD be configurable in vendor implementations,
+         programmable at deployment.
+
+      7. Reliability - The RAQMON Framework expects PDUs to operate in
+         lossy networks.  However, retransmission is not included in the
+         RAQMON framework, in order to keep the design simple.  If
+         retransmission is a necessity, RAQMON MAY operate over
+         transport protocols, such as TCP.
+
+   In the future, if RAQMON PDUs are to be carried in an underlying
+   protocol that provides the abstraction of a continuous octet stream
+   rather than messages (packets), an encapsulation for the RAQMON
+   packets must be defined to provide a framing mechanism.  Framing is
+   also needed if the underlying protocol contains padding so that the
+   extent of the RAQMON payload cannot be determined.  No framing
+   mechanism is defined in this document.  Carrying several RAQMON
+   packets in one network or transport packet reduces header overhead.
+
+   Further memos like [RFC4712] describe how the PDU is transported over
+   existing protocols like the Transmission Control Protocol (TCP) or
+   the Simple Network Management Protocol (SNMP).
+
+3.  RAQMON Operation in Congestion-Safe Mode
+
+   RAQMON PDUs can be transmitted over multiple transport protocols.
+   The RAQMON Framework will be congestion safe, if a RAQMON PDU is
+   transported over TCP.
+
+   One solution to the congestion awareness problem could have been to
+   discourage the use of UDP entirely for RAQMON.  Though RAQMON PDUs
+   can be transported over TCP, some transports like SNMP over TCP are
+   not commonly practiced in practical deployments.
+
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 11]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   The use of UDP inherently increases the risks of network congestion
+   problems, as UDP itself does not define congestion prevention,
+   avoidance, detection, or correction mechanisms.  The fundamental
+   problem with UDP is that it provides no feedback mechanism to allow a
+   sender to pace its transmissions against the real performance of the
+   network.  While this tends to have no significant effect on extremely
+   low-volume sender-receiver pairs, the impact of high-volume
+   relationships on the network can be severe.  This problem could be
+   further aggravated by large RAQMON PDUs fragmented at the UDP level.
+   Transport protocols such as DCCP can also be used as underlying
+   RAQMON PDU transport, which provides flexibility of UDP style
+   datagram transmission with congestion control.
+
+   It should be noted that the congestion problem is not just between
+   RDS and RRC pairs, but whenever there is a high fan-in ratio,
+   congestion could occur (e.g., many RDSs reporting to an RRC).  Within
+   the RAQMON Framework using UDP as a transport, congestion safety can
+   be achieved in following ways:
+
+      1. Constant Transmission Rate: In a well-managed network, a
+         constant transmission rate policy (e.g., 1 RAQMON PDU per
+         device every N seconds) will ensure congestion safety as
+         devices are introduced into the network in a controlled manner.
+         For example, in an enterprise network, IP Phones are added in a
+         controlled manner, and a constant transmission rate policy can
+         be sufficient to ensure congestion-safe operation.  The
+         configured rate needs to be related to the expected peak number
+         of devices.  As a worst-case scenario, if the RDSs enforce an
+         administrative policy where the maximum PDU transmission rate
+         is no more than one RAQMON PDU every two minutes, a UDP-based
+         implementation can be as congestion safe as a TCP-based
+         implementation.  Such policies can be enforced while
+         configuring RDSs, and the timers for the constant rate need to
+         be randomly jittered.
+
+      2. Single outstanding requests: This approach requires that a
+         request be sent at the application level, then there is a wait
+         for some sort of response indicating that the request was
+         received before sending anything else.  This produces an effect
+         described by some as "ping-ponging":  traffic bounces back and
+         forth between two nodes like a ping-pong ball in a match.
+         Since there's only one ball in play between any two players at
+         any given time, most of the potential for congestion cascades
+         is eliminated.  For reliability and efficiency reasons, this
+         technique must include backed-off retransmissions.  For
+         example, if RAQMON PDUs are transported using SNMP INFORM PDUs
+         over UDP, a SNMP response from the RRC SHOULD be processed by
+         the RDS to implement this mechanism.  [RFC4712] specifies that
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 12]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+         if the SNMP notifications transport mapping mechanism is
+         implemented, it is RECOMMENDED to use INFORM PDUs, and it is
+         NOT RECOMMENDED to use Trap PDUs.
+
+         This pacing or serialization approach has the side-effect of
+         significantly reducing the maximum throughput, as transmission
+         occurs in only one direction at a time and there is at least a
+         2xRTT (round-trip time) delay between transmissions.  More
+         sophisticated algorithms (such as those in TCP and Stream
+         Control Transmission Protocol (SCTP)) have been developed to
+         address this, and it would be inappropriate to duplicate that
+         work at the application level.  Consequently, if greater
+         efficiency is required than that provided by this simple
+         approach, implementers SHOULD use TCP, SCTP, or another such
+         protocol.  But if one absolutely must use UDP, this approach
+         works.  It has been also used in other application scenarios
+         like SIP over UDP.
+
+      3. By restricting transmission to a maximum transmission unit
+         (MTU) size:  An RDS may be faced with a request to deliver a
+         large message using UDP as a transport.  Fragmentation of such
+         messages is problematic in several ways.  Loss of any fragment
+         requires time-out and retransmission of the message.  The
+         fragments are commonly transmitted out of the interface at
+         local interface (usually LAN) rates, without awareness of the
+         intervening network conditions.  For these reasons, it is
+         generally considered a bad practice to send large PDUs over
+         UDP.  If the MTU size is known, as an implementation, an RDS
+         should not allow an application to send more information by
+         limiting the size of transmissions over UDP to reduce the
+         effects of fragmentation.  As an alternate, an RDS MAY also
+         send parameters to RRC over multiple RAQMON PDUs but identify
+         them as part of the same RAQMON reporting session with exactly
+         the same Network Time Protocol (NTP) [RFC1305] time stamp.
+
+         While the actual MTU of a link may not be known, common
+         practice seems to indicate that the RDS local interface MTU is
+         likely to be a reasonable "approximation".  Where the actual
+         path MTU is known, that value SHOULD be used instead.
+
+      4. Irrespective of choice of transport protocol, it is also
+         RECOMMENDED that no more than 10% network bandwidth be used for
+         RDS/RRC reporting.  More frequent reports from an RDS to RRC
+         would imply requirements for higher network bandwidth usage.
+
+
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 13]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+4.  Measurement Methodology
+
+   It is not the intent of this document to recommend a methodology to
+   measure any of the QoS parameters defined in Section 5.  Measurement
+   algorithms are left to the implementers and equipment vendors to
+   choose.  There are many different measurement methodologies available
+   for measuring application performance.  These include probe-based,
+   client-based, synthetic-transaction, and other approaches.  This
+   specification does not mandate a particular methodology and is open
+   to any methodology that meets the minimum requirements.  For
+   conformance to this specification, it is REQUIRED that the collected
+   data match the semantics described herein.  However, it is
+   RECOMMENDED that vendors use IETF-defined and International
+   Telecommunication Union (ITU)-specified methodologies to measure
+   parameters when possible.
+
+5.  Metrics Pre-Defined for the BASIC Part of the RAQMON PDU
+
+   The BASIC part of the RAQMON PDU provides for a list of pre-defined
+   parameters frequently used by applications to characterize end-to-end
+   application Quality of Service.  This section defines a set of simple
+   metrics to be contained in the BASIC part of the RAQMON PDU, through
+   reference to existing IETF, ITU, and other standards organizations'
+   documents.  Appropriate IETF or ITU references are included in the
+   metrics definitions.
+
+   As mentioned earlier, the RAQMON PDU also contains an application-
+   specific part, where application- and vendor-specific information not
+   included in BASIC part can be added as <Name, Value> pairs, or as a
+   variable binding list.  These extensions, managed independently by
+   vendors or other organizations, should be published for wider
+   interoperability.
+
+   Applications are not required to report all the parameters mentioned
+   in this section, but should have the flexibility to report a subset
+   of these parameters appropriate to an application context.  The memo
+   further identifies the parameters that RDSs are required to include
+   in all PDUs for compliance, as well as optional parameters that RDSs
+   may report as needed.  The definitions presented here are meant to
+   provide guidance to implementers, and IETF metric definition
+   references are provided for each metric.  Application developers
+   should choose the metrics appropriate to their applications' needs.
+   Syntactical representations of the parameters identified here are
+   provided in the [RFC4712] specification.
+
+
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 14]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+5.1.  Data Source Address (DA)
+
+   The Data Source Address (DA) is the address of the data source.  This
+   could be either a globally unique IPv4 or IPv6 address, or a
+   privately IPv4 allocated address as defined in [RFC1918].
+
+   It is expected that the DA would remain constant within a given
+   communication session.  RDSs SHOULD avoid sending these parameters
+   within RAQMON reports too often to ensure an efficient usage of
+   network resources.
+
+5.2.  Receiver Address (RA)
+
+   The Receiver Address (RA) takes the same form as the Data Source
+   Address (DA) but represents the Receiver's Address.  In a
+   communication session, the reporting RDSs SHOULD fill in the other
+   party's address as a Receiver Address.  Like the Data Source Address,
+   this could be either a globally unique IPv4 or IPv6 address, or a
+   privately allocated IPv4 address as defined in [RFC1918].
+
+   It is expected that the Receiver Address (RA) would remain constant
+   within a given communication session.  RDSs SHOULD avoid sending
+   these parameters within RAQMON reports too often in order to ensure
+   an efficient usage of network resources.
+
+5.3.  Data Source Name (DN)
+
+   The Data Source Name (DN) item could be of various formats as needed
+   by the application.  Forms the DN could take include, but are not
+   restricted to:
+
+      - "user@host", or "host" if a user name is not available as on
+        single-user systems.  For both of these formats, "host" is the
+        fully qualified domain name of the host from which the payload
+        originates, formatted according to the rules specified in
+        [RFC1034], [RFC1035], and Section 2.1 of [RFC1123].  Use example
+        names are "big-guy@example.com" or "big-guy@192.0.2.178" for a
+        multi-user system.  On a system with no user name, an example
+        would be "ip-phone4630.example.com".  It is RECOMMENDED that the
+        standard host's numeric address not be reported via the DN
+        parameter, as the DA parameter is used for that purpose.
+
+      - Another instance of a DN could be a valid E.164 phone number, a
+        SIP URI, or any other form of telephone or pager number.  The
+        phone number SHOULD be formatted with a plus sign replacing the
+        international access code.  Example: "+44-116-496-0348" for a
+        number in the UK.
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 15]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   The DN value is expected to remain constant for the duration of a
+   session.  RDSs SHOULD avoid sending these parameters within RAQMON
+   reports too often in order to ensure an efficient usage of network
+   resources.
+
+5.4.  Receiver Name (RN)
+
+   The Receiver Name (RN) takes the same form as DN, but represents the
+   Receiver's name.  In a communication session, an application SHOULD
+   supply as an RN the name of the other party with which it is
+   communicating.
+
+   The RN value is expected to remain constant for the duration of a
+   session.  RDSs SHOULD avoid sending these parameters within RAQMON
+   reports too often in order to ensure an efficient usage of network
+   resources.
+
+5.5.  Data Source Device Port Used
+
+   This parameter indicates the source port used by the application for
+   a particular session or sub-session in communication.  Examples of
+   ports include TCP Ports or UDP Ports, as used by communication
+   application protocols such as Session Initiation Protocol (SIP), SIP
+   for Instant Messaging and Presence Leveraging Extensions (SIMPLE),
+   H.323, RTP, HyperText Transport Protocol (HTTP), and so on.
+
+   This parameter MUST be sent in the first RAQMON PDU.
+
+5.6.  Receiver Device Port Used
+
+   This parameter indicates the receiver port used by the application
+   for a particular session or sub-session.  Examples of ports include
+   TCP Ports, or UDP Ports used by communication application protocols
+   such as SIP, SIMPLE, H.323, RTP, HTTP, etc.
+
+   This parameter MUST be sent in the first RAQMON PDU.
+
+5.7.  Session Setup Date/Time
+
+   This parameter gives the time when the setup was initiated, if the
+   application has a setup phase, or when the session was started, if
+   such a setup phase does not exist.  The time is represented using the
+   timestamp format of the Network Time Protocol (NTP), which is in
+   seconds relative to 0h UTC (Coordinated Universal Time) on 1 January
+   1900 [RFC1305].
+
+   This parameter SHOULD be sent only in the first RAQMON PDU, after the
+   session setup is completed.
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 16]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+5.8.  Session Setup Delay
+
+   The Session Setup Delay metric reports the time taken from an
+   origination request being initiated by a host/endpoint to the media
+   path being established (or a session progress indication being
+   received from the remote host/endpoint), expressed in milliseconds.
+   For example, in VoIP systems, a session setup time can be measured as
+   the interval from the last DTMF (dual-tone multi-frequency) button
+   pushed to the first ring-back tone that indicates that the far end is
+   ringing.  Another example would be the Session Setup Delay of a SIP
+   call, which is measured as the elapsed time between when an INVITE is
+   generated by a User Agent and when the 200 OK is received.
+
+   This parameter SHOULD be sent only in the first RAQMON PDU, after the
+   session setup is completed.
+
+5.9.  Session Duration
+
+   The Session Duration metric reports how long a session or a sub-
+   session lasted.  This metric is application context sensitive.  For
+   example, a VoIP Call Session Duration can be measured as the elapsed
+   time between call pickup and call termination, including session
+   setup time.
+
+   This parameter SHOULD be sent only in the first RAQMON PDU, after the
+   session is terminated.
+
+5.10.  Session Setup Status
+
+   The Session Setup Status metric is intended to report the
+   communication status of a session.  Its values identify appropriate
+   communication session states, such as Call Progressing, Call
+   Established successfully, "trying", "ringing", "re-trying", "RSVP
+   reservation failed", and so on.
+
+   Session setup status is meaningful in the context of applications.
+   For this reason, applications SHOULD use this metric together with
+   the application/name metrics defined in Section 5.32.
+
+   This information could be used by network management systems to
+   calculate parameters such as call success rate, call failure rate,
+   etc., or by a debugging tool that captures the status of a call's
+   setup phase as soon as a call is established.
+
+   This parameter SHOULD be sent after each change in the session
+   status.
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 17]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+5.11.  Round-Trip End-to-End Network Delay
+
+   The Round-Trip End-to-End Network Delay, defined in [RFC3550] for
+   applications running over RTP and in [RFC2681] for all other IP
+   applications, is a key metric for Application QoS Monitoring.  Some
+   applications do not perform well (or at all) if the end-to-end delay
+   between hosts is large relative to some threshold value.  Erratic
+   variation in delay values makes it difficult (or impossible) to
+   support many real-time applications such as Voice over IP, Video over
+   IP, Fax over IP etc.
+
+   The Round-Trip End-to-End Network delay of the underlying transport
+   network is measured using methodologies described in [RFC3550] for
+   RTP and in [RFC2681] for other IP applications.
+
+   Note that the packets used for measurement in some methodologies may
+   be of a different type from those used for media (e.g., ICMP instead
+   of RTP) and hence may differ in terms of route and queue priority.
+   This may result in measured delays being different from those
+   experienced on the media path.  Conformance for this metric requires
+   that actual application packets, or packets of the same application
+   type, be used.
+
+   Support for RTP can be determined by the support of the RTP MIB
+   [RFC2959] in the hosts running the applications or by inclusion of
+   the string 'RTP' at the beginning of the Application Name (Section
+   5.32).
+
+   This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the
+   capability of determining its value and if the parameter is relevant
+   for the application.
+
+5.12.  One-Way End-to-End Network Delay
+
+   The One-Way End-to-End Network Delay [RFC2679] metric reports the
+   One-Way End-to-End delay encountered by traffic from the source to
+   the destination network interface.  One-Way Delay measurements
+   identified by the IP Performance Metrics (IPPM) Working Group
+   [RFC2679] will be used to measure one-way end-to-end network delay.
+
+   The need for such a metric is derived from the fact that the path
+   from a source to a destination may be different from the path from
+   the destination back to the source ("asymmetric paths"), such that
+   different sequences of routers are used for the forward and reverse
+   paths.  Therefore, round-trip measurements actually measure the
+   performance of two distinct paths together.
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 18]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   Measuring each path independently highlights the performance
+   difference between the two paths that may traverse different Internet
+   service providers, and even radically different types of networks
+   (for example, research versus commodity networks, or ATM
+   (Asynchronous Transfer Mode) versus Packet-over-SONET (Synchronous
+   Optical) transport networks).
+
+   Even when the two paths are symmetric, they may have radically
+   different performance characteristics due to asymmetric queuing.
+   Performance of an application may depend mostly on the performance in
+   one direction.  For example, a file transfer using TCP may depend
+   more on the performance in the direction that data flows than on the
+   direction in which acknowledgements travel.
+
+   In QoS-enabled networks, provisioning in one direction may be
+   radically different from provisioning in the reverse direction, and
+   thus the QoS guarantees differ.  Measuring the paths independently
+   allows the verification of both guarantees.
+
+   RAQMON SHOULD NOT derive One-Way End-to-End Network Delay by assuming
+   Internet paths are symmetric (i.e., dividing Round-Trip Delay by
+   two).
+
+   Note that the packets used for measurement in some methodologies may
+   be of a different type from those used for media (e.g., ICMP instead
+   of RTP) and hence may differ in terms of route and queue priority.
+   This may result in measured delays being different from those
+   experienced on the media path.  Conformance for this metric requires
+   that actual application packets, or packets of the same application
+   type, be used.
+
+   This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the
+   capability of determining its value and if the parameter is relevant
+   for the application.
+
+5.13.  Application Delay
+
+   Various Network Delay versions, as outlined in Sections 5.11 and
+   5.12, do not include delays associated with buffering, play-out,
+   packet-sequencing, coding/decoding, etc., in the end-devices.  The
+   Application Delay metric defined in this section is targeted to
+   capture all such delay parameters, providing a total application
+   endpoint delay.
+
+   Application delay can be expressed as the time delay introduced
+   between the network interface and the application-level presentation.
+   Since it is difficult to envision usage of all sorts of applications,
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 19]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   the following guidance is provided to the implementers to measure the
+   application delay:
+
+   - The sending end contribution to application delay is defined as the
+     sum of sample sequencing, accumulation, and encoding delay.
+
+   - The receiving end contribution to application delay is calculated
+     as the sum of delays associated with buffering, play-out, packet-
+     sequencing, and decoding associated with the receiving direction,
+     if relevant.
+
+   The endpoint application delay is defined as the sum of the receiving
+   and sending contributions to delay measured or estimated within the
+   endpoint that is generating this report.
+
+   It is easy to recognize that applications running on an IP device can
+   experience same network delay but have different application-
+   associated delay values.  As such, the user experience associated
+   with specific applications may vary while the network delay value
+   remains same for both the applications.
+
+   Having network delay and application delay measurements available, a
+   management application can represent the delay experienced by the end
+   user at the application level as a sum of network delay and the
+   application delays reported from the endpoints.  However, the
+   specification of such a management application is outside the scope
+   of the RAQMON specification.
+
+   This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the
+   capability of determining its value and if the parameter is relevant
+   for the application.
+
+5.14.  Inter-Arrival Jitter
+
+   The Inter-Arrival Jitter metric provides a short-term measure of
+   network congestion [RFC3550].  The jitter measure may indicate
+   congestion before it leads to packet loss.  The inter-arrival jitter
+   field is only a snapshot of the jitter at the time when a RAQMON PDU
+   is generated and is not intended to be taken quantitatively as
+   indicated in [RFC3550].  Rather, it is intended for comparison of
+   inter-arrival jitter from one receiver over time.  Such inter-arrival
+   jitter information is extremely useful to understand the behavior of
+   certain applications such as Voice over IP, Video over IP, etc.
+   Inter-arrival jitter information is also used in the sizing of play-
+   out buffers for applications requiring the regular delivery of
+   packets (for example, voice or video play-out).
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 20]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   In [RFC3550], the selection function is implicitly applied to
+   consecutive packet pairs, and the "jitter estimate" is computed by
+   applying an exponential filter with parameter 1/16 to generate the
+   estimate (i.e., j_new = 15/16* j_old + 1/16*j_new).
+
+   This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the
+   capability of determining its value and if the parameter is relevant
+   for the application.
+
+5.15.  IP Packet Delay Variation
+
+   [RFC3393] provides guidance to several absolute jitter parameters.
+   RAQMON uses the [RFC3393] definition of the IP Packet Delay Variation
+   (ipdv) for packets inside a stream of packets.  The IP Delay
+   Variation metric is used to determine the dynamics of queues within a
+   network (or router) where the changes in delay variation can be
+   linked to changes in the queue length processes at a given link or a
+   combination of links.  Such a parameter provides visibility within an
+   IP Network and a better understanding of application-level
+   performance problems as it relates to IP Network performance.
+
+   This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the
+   capability of determining its value and if the parameter is relevant
+   for the application.
+
+5.16.  Total Number of Application Packets Received
+
+   This metric reports the number of application payload packets
+   received by the RDS as part of this session since the last RAQMON PDU
+   was sent up until the time this RAQMON PDU was generated.
+
+   This parameter represents a very simple incremental counter that
+   counts the number of "application" packets that an RDS has received.
+   Application packets MAY include signaling packets.  Since this count
+   is a snapshot in time, depending on application type, it also varies
+   based on the application states, e.g., an RDS within an application
+   session will report the aggregated number of application packets that
+   were sent out during signaling setup, media packets received, session
+   termination, etc.
+
+   For example, during Voice over IP or Video over IP sessions setup,
+   this counter represents the number of signaling-session-related
+   packets that have been received that will be derived from the
+   relevant application signaling protocol stack such as SIP or H.323,
+   SIMPLE, and various other signaling protocols used by the application
+   to establish the communication session.
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 21]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   However, during a period when media is established between the
+   communicating entities, this counter will be indicative of the number
+   of RTP Frames that have been sent out to the communicating party
+   since last PDU was sent out.  The methodology described within RTCP
+   SR/RR reports [RFC3550] to count RTP frames will be applied wherever
+   applications use RTP.  This being a cumulative counter, applications
+   need to take into consideration the possibility of the counter
+   overflowing and restarting counting from zero.
+
+   Support for RTP can be determined by the support of the RTP MIB
+   [RFC2959] in the hosts running the applications or by inclusion of
+   the string 'RTP' at the beginning of the Application Name (Section
+   5.32).
+
+   This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the
+   capability of determining its value and if the parameter is relevant
+   for the application.
+
+5.17.  Total Number of Application Packets Sent
+
+   This metric reports the number of signaling and payload packets sent
+   by the RDS as part of this session since the last RAQMON PDU was sent
+   until the time this RAQMON PDU was generated.  Applications packets
+   MAY include signaling packets.  Similar to the total number of
+   application packets received parameter in Section 5.16, this count is
+   a snapshot in time.  Depending on the application type, the counter
+   also varies based on various application states, including packet
+   counts for signaling setup, media establishment, session termination
+   states, and so on.  This being a cumulative counter, applications
+   need to take into consideration the possibility of the counter
+   overflowing and restarting counting from zero.
+
+   This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the
+   capability of determining its value and if the parameter is relevant
+   for the application.
+
+5.18.  Total Number of Application Octets Received
+
+   This metric reports the total number of signaling and payload octets
+   received in packets by the RDS as part of this session since the last
+   RAQMON PDU was sent, up until the time this RAQMON packet was
+   generated.  Applications octets MAY include signaling octets.  The
+   methodology described by [RFC3550] will be applied wherever
+   applications use RTP.  This being a cumulative counter, applications
+   need to take into consideration the possibility of the counter
+   overflowing and restarting counting from zero.
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 22]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   Support for RTP can be determined by the support of the RTP MIB
+   [RFC2959] in the hosts running the applications or by inclusion of
+   the string 'RTP' at the beginning of the Application Name (Section
+   5.32).
+
+   This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the
+   capability of determining its value and if the parameter is relevant
+   for the application.
+
+5.19.  Total Number of Application Octets Sent
+
+   This metric reports the total number of signaling and payload octets
+   received in packets by the RDS as part of this session since the last
+   RAQMON PDU was sent, up until the time this RAQMON packet was
+   generated.  This is similar to the Total Number of Application Octets
+   Received metric.  Applications octets MAY include signaling octets.
+   The methodology described by [RFC3550] will be applied wherever
+   applications use RTP.  This being a cumulative counter, applications
+   need to take into consideration the possibility of the counter
+   overflowing and restarting counting from zero.
+
+   Support for RTP can be determined by the support of the RTP MIB
+   [RFC2959] in the hosts running the applications or by inclusion of
+   the string 'RTP' at the beginning of the Application Name (Section
+   5.32).
+
+   This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the
+   capability of determining its value and if the parameter is relevant
+   for the application.
+
+5.20.  Cumulative Packet Loss
+
+   The cumulative packet loss metric indicates the loss associated with
+   the network as well as local device losses over time.  This parameter
+   is counted as the total number of application packets from the source
+   that have been lost since the beginning of the session.  This number
+   is defined to be the number of packets expected less the number of
+   packets actually received, where the number of packets received
+   includes the count of packets that are late or duplicates.  If a
+   packet is discarded due to late arrival, then it MUST be counted as
+   either lost or discarded but MUST NOT be counted as both.
+
+   Packet loss by the underlying transport network SHALL be measured
+   using the methodologies described in [RFC3550] for RTP traffic and
+   [RFC2680] for other IP traffic.  The number of packets expected is
+   defined to be the extended last sequence number received, as defined
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 23]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   next, less the initial sequence number received.  For RTP traffic,
+   this may be calculated using techniques such as those shown in
+   Appendix A.3 of [RFC3550].
+
+   Packet loss by the underlying transport network SHALL be measured
+   using the methodologies described in [RFC3550] for RTP traffic and
+   [RFC2680] for other IP traffic.  The number of packets expected is
+   defined to be the extended last sequence number received, as defined
+   next, less the initial sequence number received.  For RTP traffic,
+   this may be calculated using techniques such as those shown in
+   Appendix A.3 of [RFC3550].
+
+   Support for RTP can be determined by the support of the RTP MIB
+   [RFC2959] in the hosts running the applications or by inclusion of
+   the string 'RTP' at the beginning of the Application Name (Section
+   5.32).
+
+   This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the
+   capability of determining its value and if the parameter is relevant
+   for the application.
+
+5.21.  Packet Loss in Fraction
+
+   The Packet Loss in Fraction metric represents the packet loss as
+   defined above, but expressed as a fraction of the total traffic over
+   time.
+
+   This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the
+   capability of determining its value and if the parameter is relevant
+   for the application.
+
+5.22.  Cumulative Application Packet Discards
+
+   The RAQMON Framework allows applications to distinguish between
+   packets lost by the network and those discarded due to jitter and
+   other application-level errors.  Though packet loss and discards have
+   an equal effect on the quality of the application, having separate
+   counts for packet loss and discards helps identify the source of
+   quality degradation.
+
+   The packet discard metric indicates packets discarded locally by the
+   device over time.  Local device-level packet discard is captured as
+   the total number of application-level packets from the source that
+   have been discarded since the beginning of reception, due to late or
+   early arrival, under-run or overflow at the receiving jitter buffer,
+   or any other application-specific reasons.
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 24]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   If the RDS cannot tell the difference between discards and lost
+   packets, then it MUST report only lost packets and MUST NOT report
+   discards.
+
+   This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the
+   capability of determining its value and if the parameter is relevant
+   for the application.
+
+5.23.  Packet Discards in Fraction
+
+   The packet discards in fraction metric represents packets from the
+   source that have been discarded since the beginning of the reception
+   but expressed as a fraction of the total traffic over time.
+
+   This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the
+   capability of determining its value and if the parameter is relevant
+   for the application.
+
+5.24.  Source Payload Type
+
+   The source payload type reports payload formats (e.g., media
+   encoding) as sent by the data source, e.g., ITU G.711, ITU G.729B,
+   H.263, MPEG-2, ASCII, etc.  This memo follows the definition of
+   Payload Type (PT) in [RFC3551].  For example, to indicate that the
+   source payload type used for a session is PCMA (pulse-code modulation
+   with A-law scaling), the value of the source payload field for the
+   respective session will be 8.
+
+   The source payload type value is expected to remain constant for the
+   duration of a session, with the exception of events like dynamic
+   codec changes.  RDSs SHOULD avoid sending these parameters within
+   RAQMON reports more often than necessary (e.g., at dynamic codec
+   changes) to ensure an efficient usage of network resources.
+
+   If dynamic types (values 96 to 127, according to [RFC3551]) are being
+   used to identify the source payload type, a RAQMON extension
+   parameter MAY be defined to indicate the MIME subtypes.  In the case
+   where the RDS does send reports noting dynamic codec changes, there
+   may be instances where this extension parameter is used only before
+   or after the codec change, as the source payload may shift between
+   the dynamic and static types.
+
+5.25.  Receiver Payload Type
+
+   The receiver payload type reports payload formats (e.g., media
+   encodings) as sent by the other communicating party back to the
+   source, e.g., ITU G.711, ITU G.729B, H.263, MPEG-2, ASCII, etc.  This
+   document follows the definition of payload type (PT) in [RFC3551].
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 25]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   For example, to indicate that the destination payload type used for a
+   session is PCMA, the destination payload type field for the
+   respective session will be 8.
+
+   The destination payload type value is expected to remain constant for
+   the duration of a session, with the exception of events like dynamic
+   codec changes.  RDSs SHOULD avoid sending these parameters within
+   RAQMON reports more often than necessary (e.g., at dynamic codec
+   changes) to ensure an efficient usage of network resources.
+
+   If dynamic types (values 96 to 127, according to [RFC3551]) are being
+   used to identify the destination payload type, a RAQMON extension
+   parameter MAY be defined to indicate the MIME subtypes.  In the case
+   where the RDS does send reports noting dynamic codec changes, there
+   may be instances where this extension parameter is used only before
+   or after the codec change, as the destination payload may shift
+   between the dynamic and static types.
+
+5.26.  Source Layer 2 Priority
+
+   Many devices use Layer 2 technologies to prioritize certain types of
+   traffic in the Local Area Network environment.  For example, the 1998
+   Edition of IEEE 802.1D [IEEE802.1D], "Media Access Control Bridges",
+   contains expedited traffic capabilities to support transmission of
+   time-critical information.  Many devices use that standard to mark
+   Ethernet frames according to IEEE P802.1p standard.  Details on these
+   can be found in [IEEE802.1D], which incorporates P802.1p.  The Source
+   Layer 2 Priority RAQMON field indicates what Layer 2 values were used
+   by the host running the RDS to prioritize these packets in the Local
+   Area Network environment.
+
+   The Source Layer 2 Priority value is expected to remain constant for
+   the duration of a session.  Hosts running the RDSs SHOULD avoid
+   sending these parameters within RAQMON reports too often in order to
+   ensure an efficient usage of network resources.
+
+5.27.  Source TOS/DSCP Value
+
+   Various Layer 3 technologies are in place to prioritize traffic in
+   the Internet.  For example, the traditional IP Precedence [RFC791]
+   and Type of Service (TOS) [RFC1812], or more recent technologies like
+   Differentiated Services [RFC2474] [RFC2475], use the TOS octet in
+   IPv4, whereas the traffic class octet is used to prioritize traffic
+   in IPv6.  Source Layer TOS/DCP RAQMON field reports the appropriate
+   Layer 3 values used by the Data Source to prioritize these packets.
+
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 26]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   The Source TOS/DSCP value is expected to remain constant for the
+   duration of a session.  Hosts running the RDSs SHOULD avoid sending
+   these parameters within RAQMON reports too often in order to ensure
+   an efficient usage of network resources.
+
+5.28.  Destination Layer 2 Priority
+
+   The Destination Layer 2 Priority reports the Layer 2 value used by
+   the communication receiver to prioritize packets while sending
+   traffic to the data source in the Local Area Networks environment.
+   Like Source Layer 2 Priority, Destination Layer 2 Priority could
+   indicate whether the destination has used Layer 2 technologies like
+   IEEE P802.1p for priority queuing.
+
+   The Destination Layer 2 Priority value is expected to remain constant
+   for the duration of a session.  Hosts running the RDSs SHOULD avoid
+   sending these parameters within RAQMON reports too often in order to
+   ensure an efficient usage of network resources.
+
+5.29.  Destination TOS/DSCP Value
+
+   The Destination TOS/DSCP RAQMON field reports the values used by the
+   Data Receiver to prioritize these packets received by the source.
+   Similar to Source Layer 3 Priority, Destination Layer 3 Priority
+   indicates whether the destination has used any Layer 3 technologies
+   like IP Precedence [RFC791] and Type of Service (TOS) [RFC1812], or
+   more recent technologies like Differentiated Service [RFC2474]
+   [RFC2475].
+
+   The Destination TOS/DSCP value is expected to remain constant for the
+   duration of a session.  Hosts running the RDSs SHOULD avoid sending
+   these parameters within RAQMON reports too often in order to ensure
+   an efficient usage of network resources.
+
+5.30.  CPU Utilization in Fraction
+
+   This parameter captures the CPU usage of the hosts running the RDSs
+   that may have very critical implications for QoS of an end-device.
+   It is computed as an average since the last reporting interval, and
+   corresponds to the percentage of that time that the CPU was busy.
+
+   In the case of multiple CPU hosts, the maximum utilization among the
+   different CPUs MUST be reported.
+
+   This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the
+   capability of determining its value and if the parameter is relevant
+   for the application.
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 27]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+5.31.  Memory Utilization in Fraction
+
+   This parameter captures the memory usage of the hosts running the
+   RDSs that may have very critical implications for QoS of an end-
+   device.  It is computed as an average since the last reporting
+   interval and corresponds to the average percentage of the total
+   memory space critical for the applications in use during that time
+   interval (e.g., primary CPU RAM, buffers).
+
+   In the case of multiple CPU hosts, the maximum memory utilization
+   among the different CPUs MUST be reported.
+
+   This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the
+   capability of determining its value and if the parameter is relevant
+   for the application.
+
+5.32.  Application Name/Version
+
+   The Application Name/Version parameter gives the name and,
+   optionally, the version of the application associated with that
+   session or sub-session, e.g., "XYZ VoIP Agent 1.2".  This information
+   may be useful for scenarios where the end-device is running multiple
+   applications with various priorities and could be very handy for
+   debugging purposes.
+
+   If the application is using RTP [RFC3550], the Application Name
+   SHOULD begin with the string 'RTP'.
+
+   This parameter MUST be sent in the first RAQMON PDU.
+
+6.  Report Aggregation and Statistical Data processing
+
+   Within the RAQMON Framework, RRCs are expected to have significantly
+   greater computational resources than RDSs.  Consequently, various
+   aggregation functions are performed by the RRCs, while RDSs are not
+   burdened by statistical data processing such as computation of
+   minima, maxima, averages, standard deviations, etc.
+
+   The RAQMON MIB provides minimal aggregation of the RAQMON parameters
+   defined above.  The RAQMON MIB is not designed to provide extensive
+   aggregation like the Application Performance Measurement (APM) MIB
+   [RFC3729] or the Transport Performance Metrics (TPM) MIB [RFC4150].
+   One should use APM and TPM MIBs to aggregate parameters based on
+   protocols (e.g., performance of HTTP, RTP) or applications (e.g.,
+   performance of VoIP, Video Applications).
+
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 28]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   In the RAQMON MIB, aggregation can be performed only on specific
+   RAQMON metric parameters.  Aggregation always results in statistical
+   Mean/Min/Max values, according to these definitions:
+
+      Mean: Mean is defined as the statistical average of a metric over
+            the duration of a communication session.  For example, if an
+            RDS reported End-to-End delay metric N times within a
+            communication session, then the Mean End-to-End Delay can be
+            computed by summing of these N reported values, and then
+            dividing by N.
+
+      Min:  Min is defined as the statistical minimum of a metric over
+            the duration of a communication session.  For example, if
+            the end-to-end delay metric of an end-device within a
+            communication session is reported N times by the RDS, then
+            the Min end-to-end delay is the smallest of the N end-to-end
+            delay metric values reported.
+
+      Max:  Max is defined as the statistical maximum of a metric over
+            the duration of a communication session.  For example, if
+            the end-to-end delay metric of an end-device within a
+            communication session is reported N times by the RDS, then
+            the Max End-to-End Delay is the largest of the N End-to-End
+            Delay metric values reported.
+
+7.  Keeping Historical Data and Storage
+
+   It is evident from the document that the RAQMON MIB data need to be
+   managed to optimize storage space.  The large volume of data gathered
+   in a communication session could be optimized for storage space by
+   performing and storing only aggregated RAQMON metrics for history if
+   required.
+
+   Examples of how such storage space optimization can be performed
+   include:
+
+      1. Make data available through the MIB only at the end of a
+         communication session, i.e., upon receipt of a NULL PDU.  The
+         aggregated data could be made available using the RAQMON MIB as
+         Mean, Max, or Min entries and saved for historical purposes.
+
+      2. Use a time-based algorithm that aggregates data over a specific
+         period of time within a communication session, thus requiring
+         fewer entries, to reduce storage space requirements.  For
+         example, if an RDS sends data out every 10 seconds and the RRC
+         updates the RAQMON MIB once every minute, for every 6 data
+         points there would be one MIB entry.
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 29]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+      3. Periodically delete historical data in accordance with an
+         administrative policy.  An example of such a policy would be to
+         delete historical data older than 60 days.  The implementation
+         of such policies is left to the application developer's
+         discretion, and their use is an operational concern.
+
+8.  Security Considerations
+
+   Security considerations associated with the RAQMON Framework are
+   discussed below, and in greater detail in other RAQMON memos as is
+   appropriate.
+
+8.1.  The RAQMON Threat Model
+
+   The vulnerabilities associated with the RAQMON Framework are a
+   combination of those associated with the underlying layers up to the
+   transport layer, and of possible exploits of RAQMON payload.
+   Possible exploits of RAQMON payloads fall within these classes:
+
+      1. Unauthorized examination of sensitive information in the
+         payload in transit.
+
+      2. Unauthorized modification of payload contents in transit,
+         leading to:
+
+         a. Mis-identification of information from one RAQMON reporting
+            session as belonging to another destined to the same RRC;
+
+         b. Mismapping of RAQMON sessions;
+
+         c. Various forms of session-level denial-of-service (DoS)
+            attacks;
+
+         d. DoS through modification of RAQMON parameter values and
+            statistics;
+
+         e. Invalid timestamps, leading to false interpretation of the
+            monitored data, affecting call records information, and
+            making difficult to place monitoring events in their
+            appropriate temporal context.
+
+      3. Malformed payloads, permitting the exploitation of potential
+         implementation weaknesses to compromise an RRC.
+
+      4. Unauthorized disclosure of sensitive data carried by
+         application PDUs, leading to a breach of confidentiality.
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 30]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   Consequently, threats based on  unauthorized disclosure or
+   modification of payloads or headers will have to be assumed.
+
+8.2.  The RAQMON Security Requirements and Assumptions
+
+   In order to preserve integrity of the RAQMON PDU against these
+   threats, the RAQMON model must provide for cryptographically strong
+   security services.
+
+   Consequently, the RAQMON framework must be able to provide for the
+   following protections:
+
+      1. Authentication - the RRC should be able to verify that a RAQMON
+         PDU was in fact originated by the RDS that claims to have sent
+         it.
+
+      2. Privacy - Since RAQMON information includes identification of
+         the parties participating in a communication session, the
+         RAQMON framework should be able to provide for protection from
+         eavesdropping, to prevent an unauthorized third party from
+         gathering potentially sensitive information.  This can be
+         achieved by using various payload encryption technologies, such
+         as Data Encryption Standard (DES), 3-DES, Advanced Encryption
+         Standard (AES), etc.
+
+      3. Protection from DoS attacks directed at the RRC - RDSs send
+         RAQMON reports as a side effect of an external event (for
+         example, a phone call is being received).  An attacker can try
+         to overwhelm the RRC (or the network) by initiating a large
+         number of events (i.e., calls) for the purpose of swamping the
+         RRC with too many RAQMON PDUs.
+
+         To prevent DoS attacks against RRC, the RDS will send the first
+         report for a session only after the session has been in
+         progress for the five-second reporting interval.  Sessions
+         shorter than that should be stored in the RDS and will be
+         reported only after that interval has expired.
+
+8.3.  RAQMON Security Model
+
+   The RAQMON architecture permits the use of multiple transport
+   protocols.  Most of these support a secure mode of operation.  There
+   are advantages to relying on the security provided at the transport
+   protocol layer.
+
+      1. Transport-protocol-level security can generally protect the
+         payload with end-to-end authentication, confidentiality,
+         message integrity, and replay protection services.
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 31]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+      2. A good cryptographic security protocol always has an associated
+         key management protocol.  Use of transport protocol security
+         relies on its key management and does not require development
+         of another mechanism.
+
+      3. When transport protocol security is already enabled between the
+         RDS and RRC, additional encryption and message authentication
+         at the application level is avoided.
+
+   However, there are also shortcomings to be noted in relying on
+   transport protocol security.
+
+      1. When session-level isolation of the different RAQMON sessions
+         of an RDS-RRC pair is required, it will be necessary to open
+         separate transport protocol instances.  Such cases, however,
+         may be rare.
+
+      2. Since security services are not provided by the RAQMON
+         framework, the absence of transport or lower protocol security
+         implies the absence of RAQMON security.
+
+9.  Acknowledgements
+
+   The authors would like to thank Andy Bierman, Alan Clark, Mahalingam
+   Mani, Colin Perkins, Steve Waldbusser, Magnus Westerlund, and Itai
+   Zilbershtein for the precious advices and real contributions brought
+   to this document.  The authors would also like to extend special
+   thanks to Randy Presuhn, who reviewed this document for spelling and
+   formatting purposes, and who provided a deep review of the technical
+   content.  We also would like to thank Bert Wijnen for the permanent
+   coaching during the evolution of this document and the detailed
+   review of its final versions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 32]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+10.  Normative References
+
+   [RFC791]     Postel, J., "Internet Protocol", STD 5, RFC 791,
+                September 1981.
+
+   [RFC1812]    Baker, F., "Requirements for IP Version 4 Routers", RFC
+                1812, June 1995.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2474]    Nichols, K., Blake, S., Baker, F., and D. Black,
+                "Definition of the Differentiated Services Field (DS
+                Field) in the IPv4 and IPv6 Headers", RFC 2474, December
+                1998.
+
+   [RFC2475]    Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
+                and W. Weiss, "An Architecture for Differentiated
+                Service", RFC 2475, December 1998.
+
+   [RFC2679]    Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
+                Delay Metric for IPPM", RFC 2679, September 1999.
+
+   [RFC2680]    Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
+                Packet Loss Metric for IPPM", RFC 2680, September 1999.
+
+   [RFC2681]    Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-
+                trip Delay Metric for IPPM", RFC 2681, September 1999.
+
+   [RFC2819]    Waldbusser, S., "Remote Network Monitoring Management
+                Information Base", STD 59, RFC 2819, May 2000.
+
+   [RFC2959]    Baugher, M., Strahm, B., and I. Suconick, "Real-Time
+                Transport Protocol Management Information Base", RFC
+                2959, October 2000.
+
+   [RFC3393]    Demichelis, C. and P. Chimento, "IP Packet Delay
+                Variation Metric for IP Performance Metrics (IPPM)", RFC
+                3393, November 2002.
+
+   [RFC3416]    Presuhn, R., Ed., "Version 2 of the Protocol Operations
+                for the Simple Network Management Protocol (SNMP)", STD
+                62, RFC 3416, December 2002.
+
+   [RFC3550]    Schulzrinne, H., Casner, S., Frederick, R., and V.
+                Jacobson, "RTP: A Transport Protocol for Real-Time
+                Applications", STD 64, RFC 3550, July 2003.
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 33]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   [RFC3551]    Schulzrinne, H. and S. Casner, "RTP Profile for Audio
+                and Video Conferences with Minimal Control", STD 65, RFC
+                3551, July 2003.
+
+11.  Informative References
+
+   [RFC1034]    Mockapetris, P., "Domain names - concepts and
+                facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC1035]    Mockapetris, P., "Domain names - implementation and
+                specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1123]    Braden, R., "Requirements for Internet Hosts -
+                Application and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC1305]    Mills, D., "Network Time Protocol (Version 3)
+                Specification, Implementation and Analysis", RFC 1305,
+                March 1992.
+
+   [RFC1918]    Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
+                G., and E. Lear, "Address Allocation for Private
+                Internets", BCP 5, RFC 1918, February 1996.
+
+   [RFC2914]    Floyd, S., "Congestion Control Principles", BCP 41, RFC
+                2914, September 2000.
+
+   [RFC3235]    Senie, D., "Network Address Translator (NAT)-Friendly
+                Application Design Guidelines", RFC 3235, January 2002.
+
+   [RFC3611]    Friedman, T., Caceres, R., and A. Clark, "RTP Control
+                Protocol Extended Reports (RTCP XR)", RFC 3611, November
+                2003.
+
+   [RFC3729]    Waldbusser, S., "Application Performance Measurement
+                MIB", RFC 3729, March 2004.
+
+   [RFC4150]    Dietz, R. and R. Cole, "Transport Performance Metrics
+                MIB", RFC 4150, August 2005.
+
+   [RFC4711]    Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-
+                time Application Quality-of-Service Monitoring (RAQMON)
+                MIB", RFC 4711, October 2006.
+
+   [RFC4712]    Siddiqui, A., Romascanu, D., Golovinsky, E., Ramhman,
+                M., and Y. Kim, "Transport Mappings for Real-time
+                Application Quality-of-Service Monitoring (RAQMON)
+                Protocol Data Unit (PDU)", RFC 4712, October 2006.
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 34]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+   [IEEE802.1D] Information technology - Telecommunications and
+                information exchange between systems - Local and
+                metropolitan area networks - Common Specification a -
+                Media access control (MAC) bridges:15802-3:  1998
+                (ISO/IEC). Revision. This is a revision of ISO/IEC
+                10038: 1993, 802.1j-1992 and 802.6k-1992.  It
+                incorporates P802.11c, P802.1p and P802.12e [ANSI/IEEE
+                Std 802.1D, 1998 Edition]
+
+Authors' Addresses
+
+   Anwar A. Siddiqui
+   Avaya Labs
+   307 Middletown Lincroft Road
+   Lincroft, New Jersey 07738
+   USA
+
+   Phone: +1 732 852-3200
+   EMail: anwars@avaya.com
+
+
+   Dan Romascanu
+   Avaya
+   Atidim Technology Park, Building #3
+   Tel Aviv, 61131
+   Israel
+
+   Phone: +972-3-645-8414
+   EMail: dromasca@avaya.com
+
+
+   Eugene Golovinsky
+
+   EMail: gene@alertlogic.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 35]
+
+RFC 4710                    RAQMON Framework                October 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Siddiqui, et al.            Standards Track                    [Page 36]
+