📄 rfc3289.txt
字号:
|
+--+--+ +-----+ +-----+ +-----+ +-----+
| AF1 +-----+ AF2 +-----+ AF3 +-----+ AF4 +-----+ EF |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
|trTCM| |trTCM| |trTCM| |trTCM| |srTCM|
|Meter| |Meter| |Meter| |Meter| |Meter|
+-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+
||| ||| ||| ||| | |
+-+||---+ +-+||---+ +-+||---+ +-+||---+ +-+-|---+
|+-+|----+ |+-+|----+ |+-+|----+ |+-+|----+ |+--+----+
||+-+-----+ ||+-+-----+ ||+-+-----+ ||+-+-----+ ||Actions|
+||Actions| +||Actions| +||Actions| +||Actions| +| |
+| | +| | +| | +| | +-+-----+
+-+-----+ +-+-----+ +-+-----+ +-+-----+ |
||| ||| ||| ||| |
VVV VVV VVV VVV V
Accepted traffic is sent to IP forwarding
Figure 7: combined EF and AF implementation, ingress side
Baker, et. al. Standards Track [Page 21]
RFC 3289 Differentiated Services MIB May 2002
3.6.1.1. Classification In The Example
A packet arriving at an ingress interface picks up its policy from
the diffServDataPathTable. This points to a classifier, which will
select traffic according to some specification for each traffic
class.
An example of a classifier for an AFm class would be a set of three
classifier elements, each pointing to a Multi-field classification
parameter block identifying one of the AFmn DSCPs. Alternatively,
the filters might contain selectors for HTTP traffic or some other
application.
An example of a classifier for EF traffic might be a classifier
element pointing to a filter specifying the EF code point, a
collection of classifiers with parameter blocks specifying individual
telephone calls, or a variety of other approaches.
Typically, of course, a classifier identifies a variety of traffic
and breaks it up into separate classes. It might very well contain
fourteen classifier elements indicating the twelve AFmn DSCP values,
EF, and "everything else". These would presumably direct traffic
down six functional data paths: one for each AF or EF class, and one
for all other traffic.
3.6.1.2. AF Implementation On an Ingress Edge Interface
Each AFm class applies a Two Rate Three Color Meter, dividing traffic
into three groups. These groups of traffic conform to both specified
rates, only the higher one, or none. The intent, on the ingress
interface at the edge of the network, is to measure and appropriately
mark traffic.
3.6.1.2.1. AF Metering On an Ingress Edge Interface
Each AFm class applies a Two Rate Three Color Meter, dividing traffic
into three groups. If two rates R and S, where R < S, are specified
and traffic arrives at rate T, traffic comprising up to R bits per
second is considered to conform to the "confirmed" rate, R. If
R < T, traffic comprising up to S-R bits per second is considered to
conform to the "excess" rate, S. Any further excess is non-
conformant.
Two meter entries are used to configure this, one for the conforming
rate and one for the excess rate. The rate parameters are stored in
associated Token Bucket Parameter Entries. The "FailNext" pointer of
the lower rate Meter Entry points to the other Meter Entry; both
"SucceedNext" pointers and the "FailNext" pointer of the higher Meter
Baker, et. al. Standards Track [Page 22]
RFC 3289 Differentiated Services MIB May 2002
Entry point to lists of actions. In the color-blind mode, all three
classifier "next" entries point to the lower rate meter entry. In
the color-aware mode, the AFm1 classifier points to the lower rate
entry, the AFm2 classifier points to the higher rate entry (as it is
only compared against that rate), and the AFm3 classifier points
directly to the actions taken when both rates fail.
3.6.1.2.2. AF Actions On an Ingress Edge Interface
For network planning and perhaps for billing purposes, arriving
traffic is normally counted. Therefore, a "count" action, consisting
of an action table entry pointing to a count table entry, is
configured.
Also, traffic is marked with the appropriate DSCP. The first R bits
per second are marked AFm1, the next S-R bits per second are marked
AFm2, and the rest is marked AFm3. It may be that traffic is
arriving marked with the same DSCP, but in general, the additional
complexity of deciding that it is being remarked to the same value is
not useful. Therefore, a "mark" action, consisting of an action
table entry pointing to a mark table entry, is configured.
At this point, the usual case is that traffic is now forwarded in the
usual manner. To indicate this, the "SucceedNext" pointer of the
Mark Action is set to zeroDotZero.
3.6.1.3. EF Implementation On an Ingress Edge Interface
The EF class applies a Single Rate Two Color Meter, dividing traffic
into "conforming" and "excess" groups. The intent, on the ingress
interface at the edge of the network, is to measure and appropriately
mark conforming traffic and drop the excess.
3.6.1.3.1. EF Metering On an Ingress Edge Interface
A single rate two color (srTCM) meter requires one token bucket. It
is therefore configured using a single meter entry with a
corresponding Token Bucket Parameter Entry. Arriving traffic either
"succeeds" or "fails".
3.6.1.3.2. EF Actions On an Ingress Edge Interface
For network planning and perhaps for billing purposes, arriving
traffic that conforms to the meter is normally counted. Therefore, a
"count" action, consisting of an action table entry pointing to a
count table entry, is configured.
Baker, et. al. Standards Track [Page 23]
RFC 3289 Differentiated Services MIB May 2002
Also, traffic is (re)marked with the EF DSCP. Therefore, a "mark"
action, consisting of an action table entry pointing to a mark table
entry, is configured.
At this point, the successful traffic is now forwarded in the usual
manner. To indicate this, the "SucceedNext" pointer of the Mark
Action is set to zeroDotZero.
Traffic that exceeded the arrival policy, however, is to be dropped.
One can use a count action on this traffic if the several counters
are interesting. However, since the drop counter in the Algorithmic
Drop Entry will count packets dropped, this is not clearly necessary.
An Algorithmic Drop Entry of the type "alwaysDrop" with no successor
is sufficient.
3.7. AF and EF Egress Edge Interface Configuration
3.7.1. Classification On an Egress Edge Interface
A packet arriving at an egress interface may have been classified on
an ingress interface, and the egress interface may have access to
that information. If it is relevant, there is no reason not to use
that information. If it is not available, however, there may be a
need to (re)classify on the egress interface. In any event, it picks
up its "program" from the diffServDataPathTable. This points to a
classifier, which will select traffic according to some specification
for each traffic class.
Baker, et. al. Standards Track [Page 24]
RFC 3289 Differentiated Services MIB May 2002
+-----------------------+
| diffServDataPathStart |
+-----------+-----------+
|
+----------+
|
+--+--+ +-----+ +-----+ +-----+ +-----+
| AF1 +-----+ AF2 +-----+ AF3 +-----+ AF4 +-----+ EF |
+-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+
||| ||| ||| ||| | |
+-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+
|trTCM| |trTCM| |trTCM| |trTCM| |srTCM|
|Meter| |Meter| |Meter| |Meter| |Meter|
+-+++-+ +-+++-+ +-+++-+ +-+++-+ +-+-+-+
||| ||| ||| ||| | |
+-+||---+ +-+||---+ +-+||---+ +-+||---+ +-+-|---+
|+-+|----+ |+-+|----+ |+-+|----+ |+-+|----+ |+--+----+
||+-+-----+ ||+-+-----+ ||+-+-----+ ||+-+-----+ ||Actions|
+||Actions| +||Actions| +||Actions| +||Actions| +| |
+| | +| | +| | +| | +-+-----+
+-+-----+ +-+-----+ +-+-----+ +-+-----+ |
||| ||| ||| ||| |
+-+++--+ +-+++--+ +-+++--+ +-+++--+ +--+---+
| Queue| | Queue| | Queue| | Queue| | Queue|
+--+---+ +--+---+ +--+---+ +--+---+ +--+---+
| | | | |
+--+-----------+-----------+-----------+---+ |
| WFQ/WRR Scheduler | |
+--------------------------------------+---+ |
| |
+-----+-----------+----+
| Priority Scheduler |
+----------+-----------+
|
V
Figure 8: combined EF and AF implementation
An example of a classifier for an AFm class would be a succession of
three classifier elements, each pointing to a Multi-field
classification parameter block identifying one of the AFmn DSCPs.
Alternatively, the filter might contain selectors for HTTP traffic or
some other application.
Baker, et. al. Standards Track [Page 25]
RFC 3289 Differentiated Services MIB May 2002
An example of a classifier for EF traffic might be either a
classifier element pointing to a Multi-field parameter specifying the
EF code point, or a collection of classifiers with parameter blocks
specifying individual telephone calls, or a variety of other
approaches.
Each classifier delivers traffic to appropriate functional data path
elements.
3.7.2. AF Implementation On an Egress Edge Interface
Each AFm class applies a Two Rate Three Color Meter, dividing traffic
into three groups. These groups of traffic conform to both specified
rates, only the higher one, or none. The intent, on the ingress
interface at the edge of the network, is to measure and appropriately
mark traffic.
3.7.2.1. AF Metering On an Egress Edge Interface
Each AFm class applies a Two Rate Three Color Meter, dividing traffic
into three groups. If two rates R and S, where R < S, are specified
and traffic arrives at rate T, traffic comprising up to R bits per
second is considered to conform to the "confirmed" rate, R. If
R < T, traffic comprising up to S-R bits per second is considered to
conform to the "excess" rate, S. Any further excess is non-
conformant.
Two meter entries are used to configure this, one for the conforming
rate and one for the excess rate. The rate parameters are stored in
associated Token Bucket Parameter Entries. The "FailNext" pointer of
the lower rate Meter Entry points to the other Meter Entry; both
"SucceedNext" pointers and the "FailNext" pointer of the higher Meter
Entry point to lists of actions. In the color-blind mode, all three
classifier "next"⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -