Transcript PPT Version

Realtime Application QOS Monitoring (RAQMON)
Framework
56th IETF Session – San Francisco
RMON Work Group
Anwar Siddiqui, Dan Romascanu, Eugene Golovinsky
<draft-ietf-rmonmib-raqmon-framework-01.txt>
1
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
2
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
3
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. )
4
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?
5
Item # 3: Mandatory Support of Transport Protocol
Option A

Option B
RRC MAY support either RTCP OR
SNMP as Transport Protocol

RRC MUST support RTCP AND SNMP
as Transport Protocol for compliance
Note: If one implements the RAQMON MIB,
SNMP support is almost given!
ADVANTAGES:
– Simple RRC Design
DISADVANTAGES:
– RDS/RRC Pair needs to know about
each others transport protocol type
ADVANTAGES:
– Flexible Operation
DISADVANTAGES:
– Adds complexity in RRC implementation
RRC Conformance!
6
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
7
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/IP
i. Rely on RTCP BYE Packet
ii. RRCs can time out for in active RDSs
Case B: SNMP/UDP/IP
i. RRCs can time out for in active RDSs
Realtime information needs to be stored for historical purpose!
8
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)
9
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!
10
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!
11
RAQMON Protocol Data Unit (PDU)
56th IETF Session – San Francisco
RMON Work Group
Anwar Siddiqui, Dan Romascanu, Eugene Golovinsky
<draft-ietf-rmonmib-raqmon-pdu-01.txt>
12
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
13
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
14
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!
15
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
16
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!
17
Item # 4: Handling Compound Application Sessions

Compound application sessions can be reported in one BASIC PDU

Clarifying text is needed to explain
A. When to report multiple application session within the same DSRC of a BASIC PDU
B. When to report multiple application session in different DSRC
C. Do we need to keep the RC_n unchanged when the RDSs have started a session
RDS 1
AUDIO
RDS 2
RDS 3
TEXT
RDS 1
AUDIO
RDS 2
TEXT
RRC
RRC
•Same DSRC in BASIC PDU
• Different DSRC in BASIC PDU
• One RAQMON BASIC PDU
from RDS  RRC
• Different RAQMON BASIC PDU
from RDS  RRC
18
Item # 5: IANA Registration
 IANA Port for RAQMON PDUs over RTCP
Version &
subtype
PT=204
Length
SSRC/CSRC
Name=RAQMON (ascii)
RAQMON PDU
RTCP APP
Packet
RAQMON
specific and
IANA
Registered
 IANA Port for RAQMON PDUs over SNMP
19
RAQMON MIB
56th IETF Session – San Francisco
RMON Work Group
Anwar Siddiqui, Dan Romascanu, Eugene Golovinsky
<draft-ietf-rmonmib-raqmon-mib-00.txt>
20
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
21
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 Endto-End Delay
 Configuration Issues!
22
Backgrounder
23
RAQMON Context Setting
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
24
Item # 1: Extensibility of RAQMON PDUs (cont.)
-
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
Framework Accommodates addition of new parameters to the list25…..
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
26
Framework Definition
Out of Scope of Charter
Protocol used to communicate between APPs
Measurement Methodology Used
Measurement Accuracy
End Device
RDS
X
End Device
RDS
UNDERLYING TRANSPORT
(e.g. RTCP, SNMP)
Common RAQMON
PDU format
RRC
SNMP
RAQMON
MIB
Scope of the Framework
Existing Transport Protocol to carry RAQMON PDU
RAQMON SNMP MIB
27
RAQMON Architecture (Functional )
IP End Device
Communication
Network

APPLICATION
Context-sensitive Metrics (e.g.VoIP vs. Instant Messaging)

IP
PSTN
Cellular
Optical
RAQMON Data
Source (RDS)
Variable Metrics list Updated
using RAQMON PDU
Transport Protocol
Agnostic
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)
Network Alarm
Manager

(IP Address, port)
RAQMON
Report Collector
(RRC) # 1
SNMP
RAQMON MIB
Management
Application
28
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
29
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
SSRC/CSRC
Name=RAQMON (ascii)
RAQMON PDU
RTCP APP
Packet
RAQMON
specific and
IANA
Registered
30
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
31
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.
32
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.
33