DLEP Traffic Classification Data ItemMIT Lincoln LaboratoryMassachusetts Institute of Technology244 Wood StreetLexingtonMA02421-6426bcheng@ll.mit.eduMIT Lincoln LaboratoryMassachusetts Institute of Technology244 Wood StreetLexingtonMA02421-6426David.Wiggins@ll.mit.eduLabN Consulting, L.L.C.lberger@labn.net
This document defines a new Dynamic Link Exchange Protocol (DLEP) Data Item that is used
to support traffic classification. Traffic classification
information is used to identify traffic flows based on
frame/packet content such as destination address. The Data Item
is defined in an extensible and reusable fashion. Its use will be
mandated in other documents defining specific DLEP extensions.
This document also introduces DLEP Sub-Data Items, and Sub-Data
Items are defined to support DiffServ and Ethernet traffic
classification.
The Dynamic Link Exchange Protocol (DLEP) is defined in . It provides the exchange of link related
control information between DLEP peers. DLEP peers are comprised
of a modem and a router. DLEP defines a base set of mechanisms as
well as support for possible extensions. DLEP defines Data Items
which are sets of information that can be reused in DLEP
messaging. The base DLEP specification does not include any flow
identification beyond DLEP endpoints. This document defines DLEP
Data Item formats which provide flow identification on a more
granular basis. Specifically it enables a router
to use traffic flow classification information provided by the
modem to identify traffic flows. In this case, a flow is
identified based on information found in a data plane header and
one or more matches are associated with a single flow. (For
general background on traffic classification see Section 2.3.) The Data Item is structured to
allow for use of the defined traffic classification information
with applications such as credit window control as specified in
This document defines traffic classification based on a DLEP
destination and flows identified by either DiffServ DSCPs (differentiated services codepoints) or IEEE
802.1Q Ethernet Priority Code Points
(PCP). The defined mechanism allows for flows to be described in
a flexible fashion and when combined with applications such as
credit window control, allows credit windows to be shared
across traffic sent to multiple DLEP destinations and as part of
multiple flows, or used
exclusively for traffic sent to a particular destination and/or
belonging to a particular flow.
The extension also supports the "wildcard" matching of any flow (DSCP
or PCP). Traffic classification information is provided such that it
can be readily extended to support other traffic classification
techniques, or be used by non-credit window related extensions, such
as or even
5-tuple IP flows.
This document defines support for traffic classification using a
single new Data Item in for general
support and two new Sub-Data Items are defined to support
identification of flows based on DSCPs and PCPs.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 when, and
only when, they appear in all capitals, as shown here.
The Traffic Classification Data Item is used to represent a list of
flows that may be used at the same time for traffic sent from a
router to a modem. The data plane information used to identify each
flow is represented in a separate Sub-Data Item. The Data Item and
Sub-Data Item structure is intended to be independent of any
specific usage of the flow identification, e.g., flow control. The
Sub-Data Item structure is also intended to allow for future traffic
classification types, e.g., 5-tuple flows. While the structure of
the Data Items is extensible, actual flow information is expected to
be used in an extension dependent manner. Support for DSCP and
PCP-based flows are defined via individual Sub-Data Items
below. Other types of flow identification, e.g., based on IP
protocol and ports, may be defined in the future via new Sub-Data
Items. Note that when extensions supporting multiple Sub-Data Item
types are negotiated, these types MAY be combined in a single Data Item.
Each list of flows is identified
using a "Traffic Classification Identifier" or "TID" and is expected
to represent a valid combination of data plane identifiers that may
be used at the same time. Each flow is identified via a "Flow
Identifier" or "FID". Each FID is defined in a Sub-Data Item which
carries the data plane identifier or identifiers used to associate
traffic with the flow. A DLEP destination address is also needed to
complete traffic classification information used in extensions such
as flow control. This information is expected to be provided in an
extension specific manner. For example, this address can be provided
by a modem when it identifies the traffic classification set in a
Destination Up Message using the Credit Window Associate Data Item
defined in .
TID and FID values have modem-local scope.
This sections defines the Traffic Classification Data Item. This
Data Item is used by a modem to provide a router with traffic
classification information. When an extension requires use of
this Data Item the Traffic Classification Data Item SHOULD be
included by a modem in any Session Initialization Response Message,
e.g., see . Updates to
previously provided traffic classifications or new traffic
classifications MAY be sent by a modem by including the Data Item
in Session Update Messages. More than one Data Item MAY be
included in a message to provide information on multiple traffic
classifiers.
The set of traffic classification information provided in the data
item is identified using a Traffic Classification Identifier, or
TID. The actual data plane related information used in traffic
classification is provided in a variable list of Traffic
Classification Sub-Data Items.
The format of the Traffic Classification Data Item is:
TBA1Variable
Per Length
is the number of octets in the Data Item, excluding the Type and
Length fields.
A 16-bit unsigned integer identifying a traffic classification
set. There is no restriction on values used by a modem, and there
is no requirement for sequential or ordered values.
An 8-bit unsigned integer indicating the number of Traffic
Classification Sub-Data Items included in the Data Item. A value
of zero (0) is allowed and indicates that no traffic should be
matched against this TID.
MUST be set to zero by the sender (a modem) and ignored by the
receiver (a router).
Zero or more Traffic Classification Sub-Data Items of the format
defined below MAY be included. The number MUST match the value
carried in the Num SDIs field.
A router receiving the Traffic Classification Data Item MUST
locate the traffic classification information that is associated
with the TID indicated in each received Data Item. If no
associated traffic classification information is found, the router
MUST initialize a new information set using the values carried in
the Data Item. When associated traffic classification information
is found, the router MUST replace the corresponding information using the values
carried in the Data Item. In both cases, a router MUST also
ensure that any data plane state, e.g., , that is
associated with the TID is updated as needed.
All Traffic Classification Sub-Data Items share a common format
that is patterned after the standard DLEP Data Item format, see
Section 11.3. There is no requirement
on, or meaning to Sub-Data Item ordering. Any errors or
inconsistencies encountered in parsing Sub-Data Items are
handled in the same fashion as any other Data Item parsing error
encountered in DLEP.
The format of the Traffic Classification Sub-Data Item is:
A 16-bit unsigned integer that indicates the type and
corresponding format of the Sub-Data Item's Value field.
Sub-Data Item Types are scoped within the Data Item in which
they are carried, i.e., the Sub-Data Item Type field MUST be
used together with the Traffic Classification Data Item Type to identify the format
of the Sub-Data Item. Traffic Classification Sub-Data
Item Types are managed according to the IANA registry described
in .
Variable
Copying , Length is a 16-bit unsigned
integer that is the number of octets in the Sub-Data Item,
excluding the Type and Length fields.
The DiffServ Traffic Classification Sub-Data Item is used to
identify the set of DSCPs that should be treated as a
single flow, i.e., receive the same traffic treatment. DSCPs are
identified in a list of DiffServ fields. An implementation that
does not support DSCPs and wants the same traffic treatment for
all traffic to a destination or destinations would indicate
0 DSCPs.
The format of the DiffServ Traffic Classification Sub-Data Item
is:
Variable
Length is defined above. For this Sub-Data Item, it is
equal to three (3) plus the value of the Num DSCPs field.
A 16-bit unsigned integer representing the data plane
information carried in the Sub-Data Item that is to be used in
identifying a flow. The value of 0xFFFF is reserved and MUST
NOT be used in this field.
An 8-bit unsigned integer indicating the number of DSCPs
carried in the Sub-Data Item. A zero (0) indicates a (wildcard)
match against any DSCP value.
Each DS Field is an 8-bit that carries the DSCP field defined
in .
A router receiving the Traffic Classification Sub-Data
Item MUST validate the information on receipt, prior to using
the carried information, including potentially updating the data
behavior as determined by the extension requiring the use of the
Sub-Data Item. Validation failures MUST be treated as an error as
described above.
Once validated, the receiver MUST ensure that each DS Field
value is listed only once across the whole Traffic
Classification Data Item. Note, this check is across the Data
Item and not the individual Sub-Data Item. If the same DS Field
value is listed more than once within the same Traffic
Classification Data Item, the Data Item MUST be treated as an
error as described above.
The Ethernet Traffic Classification Sub-Data Item is used to
identify the VLAN and PCPs that should be treated as a single
flow, i.e., receive the same traffic treatment. Ethernet Priority
Code Point support is defined as part of the IEEE 802.1Q tag format and includes a 3 bit "PCP"
field. The tag format also includes a 12 bit VLAN identifier
(VID) field. PCPs are identified in a list of priority fields. An
implementation that does not support PCPs and wants the same
traffic treatment for all traffic to a destination or destinations
would indicate 0 PCPs. Such an implementation could identify a
VLAN to use per destination.
The format of the Ethernet Traffic Classification
Sub-Data Item is:
Variable
Length is defined above. For this Sub-Data Item, it is equal
to four (4) plus the number of octets needed to accommodate
the number of Priority fields indicated by the NumPCPs
field. Note that as length is in octets and each Priority
field is 4 bits, the additional length is the value carried in
the NumPCPs field divided by two and rounded up to the next
higher integer quantity.
A 16-bit unsigned integer representing the data plane
information carried in the Sub-Data Item that is to be used in
identifying a flow. The value of 0xFFFF is reserved and MUST
NOT be used in this field.
A 4-bit unsigned integer indicating the number of Priority
fields carried in the Sub-Data Item. A zero (0) indicates a
(wildcard) match against any PCP value.
A 12-bit unsigned integer field indicating the VLAN to be
used in traffic classification. A value of zero (0) indicates
that the VID is to be ignored and any VID is to be accepted during
traffic classification.
Each Priority Field is 4-bits long and indicates a
PCP field defined in . Note
that zero (0) is a valid value for either PCP.
A 4-bit long field included when NumPCPs is an odd number.
This field MUST be set to zero by the sender, and MUST be ignored
on receipt.
A router receiving the Traffic Classification Sub-Data
Item MUST validate the information on receipt, prior to the using
the carried information, including potentially updating the data
behavior as determined by the extension requiring the use of the
Sub-Data Item. Validation failures MUST be treated as an error as
described above.
Once validated, the receiver MUST ensure that each Priority
Field value is listed only once across the whole Traffic
Classification Data Item. Note, this check is across the Data
Item and not the individual Sub-Data Item. If the same Priority
Field value is listed more than once within the same Traffic
Classification Data Item, the Data Item MUST be treated as an
error as described above.
If a packet matches both a DiffServ Traffic Classification
Sub-Data Item (), e.g., DSCP
match, and an Ethernet Traffic Classification Sub-Data Item (see
Section 2.3), e.g., PCP match, then the TID with which the
DiffServ Traffic Classification Sub-Data Item is associated MUST
take precedence.
The formats defined in this document will only be used when
extensions require their use.
This document introduces finer grain flow identification mechanisms
to DLEP. These mechanisms do not inherently introduce any
additional vulnerabilities above those documented in . The approach taken to Security in that document
applies equally to the mechanism defined in this document.
This document requests the assignment of several values by IANA. All
assignments are to registries defined by .
This document requests the following new assignments to the DLEP Data Item
Registry named "Data Item Type Values" in the range with the "Specification
Required" policy. The requested values are as follows:
Type CodeDescriptionTBA1Traffic Classification
Upon approval of this document, IANA is requested to create a new
DLEP registry, named "Traffic Classification Sub-Data Item Type Values".
The following table provides initial registry values and the
defined policies that should apply to the registry:
Type CodeDescription0Reserved1DiffServ Traffic Classification2Ethernet Traffic Classification3-65407Specification Required65408-65534Private Use65535Reserved
IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks
IEEE
This standard specifies how the Media Access Control (MAC) Service is supported by Bridged Networks, the principles of operation of those networks, and the operation of MAC Bridges and VLAN Bridges, including management, protocols, and algorithms
The Sub-Data Item format was inspired by Rick Taylor's "Data Item
Containers". He also proposed the separation of credit windows
from traffic classification at IETF98. Many useful comments were
received from contributors to the MANET working group. This
document was derived from as a result of
discussions at IETF 101. Many useful comments were
received from contributors to the MANET working group, notably
Ronald in't Velt and David Black.