tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4712

 
 
 

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

Part 2 of 2, p. 22 to 48
Prev RFC Part

 


prevText      Top      Up      ToC       Page 22 
2.3.  SNMP Notifications as an RDS/RRC Network Transport Protocol

   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 the intent of using existing
   installed devices implementing SNMP agents as RAQMON Data Sources
   (RDSs).

   There are some potential problems with the usage of SNMP as a
   transport mapping protocol:

   o  The potential of congestion is higher than with the TCP transport,
      because of the usage of UDP at the transport layer.

   o  The encoding of the information is less efficient, and this
      results in bigger message size, which again may negatively impact
      congestion conditions and memory size requirements in the devices.

   In order to avoid these potential problems, the following
   recommendations are made:

   o  Usage of the TCP transport is RECOMMENDED in deployment over the
      SNMP transport wherever available for a pair of RDS/RRC.

   o  The usage of Inform PDUs is RECOMMENDED.

   o  The usage of Traps PDU is NOT RECOMMENDED.

   o  It is RECOMMENDED that information carried by notifications be
      maintained within the limits of the MTU size in order to avoid
      fragmentation.

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

Top      Up      ToC       Page 23 
   o  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.

   o  Since RDSs are not computationally rich, and in order 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 [RFC3414].

   o  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 MUST serialize the PDU
      transmission rate, i.e., limit the number of PDUS sent in a
      specific time interval.

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

2.3.1.  Encoding RAQMON 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 module defines the
   objects needed for mapping the BASIC part of RAQMON PDU, defined in
   [RFC4710], 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 [RFC4710], additional
   variable bindings MAY be included in RAQMON notifications as
   described in the MIB module.

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   [RFC3410].

   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).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   [RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580].

Top      Up      ToC       Page 24 
   The following MIB module IMPORTS definitions from the following:

            SNMPv2-SMI [RFC2578]
            SNMPv2-TC [RFC2579]
            SNMPv2-CONF [RFC2580]
            RMON-MIB [RFC2819]
            DIFFSERV-DSCP-TC [RFC3289]
            SNMP-FRAMEWORK-MIB [RFC3411]
            INET-ADDRESS-MIB [RFC4001]

   It also uses REFERENCE clauses to refer to [RFC4710].

   RAQMON-RDS-MIB DEFINITIONS ::= BEGIN

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

          DateAndTime
              FROM SNMPv2-TC

          rmon
              FROM RMON-MIB

          SnmpAdminString
              FROM SNMP-FRAMEWORK-MIB

          InetAddressType, InetAddress, InetPortNumber
              FROM INET-ADDRESS-MIB

          Dscp
              FROM DIFFSERV-DSCP-TC

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

      raqmonDsMIB MODULE-IDENTITY
          LAST-UPDATED "200610100000Z"      -- October 10, 2006
          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,

Top      Up      ToC       Page 25 
                       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.

               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 (2006).

               This version of this MIB module is part of RFC 4712;
               See the RFC itself for full legal notices."

          REVISION      "200610100000Z"     -- October 10, 2006
          DESCRIPTION
              "Initial version, published as RFC 4712."

                 ::= { rmon 32 }

   -- This OID allocation conforms to [RFC3737]


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

               Note that there is no concern about the indexation of
               this table exceeding the limits defined by RFC 2578
               Section 3.5.  According to [RFC4710], Section 5.1,

Top      Up      ToC       Page 26 
               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 purposes only."
          INDEX { raqmonDsDSRC, raqmonDsRCN, raqmonDsPeerAddrType,
                  raqmonDsPeerAddr }
          ::= { raqmonDsNotificationTable 1 }

      RaqmonDsNotificationEntry ::= SEQUENCE {
              raqmonDsDSRC                      Unsigned32,
              raqmonDsRCN                       Unsigned32,
              raqmonDsPeerAddrType              InetAddressType,
              raqmonDsPeerAddr                  InetAddress,
              raqmonDsAppName                   SnmpAdminString,
              raqmonDsDataSourceDevicePort      InetPortNumber,
              raqmonDsReceiverDevicePort        InetPortNumber,
              raqmonDsSessionSetupDateTime      DateAndTime,
              raqmonDsSessionSetupDelay         Unsigned32,
              raqmonDsSessionDuration           Unsigned32,
              raqmonDsSessionSetupStatus        SnmpAdminString,
              raqmonDsRoundTripEndToEndNetDelay Unsigned32,
              raqmonDsOneWayEndToEndNetDelay    Unsigned32,
              raqmonDsApplicationDelay          Unsigned32,
              raqmonDsInterArrivalJitter        Unsigned32,
              raqmonDsIPPacketDelayVariation    Unsigned32,
              raqmonDsTotalPacketsReceived      Counter32,
              raqmonDsTotalPacketsSent          Counter32,
              raqmonDsTotalOctetsReceived       Counter32,
              raqmonDsTotalOctetsSent           Counter32,
              raqmonDsCumulativePacketLoss      Counter32,
              raqmonDsPacketLossFraction        Unsigned32,
              raqmonDsCumulativeDiscards        Counter32,
              raqmonDsDiscardsFraction          Unsigned32,
              raqmonDsSourcePayloadType         Unsigned32,
              raqmonDsReceiverPayloadType       Unsigned32,
              raqmonDsSourceLayer2Priority      Unsigned32,
              raqmonDsSourceDscp                Dscp,
              raqmonDsDestinationLayer2Priority Unsigned32,
              raqmonDsDestinationDscp           Dscp,
              raqmonDsCpuUtilization            Unsigned32,
              raqmonDsMemoryUtilization         Unsigned32 }

Top      Up      ToC       Page 27 
      raqmonDsDSRC OBJECT-TYPE
          SYNTAX     Unsigned32
          MAX-ACCESS not-accessible
          STATUS     current
          DESCRIPTION
              "Data Source identifier represents a unique session
               descriptor that points to a specific session
               between communicating entities.  Identifiers unique for
               sessions conducted between two entities are
               generated by the communicating entities.  Zero is a
               valid value, with no special semantics."
          ::= { raqmonDsNotificationEntry 1 }

      raqmonDsRCN OBJECT-TYPE
           SYNTAX      Unsigned32 (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 }

      raqmonDsPeerAddrType 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 [RFC4710]"
          ::= { raqmonDsNotificationEntry 3 }

      raqmonDsPeerAddr 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 [RFC4710]"
          ::= { raqmonDsNotificationEntry 4 }

      raqmonDsAppName  OBJECT-TYPE

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

      raqmonDsDataSourceDevicePort OBJECT-TYPE
          SYNTAX     InetPortNumber
          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 [RFC4710]"
          ::= { raqmonDsNotificationEntry 6 }

      raqmonDsReceiverDevicePort OBJECT-TYPE
          SYNTAX     InetPortNumber
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "The port number where the data for this session was
               received."
          REFERENCE
              "Section 5.6 of [RFC4710]"
          ::= { raqmonDsNotificationEntry 7 }

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

      raqmonDsSessionSetupDelay OBJECT-TYPE
          SYNTAX     Unsigned32 (0..65535)
          UNITS      "milliseconds"
          MAX-ACCESS accessible-for-notify
          STATUS     current

Top      Up      ToC       Page 29 
          DESCRIPTION
              "Session setup time."
          REFERENCE
              "Section 5.8 of [RFC4710]"
          ::= { raqmonDsNotificationEntry 9 }

      raqmonDsSessionDuration 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 expression of the duration of sessions
               that do not exceed 4660 hours and 20 minutes."
          REFERENCE
              "Section 5.9 of [RFC4710]"
          ::= { raqmonDsNotificationEntry 10 }

      raqmonDsSessionSetupStatus 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 [RFC4710]"
          ::= { raqmonDsNotificationEntry 11 }

      raqmonDsRoundTripEndToEndNetDelay 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 [RFC4710]"
          ::= { raqmonDsNotificationEntry  12}

      raqmonDsOneWayEndToEndNetDelay OBJECT-TYPE
          SYNTAX     Unsigned32
          UNITS      "milliseconds"
          MAX-ACCESS accessible-for-notify
          STATUS     current

Top      Up      ToC       Page 30 
          DESCRIPTION
              "Most recent available information about the
               one-way end-to-end network delay."
          REFERENCE
              "Section 5.12 of [RFC4710]"
          ::= { raqmonDsNotificationEntry  13}

      raqmonDsApplicationDelay OBJECT-TYPE
          SYNTAX     Unsigned32  (0..65535)
          UNITS      "milliseconds"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "Most recent available information about the
               application delay."
          REFERENCE
              "Section 5.13 of [RFC4710"
          ::= { raqmonDsNotificationEntry  14}

      raqmonDsInterArrivalJitter OBJECT-TYPE
          SYNTAX     Unsigned32  (0..65535)
          UNITS      "milliseconds"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "An estimate of the inter-arrival jitter."
          REFERENCE
              "Section 5.14 of [RFC4710]"
          ::= { raqmonDsNotificationEntry  15}

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

      raqmonDsTotalPacketsReceived OBJECT-TYPE
          SYNTAX     Counter32
          UNITS     "packets"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "The number of packets transmitted within a communication

Top      Up      ToC       Page 31 
               session by the receiver since the start of the session."
          REFERENCE
              "Section 5.16 of [RFC4710]"
          ::= { raqmonDsNotificationEntry 17 }

      raqmonDsTotalPacketsSent 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 the start of the session."
          REFERENCE
              "Section 5.17 of [RFC4710]"
          ::= { raqmonDsNotificationEntry 18 }

      raqmonDsTotalOctetsReceived 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 the start
               of the session."
          REFERENCE
              "Section 5.18 of [RFC4710]"
          ::= { raqmonDsNotificationEntry 19 }

      raqmonDsTotalOctetsSent 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 sub-session since the start of the
               session."
          REFERENCE
              "Section 5.19 of [RFC4710]"
          ::= { raqmonDsNotificationEntry 20 }

      raqmonDsCumulativePacketLoss OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "packets"

Top      Up      ToC       Page 32 
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "The number of packets from this session whose loss
               had been detected since the start of the session."
          REFERENCE
              "Section 5.20 of [RFC4710]"
          ::= { raqmonDsNotificationEntry 21 }

      raqmonDsPacketLossFraction 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 [RFC4710]"
          ::= { raqmonDsNotificationEntry 22 }

      raqmonDsCumulativeDiscards OBJECT-TYPE
          SYNTAX     Counter32
          UNITS      "packets"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION
              "The number of packet discards detected since the
               start of the session."
          REFERENCE
              "Section 5.22 of [RFC4710]"
          ::= { raqmonDsNotificationEntry 23 }

      raqmonDsDiscardsFraction OBJECT-TYPE
          SYNTAX     Unsigned32 (0..100)
          UNITS      "percentage of packets sent"
          MAX-ACCESS accessible-for-notify
          STATUS     current
          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 [RFC4710]"
          ::= { raqmonDsNotificationEntry 24 }

Top      Up      ToC       Page 33 
      raqmonDsSourcePayloadType 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 [RFC4710] "
          ::= { raqmonDsNotificationEntry 25 }

      raqmonDsReceiverPayloadType 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 [RFC4710] "
      ::= { raqmonDsNotificationEntry 26 }

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

      raqmonDsSourceDscp 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."
          REFERENCE
              "Section 5.27 of [RFC4710]"
          ::= { raqmonDsNotificationEntry 28 }

      raqmonDsDestinationLayer2Priority OBJECT-TYPE
          SYNTAX     Unsigned32 (0..7)
          MAX-ACCESS accessible-for-notify
          STATUS     current
          DESCRIPTION

Top      Up      ToC       Page 34 
              "Destination Layer 2 priority.  This is the priority used
               by the peer communicating entity to send packets to the
               data source."
          REFERENCE
              "Section 5.28 of [RFC4710]"
          ::= { raqmonDsNotificationEntry 29 }

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

      raqmonDsCpuUtilization 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 [RFC4710]"
          ::= { raqmonDsNotificationEntry 31 }

      raqmonDsMemoryUtilization 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
              "Section 5.31 of [RFC4710]"
          ::= { raqmonDsNotificationEntry 32 }

      -- definitions of the notifications
      --
      -- raqmonDsAppName is the only object that MUST be sent by an
      -- RDS every time the static notification is generated.

Top      Up      ToC       Page 35 
      -- raqmonDsTotalPacketsReceived is the only object that MUST be
      -- sent by an RD every time the dynamic notification is generated.

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

         raqmonDsStaticNotification NOTIFICATION-TYPE
          OBJECTS { raqmonDsAppName }
          STATUS current
          DESCRIPTION
              "This notification maps the static parameters in the
               BASIC RAQMON PDU onto an SNMP transport.
               This notification is expected to be sent once per
               session, or when a new sub-session is initiated.
               The following objects MAY be carried by the
               raqmonDsStaticNotification:

               raqmonDsDataSourceDevicePort,
               raqmonDsReceiverDevicePort,
               raqmonDsSessionSetupDateTime,
               raqmonDsSessionSetupDelay,
               raqmonDsSessionDuration,
               raqmonDsSourcePayloadType,
               raqmonDsReceiverPayloadType,
               raqmonDsSourceLayer2Priority,
               raqmonDsSourceDscp,
               raqmonDsDestinationLayer2Priority,
               raqmonDsDestinationDscp

               It is RECOMMENDED to keep the size of a notification
               within the MTU size limits in order to avoid
               fragmentation."
          ::= { raqmonDsNotifications  1 }

      raqmonDsDynamicNotification NOTIFICATION-TYPE
          OBJECTS { raqmonDsTotalPacketsReceived }
          STATUS current
          DESCRIPTION
              "This notification maps the dynamic parameters in the
               BASIC RAQMON PDU onto an SNMP transport.

               The following objects MAY be carried by the
               raqmonDsDynamicNotification:

               raqmonDsRoundTripEndToEndNetDelay,
               raqmonDsOneWayEndToEndNetDelay,

Top      Up      ToC       Page 36 
               raqmonDsApplicationDelay,
               raqmonDsInterArrivalJitter,
               raqmonDsIPPacketDelayVariation,
               raqmonDsTotalPacketsSent,
               raqmonDsTotalOctetsReceived,
               raqmonDsTotalOctetsSent,
               raqmonDsCumulativePacketLoss,
               raqmonDsPacketLossFraction,
               raqmonDsCumulativeDiscards,
               raqmonDsDiscardsFraction,
               raqmonDsCpuUtilization,
               raqmonDsMemoryUtilization

               It is RECOMMENDED to keep the size of a notification
               within the MTU size limits in order to avoid
               fragmentation."

          ::= { raqmonDsNotifications  2 }

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

      --
      -- conformance information
      raqmonDsCompliance OBJECT IDENTIFIER ::=
                                           { raqmonDsConformance 1 }
      raqmonDsGroups OBJECT IDENTIFIER ::= { raqmonDsConformance 2 }

   raqmonDsBasicCompliance MODULE-COMPLIANCE
           STATUS current
           DESCRIPTION
              "The compliance statement for SNMP entities that
               implement this MIB module.

               There are a number of INDEX objects that cannot be
               represented in the form of OBJECT clauses in SMIv2, but
               for which we have the following compliance requirements,
               expressed in OBJECT clause form in this description
               clause:

               -- OBJECT      raqmonDsPeerAddrType
               -- SYNTAX      InetAddressType { ipv4(1), ipv6(2) }

Top      Up      ToC       Page 37 
               -- DESCRIPTION
               --     This MIB requires support for only global IPv4
               --     and IPv6 address types.
               --
               -- OBJECT      raqmonDsPeerAddr
               -- SYNTAX      InetAddress (SIZE(4|16))
               -- DESCRIPTION
               --     This MIB requires support for only global IPv4
               --     and IPv6 address types.
               --
              "
           MODULE  -- this module
               MANDATORY-GROUPS { raqmonDsNotificationGroup,
                                  raqmonDsPayloadGroup }
           ::= { raqmonDsCompliance 1 }

      raqmonDsNotificationGroup NOTIFICATION-GROUP
          NOTIFICATIONS { raqmonDsStaticNotification,
                          raqmonDsDynamicNotification,
                          raqmonDsByeNotification }
          STATUS current
          DESCRIPTION
              "Standard RAQMON Data Source Notification group."
          ::= { raqmonDsGroups 1 }

      raqmonDsPayloadGroup OBJECT-GROUP
          OBJECTS { raqmonDsAppName,
                    raqmonDsDataSourceDevicePort,
                    raqmonDsReceiverDevicePort,
                    raqmonDsSessionSetupDateTime,
                    raqmonDsSessionSetupDelay,
                    raqmonDsSessionDuration,
                    raqmonDsSessionSetupStatus,
                    raqmonDsRoundTripEndToEndNetDelay,
                    raqmonDsOneWayEndToEndNetDelay,
                    raqmonDsApplicationDelay,
                    raqmonDsInterArrivalJitter,
                    raqmonDsIPPacketDelayVariation,
                    raqmonDsTotalPacketsReceived,
                    raqmonDsTotalPacketsSent,
                    raqmonDsTotalOctetsReceived,
                    raqmonDsTotalOctetsSent,
                    raqmonDsCumulativePacketLoss,
                    raqmonDsPacketLossFraction,
                    raqmonDsCumulativeDiscards,
                    raqmonDsDiscardsFraction,
                    raqmonDsSourcePayloadType,
                    raqmonDsReceiverPayloadType,

Top      Up      ToC       Page 38 
                    raqmonDsSourceLayer2Priority,
                    raqmonDsSourceDscp,
                    raqmonDsDestinationLayer2Priority,
                    raqmonDsDestinationDscp,
                    raqmonDsCpuUtilization,
                    raqmonDsMemoryUtilization }
          STATUS current
          DESCRIPTION
              "Standard RAQMON Data Source payload MIB objects group."
          ::= { raqmonDsGroups 2 }

      END

3.  IANA Considerations

   Applications using the RAQMON Framework require a single fixed port.
   Port number 7744 is 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.

   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.

   The OID assignment for the raqmonDsMIB MODULE-IDENTITY is made
   according to [RFC3737], and there is no need for any IANA action on
   this respect.

4.  Congestion-Safe RAQMON Operation

   As outlined in earlier sections, the TCP congestion control mechanism
   provides inherent congestion safety features when TCP is implemented
   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 a widely deployed transport protocol.

   When SNMP is chosen as RAQMON PDU Transport, implementers MUST follow
   section 3 of [RFC4710], which outlines measures that MUST be taken to
   use RAQMON in a congestion-safe manner.  Congestion safety

Top      Up      ToC       Page 39 
   requirements in section 3 of [RFC4710] would ensure that a RAQMON
   implementation using SNMP over UDP does not lead to congestion under
   heavy network load.

5.  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, 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.  The Security Considerations section was reviewed by Sam
   Hartman and Kurt D. Zeilenga and almost completely re-written by
   Mahalingam Mani.

6.  Security Considerations

   [RFC4710] 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 [RFC1321].

   2.  Privacy: RAQMON information includes identification of the
       parties participating in a communication session.  RAQMON
       deployments SHOULD be able to provide protection from
       eavesdropping, and to prevent an unauthorized third party from
       gathering potentially sensitive information.  This can be
       achieved by using secure transport protocols supporting
       confidentiality based on encryption technologies such as DES
       (Data Encryption Standard), [3DES], and AES (Advanced Encryption
       Standard) [AES].

   3.  Protection from DoS 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.

Top      Up      ToC       Page 40 
       To prevent DoS 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 MUST be used to provide transport layer
   security.  Section 6.1 describes the usage of TLS with RAQMON.

   This memo also defines the RAQMON-RDS-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 the RAQMON-
   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
   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.

Top      Up      ToC       Page 41 
   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 confidentiality).

   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.

6.1.  Usage of TLS with RAQMON

6.1.1.  Confidentiality & Message Integrity

   The subsequently authorized RAQMON data flow itself is protected by
   the same TLS security association that protects the client-side
   exchange.  This standard TLS channel is now bound to the server
   through the above client-side authentication.  The session itself is
   identified by the tuple {RDS ip-address:RDS_port / RRC ip-address:
   RRC port}.

6.1.2.  TLS CipherSuites

   Several issues should be considered when selecting TLS ciphersuites
   that are appropriate for use in a given circumstance.  These issues
   include the following:

   The ciphersuite's ability to provide adequate confidentiality
   protection for passwords and other data sent over the transport
   connection.  Client and server implementers should recognize that
   some TLS ciphersuites provide no confidentiality protection, while
   other ciphersuites that do provide confidentiality protection may be
   vulnerable to being cracked using brute force methods, especially in
   light of ever-increasing CPU speeds that reduce the time needed to
   successfully mount such attacks.

   Client and server implementers should carefully consider the value of
   the password or data being protected versus the level of
   confidentiality protection provided by the ciphersuite to ensure that
   the level of protection afforded by the ciphersuite is appropriate.

   The ciphersuite's vulnerability (or lack thereof) to man-in-the-
   middle attacks.  Ciphersuites vulnerable to man-in-the-middle attacks
   SHOULD NOT be used to protect passwords or sensitive data, unless the
   network configuration is such that the danger of a man-in-the-middle
   attack is negligible.

Top      Up      ToC       Page 42 
   After a TLS negotiation (either initial or subsequent) is completed,
   both protocol peers should independently verify that the security
   services provided by the negotiated ciphersuite are adequate for the
   intended use of the RAQMON session.  If not, the TLS layer should be
   closed.

   Spoofing Attacks: When anonymous TLS alone is negotiated without
   client authentication, the client's identity is never established.
   This easily allows any end-entity to establish a TLS-secured RAQMON
   connection to the RRC.  This not only offers an opportunity to spoof
   legitimate RDS clients and hence compromise the integrity of RRC
   monitoring data, but also opens the RRC up to unauthorized clients
   posing as genuine RDS entities to launch a DoS by flooding data.
   RAQMON deployment policy MUST consider requiring RDS client
   authentication during TLS session establishment, especially when RDS
   clients communicate across unprotected internet.

   Insider attacks: Even client-authenticated TLS connections are open
   to spoofing attacks by one trusted client on another.  Validation of
   RDS source address against RDS TLS-session source address SHOULD be
   performed to detect such attempts.

6.1.3.  RAQMON Authorization State

   Every RAQMON session (between RDS and RRC) has an associated
   authorization state.  This state is comprised of numerous factors
   such as what (if any) authorization state has been established, how
   it was established, and what security services are in place.  Some
   factors may be determined and/or affected by protocol events (e.g.,
   StartTLS, or TLS closure), and some factors may be determined by
   external events (e.g., time of day or server load).

   While it is often convenient to view authorization state in
   simplistic terms (as we often do in this technical specification)
   such as "an anonymous state", it is noted that authorization systems
   in RAQMON implementations commonly involve many factors that
   interrelate.

   Authorization in RAQMON is a local matter.  One of the key factors in
   making authorization decisions is authorization identity.  The
   initial session establishment defined in Section 2.2 allows
   information to be exchanged between the client and server to
   establish an authorization identity for the RAQMON session.  The RRC
   is not to allow any RDS-transactions-related traffic through for
   processing until the client authentication is complete, unless
   anonymous authentication mode is negotiated.

Top      Up      ToC       Page 43 
   Upon initial establishment of the RAQMON session, the session has an
   anonymous authorization identity.  Among other things, this implies
   that the client need not send a TLSStartRequired in the first PDU of
   the RAQMON message.  The client may send any operation request prior
   to binding RDS to any authentication, and the RRC MUST treat it as if
   it had been performed after an anonymous RAQMON session start.

   The RDS automatically is placed in an unauthorized state upon RRC
   sending a TLSstart request to the RRC.

   It is noted that other events both internal and external to RAQMON
   may result in the authentication and authorization states being moved
   to an anonymous one.  For instance, the establishment, change, or
   closure of data security services may result in a move to an
   anonymous state, or the user's credential information (e.g.,
   certificate) may have expired.  The former is an example of an event
   internal to RAQMON, whereas the latter is an example of an event
   external to RAQMON.

7.  References

7.1.  Normative References

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

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

   [RFC3289]     Baker, F., Chan, K., and A. Smith, "Management
                 Information Base for the Differentiated Services
                 Architecture", RFC 3289, May 2002.

Top      Up      ToC       Page 44 
   [RFC3411]     Harrington, D., Preshun, R., and B. Wijnen, "An
                 Architecture for Describing Simple Network Management
                 Protocol (SNMP) Management Frameworks", STD 62,
                 RFC 3411, December 2002.

   [RFC4001]     Daniele, M., Haberman, B., Routhier, S., and J.
                 Schoenwalder, "Textual Conventions for Internet Network
                 Addresses", RFC 4001, February 2005.

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

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

   [RFC4710]     Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-
                 time Application Quality-of-Service Monitoring
                 (RAQMON)", RFC 4710, October 2006.

   [TLS]         Dierks, T. and E. Rescorla, "The Transport Layer
                 Security (TLS) Protocol Version 1.1", RFC 4346, April
                 2006.

7.2.  Informative References

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

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

   [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 Edition], 1998.

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

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

Top      Up      ToC       Page 45 
   [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.

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

   [RFC3551]     Schulzrinne, H. and S. Casner, "RTP Profile for Audio
                 and Video Conferences with Minimal Control", STD 65,
                 RFC 3551, July 2003.

   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
                 10646", STD 63, RFC 3629, November 2003.

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

   [RFC4513]     Harrison, R., "Lightweight Directory Access Protocol
                 (LDAP): Authentication Methods and Security
                 Mechanisms", RFC 4513, June 2006.

   [TLS-PSK]     Eronen, P. and H. Tschofenig, "Pre-Shared Key
                 Ciphersuites for Transport Layer Security (TLS)",
                 RFC 4279, December 2005.

Top      Up      ToC       Page 46 
Appendix A.  Pseudocode

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

   Pseudocode for RDS & RRC

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

     RDS:
             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
              }

Top      Up      ToC       Page 47 
Authors' Addresses

   Anwar Siddiqui
   Avaya
   307 Middletown Lincroft Road
   Lincroft, NJ  80302
   USA

   Phone: +1 732 852-3200
   EMail: anwars@avaya.com


   Dan Romascanu
   Avaya
   Atidim Technology Park, Bldg #3
   Tel Aviv,   61131
   Israel

   Phone: +972-3-645-8414
   EMail: dromasca@avaya.com


   Eugene Golovinsky
   Alert Logic

   Phone: +1 713 918-1816
   EMail: gene@alertlogic.net


   Mahfuzur Rahman
   Samsung Information Systems America
   75 West Plumeria Drive
   San Jose, CA  95134
   USA

   Phone: +1 408 544-5559


   Yongbum Yong Kim
   Broadcom
   3151 Zanker Road
   San Jose, CA  95134
   USA

   Phone: +1 408 501-7800
   EMail: ybkim@broadcom.com

Top      Up      ToC       Page 48 
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).