1 / 8

NVO3 Requirements for Tunneling

NVO3 Requirements for Tunneling . Igor Gashinsky and Bruce Davie IETF. Why tunnels?. M anage overlapping addresses between multiple tenants Decouple virtual topology provided by tunnels from physical network topology

danika
Télécharger la présentation

NVO3 Requirements for Tunneling

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. NVO3 Requirements for Tunneling Igor Gashinsky and Bruce Davie IETF

  2. Why tunnels? • Manage overlapping addresses between multiple tenants • Decouple virtual topology provided by tunnels from physical network topology • Decouple virtual network service from physical network (e.g. provide an L2 service over an L3 fabric) • Support VM mobility independent of the physical network • Support larger numbers of virtual networks (vs. VLANs for example) • Reduce state requirements for physical network (e.g. MAC addresses) • Because all CS problems can be solved with another level of indirection

  3. Disclaimers • We have a horse in this race, but we’ve tried hard to be objective • AFAICT, no existing protocol meets all the requirements in this presentation • We’ve put a lot of emphasis on compatibility with existing HW – others may differ on the importance of that

  4. Requirements Overview • Control Plane independence • Backwards compatibility • Lots of installed devices & services to consider • Context identification

  5. Control Plane Independence • Data planes tend to get baked into HW, control planes evolve • Best not to specify control plane as part of tunnel encaps

  6. Backwards Compatibility (1) • With switches and routers • IP-based encaps likely to be most compatible • ECMP – mostly looks at IP src/dst and TCP or UDP ports, so make use of that • With NICs • Most tunneling methods break TSO, causing major performance hit for host-terminated tunnels • For current generation NICs, only way to keep TSO is to completely match TCP header – see draft-davie-stt-01

  7. Backwards Compatibility (2) • Middle Boxes • Should be possible to transit them • They may need to inspect payload (e.g. for stateful firewall) • Stream or Frame Reassembly may be needed for L4/L7 services • Hardware or software-based “NV Edge” • “Edge” may be in hypervisor, physical switch, appliance etc. • With WAN services (e.g. Public IP, L3VPNs, VPLS) • These services carry IP or Ethernet, so compatible with IP-based encaps

  8. Context Identification • As packets exit from tunnels, need to deliver them to the right “context” • A context may be simply a “tenant”, or a “virtual network instance” but these are special cases • Can also use it for other metadata (state versioning, distributed lookup, etc.) • Note that L3VPNs don’t have any single field that is the VPN-ID, and that’s a good thing • Allows much more complex notions of VPN membership than “a member of exactly one VPN” • An opaque context ID with control-plane defined semantics also supports control-plane independence goal

More Related