1 realtime application qos monitoring (raqmon) framework 56 th ietf session san francisco rmon work...
DESCRIPTION
3 Changes/Updates/Modification in framework–01.txt –Editorial Changes & clean up (work continues!) –Re-arrangements of sections as suggested in the mailing list and various IETF Sessions –Better Architectural Definitions upfront in the document –Better Definitions of parameters –Guidance on selecting appropriate measurement methodologies based on application text (e.g. End-to-End Delay) –Clear text on “extensibility” of the PDU Types in the framework –Incorporation of One Way End-to-End Delay in BASIC PDU –Removed 8 bit vendor specific information from BASIC PDUTRANSCRIPT
1
Realtime Application QOS Monitoring (RAQMON) Framework
56th IETF Session – San FranciscoRMON Work Group
Anwar Siddiqui, Dan Romascanu, Eugene Golovinsky
<draft-ietf-rmonmib-raqmon-framework-01.txt>
2
RAQMON Framework Draft – Progress Status
RAQMON I-D accepted as RMON WG draft during IETF 55 @ Atlanta
draft-ietf-rmonmib-raqmon-framework-00.txt issued on 01/15/2003
draft-ietf-rmonmib-raqmon-framework-01.txt issued on 03/03/2003
WG last call deadline APRIL’ 2003
3
Changes/Updates/Modification in framework–01.txt
– Editorial Changes & clean up (work continues!)– Re-arrangements of sections as suggested in the mailing list and various IETF
Sessions– Better Architectural Definitions upfront in the document– Better Definitions of parameters – Guidance on selecting appropriate measurement methodologies based on
application text (e.g. End-to-End Delay)
– Clear text on “extensibility” of the PDU Types in the framework
– Incorporation of One Way End-to-End Delay in BASIC PDU
– Removed 8 bit vendor specific information from BASIC PDU
4
Item # 1: Extensibility of RAQMON PDUs
BASIC PDU defines a pre-listed set of parameters– Currently allows 28 pre-listed parameters
Use RAQMON APP PDUs to add additional parameters– Vendor specific information – Application specific information/profile (e.g. echo cancellation type, echo length etc. )
5
Item # 2: Extensibility of Transport protocol
RAQMON PDUs are carried over– RTCP– SNMP
Do we allow more transport protocols to carry RAQMON PDUs?
If Yes: Do we need to address that issue in the Framework Document?
6
Item # 3: Mandatory Support of Transport Protocol
RRC MAY support either RTCP OR SNMP as Transport Protocol
Note: If one implements the RAQMON MIB, SNMP support is almost given!
ADVANTAGES:– Simple RRC DesignDISADVANTAGES:– RDS/RRC Pair needs to know about
each others transport protocol type
RRC MUST support RTCP AND SNMP as Transport Protocol for compliance
ADVANTAGES:– Flexible OperationDISADVANTAGES:– Adds complexity in RRC implementation
Option A Option B
RRC Conformance!
7
Item # 4: Lossy vs. Lossless
Being lossless is not a RAQMON Requirement for the – RAQMON PDUs COULD be “lossy”
– RAQMON PDUs do not guarantee delivery nor does it assume that the underlying network is reliable!
RDS/RRC Sessions could be engineered to be lossless– RAQMON PDUs itself does not provide any mechanism to ensure timely delivery
but relies on lower-layer services to do so. – Option A: RAQMON PDU over RTCP/TCP/IP– Option B: RAQMON PDU over SNMP/TCP/IP (deployment ??)
Will add clarifications on this in the Framework Doc
8
Item # 5: Coping with lossy transport
RDSs never re-transmits– RDS design is simple/stateless
RRCs does not try to recover lost packets– RAQMON not be used for mission critical applications (e.g. billing)
RRCs may handle open “reporting” sessions with Case A: RTCP/UDP/IPi. Rely on RTCP BYE Packetii. RRCs can time out for in active RDSsCase B: SNMP/UDP/IPi. RRCs can time out for in active RDSs
Realtime information needs to be stored for historical purpose!
9
Item # 6: One Way vs. Roundtrip End-to-End Delay
One Way End to End Delay is explicit in the Framework– End-to-End Delay in Previous drafts Roundtrip End-to-End
Delay in current draft– One Way End-to-End Delay is also reflected in aggregation
process– Need to reflect in the MIB!
Applications/end devices can select either End to End Delay parameter to report as felt appropriate by selecting appropriate RPPF bit (RAQMON Parameter Presence Flags)
10
Item # 7: A Suggestive list of Provisioning parameters
Clarifying text on a list of parameters that RDSs may need be provisioned with before reporting to RRC.
– RRC IP Address– RRC Port– Type of Transport Protocol supported by RRC– Rate of Transmitting PDUs/Time Interval
Please comment if something is missing!
11
Item # 8: Mandatory Security Requirements
RDS/RRC MUST support some sort of Authentication for compliance (or not!)– RDS/RRCs must support some authentication!
Should RRC Police rate an RDS at RRC level to avoid DOS attack?
Could use security reviews/help!
12
RAQMON Protocol Data Unit (PDU)
56th IETF Session – San FranciscoRMON Work Group
Anwar Siddiqui, Dan Romascanu, Eugene Golovinsky
<draft-ietf-rmonmib-raqmon-pdu-01.txt>
13
RAQMON PDU Draft – Progress Status
RAQMON PDU I-D accepted as RMON WG draft during IETF 55 @ Atlanta
draft-ietf-rmonmib-raqmon-pdu-00.txt issued on 01/15/2003
draft-ietf-rmonmib-raqmon-pdu-01.txt issued on 03/03/2003
WG last call deadline MAY’ 2003
14
Changes/Updates/Modification in last draft
– Editorial Changes & clean up (work continues!)– Better Definitions of parameters units (ms, Sec, %, second etc)
– Incorporation of One Way End-to-End Delay in BASIC PDU
– Removed 8 bit vendor specific information from BASIC PDU– All vendor specific/special application specific values goes to APP PDU
15
Item # 1: Rate of Reporting
Option A: Rate Controlled Approach: Algorithms that MAY be used as to calculate rate of reporting
given a target Bandwidth allocated for reporting!– Recommendation on no more than 10% bandwidth be wasted for Reporting
as a guideline!
Option B: Pre-Provision Approach: Guidelines on “pre-provisioning” RDSs with specific Transmission
Rate is included (section 2.1.1 of the Framework Draft)
Both Approaches are supported and documented!
16
Item # 2: Congestion Avoidance
Recommend usage of TCP as transport for congestion control
– Option A: RAQMON PDU over RTCP/TCP/IP– Option B: RAQMON PDU over SNMP/TCP/IP (any deployment issue)
Recommendation on no more than 10% aggregate bandwidth be wasted for Reporting as a design guideline guideline!
– Reference Algorithms that MAY be used as to calculate rate of reporting given a target Bandwidth allocated for reporting!
– Guidelines on “pre-provisioning” RDSs with specific Transmission Rate (e.g. 1 PDU every 5 seconds)
– section 2.1.1 of the Framework Draft
17
Item #3: RAQMON PDU Level Compliance
Clarifying text on BASIC RAQMON PDU– Every BASIC PDU MUST include RPPF bits (RAQMON Parameter Presence
Flags) – BASIC PDU without any parameter will be considered as VALID (RPPF = 0)– RRCs would have the option to drop such PDUs with RPPF = 0– BASIC PDU MUST be used while reporting any parameter pre-listed in BASIC
PDU set
APP PDU– Can be extended to add new parameters not spelled out in BASIC PDU– Its not Mandatory to send a BASIC PDU before sending an APP PDU – Vendors should not use APP PDUs to carry the same parameters pre-
identified in BASIC PDU (Will ensure better Interoperability)
Re-issue the PDU draft with above mentioned level of compliance!
18
Item # 4: Handling Compound Application Sessions
Compound application sessions can be reported in one BASIC PDU
Clarifying text is needed to explainA. When to report multiple application session within the same DSRC of a BASIC PDUB. When to report multiple application session in different DSRCC. Do we need to keep the RC_n unchanged when the RDSs have started a session
RDS 1 RDS 2AUDIO
TEXT
RRC
•Same DSRC in BASIC PDU • One RAQMON BASIC PDU from RDS RRC
RDS 2AUDIOTEXT
RRC
• Different DSRC in BASIC PDU • Different RAQMON BASIC PDU from RDS RRC
RDS 3 RDS 1
19
Item # 5: IANA Registration
IANA Port for RAQMON PDUs over RTCP
IANA Port for RAQMON PDUs over SNMP
RAQMON PDU
Name=RAQMON (ascii)
SSRC/CSRC
LengthPT=204Version & subtype
RAQMON specific and
IANA
Registered
RTCP APP Packet
20
RAQMON MIB
56th IETF Session – San FranciscoRMON Work Group
Anwar Siddiqui, Dan Romascanu, Eugene Golovinsky
<draft-ietf-rmonmib-raqmon-mib-00.txt>
21
RAQMON MIB Draft – Progress Status
RAQMON MIB I-D accepted as RMON WG draft during IETF 55 @ Atlanta
draft-ietf-rmonmib-raqmon-mib-00.txt issued on 01/15/2003
WG last call deadline MAY’ 2003
22
MIB Drafts Will be updated in next version
One Way End-to-End Delay will be added in the next version
Aggregation (i.e. Avg, Min, Max) for One Way End-to-End Delay
Configuration Issues!
23
Backgrounder
24
RAQMON Context Setting
IP Network
Applications
RTP / FTP/ HTTP
TCP/UDP
MAC IEEE 802.3
PHYSICAL
IP
MAC 802.3
IP
IP End Points Router
PHYSICAL
MAC 802.3
IP
Router
PHYSICAL
Applications
RTP / FTP/ HTTP
TCP/UDP
MAC IEEE 802.3
PHYSICAL
IP
IP End Points
PDAMG
Streaming Media, Transaction, Bulk data transfer etc
Application level priority (e.g. RSVP for S1, but no RSVP for S2)
Various packet level priority ( TOS, DiffServ etc.)
Domain 1
Domain 2 …….
Domain N+1
Multiple Equipment vendors, Multiple geographic locations, Multiple xSPs Control multiple Administrative and Provisioning domain
Domain N
25
- 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 - Round Trip End-to-End Delay - One Way 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 (in %)- 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 (in %)- Memory utilization in Fraction (in %)
- Application Name/version
Item # 1: Extensibility of RAQMON PDUs (cont.)
Framework Accommodates addition of new parameters to the list …..
26
RAQMON Network Configuration
Telephone
Laptop computer
Telephone
IP Network
Video/IP/IM/Voice
Voice over IP
Router
Media GatewayFax
Wireless Gateway
Regional Report Collector (Periodic Packets to populate MIB)
LAN/VPN INTRANET
Laptop computer
Corporate Network
Application Administrator
Monitoring Applications via
SNMP
PDANetwork /
Application Service Provider
SNMP
SNMP
SNMP
SNMP
Statistics Reported
Telephone
PDABluetooth
27
Framework Definition
RRC
Out of Scope of Charter Protocol used to communicate between APPs
Measurement Methodology Used Measurement Accuracy
Scope of the Framework Existing Transport Protocol to carry RAQMON PDU
RAQMON SNMP MIB
SNMP
RAQMON MIB
RDS RDS
X End DeviceEnd Device
UNDERLYING TRANSPORT
(e.g. RTCP, SNMP)
Common RAQMON PDU format
28
RAQMON Architecture (Functional )
Communication NetworkIP
PSTNCellularOptical
RAQMON Report Collector
(RRC) # 1RAQMON MIB
(IP Address, port)
Network Alarm Manager
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)
Variable Metrics list Updated using RAQMON PDU
SNMP
Management Application
IP End Device
RAQMON Data Source (RDS)
APPLICATION
Transport Protocol Agnostic
29
RAQMON PDU Overview
A set of RAQMON Application level PDUs to have “common formats” for reporting statistics – Between a RAQMON Data Source (RDS) and a RAQMON Report Collector (RRC).
RAQMON PDUs will be transported over existing protocols– RTCP (using RTCP APP Packets)– SNMP (using SNMP INFORM)
RDS and RRC are Peer-to-Peer entities– 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 – Minimal (preferably No) setup transaction to tell the collector which metrics the data source will be sending later on.
RAQMON PDUs can be lossy – Complementary to IPFIX charter
RAQMON PDUs should be extensible for future– To add additional matrices
30
RAQMON PDU over RTCP
RAQMON PDUs inside RTCP APP Packets Different Ports will be IANA registered for RAQMON PDUs over RTCP
RAQMON PDU
Name=RAQMON (ascii)
SSRC/CSRC
LengthPT=204Version & subtype
RAQMON specific and
IANA
Registered
RTCP APP Packet
31
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– Use MIB object to encapsulate the RAQMON PDU payload
32
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.
33
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.
Relationship to current work in various WGs