Subject: RE: [AAA-WG]: QoS-Filter-Rule AVP missing in NASREQ?

From: <[email-masked]>
Date: Sun, 4 Jul 2004 19:24:30 +0300

Bernard Aboba wrote:
> 
> RFC 3588 defines a QoS Filter Rule syntax in Section 4.3.  My
> understanding was that this syntax was to be used by the
> QoS-Filter-Rule AVP in NASREQ.  Among other things, the need for 
> QoS filters was described in the original AAA and NASREQ 
> requirements documents.
> 
> Did this AVP somehow get lost on the cutting room floor?

It's not present in any version of NASREQ (00..16).

Perhaps it could be left to a separate document?
There has been some discussion at RADIUSEXT about the
"bandwidth" attributes that provide a subset of the
QoSFilterRule functionality; I'm wondering if that
subset would be sufficient for many cases...?

BTW, as I mentioned on the RADIUSEXT mailing list a while ago, 
some parts of the QoSFilterRule syntax got lost somewhere in 
the process, too. Perhaps the missing text (salvaged from 
BASE -09) should be filed as an errata issue for RFC3588?

   DSCP <color>
           color values as defined in [DIFFSERV]. Exact
           matching of DSCP values is required (no masks or
           ranges).

   metering <rate> <color_under> <color_over>
           The metering option provides Assured Forwarding,
           as defined in [DIFFSERVAF], and MUST be present
           if the action is set to meter. The rate option is
           the throughput, in bits per second, which is used
           by the access device to mark packets. Traffic
           above the rate is marked with the color_over
           codepoint, while traffic under the rate is marked
           with the color_under codepoint. The color_under
           and color_over options contain the drop
           preferences, and MUST conform to the recommended
           codepoint keywords described in [DIFFSERVAF]
           (e.g. AF13).

           The metering option also supports the strict
           limit on traffic required by Expedited
           Forwarding, as defined in [DIFFSERVEF]. The
           color_over option may contain the keyword "drop"
           to prevent forwarding of traffic that exceeds the
           rate parameter.

Best regards,
Pasi

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 4 Jul 2004 09:41:12 -0700 (PDT)

> Perhaps it could be left to a separate document?

I'm not sure this is possible, because it would probably have to be a
mandatory AVP, and addition of mandatory AVPs to an existing application
requires defining a new Application-Id, which would break compatibility
with the existing NASREQ Application.

For that reason, I'd prefer if this AVP were to be defined in NASREQ.
This might also allow us to address the issue of the missing text.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 05 Jul 2004 09:09:59 +0300

> For that reason, I'd prefer if this AVP were to be defined in NASREQ.

Yes.

> This might also allow us to address the issue of the missing text.

Do we remember why the missing text was taken away?

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 7 Jul 2004 09:14:56 -0700 (PDT)

> Do we remember why the missing text was taken away?

I've done a bit more archeology, and here is what I've found.

Apparently, QoS-Filter-Rule AVP was never included in NASREQ.  However,
the QoS-Filter-Rule data type first found its way into the Diameter Base
specification with draft-ietf-aaa-diameter-07.txt, submitted in July
2001.

The text remained unchanged until the second half of it was
removed in draft-ietf-aaa-diameter-10.txt, submitted in April 2002.
This looks like an editing mistake, rather than an intentional removal,
since I can't find an Issue for which the removal might be a resolution.  The
mistake was apparently not detected prior to publication of RFC 3588.

To understand how QoS-Filter-Rule AVP got into Diameter Base in the first
place, I went back to the original requirements documents.

In terms of NASREQ QoS support, the original requirement came from RFC
2881 (NASREQNG). Section 9.3.6 says:

   A NAS may delivery different qualities, types, or levels of service
   to different users based on policy and identity.  NAS's may perform
   bandwidth management, allow differential speeds or methods of access,
   or even participate in provisioned or signaled Quality of Service
   (QoS) networks.

This was the original requirement that QoS-Filter-Rule AVP was trying to
address.

The NASREQ requirement was then rolled up into RFC 2989, "Criteria for
Evaluating AAA Protocols for Network Access".  This document included
"Support for Access Rules, Restrictions, Filters" as a MUST for NASREQ,
with a footnote e) clarifying the requirement:

[e]  This requirement refers to the ability to of the protocol to
     describe access operational limitations and authorization
     restrictions to usage to the NAS which includes (but is not
     limited to):

        1. Session expirations and Idle Timeouts
        2. Packet filters
        3. Static routes
        4. QoS parameters

Given the importance of the QoS requirement for NASREQ (a MUST), the
history within Diameter Base (apparent editorial mistake), and the
relative ease with which the issue can be fixed (inclusion of a paragraph
such as the following), I think this issue really does need to be
addressed.

Suggested fix:

Insert a new section:

X.X  QoS-Filter-Rule AVP

   The QoS-Filter-Rule AVP (AVP Code XXX) is of type QoSFilterRule, and
   provides QoS filter rules that need to be configured on the NAS for the
   user. One or more such AVPs MAY be present in an authorization
   response.

   Note:  Due to an editorial mistake in [RFC3588], the complete
   QoSFilterRule definition was not included.  It is reprinted here
   for clarification.

   QoSFilterRule
      The QosFilterRule format is derived from the OctetString AVP Base
      Format.  It uses the ASCII charset.  Packets may be marked or
      metered based on the following information that is associated with
      it:

         Direction                          (in or out)
         Source and destination IP address  (possibly masked)
         Protocol
         Source and destination port        (lists or ranges)
         DSCP values                        (no mask or range)

      Rules for the appropriate direction are evaluated in order, with
      the first matched rule terminating the evaluation.  Each packet is
      evaluated once.  If no rule matches, the packet is treated as best
      effort.  An access device that is unable to interpret or apply a
      QoS rule SHOULD NOT terminate the session.

   QoSFilterRule filters MUST follow the format:

   action dir proto from src to dst [options]

                tag    - Mark packet with a specific DSCP
                         [DIFFSERV].  The DSCP option MUST be
                         included.
                meter  - Meter traffic.  The metering options
                         MUST be included.

   dir          The format is as described under IPFilterRule.

   proto        The format is as described under IPFilterRule.

  src and dst   The format is as described under IPFilterRule.

            options:

               DSCP <color>

         The rule syntax is a modified subset of ipfw(8) from FreeBSD,
         and the ipfw.c code may provide a useful base for
         implementations.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 Jul 2004 09:22:35 +0300

Ok. Lets put it there.

--Jari