Download PPT Version

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Computer network wikipedia , lookup

Distributed firewall wikipedia , lookup

Remote Desktop Services wikipedia , lookup

Airborne Networking wikipedia , lookup

Network tap wikipedia , lookup

Net bias wikipedia , lookup

TCP congestion control wikipedia , lookup

Multiprotocol Label Switching wikipedia , lookup

Lag wikipedia , lookup

Serial digital interface wikipedia , lookup

Asynchronous Transfer Mode wikipedia , lookup

Internet protocol suite wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

RapidIO wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

IEEE 1355 wikipedia , lookup

Wake-on-LAN wikipedia , lookup

UniPro protocol stack wikipedia , lookup

Deep packet inspection wikipedia , lookup

Transcript
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
Draft-ietf-rmonmib-raqmonframework-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,
RAQMON Data Model
-
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
2
-
Session Setup Date/Time
Session Setup delay
Session duration
Session Setup Status
3
-
Source Layer 2 Priority
Destination Layer 2 Priority
Source Layer 3 Priority
Destination Layer 3 Priority
1
4
5
-
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 %)
-
CPU utilization in Fraction (in %)
Memory utilization in Fraction (in %)
…add other parameters by using extension of Vendor Specific part of PDU
Comments and Open issues wrt. draft-ietfrmonmib-raqmon-framework-07.txt
•
5.7 Session Setup Date/ Time
–
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
–
5.11/ 5.12 End-to-End delay
–
Should be titled "Report Date/ Time"
as it relates to the time at which the
report was generated rather than the
session setup
•
–
•
"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
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
Comments and Open issues wrt. draft-ietfrmonmib-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?
•
–
5.16 etc
–
See above
Some IP endpoints separate
signaling and media path system
components. It would be more
practical to say that applications
packets MAY include signaling
packets
•
•
–
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
•
•
Accepted
5.20 Cumulative Packet Loss
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“
•
•
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
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
– 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
• RDS can implement either
• change template for new
one, but RRC MUST
IPR requirements
implement both
• IANA considerations
• Syntactical rearrangement of PDU to
accommodate 4 New
Parameters
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
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
……………………..
Shortened
Report Type
ReArrangement
256 Sub
sessions
……………………..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
SMI Enterprise Code = "xxx"
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Report Type = "yyy"
| Length of Application Part
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
application/vendor specific extension
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extensions
Draft-ietf-rmonmib-raqmon-mib04.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
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