OAM from the end

Download Report

Transcript OAM from the end

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
1. 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
2. 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
OAM-YJS Slide 2
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 ?
OAM-YJS Slide 3
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
OAM-YJS Slide 4
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
OAM-YJS Slide 5
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
5 sec of traffic on Gb link
• some  length flows
(UDP and peer-to-peer)
• Conclusion
only small fraction of
packets are in flows
OAM-YJS Slide 6
Residential Internet –
flow length distribution (2)
• more BW in VERY short than longer
( 3% BW are single packet)
• average length  400
• for long lengths
5 sec of traffic on Gb link
BW  flow length
• Conclusion
sizeable small fraction of
BW are not in flows
OAM-YJS Slide 7
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)
OAM-YJS Slide 8
Proposals (1)
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
2. 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
3. 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
OAM-YJS Slide 9
Proposals (2)
5. OAM needs to determine/measure :
• for access network only :
1. [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
2. [PM] unidirectional data rates
3. [PM] round-trip latency
access
network
OAM-YJS Slide 10