Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8325

Mapping Diffserv to IEEE 802.11

Pages: 37
Proposed Standard
Errata
Updated by:  8622
Part 2 of 3 – Pages 13 to 24
First   Prev   Next

Top   ToC   RFC8325 - Page 13   prevText

4. Recommendations for DSCP-to-UP Mapping

The following section specifies downstream (wired-to-wireless) mappings between [RFC4594], "Configuration Guidelines for Diffserv Service Classes" and [IEEE.802.11-2016]. As such, this section draws heavily from [RFC4594], including service class definitions and recommendations.
Top   ToC   RFC8325 - Page 14
   This section assumes [IEEE.802.11-2016] wireless APs and/or WLAN
   controllers that support customizable, non-default DSCP-to-UP mapping
   schemes.

   This section also assumes that [IEEE.802.11-2016] APs and endpoint
   devices differentiate UP markings with corresponding queuing and
   dequeuing treatments, as described in Section 2.2.

4.1. Network Control Traffic

Network Control Traffic is defined as packet flows that are essential for stable operation of the administered network [RFC4594], Section 3. Network Control Traffic is different from user application control (signaling) that may be generated by some applications or services. Network Control Traffic MAY be split into two service classes: o Network Control, and o Operations, Administration, and Maintenance (OAM)

4.1.1. Network Control Protocols

The Network Control service class is used for transmitting packets between network devices (e.g., routers) that require control (routing) information to be exchanged between nodes within the administrative domain, as well as across a peering point between different administrative domains. [RFC4594], Section 3.2, recommends that Network Control Traffic be marked CS6 DSCP. Additionally, as stated in [RFC4594], Section 3.1: "CS7 DSCP value SHOULD be reserved for future use, potentially for future routing or control protocols." By default (as described in Section 2.4), packets marked DSCP CS7 will be mapped to UP 7 and serviced within the Voice Access Category (AC_VO). This represents the RECOMMENDED mapping for CS7, that is, packets marked to CS7 DSCP are RECOMMENDED to be mapped to UP 7. However, by default (as described in Section 2.4), packets marked DSCP CS6 will be mapped to UP 6 and serviced within the Voice Access Category (AC_VO); such mapping and servicing is a contradiction to the intent expressed in [RFC4594], Section 3.2. As such, it is RECOMMENDED to map Network Control Traffic marked CS6 to UP 7 (per [IEEE.802.11-2016], Section 10.2.4.2, Table 10-1), thereby admitting it to the Voice Access Category (AC_VO), albeit with a marking distinguishing it from (data-plane) voice traffic.
Top   ToC   RFC8325 - Page 15
   It should be noted that encapsulated routing protocols for
   encapsulated or overlay networks (e.g., VPN, Network Virtualization
   Overlays, etc.) are not Network Control Traffic for any physical
   network at the AP; hence, they SHOULD NOT be marked with CS6 in the
   first place.

   Additionally, and as previously noted, the Security Considerations
   section (Section 8) contains additional recommendations for hardening
   Wi-Fi-at-the-edge deployment models, where, for example, network
   control protocols are not expected to be sent nor received between
   APs and client endpoint devices that are downstream.

4.1.2. Operations, Administration, and Maintenance (OAM)

The OAM (Operations, Administration, and Maintenance) service class is recommended for OAM&P (Operations, Administration, and Maintenance and Provisioning). The OAM service class can include network management protocols, such as SNMP, Secure Shell (SSH), TFTP, Syslog, etc., as well as network services, such as NTP, DNS, DHCP, etc. [RFC4594], Section 3.3, recommends that OAM traffic be marked CS2 DSCP. By default (as described in Section 2.3), packets marked DSCP CS2 will be mapped to UP 2 and serviced with the Background Access Category (AC_BK). Such servicing is a contradiction to the intent expressed in [RFC4594], Section 3.3. As such, it is RECOMMENDED that a non-default mapping be applied to OAM traffic, such that CS2 DSCP is mapped to UP 0, thereby admitting it to the Best Effort Access Category (AC_BE).

4.2. User Traffic

User traffic is defined as packet flows between different users or subscribers. It is the traffic that is sent to or from end-terminals and that supports a very wide variety of applications and services [RFC4594], Section 4. Network administrators can categorize their applications according to the type of behavior that they require and MAY choose to support all or a subset of the defined service classes.

4.2.1. Telephony

The Telephony service class is recommended for applications that require real-time, very low delay, very low jitter, and very low packet loss for relatively constant-rate traffic sources (inelastic traffic sources). This service class SHOULD be used for IP telephony service. The fundamental service offered to traffic in the Telephony
Top   ToC   RFC8325 - Page 16
   service class is minimum jitter, delay, and packet loss service up to
   a specified upper bound.  [RFC4594], Section 4.1, recommends that
   Telephony traffic be marked EF DSCP.

   Traffic marked to DSCP EF will map by default (as described in
   Section 2.3) to UP 5 and, thus, to the Video Access Category (AC_VI)
   rather than to the Voice Access Category (AC_VO), for which it is
   intended.  Therefore, a non-default DSCP-to-UP mapping is
   RECOMMENDED, such that EF DSCP is mapped to UP 6, thereby admitting
   it into the Voice Access Category (AC_VO).

   Similarly, the VOICE-ADMIT DSCP (44 decimal / 101100 binary)
   described in [RFC5865] is RECOMMENDED to be mapped to UP 6, thereby
   admitting it also into the Voice Access Category (AC_VO).

4.2.2. Signaling

The Signaling service class is recommended for delay-sensitive client-server (e.g., traditional telephony) and peer-to-peer application signaling. Telephony signaling includes signaling between 1) IP phone and soft-switch, 2) soft-client and soft-switch, and 3) media gateway and soft-switch as well as peer-to-peer using various protocols. This service class is intended to be used for control of sessions and applications. [RFC4594], Section 4.2, recommends that Signaling traffic be marked CS5 DSCP. While Signaling is recommended to receive a superior level of service relative to the default class (i.e., AC_BE), it does not require the highest level of service (i.e., AC_VO). This leaves only the Video Access Category (AC_VI), which it will map to by default (as described in Section 2.3). Therefore, it is RECOMMENDED to map Signaling traffic marked CS5 DSCP to UP 5, thereby admitting it to the Video Access Category (AC_VI). Note: Signaling traffic is not control-plane traffic from the perspective of the network (but rather is data-plane traffic); as such, it does not merit provisioning in the Network Control service class (marked CS6 and mapped to UP 6). However, Signaling traffic is control-plane traffic from the perspective of the voice/video telephony overlay-infrastructure. As such, Signaling should be treated with preferential servicing versus other data-plane flows. This may be achieved in common WLAN deployments by mapping Signaling traffic marked CS5 to UP 5. On APs supporting per-UP EDCAF queuing logic (as described in Section 2.2), this will result in preferential treatment for Signaling traffic versus other video flows in the same access category (AC_VI), which are marked to UP 4, as well as preferred treatment over flows in the Best Effort (AC_BE) and Background (AC_BK) Access Categories.
Top   ToC   RFC8325 - Page 17

4.2.3. Multimedia Conferencing

The Multimedia Conferencing service class is recommended for applications that require real-time service for rate-adaptive traffic. [RFC4594], Section 4.3, recommends Multimedia Conferencing traffic be marked AF4x (that is, AF41, AF42, and AF43, according to the rules defined in [RFC2475]). The primary media type typically carried within the Multimedia Conferencing service class is video; as such, it is RECOMMENDED to map this class into the Video Access Category (AC_VI), which it does by default (as described in Section 2.3). Specifically, it is RECOMMENDED to map AF41, AF42, and AF43 to UP 4, thereby admitting Multimedia Conferencing into the Video Access Category (AC_VI).

4.2.4. Real-Time Interactive

The Real-Time Interactive service class is recommended for applications that require low loss and jitter and very low delay for variable-rate inelastic traffic sources. Such applications may include inelastic video-conferencing applications, but may also include gaming applications (as pointed out in [RFC4594], Sections 2.1 through 2.3 and Section 4.4). [RFC4594], Section 4.4, recommends Real-Time Interactive traffic be marked CS4 DSCP. The primary media type typically carried within the Real-Time Interactive service class is video; as such, it is RECOMMENDED to map this class into the Video Access Category (AC_VI), which it does by default (as described in Section 2.3). Specifically, it is RECOMMENDED to map CS4 to UP 4, thereby admitting Real-Time Interactive traffic into the Video Access Category (AC_VI).

4.2.5. Multimedia Streaming

The Multimedia Streaming service class is recommended for applications that require near-real-time packet forwarding of variable-rate elastic traffic sources. Typically, these flows are unidirectional. [RFC4594], Section 4.5, recommends Multimedia Streaming traffic be marked AF3x (that is, AF31, AF32, and AF33, according to the rules defined in [RFC2475]). The primary media type typically carried within the Multimedia Streaming service class is video; as such, it is RECOMMENDED to map this class into the Video Access Category (AC_VI), which it will by default (as described in Section 2.3). Specifically, it is RECOMMENDED to map AF31, AF32, and AF33 to UP 4, thereby admitting Multimedia Streaming into the Video Access Category (AC_VI).
Top   ToC   RFC8325 - Page 18

4.2.6. Broadcast Video

The Broadcast Video service class is recommended for applications that require near-real-time packet forwarding with very low packet loss of constant rate and variable-rate inelastic traffic sources. Typically these flows are unidirectional. [RFC4594] Section 4.6 recommends Broadcast Video traffic be marked CS3 DSCP. As directly implied by the name, the primary media type typically carried within the Broadcast Video service class is video; as such, it is RECOMMENDED to map this class into the Video Access Category (AC_VI); however, by default (as described in Section 2.3), this service class will map to UP 3 and, thus, the Best Effort Access Category (AC_BE). Therefore, a non-default mapping is RECOMMENDED, such that CS4 maps to UP 4, thereby admitting Broadcast Video into the Video Access Category (AC_VI).

4.2.7. Low-Latency Data

The Low-Latency Data service class is recommended for elastic and time-sensitive data applications, often of a transactional nature, where a user is waiting for a response via the network in order to continue with a task at hand. As such, these flows are considered foreground traffic, with delays or drops to such traffic directly impacting user productivity. [RFC4594], Section 4.7, recommends Low-Latency Data be marked AF2x (that is, AF21, AF22, and AF23, according to the rules defined in [RFC2475]). By default (as described in Section 2.3), Low-Latency Data will map to UP 2 and, thus, to the Background Access Category (AC_BK), which is contrary to the intent expressed in [RFC4594]. Mapping Low-Latency Data to UP 3 may allow targeted traffic to receive a superior level of service via per-UP transmit queues servicing the EDCAF hardware for the Best Effort Access Category (AC_BE), as described in Section 2.2. Therefore it is RECOMMENDED to map Low-Latency Data traffic marked AF2x DSCP to UP 3, thereby admitting it to the Best Effort Access Category (AC_BE).

4.2.8. High-Throughput Data

The High-Throughput Data service class is recommended for elastic applications that require timely packet forwarding of variable-rate traffic sources and, more specifically, is configured to provide efficient, yet constrained (when necessary) throughput for TCP longer-lived flows. These flows are typically not user interactive. According to [RFC4594], Section 4.8, it can be assumed that this class will consume any available bandwidth and that packets
Top   ToC   RFC8325 - Page 19
   traversing congested links may experience higher queuing delays or
   packet loss.  It is also assumed that this traffic is elastic and
   responds dynamically to packet loss.  [RFC4594], Section 4.8,
   recommends High-Throughput Data be marked AF1x (that is, AF11, AF12,
   and AF13, according to the rules defined in [RFC2475]).

   By default (as described in Section 2.3), High-Throughput Data will
   map to UP 1 and, thus, to the Background Access Category (AC_BK),
   which is contrary to the intent expressed in [RFC4594].

   Unfortunately, there really is no corresponding fit for the High-
   Throughput Data service class within the constrained 4 Access
   Category [IEEE.802.11-2016] model.  If the High-Throughput Data
   service class is assigned to the Best Effort Access Category (AC_BE),
   then it would contend with Low-Latency Data (while [RFC4594]
   recommends a distinction in servicing between these service classes)
   as well as with the default service class; alternatively, if it is
   assigned to the Background Access Category (AC_BK), then it would
   receive a less-then-best-effort service and contend with Low-Priority
   Data (as discussed in Section 4.2.10).

   As such, since there is no directly corresponding fit for the High-
   Throughout Data service class within the [IEEE.802.11-2016] model, it
   is generally RECOMMENDED to map High-Throughput Data to UP 0, thereby
   admitting it to the Best Effort Access Category (AC_BE).

4.2.9. Standard

The Standard service class is recommended for traffic that has not been classified into one of the other supported forwarding service classes in the Diffserv network domain. This service class provides the Internet's "best-effort" forwarding behavior. [RFC4594], Section 4.9, states that the "Standard service class MUST use the Default Forwarding (DF) PHB". The Standard service class loosely corresponds to the [IEEE.802.11-2016] Best Effort Access Category (AC_BE); therefore, it is RECOMMENDED to map Standard service class traffic marked DF DSCP to UP 0, thereby admitting it to the Best Effort Access Category (AC_BE). This happens to correspond to the default mapping (as described in Section 2.3).
Top   ToC   RFC8325 - Page 20

4.2.10. Low-Priority Data

The Low-Priority Data service class serves applications that the user is willing to accept without service assurances. This service class is specified in [RFC3662] and [LE-PHB]. [RFC3662] and [RFC4594] both recommend Low-Priority Data be marked CS1 DSCP. Note: This marking recommendation may change in the future, as [LE-PHB] defines a Lower Effort (LE) PHB for Low-Priority Data traffic and recommends an additional DSCP for this traffic. The Low-Priority Data service class loosely corresponds to the [IEEE.802.11-2016] Background Access Category (AC_BK); therefore, it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP 1, thereby admitting it to the Background Access Category (AC_BK). This happens to correspond to the default mapping (as described in Section 2.3).

4.3. Summary of Recommendations for DSCP-to-UP Mapping

Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped to [IEEE.802.11-2016] UP and Access Categories applied in the downstream direction (i.e., from wired-to-wireless networks). +-------------------------------------------------------------------+ | IETF Diffserv | PHB |Reference | IEEE 802.11 | | Service Class | | RFC |User Priority| Access Category | |===============+======+==========+=============+====================| | | | | 7 | AC_VO (Voice) | |Network Control| CS7 | RFC 2474 | OR | |(reserved for | | | 0 | AC_BE (Best Effort)| | future use) | | |See Security Considerations-Sec.8 | +---------------+------+----------+-------------+--------------------+ | | | | 7 | AC_VO (Voice) | |Network Control| CS6 | RFC 2474 | OR | | | | | 0 | AC_BE (Best Effort)| | | | | See Security Considerations | +---------------+------+----------+-------------+--------------------+ | Telephony | EF | RFC 3246 | 6 | AC_VO (Voice) | +---------------+------+----------+-------------+--------------------+ | VOICE-ADMIT | VA | RFC 5865 | 6 | AC_VO (Voice) | | | | | | | +---------------+------+----------+-------------+--------------------+ | Signaling | CS5 | RFC 2474 | 5 | AC_VI (Video) |
Top   ToC   RFC8325 - Page 21
  +---------------+------+----------+-------------+--------------------+
  |   Multimedia  | AF41 |          |             |                    |
  | Conferencing  | AF42 | RFC 2597 |     4       |    AC_VI (Video)   |
  |               | AF43 |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |   Real-Time   | CS4  | RFC 2474 |     4       |    AC_VI (Video)   |
  |  Interactive  |      |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |  Multimedia   | AF31 |          |             |                    |
  |  Streaming    | AF32 | RFC 2597 |     4       |    AC_VI (Video)   |
  |               | AF33 |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |Broadcast Video| CS3  | RFC 2474 |     4       |    AC_VI (Video)   |
  +---------------+------+----------+-------------+--------------------+
  |    Low-       | AF21 |          |             |                    |
  |    Latency    | AF22 | RFC 2597 |     3       | AC_BE (Best Effort)|
  |    Data       | AF23 |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |     OAM       | CS2  | RFC 2474 |     0       | AC_BE (Best Effort)|
  +---------------+------+----------+-------------+--------------------+
  |    High-      | AF11 |          |             |                    |
  |  Throughput   | AF12 | RFC 2597 |     0       | AC_BE (Best Effort)|
  |    Data       | AF13 |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |   Standard    | DF   | RFC 2474 |     0       | AC_BE (Best Effort)|
  +---------------+------+----------+-------------+--------------------+
  | Low-Priority  | CS1  | RFC 3662 |     1       | AC_BK (Background) |
  |     Data      |      |          |             |                    |
  +--------------------------------------------------------------------+

  Note: All unused codepoints are RECOMMENDED to be mapped to UP 0
  (See Security Considerations below)

       Figure 1: Summary of Mapping Recommendations from Downstream
                       DSCP to IEEE 802.11 UP and AC

5. Recommendations for Upstream Mapping and Marking

In the upstream direction (i.e., wireless-to-wired), there are three types of mapping that may be implemented: o DSCP-to-UP mapping within the wireless client operating system, and o UP-to-DSCP mapping at the wireless AP, or o DSCP-Passthrough at the wireless AP (effectively a 1:1 DSCP-to- DSCP mapping)
Top   ToC   RFC8325 - Page 22
   As an alternative to the latter two options, the network
   administrator MAY choose to use the wireless-to-wired edge as a
   Diffserv boundary and explicitly set (or reset) DSCP markings
   according to administrative policy, thus making the wireless edge a
   Diffserv policy enforcement point; this approach is RECOMMENDED
   whenever the APs support the required classification and marking
   capabilities.

   Each of these options will now be considered.

5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating System

Some operating systems on wireless client devices utilize a similar default DSCP-to-UP mapping scheme as that described in Section 2.3. As such, this can lead to the same conflicts as described in that section, but in the upstream direction. Therefore, to improve on these default mappings, and to achieve parity and consistency with downstream QoS, it is RECOMMENDED that wireless client operating systems instead utilize the same DSCP-to-UP mapping recommendations presented in Section 4. Note that it is explicitly stated that packets requesting a marking of CS6 or CS7 DSCP SHOULD be mapped to UP 0 (and not to UP 7). Furthermore, in such cases, the wireless client operating system SHOULD re-mark such packets to DSCP 0. This is because CS6 and CS7 DSCP, as well as UP 7 markings, are intended for network control protocols, and these SHOULD NOT be sourced from wireless client endpoint devices. This recommendation is detailed in the Security Considerations section (Section 8).

5.2. Upstream UP-to-DSCP Mapping at the Wireless AP

UP-to-DSCP mapping generates a DSCP value for the IP packet (either an unencapsulated IP packet or an IP packet encapsulated within a tunneling protocol such as Control and Provisioning of Wireless Access Points (CAPWAP) -- and destined towards a wireless LAN controller for decapsulation and forwarding) from the Layer 2 [IEEE.802.11-2016] UP marking. This is typically done in the manner described in Section 2.4. It should be noted that any explicit re-marking policy to be performed on such a packet generally takes place at the nearest classification and marking policy enforcement point, which may be: o At the wireless AP, and/or
Top   ToC   RFC8325 - Page 23
   o  At the wired network switch port, and/or

   o  At the wireless LAN controller

   Note: Multiple classification and marking policy enforcement points
   may exist, as some devices have the capability to re-mark at only
   Layer 2 or Layer 3, while other devices can re-mark at either/both
   layers.

   As such, UP-to-DSCP mapping allows for wireless L2 markings to affect
   the QoS treatment of a packet over the wired IP network (that is,
   until the packet reaches the nearest classification and marking
   policy enforcement point).

   It should be further noted that nowhere in the [IEEE.802.11-2016]
   specification is there an intent expressed for UP markings to be used
   to influence QoS treatment over wired IP networks.  Furthermore,
   [RFC2474], [RFC2475], and [RFC8100] all allow for the host to set
   DSCP markings for end-to-end QoS treatment over IP networks.
   Therefore, wireless APs MUST NOT leverage Layer 2 [IEEE.802.11-2016]
   UP markings as set by wireless hosts and subsequently perform a
   UP-to-DSCP mapping in the upstream direction.  But rather, if
   wireless host markings are to be leveraged (as per business
   requirements, technical constraints, and administrative policies),
   then it is RECOMMENDED to pass through the Layer 3 DSCP markings set
   by these wireless hosts instead, as is discussed in the next section.

5.3. Upstream DSCP-Passthrough at the Wireless AP

It is generally NOT RECOMMENDED to pass through DSCP markings from unauthenticated and unauthorized devices, as these are typically considered untrusted sources. When business requirements and/or technical constraints and/or administrative policies require QoS markings to be passed through at the wireless edge, then it is RECOMMENDED to pass through Layer 3 DSCP markings (over Layer 2 [IEEE.802.11-2016] UP markings) in the upstream direction, with the exception of CS6 and CS7 (as will be discussed further), for the following reasons: o [RFC2474], [RFC2475], and [RFC8100] all allow for hosts to set DSCP markings to achieve an end-to-end differentiated service o [IEEE.802.11-2016] does not specify that UP markings are to be used to affect QoS treatment over wired IP networks
Top   ToC   RFC8325 - Page 24
   o  Most present wireless device operating systems generate UP values
      by the same method as described in Section 2.3 (i.e., by using the
      3 MSBs of the encapsulated 6-bit DSCP); then, at the AP, these
      3-bit markings are converted back into DSCP values, typically in
      the default manner described in Section 2.4; as such, information
      is lost in the translation from a 6-bit marking to a 3-bit marking
      (which is then subsequently translated back to a 6-bit marking);
      passing through the original (encapsulated) DSCP marking prevents
      such loss of information

   o  A practical implementation benefit is also realized by passing
      through the DSCP set by wireless client devices, as enabling
      applications to mark DSCP is much more prevalent and accessible to
      programmers of applications running on wireless device platforms,
      vis-a-vis trying to explicitly set UP values, which requires
      special hooks into the wireless device operating system and/or
      hardware device drivers, many of which do not support such
      functionality

   CS6 and CS7 are exceptions to this passthrough recommendation because
   wireless hosts SHOULD NOT use them (see Section 5.1) and traffic with
   those two markings poses a threat to operation of the wired network
   (see Section 8.2).  CS6 and CS7 SHOULD NOT be passed through to the
   wired network in the upstream direction unless the AP has been
   specifically configured to do that by a network administrator or
   operator.

5.4. Upstream DSCP Marking at the Wireless AP

An alternative option to mapping is for the administrator to treat the wireless edge as the edge of the Diffserv domain and explicitly set (or reset) DSCP markings in the upstream direction according to administrative policy. This option is RECOMMENDED over mapping, as this typically is the most secure solution because the network administrator directly enforces the Diffserv policy across the IP network (versus an application developer and/or the developer of the operating system of the wireless endpoint device, who may be functioning completely independently of the network administrator).


(page 24 continued on part 3)

Next Section