1 / 33

Anwar Siddiqui, Dan Romascanu, Eugene Golovinsky <draft-ietf-rmonmib- raqmon - framework -01.txt>

Realtime Application QOS Monitoring (RAQMON) Framework 56 th IETF Session – San Francisco RMON Work Group. Anwar Siddiqui, Dan Romascanu, Eugene Golovinsky <draft-ietf-rmonmib- raqmon - framework -01.txt>. RAQMON Framework Draft – Progress Status.

zyta
Télécharger la présentation

Anwar Siddiqui, Dan Romascanu, Eugene Golovinsky <draft-ietf-rmonmib- raqmon - framework -01.txt>

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Realtime Application QOS Monitoring (RAQMON) Framework56th 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. RRC MAY support either RTCP ORSNMP as Transport Protocol 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 RRC MUST support RTCP AND SNMP as Transport Protocol for compliance ADVANTAGES: Flexible Operation DISADVANTAGES: Adds complexity in RRC implementation Item # 3: Mandatory Support of Transport Protocol 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/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!

  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 explain • When to report multiple application session within the same DSRC of a BASIC PDU • When to report multiple application session in different DSRC • Do we need to keep the RC_n unchanged when the RDSs have started a session AUDIO TEXT AUDIO RDS 1 RDS 2 RDS 3 RDS 1 RDS 2 TEXT RRC RRC • Same DSRC in BASIC PDU • One RAQMON BASIC PDU from RDS  RRC • Different DSRC in BASIC PDU • Different RAQMON BASIC PDU from RDS  RRC

  19. Version & subtype PT=204 Length RTCP APP Packet SSRC/CSRC Name=RAQMON (ascii) RAQMON specific and IANA Registered RAQMON PDU Item # 5: IANA Registration • IANA Port for RAQMON PDUs over RTCP • IANA Port for RAQMON PDUs over SNMP

  20. RAQMON MIB56th 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 MG 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 TCP/UDP IP IP IP IP IP Network MAC 802.3 MAC 802.3 MAC IEEE 802.3 MAC IEEE 802.3 PHYSICAL PHYSICAL PHYSICAL PHYSICAL Router Router IP End Points Domain 2 ……. IP End Points Domain N Domain 1 Domain N+1 Multiple Equipment vendors, Multiple geographic locations, Multiple xSPs Control multiple Administrative and Provisioning domain

  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 Monitoring Applications via SNMP Video/IP/IM/Voice Corporate Network Application Administrator SNMP Statistics Reported LAN/VPN INTRANET Voice over IP SNMP SNMP Regional Report Collector (Periodic Packets to populate MIB) IP Network Media Gateway SNMP Wireless Gateway Network / Application Service Provider RAQMON MIB Bluetooth

  27. Framework Definition Out of Scope of CharterProtocol used to communicate between APPs Measurement Methodology Used Measurement Accuracy Common RAQMON PDU format X End Device End Device RDS SNMP RDS RRC RAQMON MIB Scope of the Framework Existing Transport Protocol to carry RAQMON PDU RAQMON SNMP MIB UNDERLYING TRANSPORT (e.g. RTCP, SNMP)

  28. RAQMON Architecture (Functional ) IP End Device  APPLICATION Communication Network IP PSTN Cellular Optical 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)  RAQMON Data Source (RDS) Network Alarm Manager Variable Metrics list Updated using RAQMON PDU  (IP Address, port) Transport Protocol Agnostic SNMP RAQMON Report Collector (RRC) # 1 RAQMON MIB Management Application

  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. Version & subtype PT=204 Length RTCP APP Packet SSRC/CSRC Name=RAQMON (ascii) RAQMON specific and IANA Registered RAQMON PDU RAQMON PDU over RTCP • RAQMON PDUs inside RTCP APP Packets • Different Ports will be IANA registered for RAQMON PDUs over RTCP

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

More Related