Subject: [Dime] Diameter Classifier Document

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 04 Jul 2007 22:03:46 +0200

Hi all,

Avi has written a document that defines classifiers with a binary 
encoding instead of a textual encoding currently being investigated in 
the RADEXT working group with 
http://tools.ietf.org/wg/radext/draft-ietf-radext-filter-rules/.
One of the benefits is better extensibility.

You can find the document in the attachment.

It would be great to hear your thoughts about this issue. Btw, there is 
impact on the QoS attribute document.

Ciao
Hannes

Network Working Group                                            A. Lior
Internet-Draft                                       Bridgewater Systems
Intended status: Standards Track                           June 27, 2007
Expires: December 29, 2007

                          Diameter Classifier
                 draft-lior-diameter-classifier-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 29, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Lior                    Expires December 29, 2007               [Page 1]

Internet-Draft             Diameter Classifier                 June 2007

Abstract

   Many Diameter applications require classifying packets.  Diameter
   base protocols provides an IP Filter Rule type and a QoS Filter Rule
   type that is being used to classify packets.  However, because these
   types were defined for specific uses and defined in ways that are
   hard to extend and therefore are not generally applicable for those
   applications that require packet classifiers.

   This document describes a set of Diameter types that are useful to
   create packet classifiers.  The packet classier type can be used by
   various applications to express packet classifiers that best match
   the application's specific needs.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Classifier Attribute Overview  . . . . . . . . . . . . . . . .  5
   4.  Classifier AVP . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  IP Classifiers . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Source and Destination Attributes  . . . . . . . . . . . .  9
       5.1.1.  Inverted AVP . . . . . . . . . . . . . . . . . . . . .  9
       5.1.2.  IPAddress AVP  . . . . . . . . . . . . . . . . . . . .  9
       5.1.3.  Port AVP . . . . . . . . . . . . . . . . . . . . . . .  9
       5.1.4.  IPAddressRange AVP . . . . . . . . . . . . . . . . . .  9
       5.1.5.  IPAddressMask AVP  . . . . . . . . . . . . . . . . . . 10
       5.1.6.  PortRange AVP  . . . . . . . . . . . . . . . . . . . . 10
       5.1.7.  Assigned AVP . . . . . . . . . . . . . . . . . . . . . 10
     5.2.  IP Options . . . . . . . . . . . . . . . . . . . . . . . . 10
       5.2.1.  FragFlag AVP . . . . . . . . . . . . . . . . . . . . . 10
       5.2.2.  IPOptions AVP  . . . . . . . . . . . . . . . . . . . . 10
       5.2.3.  TCPOptions AVP . . . . . . . . . . . . . . . . . . . . 11
       5.2.4.  Established AVP  . . . . . . . . . . . . . . . . . . . 11
       5.2.5.  Setup AVP  . . . . . . . . . . . . . . . . . . . . . . 11
       5.2.6.  TCPFlags AVP . . . . . . . . . . . . . . . . . . . . . 11
       5.2.7.  ICMPTypes  . . . . . . . . . . . . . . . . . . . . . . 11
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 14

Lior                    Expires December 29, 2007               [Page 2]

Internet-Draft             Diameter Classifier                 June 2007

1.  Introduction

   The Diameter base protocol [2] defines two data formats, IPFilterRule
   and QoSFilterRule.  IPFilterRule is designed to implement packet
   filters and QoSFilterRule tagging and metering of packets.  Both of
   these data formats are expressed as an ASCII string which makes it
   impossible to extend and also makes it difficult to parse and thus
   equipment suffer a performance hit.

   Many applications require to express packet classifiers.  QoS based
   applications need to be able to express which packets to apply a
   certain QoS treatment.  Charging applications need to be able to
   express which packets should be have certain charging rules applied
   to them.  Some applications need to be able to redirect certain
   packets.

   The packet classifiers need to be able to classify packets at the
   various layers and various protocols.  For example, it should be
   possible to build a classifier to work on layer 2 protocols and build
   another classifier that works on layer 3 protocols such as IPv4 or
   IPv6.  Classifiers must also be able to utilize various attributes
   that are utilized in these layers and protocols.

Lior                    Expires December 29, 2007               [Page 3]

Internet-Draft             Diameter Classifier                 June 2007

2.  Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1].

Lior                    Expires December 29, 2007               [Page 4]

Internet-Draft             Diameter Classifier                 June 2007

3.  Classifier Attribute Overview

   Classifiers are used in many applications to specify how to classify
   packets.  For example in a QoS application, if a packet matches a
   classifier then that packet will be treated in accordance with a QoS
   specification associated with that classifier.

   The Classifiers are sent to on on-path element (e.g. a router) which
   uses the classifier to match packets.  Figure 1 shows a typical
   deployment.

                                                         +-----------+
                                                        +-----------+|
     +--------+          +-------------+              +------------+||
     |        |   IN     |             |              |            |||
     |        +--------->|             +------------->|            |||
     |Managed |          | Classifier  |              | Unmanaged  |||
     |Terminal|   OUT    | Entity      |              | Terminal   |||
     |        |<---------+             |<-------------+            ||+
     |        |          |             |              |            |+
     +--------+          +-------------+              +------------+
                                             ^
                                             | Classifiers
                                             |
                                      +------+-------+
                                      |              |
                                      |      AAA     |
                                      |              |
                                      +--------------+

              Figure 1: Example of a Classifier Architecture

   The managed terminal, the terminal for which the classifiers are
   being specified is located on the left of the Classifier Entity.  The
   unmanaged terminal, the terminal that receives packets from the
   Managed terminal or sends packets to the managed terminal is located
   to the right side of the Classifier Entity.

   The Classifier Entity is responsible for classifying packets that are
   incoming (IN) from the Managed Terminal or packets outgoing (OUT) to
   the Managed Terminal.

   A Classifier consists of a group of attributes that specify how to
   match a packet.  Each attributes expresses values about aspects of
   the packet - typically the packet header.  Different protocols
   therefore would use different attributes.

   In general a Classifier consists of the following:

Lior                    Expires December 29, 2007               [Page 5]

Internet-Draft             Diameter Classifier                 June 2007

   Identifier:

      The identifier uniquely identifies this classifier and maybe used
      to reference the classifier from another structure.

   From:

      Specifies the rule for matching the source part of the packet.

   To:

      Specifies the rule for matching the destination part of the
      packet.

   Protocol

      Specifies the matching protocol of the packet.

   Direction:

      Specifies whether the classifier is to apply to packets flowing
      from the Managed Terminal (IN) or to packets flowing to the
      Managed Terminal (OUT), or packets flowing in both direction.

   Options:

      Associated with each protocol or layer, or various values specific
      to the header of the protocol or layer.  Options allow matching on
      those values.

   Each protocol type will have a specific set of attributes that can be
   used to specify a classifier for that protocol.  These attributes
   will be grouped under a grouped AVP called a Classifier AVP.

Lior                    Expires December 29, 2007               [Page 6]

Internet-Draft             Diameter Classifier                 June 2007

4.  Classifier AVP

   The Classifier AVP is a grouped AVP that consists of the following:

   ClassifierID AVP:

      The ClassifierID AVP is of type OctetString that uniquely
      identifies the classifier.  Each Classifier MUST have a single
      instance of the attribute.  Each application will define whether
      this identifier is unique per terminal or globally unique.
      Exactly one ClassierID AVP MUST be contained within a Classifier
      AVP.

   Protocol AVP

      The Protocol AVP is of type enumeration that specifies the
      protocol being matched.  The attributes included in the Classifier
      AVP must be consistent with this value of the Protocol AVP.
      Exactly one of Protocol AVP MUST be contained within a Classifier
      AVP.

   Direction AVP:

      The Direction AVP is of type enumeration that specifies in which
      direction to apply the Classifier.  The values of the enumeration
      are: "IN","OUT","INOUT".  In the "IN" and "INOUT" directions, the
      From-Spec refers to the address of the Managed Terminal and the
      To-Spec refers to the unmanaged terminal.  In the "OUT" direction,
      the From-Spec refers to the Unmanaged Terminal whereas the To-Spec
      refers to the Managed Terminal.

   From-Spec AVP:

      This grouped AVP specifies the Source Specification used to match
      the packet.  Zero or more of these attributes may appear in the
      classifier.  If the attribute is absent from the classifier then
      the source address is not being matched (wild card).  If more then
      one attribute of this type appears in the Classifier then the
      attributes are used in the order specified.  The contents of this
      AVP are protocol specific.

   To-Spec:

      This grouped AVP specifies the Destination Specification used to
      match the packet.  Zero or more of these attributes may appear in
      the classifier.  If the attribute is absent from the classifier
      then the destination address is not being matched (wild card).  If
      more then one attribute of this type appears in the Classifier

Lior                    Expires December 29, 2007               [Page 7]

Internet-Draft             Diameter Classifier                 June 2007

      then the attributes are used in the order specified.  The contents
      of this AVP are protocol specific.

Lior                    Expires December 29, 2007               [Page 8]

Internet-Draft             Diameter Classifier                 June 2007

5.  IP Classifiers

   The following specifies the attribute types that can be used to build
   classifiers for IP based protocols.

5.1.  Source and Destination Attributes

   For IP classification the contents of the From-Spec and To-Spec can
   contain the following attributes.

   Combining several of this attributes within a From-Spec and To-Spec
   and using more then one From-Spec and To-Spec AVP one can express
   many different types IP address pools.

5.1.1.  Inverted AVP

   This attribute is of Enumerated [2] containing the values of True or
   False.  Exactly zero or one of these attributes may appear in a From-
   Spec of a To-Spec.  When set to True the meaning of the match in the
   To-Spec and From-Spec are inverted, causing all other addresses to be
   matched instead.

   When set to False, or when the attribute is not included in the From-
   Spec and To-Spec then the meaning of the match is not inverted,
   causing only the addresses specified to be matched.  This is
   equivalent to the '!' character of the IPFilterRule.

   Note that inversion does not impact the ports matchers.

5.1.2.  IPAddress AVP

   The IPAddress AVP is of type Address [2] and specifies an exactly IP
   address (IPv4 or IPv6) address to match.

   Zero or more of these attributes may appear in the From-Spec and the
   To-Spec grouped AVP.

5.1.3.  Port AVP

   The Port AVP is of type Integer32 and has a maximum value of 65535
   and specifies the port to match.  Note the port attribute is not
   impacted by the Invertion AVP.

5.1.4.  IPAddressRange AVP

   The IPAddressRange is a grouped AVP containing an IPAddressStart and
   IPAddressStop AVP of type Address that specifies an inclusive IP
   address range.

Lior                    Expires December 29, 2007               [Page 9]

Internet-Draft             Diameter Classifier                 June 2007

   If the IPAddressStart is not included then the address range starts
   from the first valid IP address to and including the specified
   IPAddressStop address.

   If the IPAddressStop is not included then the address range starts at
   the address specified by the IPAddressStart AVP and includes all the
   remaining valid IP addresses.

5.1.5.  IPAddressMask AVP

   The IPAddressMask AVP is a grouped AVP expressing an IP address
   range using a base IP address and a bit-mask as in: 1.2.3.4/24.  In
   this case, all IP numbers from 1.2.3.0 to 1.2.3.255 will match.  The
   bit-mask width MUST be valid for the IP version and the IP number
   MUST NOT have bits set beyond the bit-mask.

5.1.6.  PortRange AVP

   The PortRange is a grouped AVP containing a PortStart and PortEnd
   AVPs of type Integer32 which specify an inclusive range of ports.

   If the PortStart range is omitted then port 0 is assumed.  If PortEnd
   is omitted then port 65535 is assumed.

   Port Range is not impacted by the Inversion AVP.

5.1.7.  Assigned AVP

   Often, the AAA does not know the IP address assigned to the Managed
   Terminal.  The Assigned AVP is of type Enumeration and consist of the
   value "Assigned".  When present, it represents the IP address
   assigned to the Managed Terminal.

5.2.  IP Options

   The Classifier Grouped AVP may contain one or of the following AVP
   used to match on the various possible IP options.

5.2.1.  FragFlag AVP

   Match if the packet is a fragment and this is not the first fragment
   of the datagram. frag may not be used in conjunction with either
   tcpflags or TCP/UDP port specifications.

5.2.2.  IPOptions AVP

   Match if the IP header contains the comma separated list of options
   specified in spec.  The supported IP options are: ssrr (strict source

Lior                    Expires December 29, 2007              [Page 10]

Internet-Draft             Diameter Classifier                 June 2007

   route), lsrr (loose source route), rr (record packet route) and ts
   (timestamp).  The absence of a particular option may be denoted with
   a '!'.

5.2.3.  TCPOptions AVP

   Match if the TCP header contains the comma separated list of options
   specified in spec.  The supported TCP options are: mss (maximum
   segment size), window (tcp window advertisement), sack (selective
   ack), ts (rfc1323 timestamp) and cc (rfc1644 t/tcp connection count).
   The absence of a particular option may be denoted with a '!'.

5.2.4.  Established AVP

   TCP packets only.  Match packets that have the RST or ACK bits set.

5.2.5.  Setup AVP

   TCP packets only.  Match packets that have the SYN bit set but no ACK
   bit.

5.2.6.  TCPFlags AVP

   TCP packets only.  Match if the TCP header contains the comma
   separated list of flags specified in spec.  The supported TCP flags
   are: fin, syn, rst, psh, ack and urg.  The absence of a particular
   flag may be denoted with a '!'.  A rule that contains a tcpflags
   specification can never match a fragmented packet that has a non-zero
   offset.  See the frag option for details on matching fragmented
   packets.

5.2.7.  ICMPTypes

   ICMP packets only.  Match if the ICMP type is in the list types.  The
   list may be specified as any combination of ranges or individual
   types separated by commas.  Both the numeric values and the symbolic
   values listed below can be used.  The supported ICMP types are: echo
   reply (0), destination unreachable (3), source quench (4), redirect
   (5), echo request (8), router advertisement (9), router solicitation
   (10), time-to-live exceeded (11), IP header bad (12), timestamp
   request (13), timestamp reply (14), information request (15),
   information reply (16), address mask request (17) and address mask
   reply (18).

Lior                    Expires December 29, 2007              [Page 11]

Internet-Draft             Diameter Classifier                 June 2007

6.  References

6.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

6.2.  Informative References

   [2]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
        "Diameter Base Protocol", RFC 3588, September 2003.

Lior                    Expires December 29, 2007              [Page 12]

Internet-Draft             Diameter Classifier                 June 2007

Author's Address

   Avi Lior
   Bridgewater Systems
   303 Terry Fox Drive, Suite 500
   Ottawa, Ontario
   Canada K2K 3J1

   Phone: +1 613-591-6655
   Email: [email-masked]

Lior                    Expires December 29, 2007              [Page 13]

Internet-Draft             Diameter Classifier                 June 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Lior                    Expires December 29, 2007              [Page 14]

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "harish raghuveer" <[email-masked]>
Date: Thu, 5 Jul 2007 10:07:57 +0530

Hi,

Currently the document does not describe any AVP to support DSCP/TOS field
based classification (Or did I miss it in the document? :-)). IMHO, it will
be good to add support for this too.

thanks and regards,
Harish

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 5 Jul 2007 08:56:48 -0400

It makes sense to use grouped AVPs rather than some text encoding
(actually in general not just for this case).

Would that require using a new "version" of Diameter, i.e. incrementing
version value in the header? Or should there be a new grouped AVP used
during capability exchange to advertise supported "extensions" (where
each extension is indicated as a sub-AVP)

A dirty workaround could be to use (or better said to abuse)
Supported-Vendor-Id AVP and define a pseudo vendor for each new
extension. 

A fourth alternative is probably not to signal anything during
capability exchange, and let a node which uses the "old" encoding to
(hopefully) fail during the parsing. If the sender is able to switch to
the old encoding, it can retry the request to the same server or can try
an alternate server.

Any ideas?

   Thanks,
   Tolga

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, July 04, 2007 4:04 PM
> To: [email-masked]
> Subject: [Dime] Diameter Classifier Document
> 
> Hi all,
>