Internet Draft                                            Anwar Siddiqui
draft-ietf-rmonmib-raqmon-pdu-09.txt                         Avaya Labs.
Category: Standards Track                                  Dan Romascanu
Expires July 2005                                              Avaya Inc
                                                         Mahfuzur Rahman
                                                               Panasonic
                                                       Eugene Golovinsky
                                                            BMC Software
                                                                Yong Kim
                                                                Broadcom
                                                          6 January 2005

    Transport Mappings for Real-time Application Quality of Service
              Monitoring (RAQMON) Protocol Data Unit (PDU)

                          Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   This memo specifies two transport mappings of the Real-time
   Application Quality of Service Monitoring (RAQMON) information model
   defined in [RAQMON-FRAMEWORK] using TCP as a native transport and the
   Simple Network Management Protocol (SNMP) to carry the RAQMON



RMON WG                     Expires July 2005                   [Page 1]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   information from a RAQMON Data Source (RDS) to a RAQMON Report
   Collector (RRC).


   Distribution of this memo is unlimited.

Table of Contents

   Status of this Memo..................................................1
   Abstract.............................................................1
   1 Introduction.......................................................3
   2 Transporting RAQMON Protocol Data Units............................3
   3 Congestion Safe RAQMON Operation..................................29
   4 Normative References..............................................29
   5 Informative References............................................30
   6 Intellectual Property.............................................32
   7 Acknowledgements..................................................32
   8 Appendix..........................................................32
   9 Security Considerations...........................................33
   10 Authors' Addresses...............................................35
   Full Copyright Statement............................................36






























RMON WG                     Expires July 2005                   [Page 2]


INTERNET DRAFT                 RAQMON PDU                   January 2005


1. Introduction

   The Real-Time Application QoS Monitoring (RAQMON) Framework as
   outlined by [RAQMON-FRAMEWORK] extends the Remote Monitoring family
   of protocols (RMON) by defining entities such as RAQMON Data Sources
   (RDS) and RAQMON Report Collectors (RRC) to perform various
   application monitoring in real time.  [RAQMON-FRAMEWORK] defines an
   information model in the format of a common protocol data unit (PDU)
   used between a RDS and RRC to report QoS statistics.  This memo
   contains a syntactical description of the RAQMON PDU structure.

   The following sections of this memo contain detailed specifications
   for the usage of TCP and SNMP to carry RAQMON information.

   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. Transporting RAQMON Protocol Data Units

   The RAQMON Protocol Data Unit (PDU) utilizes a common data format
   understood by the RDS and the RRC. 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.  As
   part of the specification, this memo also specifies the usage of TCP
   and SNMP as underlying transport protocols to carry RAQMON PDUs
   between RDSs and RRCs. While two transport protocol choices have been
   provided as options to chose from for RDS implementers, RRCs MUST
   implement both transport options defined by this document to ensure
   interoperability.

2.1 TCP as an RDS/RRC Network Transport Protocol

   A transport binding using TCP is included within the RAQMON
   specification to facilitate reporting from various types of embedded
   devices that run applications such as Voice over IP, Voice over Wi-
   Fi, Fax over IP, Video over IP, Instant Messaging (IM), E-mail,
   software download applications, e-business style transactions, web
   access from wired or wireless computing devices etc.  For many of
   these devices PDUs and a TCP-based transport fit the deployment
   needs.

   The RAQMON transport requirements for end-to-end congestion control
   and reliability are inherently built into TCP as a transport
   protocol.

   The following section details the RAQMON PDU specifications. Though
   transmitted as one Protocol Data Unit, a RAQMON PDU is functionally



RMON WG                     Expires July 2005                   [Page 3]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   divided into two different parts, namely the basic part and
   application extensions required for vendor specific extension
   [RAQMON-FRAMEWORK]. Both functional parts trail SMI Network
   Management Private Enterprise Codes currently maintained by IANA
   http://www.iana.org/assignments/enterprise-numbers.

   A RAQMON PDU in the current version is marked as PDU Type (PDT) = 1.
   The parameters carried by RAQMON PDUs as shown in figure 1 and their
   semantics are defined in section 5 of [RAQMON-FRAMEWORK].

   Vendors MUST use the Basic part of the PDU to report parameters pre-
   listed here in the specification for interoperability as opposed to
   using the application specific portion. Vendors MAY also use
   application specific extensios to convey application, vendor, or
   device specific parameters not included in the Basic part of the
   specification, and explicitly publish such data externally to attain
   extended interoperability.

2.1.1 The RAQMON PDU


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PDT = 1  |B|  T  |P|S|R|  RC   |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            DSRC                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  SMI Enterprise Code = 0      |Report Type = 0|     RC_N      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Data Source Address {DA}                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Receiver's Address (RA)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               NTP Timestamp, most significant word            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               NTP Timestamp, least significant word           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Length       |   Application Name (AN)  ...                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Length       |   Data Source Name (DN)  ...                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



RMON WG                     Expires July 2005                   [Page 4]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   |  Length       |    Receiver's Name (RN)  ...                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Length       |    Session State          ...                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Session Duration                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Round Trip End-to-End Network Delay              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              One Way End-to-End Network Delay                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Cumulative Packet Loss                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Cumulative Application Packet Discard            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Total # Application Packets sent                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Total # Application Packets received              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Total # Application Octets sent                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Total # Application Octets received               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Data Source Device Port Used  |  Receiver Device Port Used    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    S_Layer2   |   S_Layer3    |   S_Layer2    |   S_Layer3    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Source Payload |Receiver       | CPU           | Memory        |
   |Type           |Payload Type   | Utilization   | Utilization   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Session Setup Delay        |     Application Delay         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IP Packet Delay Variation     |   Inter arrival Jitter        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Padding                  | Packet Discrd |  Packet loss  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SMI Enterprise Code = "xxx"                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Report Type = "yyy"       | Length of Application Part    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               application/vendor specific extension           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...............                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...............                    |



RMON WG                     Expires July 2005                   [Page 5]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...............                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SMI Enterprise Code = "abc"                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Report Type = "zzz"       | Length of Application Part    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               application/vendor specific extension           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ...............                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1 - RAQMON Protocol Data Unit

2.1.2 The Basic Part of the RAQMON Protocol Data Unit

   A RAQMON PDU must contain the following basic part fields at all
   times:

   PDU type (PDT): 5 bits - This indicates the type of RAQMON PDU being
   sent. PDT = 1 is used for the current RAQMON PDU version.

   basic (B): 1 bit - While set to 1, the basic flag indicates that the
   PDU has basic part of the RAQMON PDU. A value of zero is considered
   to be valid and indicates a RAQMON NULL PDU.

   trailer (T) : 3 bits - Total number of Application Specific
   Extensions that trail the BASIC Part of RAQMON PDU. A value of zero
   is considered to be valid as it may constitute a RAQMON NULL PDU.

   padding (P): 1 bit - If the padding bit is set, the basic Part of the
   RAQMON PDU contains some additional padding octets at the end of the
   Basic Part of the PDU which are not part of the monitoring
   information. Padding may be needed in some cases as reporting is
   based on the intent of a RDS to report certain parameters. Also some
   parameters may be reported only once at the beginning of the
   reporting session e.g. Data Source Name, Receiver Name, Pay Load type
   etc. Actual padding at the end of the Basic part of the PDU, is
   either 0,8, 16 or 24 bits to make the basic part of the PDU multiple
   of 32 bits long.

   Source IP version Flag (S): 1 bit - While set to 1, the source IP
   version flag indicates that the Source IP address contained in the
   PDU is a IPv6 address.

   Receiver IP version Flag (R): 1 bit - While set to 1, the receiver IP
   version flag indicates that the receiver IP address contained in the
   PDU is a IPv6 address.



RMON WG                     Expires July 2005                   [Page 6]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   record count (RC): 4 bits - Total number of records contained in the
   Basic part of the PDU. A value of zero is considered to be valid but
   useless.

   length: 16 bits - The length of the Basic Part of the RAQMON PDU in
   32-bit words minus one which includes the header and any padding.

   DSRC: 32 bits - Data Source identifier represents a unique RAQMON
   reporting session descriptor that points to a specific reporting
   session between RDS and RRC. Uniqueness of DSRC is valid only within
   a reporting session. DSRC values should be randomly generated using
   vendor chosen algorithms for each communication session. It is not
   sufficient to obtain a DSRC simply by calling random() without
   carefully initializing the state.  One could use an algorithm like
   the one defined in Appendix A.6 in [RFC3550] to create a DSRC.
   Depending on the choice of algorithm, there is a finite probability
   that two DSRCS from two different RDSs may be same. To further reduce
   the probability that two RDSs pick the same DSRC for two different
   reporting session, it is recommended that an RRC use parameters like
   Data Source Address (DA), Data Source Name (DN), MAC Address in the
   PDU in conjunction with a DSRC value. It is not mandatory for RDSs to
   send parameters like Data Source Address (DA), Data Source Name (DN),
   MAC Address in every PDU sent to RRC, but sending these parameters
   occasionally will reduce the probability of DSRC collision
   drastically. However this will cause an additional overhead per PDU.

   A value of zero for basic (B) bit and trailer (T) bits set
   constitutes a RAQMON NULL PDU (i.e. nothing to report). RDSs MUST
   send a RAQMON NULL PDU to RRC to indicate end of RDS reporting
   session. All other parameters listed in the PDU described below are
   optionally used when RDSs have some new information to send to RRC.

   SMI Enterprise Code: 16 bits.  A value of SMI Enterprise Code = 0 is
   used to indicate RMON WG compliant Basic part of the RAQMON PDU
   format.



    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V |PDT = 1|B|  T  |P|I|  RC   |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            DSRC                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  SMI Enterprise Code = 0      |Report Type = 0|     RC_N      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |



RMON WG                     Expires July 2005                   [Page 7]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 2 - RAQMON Parameter Presence Flag in RAQMON PDU

   Report Type: 8 bits - These bits are reserved by the IETF RMON Work
   Group. A value of 0 within SMI Enterprise Code = 0 is used for this
   version of the PDU.

   The basic part of Each RAQMON PDU consists of Record Count Number
   (RC_N) and RAQMON Parameter Presence Flags (RPPF) to indicate the
   presence of appropriate RAQMON parameters within a record, as defined
   in table 1.

   RC_N: 8 bits - The Record Count number indicates a sub-session within
   a communication session. A value of zero is a valid record number.
   The maximum number of records that can be described in one RAQMON
   Packet is 256.

   RAQMON Parameter Presence Flags (RPPF): 32 bits

   Each of these flags while set represent that this RAQMON PDU contains
   corresponding parameters as specified in table 1.


      Sequence Number             Presence/Absence of corresponding
                                  Parameter within this RAQMON PDU

             0                    Data Source Address (DA)
             1                    Receiver Address (RA)
             2                    NTP Timestamp
             3                    Application Name
             4                    Data Source Name (DN)
             5                    Receiver Name (RN)
             6                    Session Setup Status
             7                    Session Duration
             8                    Round Trip End-to-End Network Delay (RTT)
             9                    One Way End-to-End Network Delay (OWD)
             0                    Cumulative Packets Loss
             1                    Cumulative Packets Discards
             2                    Total number of Application Packets sent
             3                    Total number of Application Packets received
             4                    Total number of Application Octets sent
             5                    Total number of Application Octets received
             6                    Data Source Device Port Used
             7                    Receiver Device Port Used
             8                    Source Layer 2 Priority
             9                    Source Layer 3 Priority



RMON WG                     Expires July 2005                   [Page 8]


INTERNET DRAFT                 RAQMON PDU                   January 2005


             0                    Destination Layer 2 Priority
             1                    Destination Layer 3 Priority
             2                    Source Payload Type
             3                    Receiver Payload Type
             4                    CPU Utilization
             5                    Memory Utilization
             6                    Session Setup Delay
             7                    Application Delay
             8                    IP Packet Delay Variation
             9                    Inter arrival Jitter
             0                    Packet loss (in fraction)
             1                    Packet Discard (in fraction)


   Table 1: RAQMON Parameters and corresponding RPPF

   Data Source Address (DA): 32 bits or 160 bits in binary
   representation - This metrics is defined in section 5.1 of [RAQMON-
   FRAMEWORK].  IP version 6 addresses are incorporated in Data Source
   Address by setting the source IP version flag (S bit) of the RAQMON
   PDU header to 1.

   Receiver Address (RA): 32 bits or 160 bits - This metrics is defined
   in section 5.2 of [RAQMON-FRAMEWORK]. Follows exact same syntax as
   Data Source Address but used to indicate a Receiver's Address. IP
   version 6 addresses are incorporated in Receiver Address by setting
   the receiver IP version flag (R bit) of the RAQMON PDU header to 1.


   Data Source Name (DN): - This metric is defined in section 5.3 of
   [RAQMON-FRAMEWORK].  The Data Source Name field starts with an 8-bit
   octet count describing the length of the text followed by the text
   itself. Note that the text can be no longer than 255 octets.  The
   text is encoded according to the UTF-2 encoding specified in Annex F
   of ISO standard 10646 [ISO10646],[UNICODE]. This encoding is also
   known as UTF-8 or UTF-FSS.  Applications SHOULD instruct RDSs to send
   out the Data Source Name infrequently to ensure efficient usage of
   network resources as this parameter is expected to remain constant
   for the duration of the reporting session.

   Receiver Name (RN): - This metric is defined in section 5.4 of
   [RAQMON-FRAMEWORK].  Like Data Source Name, the Receiver Name field
   starts with an 8-bit octet count describing the length of the text
   followed by the text itself. The Receiver Name is a multiple of 32
   bits and follows the same padding rules as applied to the Data Source
   Name. Since the Receiver Name is expected to remain constant during
   entire reporting sessions, this information SHOULD be sent out
   occasionally over random time intervals to maximize success of



RMON WG                     Expires July 2005                   [Page 9]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   reaching a RRC and also conserve network bandwidth.

   Data Source Device Port Used: 16 bits - This metric is defined in
   section 5.5 of [RAQMON-FRAMEWORK]and describes the port Number used
   by the Data Source as used by the application in RC_N session while
   this RAQMON PDU was generated.

   Receiver Device Port Used: 16 bits - This metric is defined in
   section 5.6 of [RAQMON-FRAMEWORK], and describes the receiver port
   used by the application to communicate to the receiver. It follows
   same syntax as Source Device Port Used.

   Session Setup Date/Time (NTP timestamp): 64 bits - This metric is
   defined in section 5.7 of [RAQMON-FRAMEWORK] represented using the
   timestamp format of the Network Time Protocol (NTP), which is in
   seconds [RFC 1305]. The full resolution NTP timestamp is a 64-bit
   unsigned fixed-point number with the integer part in the first 32
   bits and the fractional part in the last 32 bits.

   A Data Source that does not support NTP SHOULD set the appropriate
   RAQMON flag to 0 to avoid wasting 64 bits in the PDU. Since the NTP
   time stamp is intended to provide the setup Date/Time of a session,
   it is RECOMMENDED that the NTP Timestamp be used only in the first
   RAQMON packet, to use network resources efficiently.

   Session Setup Delay: 16 bits - The Session Setup Delay metric is
   defined in section 5.8 of [RAQMON-FRAMEWORK] and expressed in
   milliseconds.

   Session Duration: 32 bits - The Session Setup Duration metric is
   defined in section 5.9 of [RAQMON-FRAMEWORK]. Session Duration is an
   unsigned integer expressed in seconds.

   Session Setup Status: - The Session Setup Status is defined in
   section 5.10 of [RAQMON-FRAMEWORK]. This field starts with an 8-bit
   length field followed by the text itself. Session Setup Status is a
   multiple of 32 bits.

   Round Trip End-to-End Network Delay: 32 bits - The Round Trip End-to-
   End Network Delay is defined in section 5.11 of [RAQMON-FRAMEWORK].
   This field represents the Round Trip End-to-End Delay of session
   RC_N, which is an unsigned integer, expressed in milliseconds.

   One Way End-to-End Network Delay: 32 bits - The One Way End-to-End
   Network Delay is defined in section 5.12 of [RAQMON-FRAMEWORK]. This
   field represents the One Way End-to-End Delay of sub-session RC_N,
   which is an unsigned integer, expressed in milliseconds.




RMON WG                     Expires July 2005                  [Page 10]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   Application Delay: 16 bits - The Application Delay is defined in
   section 5.13 of [RAQMON-FRAMEWORK] and is represented as an unsigned
   integer expressed in milliseconds

   Inter-Arrival Jitter: 16 bits - The Inter-Arrival Jitter is defined
   in section 5.14 of [RAQMON-FRAMEWORK] and is represented as an
   unsigned integer expressed in milliseconds.

   IP Packet Delay Variation: 16 bits - The IP Packet Delay Variation is
   defined in section 5.15 of [RAQMON-FRAMEWORK] and is represented as
   an unsigned integer expressed in milliseconds.

   Total number of Application Packets received: 32 bits - This
   parameter is defined in section 5.16 of [RAQMON-FRAMEWORK] and is
   represented as an unsigned integer, representing the total number of
   packets transmitted within sub-session RC_N by the receiver.

   Total number of Application Packets sent: 32 bits - This parameter is
   defined in section 5.17 of [RAQMON-FRAMEWORK] as an unsigned integer,
   representing the total number of packets transmitted within sub-
   session RC_N by the sender.

   Total number of Application Octets received: 32 bits - This parameter
   is defined in section 5.18 of [RAQMON-FRAMEWORK] as an unsigned
   integer representing the total number of payload octets (i.e., not
   including header or padding) transmitted in packets by the receiver
   within sub-session RC_N.

   Total number of Application Octets sent: 32 bits - This parameter is
   defined in section 5.19 of [RAQMON-FRAMEWORK] as an unsigned integer,
   representing the total number of payload octets (i.e., not including
   header or padding) transmitted in packets by the sender within sub-
   session RC_N.

   Cumulative Application Packet Loss: 32 bits - This parameter is
   defined in section 5.20 of [RAQMON-FRAMEWORK] as an unsigned integer,
   representing the total number of packets from sub-session RC_N that
   have been lost while this RAQMON PDU was generated.

   Packet Loss in Fraction: 8 bits - This parameter is defined in
   section 5.21 of [RAQMON-FRAMEWORK] expressed as a fixed-point number,
   with the binary point at the left edge of the field. The metric is
   defined to be the number of packets lost divided by the number of
   packets expected. The value is calculated by dividing the total
   number of packets lost (after the effects of applying any error
   protection such as FEC) by the total number of packets expected,
   multiplying the result of the division by 256, limiting the maximum
   value to 255 (to avoid overflow), and taking the integer part.



RMON WG                     Expires July 2005                  [Page 11]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   Cumulative Application Discards: 32 bits - This parameter is defined
   in section 5.22 of [RAQMON-FRAMEWORK] as an unsigned integer
   representing the total number of packets from sub-session RC_N that
   have been discarded while this RAQMON PDU was generated.

   Packet Discard in Fraction: 8 bits - This parameter is defined in
   section 5.23 of [RAQMON-FRAMEWORK] expressed as a fixed point number
   with the binary point at the left edge of the field. (That is
   equivalent to taking the integer part after multiplying the discard
   fraction by 256.)  This metric is defined to be the number of packets
   discarded divided by the total number of packets.

   Source Payload Type: 8 bit - This parameter is defined in section
   5.24 of [RAQMON-FRAMEWORK] as an 8-bit field. It specifies the
   payload type of the data source of the communication sub-session RC_N
   as defined in [RFC 3550].

   Receiver Payload Type: 8 bit - This parameter is defined in section
   5.25 of [RAQMON-FRAMEWORK] as an 8-bit field. It specifies the
   receiver payload type of the communication sub-session RC_N.

   S_Layer2: 8 bits - This parameter defined in section 5.26 of [RAQMON-
   FRAMEWORK] is a 8-bit field associated to source's IEEE 802.1D
   priority tagging of traffic in the communication sub-session RC_N.
   Since IEEE 802.1 priority tags are 3 bits-long, the first 3 bits of
   this parameter represent the IEEE 802.1 tag value and the last 5 bits
   are padded to 0.

   S_Layer3: 8 bits - This parameter defined in section 5.27 of [RAQMON-
   FRAMEWORK] is a 8-bit field which represents the layer 3 QoS marking
   used to send packets to the receiver by this data source during sub-
   session RC_N.

   D_Layer2: 8 bits - This parameter defined in section 5.28 of [RAQMON-
   FRAMEWORK] is a 8-bit field which represents layer 2 IEEE 802.1D
   priority tags used by the receiver to send packets to the data source
   during sub-session RC_N session if the Data Source can learn such
   information. Since IEEE 802.1 priority tags are 3 bits-long, the
   first 3 bits of this parameter represent the  IEEE 802.1 priority tag
   value and the last 5 bits are padded to 0.

   D_Layer3: 8 bits - This parameter defined in section 5.29 of [RAQMON-
   FRAMEWORK] is a 8-bit field which represents the layer 3 QoS marking
   used by the receiver to send packets to the data source during sub-
   session RC_N, if the Data Source can learn such information.

   CPU Utilization: 8 bits - This parameter defined in section 5.30 of
   [RAQMON-FRAMEWORK] represents the percentage of CPU used during



RMON WG                     Expires July 2005                  [Page 12]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   session RC_N up until the time this RAQMON PDU was generated. The CPU
   Utilization is expressed in percents in the range 0 to 100. The value
   should indicate not only CPU utilization associated to a session RC_N
   but also actual CPU Utilization, to indicate a snapshot of the end
   device CPU utilization while session RC_N in progress.

   Memory Utilization: 8 bits - This parameter defined in section 5.31
   of [RAQMON-FRAMEWORK] represents the percentage of total memory used
   during session RC_N up until the time this RAQMON PDU was generated.
   The memory utilization is expressed in percents 0 to 100. The Memory
   Utilization value should indicate not only the memory utilization
   associated to a session RC_N but the total memory utilization, to
   indicate a snapshot of end device memory utilization while session
   RC_N in progress.

   Application Name: - This parameter is defined in section 5.32 of
   [RAQMON-FRAMEWORK].  The Application Name field starts with an 8-bit
   octet count describing the length of the text followed the text
   itself.  Application Name field is multiple of 32 bits.

   padding:  0, 8, 16 or 24 bits - If the padding bit (P) is set , then
   this field may be present. The actual padding at the end of the Basic
   part of the PDU is 0,8, 16 or 24 bits to make the basic part of the
   PDU multiple of 32 bits long.

2.1.3 APP Part of RAQMON Protocol Data Unit

   The APP part of the RAQMON PDU is intended for experimental use as
   new applications and new features are developed, without requiring a
   PDU type value registration.

   Vendors may design and publish application specific extensions. Any
   RAQMON compliant RRC MUST be able to recognize vendors SMI Enterprise
   Code and Report Type fields, and MUST recognize the presence of
   application specific extensions that trail behind these fileds. There
   is no need for the RRC to understand the semantics of the Enterprise
   specific parts of the PDU.

   SMI Enterprise Code: 32 bits - Vendors and Application developers
   should fill in appropriate SMI Enterprise IDs available at
   http://www.iana.org/assignments/enterprise-numbers. A Non-Zero SMI
   Enterprise Code indicates a vendor or application specific extension.

   RAQMON PDUs are capable of carrying multiple Application Parts within
   a PDU.

   Report Type: 16 bits - Vendors and Application developers should fill
   in appropriate Report type within a specified SMI Enterprise Code. It



RMON WG                     Expires July 2005                  [Page 13]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   is recommended that vendors publish application specific extensions
   and maintain such report types for better interoperability.

   Length of the Application Part: 16 bits - The length of the
   Application Part of the RAQMON PDU in 32-bit words minus one, which
   includes the header of the Application Part.

   application-dependent data: variable length - Application/vendor-
   dependent data is defined by the application developers. It is
   interpreted by the vendor specific application and not by the RRC
   itself. It must be a multiple of 32 bits long.



2.1.4 Byte Order, Alignment, and Time Format of RAQMON PDUs

   All integer fields are carried in network byte order, that is, most
   significant byte (octet) first. This byte order is commonly known as
   big-endian. The transmission order is described in detail in
   [RFC791]. Unless otherwise noted, numeric constants are in decimal
   (base 10).

   All header data is aligned to its natural length, i.e., 16-bit fields
   are aligned on even offsets, 32-bit fields are aligned at offsets
   divisible by four, etc. Octets designated as padding have the value
   zero.

2.1.5  IANA Considerations

   Applications using RAQMON Framework requires a single fixed port.
   Port numbers 7XXX have been registered with IANA for use as the
   default port for RAQMON PDUs over TCP. Hosts that run multiple
   applications may use this port as an indication to have used RAQMON
   or provision a separate TCP port as part of provisioning RAQMON RDS
   and RAQMON Collector.

   [editor note - 7XXX will be completely specified at RFC release,
   after IANA allocates the number, and this note will be removed]

   The particular port number was chosen to lie in the range above 5000
   to accommodate port number allocation practice within the Unix
   operating system, where privileged processes can only use port
   numbers below 1024 and port numbers between 1024 and 5000 are
   automatically assigned by the operating systems.


2.2 SNMP Notifications as an RDS/RRC Network Transport Protocol




RMON WG                     Expires July 2005                  [Page 14]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   It was an inherent objective of the RAQMON Framework to re-use
   existing application level transport protocols to maximize the usage
   of existing installations as well as to avoid transport protocol
   level complexities in the design process. Choice of SNMP as a means
   to transport RAQMON PDU was motivated by that intent.

   If SNMP is chosen as a mechanism to transport RAQMON PDUs, the
   following specification applies to RAQMON related usage of SNMP:

      +  RDSs implement the capability of embedding RAQMON parameters in
         SNMP Notifications, re-using well known SNMP mechanisms to
         report RAQMON Statistics.  The RAQMON RDS MIB module as
         specified in 2.1.1 MUST be used in order to map the RAQMON PDUs
         onto the SNMP Notifications transport.

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  For a detailed overview
   of the documents that describe the current Internet-Standard
   Management Framework, please refer to section 7 of RFC 3410
   [RFC3410].

      +  Since RDSs are not computationally rich and to keep the RDS
         realization as lightweight as possible, RDSs MAY fail to
         respond to SNMP requests like GET, SET, etc., with the
         exception of the GET and SET commands required to implement the
         User-Based Security Model (USM) defined by [RFC 3414].

      +  In order to meet congestion safety requirements, SNMP INFORM
         PDUs SHOULD be used. In case INFORM PDUs are used, RDSs MUST
         process the SNMP INFORM responses from RRCs, and MAY serialize
         the PDU transmission rate, i.e. limit the number of PDUS sent
         in a specific time interval.

      +  Standard UDP port 162 SHOULD be used for SNMP Notifications.

2.2.1 Encoding RAQMON PDUs using the RAQMON RDS MIB module

   The RAQMON RDS MIB module is used to map RAQMON PDUs onto SNMP
   Notifications for transport purposes.  The MIB modules defines the
   objects needed for mapping the Basic part of RAQMON PDU defined in
   [RAQMON-FRAMEWOK] as well as the Notifications themselves.  In order
   to incorporate any application-specific extensions in the Application
   (APP) part of RAQMON PDU as defined in [RAQMON-FRAMEWOK], additional
   variable bindings MAY be included in RAQMON notifications as
   described in the MIB module.



RMON WG                     Expires July 2005                  [Page 15]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   This section specifies a MIB module that is compliant to the SMIv2,
   which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579
   [RFC2579] and STD 58, RFC 2580 [RFC2580].

      RAQMON-RDS-MIB DEFINITIONS ::= BEGIN

      IMPORTS
          MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
          Counter32, Integer32, Unsigned32
              FROM SNMPv2-SMI

          DateAndTime
              FROM SNMPv2-TC

          rmon
              FROM RMON-MIB

          SnmpAdminString
              FROM SNMP-FRAMEWORK-MIB

          InetAddressType, InetAddress
              FROM INET-ADDRESS-MIB

          Dscp
              FROM DIFFSERV-DSCP-TC

          MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
              FROM SNMPv2-CONF;

      raqmonDsMIB MODULE-IDENTITY
          LAST-UPDATED "200501060000Z"      -- January 6, 2005
          ORGANIZATION "RMON Working Group"
          CONTACT-INFO
              "WG EMail: rmonmib@ietf.org
               Subscribe: rmonmib-request@ietf.org

               MIB Editor:
               Eugene Golovinsky
               Postal: BMC Software, Inc.
                       2101 CityWest Boulevard,
                       Houston, TX, 77094
                       USA
               Tel:    +713-918-1816
               Email:  egolovin@bmc.com
              "
          DESCRIPTION
              "This is the RAQMON Data Source notification MIB Module.  It
               provides a mapping of RAQMON PDUs to SNMP Notifications.



RMON WG                     Expires July 2005                  [Page 16]


INTERNET DRAFT                 RAQMON PDU                   January 2005


               Ds stands for data source.

               Note that all of the object types defined in this module are
               accessible-for-notify, and would consequently not be
               available to a browser using simple Get, GetNext, or GetBulk
               requests.

               Copyright (c) The Internet Society (2005).

               -- RFC EDITOR: please replace yyyy with actual number
               This version of this MIB module is part of RFC yyyy; See the
               RFC itself for full legal notices.
              "

          REVISION      "200501060000Z"     -- January 6, 2005
          DESCRIPTION
              "Changes following WG Last Call Comments."

          REVISION      "200410140000Z"     -- October 14, 2004
          DESCRIPTION
              "Changes after the 60th IETF."

          REVISION      "200406150000Z"     -- June 15, 2004
          DESCRIPTION
              "Changes after the 59th IETF."

          REVISION      "200311111150Z"     -- November 11, 2003
          DESCRIPTION
              "Changes after the 58th IETF."

          ::= { rmon 32 }

   -- This OID allocation conforms to [RFC3737]


      raqmonDsEvents OBJECT IDENTIFIER ::= { raqmonDsMIB 0 }
      raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDsMIB 1 }
      raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDsMIB 2 }

      raqmonDsNotificationTable OBJECT-TYPE
          SYNTAX SEQUENCE OF RaqmonDsNotificationEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
              "This conceptual table provides the SNMP mapping of the
               RAQMON Basic PDU.  It is indexed by the RAQMON Data Source,
               sub-session, and address of the peer entity.




RMON WG                     Expires July 2005                  [Page 17]


INTERNET DRAFT                 RAQMON PDU                   January 2005


               Note that there is no concern about the indexation of this
               table exceeding the limits defined by RFC 2578 Section 3.5.
               According to [RAQMON-FRAMEWORK], Section 5.1, only IPv4 and
               IPv6 addresses can be reported as participant addresses.
              "
          ::= { raqmonDsMIBObjects 1 }

      raqmonDsNotificationEntry OBJECT-TYPE
          SYNTAX     RaqmonDsNotificationEntry
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
              "The entry (row) is not retrievable and is not kept by RDSs.
               It serves data organization purpose only.
              "
          INDEX { raqmonDSRC, raqmonRCN, raqmonPeerAddrType,
                  raqmonPeerAddr }
          ::= { raqmonDsNotificationTable 1 }

      RaqmonDsNotificationEntry ::= SEQUENCE {
              raqmonDSRC                      Unsigned32,
              raqmonRCN                       Integer32,
              raqmonPeerAddrType              InetAddressType,
              raqmonPeerAddr                  InetAddress,
              raqmonAppName                   SnmpAdminString,
              raqmonDataSourceDevicePort      Unsigned32,
              raqmonReceiverDevicePort        Unsigned32,
              raqmonSessionSetupDateTime      DateAndTime,
              raqmonSessionSetupDelay         Unsigned32,
              raqmonSessionDuration           Unsigned32,
              raqmonSessionSetupStatus        SnmpAdminString,
              raqmonRoundTripEndToEndNetDelay Unsigned32,
              raqmonOneWayEndToEndNetDelay    Unsigned32,
              raqmonApplicationDelay          Unsigned32,
              raqmonInterArrivalJitter        Unsigned32,
              raqmonIPPacketDelayVariation    Unsigned32,
              raqmonTotalPacketsReceived      Counter32,
              raqmonTotalPacketsSent          Counter32,
              raqmonTotalOctetsReceived       Counter32,
              raqmonTotalOctetsSent           Counter32,
              raqmonCumulativePacketLoss      Counter32,
              raqmonPacketLossFraction        Unsigned32,
              raqmonCumulativeDiscards        Counter32,
              raqmonDiscardsFraction          Unsigned32,
              raqmonSourcePayloadType         Unsigned32,
              raqmonReceiverPayloadType       Unsigned32,
              raqmonSourceLayer2Priority      Unsigned32,
              raqmonSourceDscp                Dscp,



RMON WG                     Expires July 2005                  [Page 18]


INTERNET DRAFT                 RAQMON PDU                   January 2005


              raqmonDestinationLayer2Priority Unsigned32,
              raqmonDestinationDscp           Dscp,
              raqmonCpuUtilization            Unsigned32,
              raqmonMemoryUtilization         Unsigned32 }

      raqmonDSRC OBJECT-TYPE
          SYNTAX     Unsigned32
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
              "Data Source identifier represents a unique session
               descriptor that points to a specific communication session
               between communicating entities. Identifiers unique for
               sessions conducted between two entities are
               generated by the communicating entities."
          ::= { raqmonDsNotificationEntry 1 }

      raqmonRCN OBJECT-TYPE
           SYNTAX      Integer32 (0..15)
           MAX-ACCESS  not-accessible
           STATUS      current
           DESCRIPTION
             "The Record Count Number indicates a sub-session
              within a communication session. A maximum number of 16
              sub-sessions are supported - this limitation is dictated
              by reasons of compatibility with other transport protocols."
             ::= { raqmonDsNotificationEntry 2 }

      raqmonPeerAddrType OBJECT-TYPE
          SYNTAX InetAddressType
          MAX-ACCESS not-accessible
          STATUS current
          DESCRIPTION
              "The type of the Internet address of the peer participant
               for this session."
          REFERENCE
              "Section 5.2 of [RAQMON-FRAMEWORK]"
              ::= { raqmonDsNotificationEntry 3 }

      raqmonPeerAddr OBJECT-TYPE
          SYNTAX InetAddress
          MAX-ACCESS not-accessible
          STATUS current
          DESCRIPTION
              "The Internet Address of the peer participant for this
               session."
          REFERENCE
              "Section 5.2 of [RAQMON-FRAMEWORK]"



RMON WG                     Expires July 2005                  [Page 19]


INTERNET DRAFT                 RAQMON PDU                   January 2005


              ::= { raqmonDsNotificationEntry 4 }

      raqmonAppName  OBJECT-TYPE
          SYNTAX     SnmpAdminString
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "This is a text string giving the name and possibly version
               of the application associated with that session,
               e.g., 'XYZ VoIP Agent 1.2'."
          REFERENCE
              "Section 5.28 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 5 }

      raqmonDataSourceDevicePort OBJECT-TYPE
          SYNTAX     Unsigned32 (0..65535)
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "The port number from which data for this session was sent
               by the Data Source device."
          REFERENCE
              "Section 5.5 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 6 }

      raqmonReceiverDevicePort OBJECT-TYPE
          SYNTAX     Unsigned32 (0..65535)
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "The port number where the data for this session was received."
          REFERENCE
              "Section 5.6 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 7 }

      raqmonSessionSetupDateTime OBJECT-TYPE
          SYNTAX     DateAndTime
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "The time when session was initiated."
          REFERENCE
            "Section 5.7 of [RAQMON-FRAMEWORK]"
      ::= { raqmonDsNotificationEntry 8 }

      raqmonSessionSetupDelay OBJECT-TYPE
          SYNTAX     Unsigned32
          UNITS      "milliseconds"



RMON WG                     Expires July 2005                  [Page 20]


INTERNET DRAFT                 RAQMON PDU                   January 2005


          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "Session setup time."
          REFERENCE
              "Section 5.8 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 9 }

      raqmonSessionDuration OBJECT-TYPE
          SYNTAX     Unsigned32
          UNITS      "seconds"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "Session duration, including setup time. The SYNTAX of this
               object allows to express the duration of sessions that do
               not exceed 4660 hours and 20 minutes."
          REFERENCE
              "Section 5.9 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 10 }

      raqmonSessionSetupStatus OBJECT-TYPE
          SYNTAX     SnmpAdminString
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "Describes appropriate communication session states e.g.
               Call Established successfully, RSVP reservation
               failed etc."
          REFERENCE
              "Section 5.10 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 11 }

      raqmonRoundTripEndToEndNetDelay OBJECT-TYPE
          SYNTAX     Unsigned32
          UNITS      "milliseconds"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "Most recent available information about the
               round trip end to end network delay."
          REFERENCE
              "Section 5.11 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry  12}

      raqmonOneWayEndToEndNetDelay OBJECT-TYPE
          SYNTAX     Unsigned32
          UNITS      "milliseconds"



RMON WG                     Expires July 2005                  [Page 21]


INTERNET DRAFT                 RAQMON PDU                   January 2005


          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              " Most recent available information about the
                one way end to end network delay."
          REFERENCE
              "Section 5.12 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry  13}

      raqmonApplicationDelay OBJECT-TYPE
          SYNTAX     Unsigned32
          UNITS      "milliseconds"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              " Most recent available information about the
                application delay."
          REFERENCE
              "Section 5.13 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry  14}

      raqmonInterArrivalJitter OBJECT-TYPE
          SYNTAX     Unsigned32
          UNITS      "milliseconds"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "An estimate of the inter-arrival jitter."
          REFERENCE
              "Section 5.14 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry  15}

      raqmonIPPacketDelayVariation OBJECT-TYPE
          SYNTAX     Unsigned32
          UNITS      "milliseconds"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "An estimate of the inter-arrival delay variation."
          REFERENCE
              "Section 5.15 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry  16}

      raqmonTotalPacketsReceived OBJECT-TYPE
          SYNTAX     Counter32
          UNITS     "packets"
          MAX-ACCESS accessible-for-notify
          STATUS     current



RMON WG                     Expires July 2005                  [Page 22]


INTERNET DRAFT                 RAQMON PDU                   January 2005


          DESCRIPTION
              "The number of packets transmitted within a communication
               session by the receiver since starting transmission up until
               the time this RAQMON PDU was generated.
              "
          REFERENCE
              "Section 5.16 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 17 }

      raqmonTotalPacketsSent OBJECT-TYPE
          SYNTAX     Counter32
          UNITS     "packets"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "The number of packets transmitted within a communication
               session by the sender since starting transmission up until
               the time this RAQMON PDU was generated.
              "
          REFERENCE
              "Section 5.17 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 18 }

      raqmonTotalOctetsReceived OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "octets"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "The total number of payload octets (i.e., not including
               header or padding octets) transmitted in packets by the
               receiver within a communication session since starting
               transmission up until the time this RAQMON PDU was
               generated.
              "
          REFERENCE
              "Section 5.18 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 19 }

      raqmonTotalOctetsSent OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "octets"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "The number of payload octets (i.e., not including headers
               or padding) transmitted in packets by the sender within
               a communication session since starting transmission up



RMON WG                     Expires July 2005                  [Page 23]


INTERNET DRAFT                 RAQMON PDU                   January 2005


               until the time this RAQMON notification was generated."
          REFERENCE
              "Section 5.19 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 20 }

      raqmonCumulativePacketLoss OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "packets"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "The number of packets from this session whose loss had been
               detected when this notification was generated.
              "
          REFERENCE
               "Section 5.20 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 21 }

      raqmonPacketLossFraction OBJECT-TYPE
          SYNTAX     Unsigned32 (0..100)
          UNITS      "percentage of packets sent"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "The percentage of lost packets with respect to the overall
               packets sent.  This is defined to be 100 times the number
               of packets lost divided by the number of packets expected."
          REFERENCE
            "Section 5.21 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 22 }

      raqmonCumulativeDiscards OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "packets"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "The number of packet discards
               detected when this notification was generated."
          REFERENCE
               "Section 5.22 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 23 }

      raqmonDiscardsFraction OBJECT-TYPE
          SYNTAX     Unsigned32 (0..100)
          UNITS      "percentage of packets sent"
          MAX-ACCESS accessible-for-notify
          STATUS     current



RMON WG                     Expires July 2005                  [Page 24]


INTERNET DRAFT                 RAQMON PDU                   January 2005


          DESCRIPTION
              "The percentage of discards with respect to the overall
               packets sent.  This is defined to be 100 times the number
               of discards divided by the number of packets expected."
          REFERENCE
            "Section 5.23 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 24 }

      raqmonSourcePayloadType OBJECT-TYPE
          SYNTAX     Unsigned32 (0..127)
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "The payload type of the packet sent by this RDS."
          REFERENCE
            "RFC 1890, Section 5.24 of [RAQMON-FRAMEWORK] "
          ::= { raqmonDsNotificationEntry 25 }

      raqmonReceiverPayloadType OBJECT-TYPE
          SYNTAX     Unsigned32 (0..127)
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "The payload type of the packet received by this RDS."
          REFERENCE
              "RFC 1890, Section 5.25 of [RAQMON-FRAMEWORK] "
      ::= { raqmonDsNotificationEntry 26 }

      raqmonSourceLayer2Priority OBJECT-TYPE
          SYNTAX     Unsigned32 (0..7)
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "Source Layer 2 priority used by the sata source to send
               packets to the receiver by this data source during this
               communication session.
              "
          REFERENCE
              "Section 5.26 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 27 }

      raqmonSourceDscp OBJECT-TYPE
          SYNTAX     Dscp
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "Layer 3 TOS/DSCP values used by the Data Source to
               prioritize traffic sent."



RMON WG                     Expires July 2005                  [Page 25]


INTERNET DRAFT                 RAQMON PDU                   January 2005


          REFERENCE
              "Section 5.27 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 28 }

      raqmonDestinationLayer2Priority OBJECT-TYPE
          SYNTAX     Unsigned32 (0..7)
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "Destination Layer 2 priority.  This is the priority use by
               the peer communicating entity to send packets to the data
               source.
              "
          REFERENCE
              "Section 5.28 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 29 }

      raqmonDestinationDscp OBJECT-TYPE
          SYNTAX     Dscp
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "Layer 3 TOS/DSCP values used by the
               peer communicating entiy to prioritize traffic
               sent to the source."
          REFERENCE
              "Section 5.29 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 30 }

      raqmonCpuUtilization OBJECT-TYPE
          SYNTAX     Unsigned32 (0..100)
          UNITS      "percent"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "Latest available information about the total CPU utilization."
          REFERENCE
              "Section 5.30 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 31 }

      raqmonMemoryUtilization OBJECT-TYPE
          SYNTAX     Unsigned32 (0..100)
          UNITS      "percent"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "Latest available information about the total memory utilization."
          REFERENCE



RMON WG                     Expires July 2005                  [Page 26]


INTERNET DRAFT                 RAQMON PDU                   January 2005


              "Section 5.31 of [RAQMON-FRAMEWORK]"
          ::= { raqmonDsNotificationEntry 32 }

      -- definitions of the notifications
      --
      -- raqmonAppName is the only object that MUST be sent by an
      -- RD every time the notification is generated.

      -- Other objects from the raqmonDsNotificationTable may be included
      -- in the variable binding list. Specifically, a raqmonDsNotification
      -- will include MIB objects that provide information about metrics
      -- that characterize the application session
      --

      raqmonDsNotification NOTIFICATION-TYPE
          OBJECTS { raqmonAppName }
          STATUS current
          DESCRIPTION
              "This notification maps the Basic RAQMON PDU onto an SNMP
               transport.
              "
          ::= { raqmonDsEvents  1 }

      raqmonDsByeNotification NOTIFICATION-TYPE
          OBJECTS { raqmonAppName }
          STATUS current
          DESCRIPTION
              "The BYE Notification. This Notification is the equivalent of
               the RAQMON BYE PDU, which signals the end of a RAQMON
               session.
              "
          ::= { raqmonDsEvents  2 }


      --
      -- conformance information
      -- These don't show up on the wire, so they only need to be unique.
      --
      raqmonDsCompliances OBJECT IDENTIFIER ::= { raqmonDsConformance 1 }
      raqmonDsGroups OBJECT IDENTIFIER ::= { raqmonDsConformance 2 }

      raqmonDsBasicCompliances MODULE-COMPLIANCE
          STATUS current
          DESCRIPTION
              "The compliance statement for SNMP entities which
               implement this MIB module."
          MODULE  -- this module
              MANDATORY-GROUPS { raqmonDsNotificationGroup,



RMON WG                     Expires July 2005                  [Page 27]


INTERNET DRAFT                 RAQMON PDU                   January 2005


                                 raqmonDsPayloadGroup }
          ::= { raqmonDsCompliances 1 }

      raqmonDsNotificationGroup NOTIFICATION-GROUP
          NOTIFICATIONS { raqmonDsNotification,
                          raqmonDsByeNotification }
          STATUS current
          DESCRIPTION
              "The notifications implemented by an SNMP entity claiming
               conformance to this MIB.
              "
          ::= { raqmonDsGroups 1 }

      raqmonDsPayloadGroup OBJECT-GROUP
          OBJECTS { raqmonAppName,
                    raqmonDataSourceDevicePort,
                    raqmonReceiverDevicePort,
                    raqmonSessionSetupDateTime,
                    raqmonSessionSetupDelay,
                    raqmonSessionDuration,
                    raqmonSessionSetupStatus,
                    raqmonRoundTripEndToEndNetDelay,
                    raqmonOneWayEndToEndNetDelay,
                    raqmonApplicationDelay,
                    raqmonInterArrivalJitter,
                    raqmonIPPacketDelayVariation,
                    raqmonTotalPacketsReceived,
                    raqmonTotalPacketsSent,
                    raqmonTotalOctetsReceived,
                    raqmonTotalOctetsSent,
                    raqmonCumulativePacketLoss,
                    raqmonPacketLossFraction,
                    raqmonCumulativeDiscards,
                    raqmonDiscardsFraction,
                    raqmonSourcePayloadType,
                    raqmonReceiverPayloadType,
                    raqmonSourceLayer2Priority,
                    raqmonSourceDscp,
                    raqmonDestinationLayer2Priority,
                    raqmonDestinationDscp,
                    raqmonCpuUtilization,
                    raqmonMemoryUtilization }
          STATUS current
          DESCRIPTION
              "These objects are required for entities claiming conformance
               to this MIB."
          ::= { raqmonDsGroups 2 }




RMON WG                     Expires July 2005                  [Page 28]


INTERNET DRAFT                 RAQMON PDU                   January 2005


      END





3. Congestion-Safe RAQMON Operation

   As outlined in earlier sections, TCP congestion control mechanism
   provides inherent congestion safety features when TCP is implemnted
   as transport to carry RAQMON PDU.

   To ensure congestion safety, clearly the best thing to do is to use a
   congestion-safe transport protocol such as TCP. If this is not
   feasible, it may be necessary to fall back to UDP since SNMP over UDP
   is more widely deployed transport protocol.

   When SNMP is chosen as RAQMON PDU Transport, implementers MUST follow
   section 3.0 of [RAQMON-FRAMEWORK] guidelines that outlines measures
   that MUST be taken to use RAQMON in congestion safe manner.
   Congestion safety requirements in section 3.0 of [RAQMON-FRAMEWORK]
   would ensure that a RAQMON implementation using SNMP over UDP does
   not lead to congestion under heavy network load.

4. Normative References

   [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
               1981.

   [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
               September 1981.

   [RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Structure of Management
               Information Version 2 (SMIv2)", STD 58, RFC 2578, April
               1999.

   [RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Textual Conventions for
               SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Conformance Statements for
               SMIv2", STD 58, RFC 2580, April 1999.

   [RFC2819]   Waldbusser, S., "Remote Network Monitoring Management
               Information Base", STD 59, RFC 2819, May 2000.




RMON WG                     Expires July 2005                  [Page 29]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   [RAQMON-FRAMEWORK] Siddiqui, A., Romascanu, D. and E. Golovinsky,
               "Framework for Real-time Application Quality of Service
               Monitoring (RAQMON)", Internet-Draft, draft-ietf-raqmon-
               framework-10.txt, January 2005.

5. Informative References

   [RFC1321]   Rivest, R., "Message Digest Algorithm MD5", RFC 1321,
               April 1992.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3550]  H. Schulzrinne, "RTP Profile for Audio and Video
               Conferences with Minimal Control" RFC 3550, July 2003.

   [RFC1305]   Mills, D., "Network Time Protocol Version 3", RFC 1305,
               March 1992.

   [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.

   [RFC1597] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de
               Groot, "Address Allocation for Private Internets", RFC
               1597, March 1994.

   [RFC2679] G. Almes, S.Kalidindi and M.Zekauskas, "A One-way Delay
               Metric for IPPM", RFC 2679, September 1999

   [RFC2680] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Packet
               Loss Metric for IPPM", RFC 2680, September 1999

   [RFC2681] G. Almes, S.kalidindi and M.Zekauskas, "A Round-Trip Delay
               Metric for IPPM", RFC 2681, September 1999

   [RFC3550]   Schulzrinne, H., Casner, S., Frederick, R., and V.
               Jacobson, "RTP: A Transport Protocol for Real-Time
               Applications", RFC 3550, July 2003.

   [ISO10646]  International Standards Organization, "ISO/IEC DIS
               10646-1:1993information technology -- universal multiple-
               octet coded character set (UCS) -- part I: Architecture



RMON WG                     Expires July 2005                  [Page 30]


INTERNET DRAFT                 RAQMON PDU                   January 2005


               and basic multilingual plane," 1993.

   [UNICODE]   The Unicode Consortium, The Unicode Standard New York,
               New York:Addison-Wesley, 1991.

   [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)
               [ANSI/IEEE Std 802.1D, 1998 Edition]

   [RFC1349] P. Almquist, "Type of Service in the Internet Protocol
               Suite", RFC 1349, July 1992

   [RFC1812] F. Baker, "Requirements for IP Version 4 Routers" RFC1812,
               June 1995

   [RFC2474] K. Nicholas, S. Blake, F. Baker and D. Black, "Definition
               of the Differentiated Services Field (DS Field) in the
               IPv4 and IPv6 Headers", RFC2474, December 1998

   [RFC3291]   Daniele, M., Haberman, B., Routhier, S., and J.
               Schoenwaelder "Textual Conventions for Internet Network
               Addresses", RFC 3291, May 2002.

   [RFC3410]   Case, J., Mundy, R., Partain, D. and B. Stewart,
               "Introduction and Applicability Statements for Internet-
               Standard Management Framework", RFC 3410, December 2002.

   [RFC3414]   Blumenthal U., and B. Wijnen, "User-based Security Model
               (USM) for version 3 of the Simple Network Management
               Protocol (SNMPv3)", RFC 3414, December 2002.

   [RFC3737]   Wijnen B., and A.Bierman "IANA Guidelines for the
               Registry of Remote Monitoring (RMON) MIB modules", RFC
               3737, April 2004.



   [3DES]     American National Standards Institute, ANSI X9.52-1998,
               "Triple Data Encryption Algorithm Modes of Operation"
               1998.

   [AES]     Federal Information Processing Standard (FIPS),
               "Specification for the ADVANCED ENCRYPTION
               STANDARD(AES)", Publication 197, November 2001.





RMON WG                     Expires July 2005                  [Page 31]


INTERNET DRAFT                 RAQMON PDU                   January 2005


6. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

   By submitting this Internet-Draft, we certify that any applicable
   patent or other IPR claims of which we are aware have been disclosed,
   and any of which we become aware will be disclosed, in accordance
   with RFC 3668.

7. Acknowledgements

   The authors would like to thank Bill Walker and Joseph Mastroguilio
   from Avaya and Bin Hu from Motorola for their discussions. The
   authors would also like to extend special thanks to Randy Presuhn,
   who reviewed this document for spelling and formatting purposes, as
   well as for a deep review of the technical content.


8.Appendix

   The implementation notes included in Appendix are for informational
   purposes only and are meant to clarify the RAQMON specification.

   Pseudo code for RDS & RRC

   We provide examples of Psuedo code for aspects of RDS and RRC. There
   may be other implementation methods that are faster in particular
   operating environments or have other advantages.

   RDS:



RMON WG                     Expires July 2005                  [Page 32]


INTERNET DRAFT                 RAQMON PDU                   January 2005


           when (session starts} {
             report.identifier = session.endpoints, session.starttime;
             report.timestamp = 0;
             while (session in progress) {
                  wait interval;
                  report.statistics = update statistics;
                  report.curtimestamp += interval;
                  if encryption required
                      report_data = encrypt(report, encrypt parameters);





                  else
                      report_data = report;
                  raqmon_pdu = header, report_data;
                  send raqmon-pdu;
             }
           } RRC:
           listen on raqmon port
           when ( raqmon_pdu received ) {
               decrypt raqmon_pdu.data if needed

               if report.identifier in database
                  if report.current_time_stamp > last update
                     update session statistics from report.statistics
                  else
                     discard report
            }


9.  Security Considerations

   [RAQMON-FRAMEWORK] outlines a threat model associated with RAQMON and
   security considerations to be taken into account in the RAQMON
   specification to mitigate against those threats.  It is imperative
   that RAQMON PDU implementations be able to provide the following
   protection mechanisms in order to attain end-to-end security:

   1. Authentication - the RRC SHOULD be able to verify that a RAQMON
      report was originated by the RDS claiming to have sent it.  At
      minimum, an RDS/RRC pair MUST use a digest-based authentication
      procedure to authenticate, like the one defined in [RFC 1321].

   2. Privacy - RAQMON information includes identification of the
      parties participating in a communication session.  RAQMON
      deployments SHOULD be able to provide protection from



RMON WG                     Expires July 2005                  [Page 33]


INTERNET DRAFT                 RAQMON PDU                   January 2005


      eavesdropping, and to prevent an unauthorized third party from
      gathering potentially sensitive information.  This can be achieved
      by using payload encryption technologies such as DES (Data
      Encryption Standard), 3-DES [3DES], and AES (Advanced Encryption
      Standard) [AES].

   3. Protection from Denial of Service attacks directed at the RRC -
      RDSs send RAQMON reports as a side effect of external events (for
      example, receipt of a phone call).  An attacker can try to
      overwhelm the RRC (or the network) by initiating a large number of
      events in order to swamp the RRC with excessive numbers of RAQMON
      PDUs.

      To prevent DoS (denial-of-service) attacks against the RRC, the
      RDS will send the first report for a session only after the
      session has been established, so that the session set-up process
      is not affected.

   4. NAT and Firewall Friendly Design: the presence of IP addresses and
      TCP/UDP port information in RAQMON PDUs may be NAT unfriendly.
      Where NAT-friendliness is a requirement, the RDS MAY omit IP
      address information from the RAQMON PDU.  Another way to avoid
      this problem is by using NAT-Aware Application Layer Gateways
      (ALGs) to ensure that correct IP addresses appear in RAQMON PDUs.

   For the usage of TCP, TLS SHOULD be used to provide transport layer
   security.

      Following SNMP Specific guidelines SHOULD be followed to ensure a
      secure implementation:

   This memo also defines an RDS SNMP MIB module with the purpose of
   mapping the RAQMON PDUs into SNMP Notifications.  To attain end-to-
   end security the following measures have been taken in RDS MIB module
   design:

   There are no management objects defined in this MIB module that have
   a MAX-ACCESS clause of read-write and/or read-create.  Consequently,
   if this MIB module is implemented correctly, there is no risk that an
   intruder can alter or create any management objects of this MIB
   module via direct SNMP SET operations.

   Some of the readable objects in this MIB module (i.e., objects with a
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP.  These are the tables and objects and their



RMON WG                     Expires July 2005                  [Page 34]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   sensitivity/vulnerability:

   raqmonDsNotificationTable

   The objects in this table contain user session information, and their
   disclosure may be sensitive in some environments.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPSec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   It is a customer/operator responsibility to ensure that the SNMP
   entity giving access to an instance of this MIB module is properly
   configured to give access to the objects only to those principals
   (users) that have legitimate rights to indeed GET or SET
   (change/create/delete) them.

10.  Authors' Addresses

   Anwar A. Siddiqui
   Avaya Labs
   307 Middletown Lincroft Road
   Lincroft, New Jersey 07738
   USA
   Tel: +1 732 852-3200
   E-mail: anwars@avaya.com

   Dan Romascanu
   Avaya
   Atidim Technology Park, Bldg. #3
   Tel Aviv, 61131
   Israel
   Tel: +972-3-645-8414
   Email: dromasca@avaya.com

   Eugene Golovinsky
   BMC Software
   2101 CityWest Blvd.
   Houston, Texas 77042
   USA
   Tel: +1 713 918-1816



RMON WG                     Expires July 2005                  [Page 35]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   Email: eugene_golovinsky@bmc.com

   Mahfuzur Rahman
   Panasonic Digital Networking Lab
   Two Research Way
   Princeton, NJ 08540
   Tel: +1 609 734 7332
   Email: mahfuz@research.panasonic.com

   Yongbum "Yong" Kim
   Broadcom
   3151 Zanker Road
   San Jose, CA 95134
   Tel: +1 408 501 7800
   E-mail: ybkim@broadcom.com

A.  Full Copyright Statement

   Copyright (C) The Internet Society (2004).  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.




RMON WG                     Expires July 2005                  [Page 36]


INTERNET DRAFT                 RAQMON PDU                   January 2005


   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 currently provided by the
   Internet Society.








































RMON WG                     Expires July 2005                  [Page 37]