Internet Draft Anwar Siddiqui
draft-ietf-rmonmib-raqmon-pdu-06.txt Avaya Inc.
Category: Standards Track Dan Romascanu
Expires January 2005 Avaya
Eugene Golovinsky
BMC Software
8 July 2004
SNMP Notification Transport for
Real-time Application Quality of Service Monitoring (RAQMON)
Protocol Data Unit (PDU)
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other intellectual property right (IPR) claims
of which he or she is aware have been or will be disclosed, and any
of which he or she becomes aware will be disclosed, in accordance
with Section 6 of 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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
A common Protocol Data Unit (PDU) has been defined to be used between
a Real-Time Application Quality of Service (QoS) Monitoring (RAQMON)
Data Source (RDS) and a RAQMON Report Collector (RRC) to report
application level Quality of Service (QoS) information. This allows
monitoring of end devices such as IP phones, pagers, Instant
Messaging clients, mobile phones, and various other hand-held
computing devices. This model fits into the Remote Monitoring (RMON)
RMON WG Expires January 2005 [Page 1]
INTERNET DRAFT RAQMON PDU July 2004
family of specifications.
This memo specifies how the Simple Network Management Protocol (SNMP)
is used to transport RAQMON PDUs between a RAQMON Data Source (RDS)
and 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..................................16
4 Normative References..............................................17
5 Informative References............................................17
6 Intellectual Property.............................................18
7 Security Considerations...........................................18
8 Authors' Addresses................................................20
Full Copyright Statement............................................21
RMON WG Expires January 2005 [Page 2]
INTERNET DRAFT RAQMON PDU July 2004
1. Introduction
There is a need to add mechanisms within RMON [RFC2819] family of
specifications to monitor end devices such as IP phones, pagers,
Instant Messaging clients, mobile phones, and various other hand-held
computing devices. The Real-Time Application QoS Monitoring (RAQMON)
Framework as outlined by [RAQMON-FRAMEWORK] extends RMON by defining
entities such as RAQMON Data Source (RDS) and RAQMON Report Collector
(RRC) to perform various application monitoring in real time.
[RAQMON-FRAMEWORK] defines an informational 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 and of the usage of SNMP as underlying transport
protocol to carry RAQMON PDUs between RDSs and RRCs.
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.
Mechanisms outlined in this draft can be used by many real-time and
non-real-time applications managed within the RMON family of
specifications which allows network appliances to report application
level QoS parameters in real time. Voice over IP, Fax over IP, Video
over IP, Instant Messaging (IM), Email, software download
applications, e-business style transactions, web access from
computing devices are a few examples of applications that can
potentially use the RAQMON Framework for monitoring purposes.
The following sections of this memo contain detailed specifications
of the usage of SNMP to carry RAQMON PDUs.
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
It is 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. 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
outlined in [RAQMON-FRAMEWORK] both the Simple Network Management
Protocol (SNMP) MUST be used as a transport protocol, while other
transport protocols meeting the transport requirements MAY also be
used.
RMON WG Expires January 2005 [Page 3]
INTERNET DRAFT RAQMON PDU July 2004
2.1 SNMP INFORM PDUs as an RDS/RRC Network Transport Protocol
If SNMP is chosen as a mechanism to transport RAQMON PDUs, the
following specification applies:
+ RDSs implement the capability of embedding RAQMON parameters in
SNMP INFORM Requests, 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, 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 tinterval.
+ Standard UDP port 162 SHOULD be used for SNMP Notifications.
2.1.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.
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].
RMON WG Expires January 2005 [Page 4]
INTERNET DRAFT RAQMON PDU July 2004
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;
raqmonDs MODULE-IDENTITY
LAST-UPDATED "200406150000Z" -- June 15. 2004
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.
Ds stands for data source.
Note that all of the object types defined in this module are
RMON WG Expires January 2005 [Page 5]
INTERNET DRAFT RAQMON PDU July 2004
accessible-for-notify, and would consequently not be
available to a browser using simple Get, GetNext, or GetBulk
requests.
Copyright (c) The Internet Society (2004).
-- 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 "200406150000Z" -- June 15, 2004
DESCRIPTION
"Changes after the 59th IETF."
REVISION "200311111150Z" -- November 11, 2003
DESCRIPTION
"Changes after the 58th IETF."
::= { rmon 32 }
raqmonDsEvents OBJECT IDENTIFIER ::= { raqmonDs 0 }
raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDs 1 }
raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDs 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 [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.
RMON WG Expires January 2005 [Page 6]
INTERNET DRAFT RAQMON PDU July 2004
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,
raqmonRoundTripEndtoEndDelay Unsigned32,
raqmonOneWayEndtoEndDelay Unsigned32,
raqmonJitterType INTEGER,
raqmonJitterValue Unsigned32,
raqmonTotalPacketsReceived Counter32,
raqmonTotalPacketsSent Counter32,
raqmonTotalOctetsReceived Counter32,
raqmonTotalOctetsSent Counter32,
raqmonCumulativePacketLoss Counter32,
raqmonPacketLossFraction Unsigned32,
raqmonSourcePayloadType Unsigned32,
raqmonReceiverPayloadType Unsigned32,
raqmonSourceLayer2Priority Unsigned32,
raqmonDestinationLayer2Priority Unsigned32,
raqmonSourceDscp Dscp,
raqmonDestinationDscp Dscp,
raqmonCpuUtilization Unsigned32,
raqmonMemoryUtilization Unsigned32 }
raqmonDSRC OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS accessible-for-notify
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 }
RMON WG Expires January 2005 [Page 7]
INTERNET DRAFT RAQMON PDU July 2004
raqmonRCN OBJECT-TYPE
SYNTAX Integer32 (0..15)
MAX-ACCESS accessible-for-notify
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 accessible-for-notify
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 accessible-for-notify
STATUS current
DESCRIPTION
"The Internet Address of the peer participant for this
session."
REFERENCE
"Section 5.2 of [RAQMON-FRAMEWORK]"
::= { 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
RMON WG Expires January 2005 [Page 8]
INTERNET DRAFT RAQMON PDU July 2004
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"
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."
RMON WG Expires January 2005 [Page 9]
INTERNET DRAFT RAQMON PDU July 2004
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 }
raqmonRoundTripEndtoEndDelay 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 delay."
REFERENCE
"Section 5.11 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 12}
raqmonOneWayEndtoEndDelay OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
" Most recent available information about the
one way end to end delay."
REFERENCE
"Section 5.12 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 13}
raqmonJitterType OBJECT-TYPE
SYNTAX INTEGER
{
interArrival(1),
absolute(2)
}
MAX-ACCESS accessible-for-notify
STATUS current
RMON WG Expires January 2005 [Page 10]
INTERNET DRAFT RAQMON PDU July 2004
DESCRIPTION
"The type of jitter measurement as reported by the RDS.
A value of interArrival(1) indicates relative jitter measurement
and reporting.
A value of absolute(2) indicates absolute jitter measurement
and reporting."
REFERENCE
"Section 5.13 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 14}
raqmonJitterValue OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"An estimate of the jitter."
REFERENCE
"Section 5.13 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 15}
raqmonTotalPacketsReceived 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 receiver since starting transmission up until
the time this RAQMON PDU was generated.
"
REFERENCE
"Section 5.14 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 16 }
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.15 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 17 }
RMON WG Expires January 2005 [Page 11]
INTERNET DRAFT RAQMON PDU July 2004
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.16 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 18 }
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
until the time this RAQMON notification was generated."
REFERENCE
"Section 5.17 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 19 }
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.18 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 20 }
raqmonPacketLossFraction OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percentage of packets sent"
MAX-ACCESS accessible-for-notify
STATUS current
RMON WG Expires January 2005 [Page 12]
INTERNET DRAFT RAQMON PDU July 2004
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.19 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 21 }
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.20 of [RAQMON-FRAMEWORK] "
::= { raqmonDsNotificationEntry 22 }
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.21 of [RAQMON-FRAMEWORK] "
::= { raqmonDsNotificationEntry 23 }
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.22 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 24 }
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
RMON WG Expires January 2005 [Page 13]
INTERNET DRAFT RAQMON PDU July 2004
source.
"
REFERENCE
"Section 5.24 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 25 }
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."
REFERENCE
"Section 5.23 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 26 }
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.25 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 27 }
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.26 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 28 }
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 January 2005 [Page 14]
INTERNET DRAFT RAQMON PDU July 2004
"Section 5.27 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 29 }
-- definitions of the notifications
--
-- The object lists include only the OBJECTS that will be sent by an
-- RD every time the notification is generated.
-- Other objects from the raqmonDsNotificationTable may be included
-- in the variable binding list.
--
raqmonDsNotification NOTIFICATION-TYPE
OBJECTS { raqmonDSRC,
raqmonRCN,
raqmonPeerAddrType,
raqmonPeerAddr
}
STATUS current
DESCRIPTION
"This notification maps the Basic RAQMON PDU onto an SNMP
transport.
"
::= { raqmonDsEvents 1 }
raqmonDsByeNotification NOTIFICATION-TYPE
OBJECTS { raqmonDSRC,
raqmonPeerAddrType,
raqmonPeerAddr
}
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
RMON WG Expires January 2005 [Page 15]
INTERNET DRAFT RAQMON PDU July 2004
"The compliance statement for SNMP entities which
implement this MIB module."
MODULE -- this module
MANDATORY-GROUPS { raqmonDsNotificationGroup,
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 { raqmonDSRC,
raqmonRCN,
raqmonPeerAddrType,
raqmonPeerAddr,
raqmonAppName,
raqmonDataSourceDevicePort,
raqmonReceiverDevicePort,
raqmonSessionSetupDateTime,
raqmonSessionSetupDelay,
raqmonSessionDuration,
raqmonSessionSetupStatus,
raqmonRoundTripEndtoEndDelay,
raqmonOneWayEndtoEndDelay,
raqmonJitterType,
raqmonJitterValue,
raqmonTotalPacketsReceived,
raqmonTotalPacketsSent,
raqmonTotalOctetsReceived,
raqmonTotalOctetsSent,
raqmonCumulativePacketLoss,
raqmonPacketLossFraction,
raqmonSourcePayloadType,
raqmonReceiverPayloadType,
raqmonSourceLayer2Priority,
raqmonDestinationLayer2Priority,
raqmonSourceDscp,
raqmonDestinationDscp,
raqmonCpuUtilization,
raqmonMemoryUtilization }
STATUS current
RMON WG Expires January 2005 [Page 16]
INTERNET DRAFT RAQMON PDU July 2004
DESCRIPTION
"These objects are required for entities claiming conformance
to this MIB."
::= { raqmonDsGroups 2 }
END
3. Congestion-Safe RAQMON Operation
The transport of RAQMON PDUs in SNMP can be handled by any underlying
network transport protocols that can be used by SNMP.
One of the more widely deployed transport protocols for SNMP is UDP,
which might lead to network congestion under heavy network load. To
ensure congestion safety, clearly the best thing to do is to use a
congestion-safe transport protocol, such as TCP or DCCP. If this is
not feasible, it may be necessary to fall back to UDP. Implementers
MUST follow section 3.0 of the [RAQMON-FRAMEWORK] guidelines, which
outlines measures that MUST be taken to use RAQMON in a congestion-
safe manner, especially when using UDP.
4. Normative References
[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.
[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-06.txt, July 2004.
5. Informative References
[RFC1321] Rivest, R., "Message Digest Algorithm MD5", RFC 1321,
RMON WG Expires January 2005 [Page 17]
INTERNET DRAFT RAQMON PDU July 2004
April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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. Weijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 3414, December 2002.
[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.
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,
RMON WG Expires January 2005 [Page 18]
INTERNET DRAFT RAQMON PDU July 2004
and any of which we become aware will be disclosed, in accordance
with RFC 3668.
7. 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
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.
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:
RMON WG Expires January 2005 [Page 19]
INTERNET DRAFT RAQMON PDU July 2004
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.
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.
8. 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
RMON WG Expires January 2005 [Page 20]
INTERNET DRAFT RAQMON PDU July 2004
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
Email: eugene_golovinsky@bmc.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 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 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 implementors or users of this
specification can be obtained from the IETF on-line 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 which may cover technology
that may be required to practice this standard. Please address the
RMON WG Expires January 2005 [Page 21]
INTERNET DRAFT RAQMON PDU July 2004
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 January 2005 [Page 22]
