wg raqmon internet-drafts rmon mib wg meeting washington, nov. 11, 2004

10
WG RAQMON Internet- Drafts RMON MIB WG Meeting Washington, Nov. 11, 2004

Upload: malcolm-lane

Post on 11-Jan-2016

214 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: WG RAQMON Internet-Drafts RMON MIB WG Meeting Washington, Nov. 11, 2004

WG RAQMON Internet-Drafts

RMON MIB WG Meeting

Washington, Nov. 11, 2004

Page 2: WG RAQMON Internet-Drafts RMON MIB WG Meeting Washington, Nov. 11, 2004

New Round of IETF Drafts as IETF-60 discussions

• TCP transport

• Draft-ietf-rmonmib-raqmon-framework-07.txt– New metrics, existing metrics changes, clarifications

• Draft-ietf-rmonmib-raqmon-pdu-07.txt– Add TCP transport

– Fixes, changes, clarifications as per framework changes

• Draft-ietf-rmonmib-raqmon-mib-05.txt– Fixes, changes, clarifications as per framework changes

• Boilerplate changes for new Intellectual Property RFCs

Page 3: WG RAQMON Internet-Drafts RMON MIB WG Meeting Washington, Nov. 11, 2004

Draft-ietf-rmonmib-raqmon-framework-07.txt

• Framework and main RAQMON entities definition• Requirements

– For RDS– RRC– Transport Protocol

• RAQMON Data Model– Metrics changes, as per IETF-60 discussions

• Rename / redefine / define new metrics for Round Trip End-to-End Network Delay, One Way End-to-End Network Delay, Application Delay, Inter-Arrival Jitter, IP Packet Delay Variation, Total Number of Application Packets Received, Total Number of Application Packets Sent, Total number of Application Octets Received, Total number of Application Octets Sent, Cumulative Application Packet Discards, Packet discards in Fraction,

Page 4: WG RAQMON Internet-Drafts RMON MIB WG Meeting Washington, Nov. 11, 2004

- Data Source Name (DN) - Receiver Name (RN)- Data Source Address (DA) - Receiver Address (RA) - Data Source Device Port

used - Receiver Device Port used - Application Name

- Roundtrip End-to-End Network Delay

- One way End-to-End Network Delay- Application Delay- Inter Arrival Jitter- IP Packet Delay Variation - Source Payload Type - Receiver Payload Type- Total number of Packets Received - Total number of Packets Sent- Total number of Octets Received- Total number of Octets Sent - Cumulative Packet Loss - Cumulative Packet Discard- Packet Loss in Fraction (in %)- Packet Discard in Fraction (in %)

RAQMON Data Model

- Session Setup Date/Time - Session Setup delay - Session duration- Session Setup Status

- 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

%)

…add other parameters by using extension of Vendor Specific part of PDU

1

2

3

4

5

Page 5: WG RAQMON Internet-Drafts RMON MIB WG Meeting Washington, Nov. 11, 2004

Comments and Open issues wrt. draft-ietf-rmonmib-raqmon-framework-07.txt

• 5.7 Session Setup Date/ Time– Should be titled "Report Date/ Time"

as it relates to the time at which the report was generated rather than the session setup

• Resolve text inconsistency

– Should this be in time zone independent format to permit easier correlation on large networks?

• No, NTP format as per RFC 1305 is widely deployed operationally

• 5.8 Session Setup Delay– "The Session Setup Delay metric

reports the time taken from an origination request being initiated by an endpoint to the media path being established (or a call progress indication being received from the remote endpoint.)“

• accept

• 5.11/ 5.12 End-to-End delay– Add a note to say that the packets

used for measurement may be of a different type to those used for media (e.g. ICMP instead of RTP) and hence may differ in terms of route and queueing priority. This may result in measured delays being different to those experienced on the media path.

• Accept – work on clarification text

• 5.12 - last paragraph– it would be simpler and more logical

to say that RAQMON implementations should NOT derive one way delay by dividing rtd by 2 - just leave the parameter out if it is not known.

• Accept

Page 6: WG RAQMON Internet-Drafts RMON MIB WG Meeting Washington, Nov. 11, 2004

Comments and Open issues wrt. draft-ietf-rmonmib-raqmon-framework-07.txt (2)

• 5.13 Application delay– "The network delay metrics

described in sections 5.11 and 5.12"......"The Application Delay metrics defined in this section are intended to capture additional elements of delay"

– it is not clear if it is intended that the application delay includes BOTH encoding and buffer/decode delay, or are there two parameters?

• Clarification – receiving end delays

– it is also confusing to talk about this as application delay, which should really be end-end. Call it "application endpoint delay", or add network delay and endpoint delay and call the sum "application delay“

• See above

• 5.16 etc– Some IP endpoints separate

signaling and media path system components. It would be more practical to say that applications packets MAY include signaling packets

• Accepted

• 5.20 Cumulative Packet Loss– Since there is now a packet discard

count then it is easier to state that a late packet may be classed as discarded or lost - there should be no ambiguity

• Clarify – avoid double counting

• Mandatory use of SNMP– Clarified on list with the commenter

• RDS may use one of the transport• RRC MUST support both

Page 7: WG RAQMON Internet-Drafts RMON MIB WG Meeting Washington, Nov. 11, 2004

Draft-ietf-rmonmib-raqmon-pdu-07.txt

• Combined tcpsip I-D with the RAQMON PDU draft– Draft renamed to reflect multiple

transport

• Has two options supported in PDU Draft: – Native TCP – SNMP

• RDS can implement either one, but RRC MUST implement both

• Syntactical re-arrangement of PDU to accommodate 4 New Parameters

– End to End Delay Split• Application/End Device

Delay• Network Delay (RTT &

OWD)

– Cumulative Packet Discards– Discards (in %)

• Corrections to the MIB as per metrics changes

• change template for new IPR requirements

• IANA considerations

Page 8: WG RAQMON Internet-Drafts RMON MIB WG Meeting Washington, Nov. 11, 2004

PDU Structure 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V |PDT = 1|B| T |P|I| RC | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMI Enterprise Code = 0 |Report Type = 0| RC_N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Re-Arrangement

256 Sub sessions

Shortened Report Type

……………………..

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMI Enterprise Code = "xxx" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Report Type = "yyy" | Length of Application Part | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | application/vendor specific extension | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

……………………..

Extensions

Page 9: WG RAQMON Internet-Drafts RMON MIB WG Meeting Washington, Nov. 11, 2004

Draft-ietf-rmonmib-raqmon-mib-04.txt

– change syntax of objects in raqmonParticipantTable to Integer32 to add values of -1 in cases when the collector did not receive any report on the specific metrics

– change object names to align with [RAQMON-FRAMEWORK]

– added objects in raqmonParticpantTable to cover all metrics in [RAQMON-FRAMEWORK]

– added raqmonRDSTimeout object to control the timeout for reports in collectors

– change template for new IPR requirements

– aligned REFERENCE clauses with new numbering in [RAQMON-FRAMEWORK]

– added new mandatory IANA considerations section

Page 10: WG RAQMON Internet-Drafts RMON MIB WG Meeting Washington, Nov. 11, 2004

Conclusions and Recommendations

• WGLC comments editorial in nature– Comments resolution includes clarifications in the

framework, no impact on PDU and MIB documents

• We seem to be converging on content and quality• It’s been taking so long (11th IETF meeting!)• Recommend to forward to the IESG, with the edits

as per decisions of this meeting