Transcript PPT Version

Realtime Application QOS Monitoring (RAQMON)
Framework
55th IETF Session – Atlanta
RMON Work Group
Anwar Siddiqui, Dan Romascanu, Eugene Golovinsky
<draft-siddiqui-rmonmib-raqmon-framework-00.txt>
1
Context Setting for the proposal
MG
PDA
Application level priority (e.g. RSVP for S1, but no RSVP for S2)
Applications
Applications
Streaming Media, Transaction, Bulk data transfer etc
RTP / FTP/ HTTP
RTP / FTP/ HTTP
Various packet level priority ( TOS, DiffServ etc.)
TCP/UDP
IP
IP
MAC IEEE 802.3
PHYSICAL
Domain 1
IP
IP
MAC 802.3
MAC 802.3
PHYSICAL
PHYSICAL
PHYSICAL
Router
IP End Points
Router
IP End Points
IP Network
TCP/UDP
Domain 2
…….
Domain N
MAC IEEE 802.3
Domain
N+1
Multiple Equipment vendors, Multiple geographic locations, Multiple xSPs
Control multiple Administrative and Provisioning domain
2
RAQMON Network Configuration
Video/IP/IM/Voice
Corporate
Network
Application
Administrator
Statistics
Reported
Voice over IP
T e le ph one
T e le ph one
T e le ph one
Rou ter
Fa x
Monitoring
Applications via
SNMP
Laptop c omputer
SNMP
LAN/VPN
INTRANET
SNMP
Regional Report Collector
(Periodic Packets to populate MIB)
IP Network
Media Gateway
Wireless
Gateway
SNMP
SNMP
Network /
Application Service
Provider
PDA
PDA
Bluetooth
Laptop c omputer
3
Scope of the Framework
Out of Scope of Framework
Protocol used to communicate
Measurement Methodology
Measurement Accuracy
End Device
RDS
X
End Device
RDS
RAQMON
PDU over
RTCP or
SNMP
RRC
SNMP
RAQMON
MIB
Scope of the Framework
Existing Internet Protocol used to carry RAQMON PDU
RAQMON SNMP MIB
4
RAQMON Architecture (Functional )
IP End Device
Communication
Network

APPLICATION
Context-sensitive Metrics (e.g.VoIP vs. Instant Messaging)
Transport Network Condition Specific Metrics (e.g. Jitter)
Network Policy Specific ( e.g. RSVP Failed, Diffsrv = EF)
Device Sate Specific Metrics (e.g. CPU Usage)

IP
PSTN
Cellular
Optical
RAQMON Data
Source (RDS)
Variable Metrics Parameters
Updated using RAQMON PDU
Transport Protocol
Agnostic
Network Alarm
Manager

(IP Address, port)
RAQMON
Report Collector
(RRC) # 1
SNMP
SNMP
RAQMON MIB
Management
Application
5
Metrics “pushed” by the RDS to RRC
-
Data Source Name (DN)
Receiver Name (RN)
Data Source Address (DA)
Receiver Address (RA)
Data Source Device Port used
Receiver Device Port used
Session Setup Date/Time
Session Setup delay
Session duration
Session Setup Status
End-to-End Delay
Inter Arrival Jitter
Total number of Packets Received
Total number of Packets Sent
-
Total number of Octets Received
Total number of Octets Sent
Cumulative Packet Loss
Packet Loss in Fraction
Source Payload Type
Receiver Payload Type
Source Layer 2 Priority
Destination Layer 2 Priority
Source Layer 3 Priority
Destination Layer 3 Priority
CPU utilization in Fraction
Memory utilization in Fraction
-
Application Name/version
This is a suggested matrix …..
Framework Accommodates addition of new parameters to the list6 …..
What is not proposed in RAQMON Framework!
 Creation/Extension/Modification of any existing protocol in
order to support RAQMON PDU is out of scope of the
RAQMON charter proposal
 Methodology to measure any of the QOS parameters defined in
the RAQMON Framework is out of scope for this proposal.
– Measurement algorithms are left upon the implementers and equipment
vendors to choose.
– Consistent with other RMON WG work items like APM, TPM etc.
7
Overall RAQMON I-D Status
 RAQMON idea was first presented at 51st IETF session in RMON WG
– There seemed interest in 51st IETF session by the RMON community
 RAQMON I-D was made available for 52nd IETF
– draft-siddiqui-rmonmib-raqmon-mib-00.txt
 Discussions around RAQMON I-D have happened
– within the RMON mailing list during 52nd and 53rd IETF
– out of band interest/comments from various vendors for participation
 Official RAQMON charter went out after 54th IETF
– 3 drafts were called out in the charter
– RAQMON Framework, RAQMON PDU and RAQMON MIB
8
RAQMON Protocol Data Unit (PDU)
55th IETF Session – Atlanta
RMON Work Group
Anwar Siddiqui, Dan Romascanu, Eugene Golovinsky
<draft-siddiqui-rmonmib-raqmon-pdu-00.txt>
9
RAQMON PDU Overview

A set of RAQMON Application level PDUs to have “common formats” for reporting statistics
–

RAQMON PDUs will be transported over existing protocols
–
–

Minimal (preferably No) setup transaction to tell the collector which metrics the data source will be sending later on.
RAQMON PDUs can be lossy
–

RDS reports what “IT” feels to be appropriate for the “application context”
RRC consumes what “IT” feels to be appropriate for the “application context”
RDS  RRC communication should be stateless
–

RTCP (using RTCP APP Packets)
SNMP (using SNMP INFORM)
RDS and RRC are Peer-to-Peer entities
–
–

Between a RAQMON Data Source (RDS) and a RAQMON Report Collector (RRC).
Complementary to IPFIX charter
RAQMON PDUs should be extensible for future
–
To add additional matrices
10
RAQMON PDU Types
 BASIC PDU
– Basic PDUs are TLV pair
– Draft provides a list of initial matrix (i.e. not meant to be exhaustive)
– Matrix parameters are selected by the apps
– Compound sessions can be reported as multiple sub-sessions
– End devices control the rate of reporting
 APP PDU
– Can be extended to add new parameters not spelled out in initial draft
11
RAQMON PDU over RTCP
 RAQMON PDUs inside RTCP APP Packets
 Different Ports will be IANA registered for RAQMON PDUs over RTCP
Version &
subtype
PT=204
Length
RTCP APP Packet
SSRC/CSRC
Name=RAQMON (ascii)
RAQMON PDU
RAQMON specific
and
IANA Registered
12
RTCP Pros and Cons
PROS
 Using a well-known protocol.
 Very light weight
 Privacy and authentication are
covered by RTP/RTCP
 No acknowledgement required
CONS
 RRC is burdened by RTCP
 RRC have to be RTCP sink!
– Need to understand atleast RTCP
APP Packets
13
RAQMON PDU over SNMP
 RDSs will not be required to respond to SNMP requests
–
Keep the RDS design simple.
 The RDS “MAY” ignore the SNMP Inform Responses, or, if better
–
Requires retransmission Inform PDU
 RAQMON information is mapped to an SNMP Inform PDU in 2 ways.
–
–
Mapping RAQMON data items to MIB variables (i.e. uses NOTIFICATION-TYPE macro)
Encoding RAQMON PDU format within a small set of MIB items.
14
SNMP Pros & Cons
PROS
 Using a well-known protocol.
 Easy integration with RMON
Framework
 Privacy and authentication are
covered by SNMPv3
 RRC can use an SNMP manager
implementation to process
Informs.
CONS

Overhead SNMP puts on low-powered
RDSs!
– BER encoding on a PDA or a pager or
in an IP Phone
Proposed Solution: To alleviate this, possibility of
encoding INFORM PDUs using UTF-8 should be studied
further. However this would require
–
–



a RAQMON PDU specific code in the RRC, and
a new IANA UDP port
Acknowledgements from RRCs to
RDSs can create bottleneck
Session centric RDS design
Sending ACKs also wastes network
bandwidth.
15
Backgrounder
16
Relationship to current work in various WGs
 Rapmon Framework correlates “per transactions statistics” to “performance
of a particular transaction” (e.g. call setup  call’s media stream performance)
 Proposed Rapmon Framework conforms to APM and TPM completely.
 Rapmon work is complementary to the work that’s going on in ippm WG.
 This proposal conforms to ippm WG’s recommendations fully.
 Proposed Rapmon Framework is complimentary to current work that is
going on in the areas of synthetic source.
17