july 2014rüdiger geib draft-geib-tsvwg-diffserv-intercon ietf 90, toronto presented by: david black...

4
July 2014 Rüdiger Geib draft-geib-tsvwg-diffserv-intercon IETF 90, Toronto Presented by: David Black Private discussions David Black, Fred Baker and Ruediger Geib (in progress): RFC 2474 and RFC 2475 on DSCP remarking for ingress traffic: RFC 2474: Packets received with an unrecognized codepoint SHOULD be forwarded as if they were marked for the Default behavior, and their codepoints should not be changed . Such packets MUST NOT cause the network node to malfunction. RFC 2475: Ingress nodes must condition all other inbound traffic to ensure that the DS codepoints are acceptable; packets found to have unacceptable codepoints must either be discarded or must have their DS codepoints modified to acceptable values before being forwarded. For example, an ingress node receiving traffic from a domain with which no enhanced service agreement exists may reset the DS codepoint to the Default PHB codepoint [DSFIELD]. Consequently, an interdomain agreement must specify how all DSCPs are treated by the receiving domain. That includes the treatment of unrecognized codepoints.

Upload: james-snow

Post on 18-Jan-2016

212 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: July 2014Rüdiger Geib draft-geib-tsvwg-diffserv-intercon IETF 90, Toronto Presented by: David Black Private discussions David Black, Fred Baker and Ruediger

Rüdiger GeibJuly 2014

draft-geib-tsvwg-diffserv-interconIETF 90, Toronto

Presented by: David Black

Private discussions David Black, Fred Baker and Ruediger Geib (in progress):

• RFC 2474 and RFC 2475 on DSCP remarking for ingress traffic:

• RFC 2474: Packets received with an unrecognized codepoint SHOULD be forwarded as if they were marked for the Default behavior, and their codepoints should not be changed. Such packets MUST NOT cause the network node to malfunction.

• RFC 2475: Ingress nodes must condition all other inbound traffic to ensure that the DS codepoints are acceptable; packets found to have unacceptable codepoints must either be discarded or must have their DS codepoints modified to acceptable values before being forwarded. For example, an ingress node receiving traffic from a domain with which no enhanced service agreement exists may reset the DS codepoint to the Default PHB codepoint [DSFIELD].

• Consequently, an interdomain agreement must specify how all DSCPs are treated by the receiving domain. That includes the treatment of unrecognized codepoints.

Page 2: July 2014Rüdiger Geib draft-geib-tsvwg-diffserv-intercon IETF 90, Toronto Presented by: David Black Private discussions David Black, Fred Baker and Ruediger

Rüdiger GeibNovember 2013

draft-geib-tsvwg-diffserv-interconIETF 90, Toronto

• DiffServ and MPLS (in scope for diffserv-intercon):

• RFC5127 indicates how to transmit different DSCPs as part of an MPLS Treatment Aggregate. This has now been picked up by diffserv-intercon.

• The MPLS Short Pipe Model (pen-ultimate hop popping), interacts with a DiffServ aware domain transporting non tunneled traffic (see next slide).

Page 3: July 2014Rüdiger Geib draft-geib-tsvwg-diffserv-intercon IETF 90, Toronto Presented by: David Black Private discussions David Black, Fred Baker and Ruediger

Rüdiger GeibMarch 2014

draft-geib-tsvwg-diffserv-intercon IETF 90, Toronto

MPLS Short Pipe, non-tunneled IPv4 and DiffServ combined

Peering Router

Broadband Access Router

CPE

Peering Label Edge Router

Due to Label Switch Router MPLS Pen Ultimate Hop Popping, domain internal DiffServ classification is required in this section.The number of supported DSCPs depends on the domains QoS concept.

Label Edge Router

IP

Per sender DSCP/PHB mapping required (no DS-Intercon scheme)

Terminating traffic: DSCPs of local domain

Red: DS Intercon proposes common set of PHBs and DSCPs at interconnection.

Label Switch Router

Peering Router

Peering Label Edge Router

IP

IP IP

IP

IP IP Label IP

IP IP

IP

DS Intercon PHBs / DSCPs leave a domain as received

Without DS Intercon scheme sending domain DSCP/PHB

The figures colour change: DSCP re-marked, PHB stays the same (or indicates suiting MPLS Treatment Aggregate).

1

2

3

Page 4: July 2014Rüdiger Geib draft-geib-tsvwg-diffserv-intercon IETF 90, Toronto Presented by: David Black Private discussions David Black, Fred Baker and Ruediger

Rüdiger GeibMarch 2014

draft-geib-tsvwg-diffserv-intercon IETF 90, Toronto

Next Steps

Current Target: Informational RFC

Slides are ahead of draft – will update draft to pick up rest of this material and discussion

Need to add discussions of IP tunneling aspects, IPv6 and MPLS based L3 VPNs.

Will document any open issues that remain.

Will solicit feedback from other carriers on their DiffServ deployments

Consult TSVWG how to make progress – will probably ask for draft adoption in Honolulu