1 / 4

IETF SFC: Service Chain Header draft-zhang-sfc-sch-01

IETF SFC: Service Chain Header draft-zhang-sfc-sch-01. H. Zhang, L. Fourie, HuaWei R. Parker, Affirmed Networks M. Zarny, Goldman Sachs. Rationale. First Draft of SCH in March, 2014 Now at -01, May, 2014 Written as an alternative to draft- quinn - nsh to address perceived shortcomings:

phuoc
Download Presentation

IETF SFC: Service Chain Header draft-zhang-sfc-sch-01

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. IETF SFC:Service Chain Headerdraft-zhang-sfc-sch-01 H. Zhang, L. Fourie, HuaWei R. Parker, Affirmed Networks M. Zarny, Goldman Sachs IETF 90, Toronto, ONTARIO, CA, 23 JULY, 2014

  2. Rationale • First Draft of SCH in March, 2014 • Now at -01, May, 2014 • Written as an alternative to draft-quinn-nsh to address perceived shortcomings: • Eliminate mandatory fixed-sized metadata • Add variable length metadata • Add organizationally defined metadata • Add version field • Draft-Quinn-nsh since revised • Now at -03, July 3, 2014 • Adds optional variable length metadata to existing fixed format mandatory metadata • Adds version fields IETF 90, Toronto, ONTARIO, CA, 23 JULY, 2014

  3. Key Differences between SCH and NSH • Metadata • SCH proposes TLV metadata when required • NSH requires 4-32 bit general purpose metadata fields in every packet and allows additional optional TLV metadata • TLV ‘Type’ Authority for Metadata • SCH recommends IANA registry for ‘standard’ types plus use of 24-bit IEEE OUI for Vendor Specific types • NSH does not support ‘standard’ types; uses new 16-bit IANA registered organizational ID for Vendor Specific types • Next protocol indication • SCH uses 16-bit IEEE ethertype (Transparent Ethernet Bridging to indicate Ethernet) • NSH uses 8-bit enumerated type (i.e., v4, v6, Ethernet) • Other minor differences • NSH has a Critical attention bit • SCH uses 8 bit total length and metadata length vs 5 bit in NSH • Applicability -- SCH text describes usage to optionally carry only chain forwarding information; only metadata; or both IETF 90, Toronto, ONTARIO, CA, 23 JULY, 2014

  4. Recommendations • Merge NSH and SCH: • Resolve major differences • Mandatory fixed-size metadata in NSH vs. none in SCH • IANA registered ‘standard’ metadata types in SCH vs. none in NSH • Next protocol information enumerated in NSH vs. ethertype in SCH • Resolve multiple minor differences • Common • Thread consensus on chain id vs. path id • Explanatory language • Etc. IETF 90, Toronto, ONTARIO, CA, 23 JULY, 2014

More Related