Sync in an NFV World (Ram, ITSF 2016)
•Download as PPTX, PDF•
0 likes•333 views
Network functions virtualization (NFV) has the potential to transform the way operators offer services. While it brings with it flexibility to enable operators to offer customizable services that can deliver great value to the end user - or as a leading carrier describes it, a "user-defined network" - it can also complicate network operations. Some of the concerns over sync and NFV are already being addressed in the data center world. Take, for example, in large financial trading houses where synchronization is tightly coupled into the software architecture to provide microsecond-level time-stamping to trades. This presentation examines the new options for synchronization as it relates to NFV - and what it will take to enable accurate synchronization over a virtual network.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Sync in an NFV World (Ram, ITSF 2016)
Similar to Sync in an NFV World (Ram, ITSF 2016) (20)
Recently uploaded
Recently uploaded (20)
Sync in an NFV World (Ram, ITSF 2016)
- 1. Sync in an NFV World www.calnexsol.com
- 2. • What is Virtualisation? What is NFV? • Standards for NFV • Why does NFV affect sync? • Challenges, Questions, Thoughts • Summary Sync in an NFV World 2
- 3. What are Virtualisation and Network Function Virtualisation? 3
- 4. Doing in software what is traditionally done in hardware by emulating the hardware Virtualisation 4 We replace this With this
- 5. • Network Functions Virtualization • The replacement of dedicated network elements with software implementations running on standard servers What is NFV? Router Firewall NAT RNC SGSN/GGSN Media Gateway Dedicated hardware for each function Virtual Appliance Virtual Appliance Virtual Appliance Virtual Appliance Virtual Appliance Virtual Appliance Virtual Appliance Standard shared hardware, virtual functions 5
- 6. Virtualisation Layers 6 COTS Hardware running a Type 1 Hypervisor (e.g. VMWare) COTS Hardware running a Traditional OS (e.g. Linux or Windows) Type 2 Hypervisor (E.g. KVM/QEMU or Virtual Box) VM running a guest OS VM running a guest OS VM running a guest OS VM running a guest OS VM running a guest OS VM running a guest OS Virtual Network Functions Virtual Network Functions Virtual Network Functions Virtual Network Functions Virtual Network Functions Virtual Network Functions Physical NICs Physical NICs Virtual NICs and Switches Virtual NICs and Switches COTS = Commercial Off the Shelf System OS = Operating System NIC = Network Interface Card VM = Virtual Machine
- 7. Why adopt NFV? 7 Massively Increased Flexibility Greatly Increased Speed of Deployment and Reconfiguration +
- 8. Standards 8
- 9. ETSI NFV Reference Architecture 9
- 10. • ETSI have finalized several Standards, Recommendations and Use Cases for NFV. • http://www.etsi.org/technologies-clusters/technologies/nfv • Virtualization Requirements document, Section 5.8: • http://www.etsi.org/deliver/etsi_gs/NFV/001_099/004/01.01.01_60/gs _NFV004v010101p.pdf • Service Assurance suggests the use of IEEE 1588 timestamps • Implemented on the NIC to establish a common time base for physical layer and upper layer processes • Timestamps to be used as precise time labels for all event processes Standards for NFV Sync 10
- 11. Why does it affect Sync? 11
- 12. 1) Accurate Sync needs deterministic elements and quality components 2) Software is both slower and less deterministic than hardware 3) The underlying processor hardware is usually clocked by a relatively low quality oscillator Why Does it affect Sync? 12
- 13. Disk 13 Process 1 Process 2 Process 3 Process 4 Processor Process 5 Interrupt Routine Interrupt What Makes Software Less Deterministic? The processor is usually shared between multiple processes. The number of active processes typically varies dynamically. Processes can be swapped out to disk to make space – this takes time. Interrupts can happen at any time – disrupting the flow of operations Scheduler
- 14. 1) Memory access times vary depending on type cache, static, dynamic, virtual, etc. 2) Modern processor techniques make predictability difficult. Predicting exactly how long a sequence of instructions will take is very difficult 3) Multi-threading and different numbers of processor cores. 4) Processors execute at different speeds at different times A given piece of software will run at a different rate on different machines. 5) Software is written in high level languages which are then compiled Each time the code is changed, the sequence and therefore the timing changes. What Else Makes Software Less Deterministic? 14
- 15. Challenges, Questions and Thoughts for NFV Sync 15
- 16. How Do We Get Accurate Time Into a VM? 16 VM running a guest OS VM running a guest OS VM running a guest OS • A sync chain requires dedicated hardware • Virtualising it will not be good enough for most real world applications • A boundary clock is a hardware function – making use of oscillators, PLL’s etc. • As soon as we cross into the software domain, things become less predictable.
- 17. 17
- 18. External GM compares returned time to GPS Lessons: Connectivity to cloud instances is key. Enormous variation depending on VM technology. Possible to sync reasonably well with off the shelf technology now given smart enough smoothing. An example from Finance 18 FSMLabs TimeKeeper based system holds Amazon VM instances to within 10 microseconds accuracy over internet High precision time source AWS instance that acts as boundary clock to serve slaves within the AWS cloud
- 19. A suggestion for Telecoms 19
- 20. A suggestion for Telecoms (contd.) 20
- 21. How accurate might we be able to make a software PTP implementation? How accurately might we be able to transfer and maintain time within a VM with or without specialised hardware? How can we solve the measurement challenge – how to verify accuracy? Questions – Research Needed 21
- 22. • NFV is coming, like it or not • Most major operators are considering it, if not actively planning for it • Probably the biggest shake-up of telecoms networks since voice-data convergence 10 years ago • Sync will be affected • NFV doesn’t remove the need for sync, sync methods need to evolve • New models of operation will be established • New opportunities will be created • The industry is moving forward • Techniques to lock SW to HW • Techniques to maintain SW accuracy • Network & equipment architecture ideas • Are we looking at a new generation of hardware or architecture? Summary 22
- 23. Questions? Ask them! Go to: @ calnexsol.com/en/blog and Ask Tim Tim’s Time & Sync Blog
Editor's Notes
- NFV – often included in the same sentence as SDN, although they’re not the same. Lots of hype – lots and lots of hype – but it’s definitely a hot area.
- Write code to emulate hardware elements. A level of abstraction. This is not a new idea.
- The paths inside the machine are virtual – there is nowhere to connect hardware probes in order to monitor the traffic. Only the traffic that passes through the physical NICs can be tapped and monitored using hardware. We can create software taps to provide a similar function – but as we will see, the problems that affect software sync in general come into play.
- Sharing of hardware resources Commodity hardware – maybe still expensive but easy to procure Economies of scale Reduced CAPEX, OPEX Reduced cost of deploying new functions Reduced barriers of entry for independent software vendors Increased competition for suppliers Improved capacity management Rapid deployment of new networks and services Rapid reconfiguration
- There is a lot of work going on within the ETSI NFV ISG to specify standards. Split into a number of different areas. A lot of discussion with open source groups as well. As can be seen from the above diagram, there is a significant ecosystem in the NFV world.
- The word precise is underlined in the above – but the level of precision is not defined. Therein lies the challenge.
- This slide illustrates the unpredictable nature of software. Even with a round robin scheduling algorithm, the number of processes can change – so you can’t necessarily predict when the next timeslot will come along. You can only process when you have the processor – and when your timeslot expires you lose the processor. Even real time operating systems have latency – although they can prevent designated processes from being swapped out or interrupted. - Processes can be swapped to and from disk. This takes an unpredictable amount of time – depends on process size, disk speed etc. - An interrupt can come along at any time – indeed interrupts can queue up – which may or may not take priority over the currently running process.