[Dime] OVLI: comments to 4.6

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Fri, 06 December 2013 12:10 UTC

Return-Path: <ulrich.wiehe@nsn.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FE01AE337 for <dime@ietfa.amsl.com>; Fri, 6 Dec 2013 04:10:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEk_78E9RX8x for <dime@ietfa.amsl.com>; Fri, 6 Dec 2013 04:10:47 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7812E1ADED8 for <dime@ietf.org>; Fri, 6 Dec 2013 04:10:47 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB6CAgAA009570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Fri, 6 Dec 2013 13:10:42 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB6CAgpq016352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Fri, 6 Dec 2013 13:10:42 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 6 Dec 2013 13:10:42 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 13:10:41 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: OVLI: comments to 4.6
Thread-Index: Ac7yfC5RbFsL+gV9TT6AJTwE2Xmtww==
Date: Fri, 06 Dec 2013 12:10:41 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.117]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 4451
X-purgate-ID: 151667::1386331842-00002466-F4EB186D/0-0/0-0
Subject: [Dime] OVLI: comments to 4.6
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 12:10:51 -0000

Dear all,
 
here are comments to clause 4.6:
 
It has already been proposed to change the type of the OC-Report-Type AVP from Enumerated to Unsinged64 in order to avoid potential extensibility problems.  
In addition to that, I think that the purpose of the Report-Type is to let the reacting node know to which (future) request commands the overload treatment should apply:

For a host report-type the overload treatment should apply to all request commands for which
a) The request command's Application-ID matches the Application-Id of the OC-Report-Type AVP's encapsulating answer command and
b) The request command's Destination-Host is present and 
c) The request command's Destination-Host matches the Origin-Host of the OC-Report-Type AVP's encapsulating answer command

For a realm report-type the overload treatment should apply to all request commands for which
a) <see a) above> and
d) The request command's Destination-Host is absent and 
e) The request command's Destination Realm matches the Origin-Realm of the OC-Report-Type AVP's encapsulating answer command.

The proposal now is to assign individual bits of the Unsinged64 type to a), b), c), d), and e):

Proposed text:


   4.6 OC-Report-Type AVP

   The OC-Report-Type AVP (AVP code TBD5) is type of Unsigned64 and contains a 64 bit flags field of a request
   command's characteristics.

   The following characteristics are defined in this document:

   APPLICATION_ID_MATCH (0x0000000000000001)

   When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
   to those request commands with an Application-ID that matches the Application-Id of the OC-Report-Type AVP's
   encapsulating answer command.

   DESTINATION_HOST_PRESENT (0x0000000000000002)

   When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
   to those request commands containing a Destination-Host AVP.

   DESTINATION_HOST_MATCH (0x0000000000000004)

   When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
   To those request commands with an Destination-Host AVP that matches the Origin-Host of the OC-Report-Type AVP's
   encapsulating answer command.

   DESTINATION_HOST_ABSENT (0x0000000000000008)

   When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
   to those request commands not containing a Destination-Host AVP.

   DESTINATION_REALM_MATCH (0x0000000000000010)

   When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
   to those request commands with an Destination-Host AVP that matches the Origin-Host of the OC-Report-Type AVP's
   encapsulating answer command.

   Combinations other than 
   1) APPLICATION_ID_MATCH and DESTINATION_HOST_PRESENT and DESTINATION_HOST_MATCH
   and
   2) APPLICATION_ID_MATCH and DESTINATION_HOST_ABSENT and DESTINATION_REALM_MATCH
   require a mutually agreed extension.




One extension required by 3GPP applications is the Overload Mitigation Differentiation per client (see 3GPP TR 29.809 clause 6.4.7. To address this, a new value would be needed e.g.
 
   ORIGIN_HOST_MATCH (0x0000000000000020)

   When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
   to those request commands with an Origin-Host AVP that matches the Destination-Host of the OC-Report-Type AVP's
   encapsulating answer command.

With this extension the following additional combinations would be allowed:
3) APPLICATION_ID_MATCH and DESTINATION_HOST_PRESENT and DESTINATION_HOST_MATCH and ORIGIN_HOST_MATCH
and
4) APPLICATION_ID_MATCH and DESTINATION_HOST_ABSENT and DESTINATION_REALM_MATCH and ORIGIN_HOST_MATCH

Another potential extension is Diameter Agent Overload. To address this, a new value would be needed e.g.

   NEXT_HOP_MATCH (0x0000000000000040)

   When this flag is set by the overload reporting endpoint it means that the overload treatment should apply only
   to those request commands sent to the same next hop the OC-Report-Type AVP's encapsulating answer command was received from.


Best regards
Ulrich