1 / 10

Network Service Header (NSH) draft- quinn - sfc-nsh IETF 90

Network Service Header (NSH) draft- quinn - sfc-nsh IETF 90. A. Chauhan Citrix U. Elzur Intel B. McConnell Rackspace C. Wright Red Hat Inc. P. Quinn , et. al Cisco Systems P. Agarwal R. Manur Broadcom Pankaj Garg Microsoft. NSH Overview.

dana
Download Presentation

Network Service Header (NSH) draft- quinn - sfc-nsh IETF 90

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. Network Service Header (NSH)draft-quinn-sfc-nshIETF 90 A. Chauhan Citrix U. Elzur Intel B. McConnell Rackspace C. Wright Red Hat Inc. P. Quinn, et. al Cisco Systems P. Agarwal R. Manur Broadcom PankajGarg Microsoft

  2. NSH Overview • Describes a dataplane header used to carry information along a service path. • Identifier for service path selection • Opaque mandatory metadata fields • Optional TLVs • Creates “service plane” • Transport independent (NSH in VXLAN, NSH in MPLS, NSH in UDP, etc.) • Service layer OAM

  3. Changes from -02 • New co-author • Base header is first 4 bytes, includes type field • Encapsulated protocol type  8 bit value • Explicit dataplane versioning • Critical TLV indicator • 4 byte service path header • Added optional metadata TLV (in addition to mandatory fixed context header) • TLV Class

  4. Implementation Update • Opensource implementations • OVS dataplane (with VXLAN) • OpenDaylight control plane (+ LISP) • Several vendor specific implementations • Early deployments underway

  5. Base Header • 8 bit Next Protocol: support non-ET protocols + reclaim space • MD type indicates format of header. NSH type = 0x1 • Critical TLV present 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|C|R|R|R|R|R|R| Length | MD Type | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  6. Service Path Header • Represents the rendering of the chain policy • Simple identifier: does not imply a static, explicit path • Resolved locally • Can be changed: branching within a service graph • Re-classification (and therefore policy) decision • Index conveys node within the graph 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path ID | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  7. Chain and Paths (no load distribution) • Chain1: Firewall  DPI  IPS Chain1 is rendered as SFPID = 10 FW’ DPI’ IPS FW’’’’ IPS’ FW DPI IPS’’ DPI’ SFF1 SFF2 SFF3 Classifier SFPID: 10  SF1: FW SFPID: 10  SF2: DPI SFPID: 10  SF2: DPI Loc(SFF1, FW, FW’) Loc(SFF2, FW’’) Loc(SFF3, FW’’’’) Loc(SFF3,DPI) Loc(SFF2,DPI’) Loc(SFF2, IPS’) Loc(SFF1, IPS) Loc(SFF3, IPS’’) Local forwarding policy Local forwarding policy Local forwarding policy Transport Transport Transport

  8. Mandatory Context Headers 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Platform Context | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Shared Context | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Platform Context | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Shared Context | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • Based on initial deployments: many use cases satisfied • with fixed size context headers • Hardware friendly: easy to parse and skip at high speed • Opaque, significance allocated via control plane

  9. Optional TLV 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class | Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • TLV Class: describes the scope of the type field • Type: type of metadata carried, includes critical indication

  10. Next Steps • Continue development • Opensource and vendors • Continued deployments • Ask for adoption as a working group document: SFC encapsulation “Generic SFC Encapsulation: This document will describe a single service-level data plane encapsulation format that:
- indicates the sequence of service functions that make up the Service Function Chain
- specifies the Service Function Path,
- communicates context information between nodes that implement 
service functions and Service Function Chains…”

More Related