RFC 5127: Aggregation of Diffserv Service Classes
In plain English — editorial summary, not part of the RFC
In the core of a high-capacity network, service differentiation may still be needed to support applications' utilization of the network. Applications with similar traffic characteristics and performance requirements are mapped into Diffserv service classes based on end- to-end behavior requirements of the applications. However, some network segments may be configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements of two or more service classes. In these cases, it may be desirable to aggregate two or more Diffserv service classes into a single forwarding treatment. This document provides guidelines for the aggregation of Diffserv service classes into forwarding treatments. This memo provides information for the Internet community.
Document record
- Document ID
- RFC5127
- Published
- February 2008
- Authors
- K. Chan; J. Babiarz; F. Baker
- Status
- INFORMATIONAL
- Stream
- IETF
- Area
- wit
- Pages
- 19
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 8100Diffserv-Interconnection Classes and PracticeCurrent
March 2017
- RFC 5129Explicit Congestion Marking in MPLSUpdated
January 2008
- RFC 5097MIB for the UDP-Lite protocolCurrent
January 2008
- RFC 5062Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current CountermeasuresCurrent
September 2007
- RFC 5061Stream Control Transmission Protocol (SCTP) Dynamic Address ReconfigurationCurrent
September 2007
- RFC 5033Specifying New Congestion Control AlgorithmsObsoleted
August 2007
- RFC 4987TCP SYN Flooding Attacks and Common MitigationsCurrent
August 2007
- RFC 5284User-Defined Errors for RSVPCurrent
August 2008
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?