1 / 9

Authors Presenter: Weiqiang Sun sunwq@{mit, sjtu}

Label Switched Path (LSP) D ata P ath Delay M etrics in Generalized MPLS/ MPLS-TE Networks Draft-ietf-ccamp- dpm -01.txt. Authors Presenter: Weiqiang Sun sunwq@{mit.edu, sjtu.edu.cn}. Background. This draft (the individual version) is a product of WGLC for the dppm draft (now RFC 5814)

maxwell-rasmussen
Download Presentation

Authors Presenter: Weiqiang Sun sunwq@{mit, sjtu}

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. Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS/ MPLS-TE NetworksDraft-ietf-ccamp-dpm-01.txt Authors Presenter: Weiqiang Sun sunwq@{mit.edu, sjtu.edu.cn}

  2. Background • This draft (the individual version) is a product of WGLC for the dppm draft (now RFC 5814) • Uses the same frame work as RFC 5814 • Accepted by CCAMP as a working group doc in May 2010 • Defines a series of metrics that complement RFC 5814, in the sense that CP and DP configurations may not be consistent.

  3. Changes made from the -00 version • A couple of editorial changes • Technical changes • The percentile of Metric sub-section: changed to use RFC 5814 text • Two metrics are added

  4. The metrics added • PSFD • Path Sent to Forward Data path becomes available • PSRD • Path Sent to Reverse Data path becomes available

  5. Why do we add these metrics (I) • The previously defined metrics are intended to complement the DPPM draft • The DPPM metrics measures the CP delay • The -00 DPM metrics measures the diff of the actual implementation against ideal values • If one implementation is not conformant with RSVP-TE specs, both measurements are necessary if one need ``real’’ signaling performance

  6. Why do we add these metrics (II) • The newly added metrics provide “one-stop” results • Can measure actual signaling performance • Will this render the DPPM doc useless? • The answer is no! • DPPM metrics are easy to obtain, and • for many cases it is sufficient according to our experience • To us, the DPM draft is still a complement to RFC 5814, even after adding the metrics

  7. Next steps • We are open for any comments/suggestions • Will revise the draft according feedbacks from the WG • Hope WGLC can be done early next year

  8. Thank you! Weiqiang Sun sunwq@mit.edu

  9. Metrics defined in the -00 version • RRFD: the delay from RESV Received to Forward data path becomes available • RSRD: the delay from RESV Sent to Reversed data path becomes available • PRFD: the delay from PATH Received to Forward data path becomes available

More Related