1 / 4

Encoding 3 PCN-States in the IP header using a single DSCP draft-ietf-pcn-3-in-1-encoding-04.txt

Encoding 3 PCN-States in the IP header using a single DSCP draft-ietf-pcn-3-in-1-encoding-04.txt. Bob Briscoe , BT Toby Moncaster, independent Michael Menth, Uni Tuebingen IETF-80 PCN Mar 2011. status. Encoding 3 PCN-States in the IP header using a single DSCP

tiger-carter
Télécharger la présentation

Encoding 3 PCN-States in the IP header using a single DSCP draft-ietf-pcn-3-in-1-encoding-04.txt

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. Encoding 3 PCN-States in the IP header using a single DSCPdraft-ietf-pcn-3-in-1-encoding-04.txt Bob Briscoe, BTToby Moncaster, independentMichael Menth, Uni Tuebingen IETF-80 PCN Mar 2011

  2. status • Encoding 3 PCN-States in the IP header using a single DSCP • mature draft: draft-ietf-pcn-3-in-1-encoding-04.txt • dependency: RFC6040 (now Proposed Standard) • intended status: experimental → standards track • exec summary: very simple but complete draft • immediate intent: WGLC over, but some spare text needs a home Consider implications of “updates 5696”

  3. additional section: support for e2e ECN • 4 approaches in baseline encoding app’x are imprecise: • tunnel across PCN domain • encode e2e ECN into an extended PCN encoding • signal lack of ECN support to source (e.g. by drop) • remark ECN-capable packets to a non-PCN-capable DSCP • now clearer what to recommend • lay out all the possible cases • esp. document precisely how PCN uses a tunnel to protect e2e ECN • flag when updates or deprecates each of the above 4 approaches • main point: e2e ECN safe if PCN placed logically within tunnel • any tunnel endpoint within 3-in-1 PCN domain must satisfy RFC6040 PCN ingress: NM PCN egress: Not-PCN* RFC 6040 RFC 6040 PCN PCN any-tunnel-rfc any-tunnel-rfc tunnel ingress tunnel egress * experimentally, could leave PCN unchanged to trigger codec adaptation

  4. Encoding 3 PCN-States in the IP header using a single DSCPdraft-ietf-pcn-3-in-1-encoding-04.txt Q&A

More Related