1 / 10

OAM – an end-user perspective

OAM – an end-user perspective. Presented by: Yaakov (J) Stein RAD Data Communications Ltd. Unique Access Solutions. FM and PM. Traditionally, a distinction has been made between 2 OAM functionalities F ault M onitoring (FM) OAM runs continuously/periodically at required rate

hiero
Download Presentation

OAM – an end-user perspective

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. OAM – an end-user perspective Presented by: Yaakov (J) Stein RAD Data Communications Ltd. Unique Access Solutions

  2. FM and PM Traditionally, a distinction has been made between 2 OAM functionalities • Fault Monitoring (FM) • OAM runs continuously/periodically at required rate • detection and reporting of anomalies, defects, and failures • used to trigger mechanisms in the • control plane (e.g. protection switching) and • management plane (alarms) • required for maintenance of basic connectivity • Performance Monitoring (PM) • OAM before enabling a service or when service quality degrades • measurement of performance criteria (delay, PDV, etc.) • required for maintenance of Quality of user Experience (QoE) In traditional Connection Oriented (CO) networks these functionalities are relatively non-overlapping although Packet Loss Ratio (PLR) is in both : • low ratios in PM • high ratios in FM

  3. From CO to CL Networks The ITU defines a connection in a CO network as an association between an input and output ports (topological definition – agnostic to distance between input and output ports) A trail (ITU-T definition) is basically • a connection with OAM For ConnectionLess (CL) networks the ITU-T defines a flow as a group of packets with common routing (probable interpretation: packets • coming from the same input • going to the same output • that require the same treatment <including routing> Isn’t this a FEC ?) A connectionless trail is • a flow with OAM But do these CL definitions make any sense ?

  4. Meaningful flows For the concept of a flow to be meaningful in this context There need to be enough packets in each flow • one or two packets do not constitute a meaningful flow ! Packets in each flow need to be sufficiently related • otherwise it does not make sense to treat similarly (QoE) • difficulties - new waists of Internet hourglass Flows need to be recognizable by the Network Elements (NEs) • NEs that insert/monitor the OAM need to recognize the flows • e.g., an IP flow could be defined by 5-tuple and time • difficulties : • peer-to-peer file transfer – many 5-tuples for single application • L2/3-VPNs – many users may use the same 5-tuples • encryption may hide port numbers

  5. Flow lengths – empirical evidence To test the number of packets in a typical flow We recorded headers from an international link of an ISP We sampled • both residential and business IPVPN • at various hours of the day We analyzed the number of packets in a “unidirectional flow” • common 5-tuple (deeper DPI did not substantially change results) • no lapse for 5 seconds (Gb interface carries about 1.5M pps) Analysis still a work in progress

  6. Residential Internet – flow length distribution (1) • most flows VERY short (>50% single packet) • average length  7 • long tail (power law) P(L)  L-1.85 • some  length flows (UDP and peer-to-peer) • Conclusion only small fraction of packets are in flows 5 sec of traffic on Gb link

  7. Residential Internet – flow length distribution (2) • more BW in VERY short than longer ( 3% BW are single packet) • average length  400 • for long lengths BW  flow length • Conclusion sizeable small fraction of BW are not in flows 5 sec of traffic on Gb link

  8. IPVPN – flow length distribution • most flows VERY short (>50% single packet) • average length (weighted on flows, not BW)  40 • long tail (power law) • usually no  length flows (and practically no peer-to-peer) • Conclusion Most packets are in very short flows (too short to warrant classification)

  9. Proposals (1) • leave most FM to lower levels - Ethernet, MPLS-TP, SDH/OTN, but not IP where it is needed for : • FRR/protection • SLAs enforcement • etc. and where the needed functionality is mostly already defined • end-users need a rather limited set of tools : • FM for the access network • PM for the access network and the end-end path don’t over-engineer • IPPM has developed methodologies and tools don’t re-invent the required measurements can be performed by TWAMP-lite reflectors in (or very close to) edge routers

  10. Proposals (2) • OAM needs to determine/measure : • for access network only : • [FM] connectivity (are we getting out to the Internet ?) 1 CC per second is usually sufficient Note: this can be indicated to user as limited connectivity and statistics collected for SLA enforcement • for both access leg and end-end path • [PM] unidirectional data rates • [PM] round-trip latency access network

More Related