[Dime] OLR applicable for any/all applications

Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> Tue, 03 December 2013 08:42 UTC

Return-Path: <maria.cruz.bartolome@ericsson.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 A49581AE097 for <dime@ietfa.amsl.com>; Tue, 3 Dec 2013 00:42:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level:
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 swTGgRMo_qhS for <dime@ietfa.amsl.com>; Tue, 3 Dec 2013 00:42:57 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAD81ADFD6 for <dime@ietf.org>; Tue, 3 Dec 2013 00:42:56 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-2f-529d998c8f27
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CF.A8.03802.C899D925; Tue, 3 Dec 2013 09:42:52 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.118]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0347.000; Tue, 3 Dec 2013 09:42:51 +0100
From: Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: OLR applicable for any/all applications
Thread-Index: Ac7wA2nX03YOMS5NT1qqOpqV4/v8iQ==
Date: Tue, 03 Dec 2013 08:42:50 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.19]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920972BE0CESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+JvrW7PzLlBBvN321jM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMu9u1kLbtVWLGk9xNLA+CWvi5GTQ0LARGLqjoXsELaYxIV7 69m6GLk4hAQOMUpMXbKLGcJZzCjx6OAeVpAqNgE7iUunXzB1MXJwiAgoS5z+5QASFhYwkLgy fSITiC0iYCpx/fwqZghbT2LpvQ1grSwCKhJnbkPEeQV8JbYseg1Wzwi0+PupNWA2s4C4xK0n 85kgDhKQWLLnPDOELSrx8vE/VghbUaL9aQMjRH2+xLWdK9khZgpKnJz5hGUCo9AsJKNmISmb haQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2Jkz03MzEkvN9rECAz7g1t+q+5gvHNO 5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYQ6c7RFe8+rG/48OdDMMa Y49Zu8v9TLZMDMjg050asIBX7sLndIOkxVtNFoZ0B38Tu7C9NvJL6fsfVX9+OT2sU7qw5sJJ kagjmy9yK4sVX77jlHmM/4rQFYWXP9QnnWS4s0jm+sm/+2zWvTSQ+c6s/Oecrvq77RGp5ox8 Mqe25OmsK+xqya1NVGIpzkg01GIuKk4EAAW56dRJAgAA
Subject: [Dime] OLR applicable for any/all applications
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: Tue, 03 Dec 2013 08:42:59 -0000

Dear all,

There may be a need by a reporting node to request traffic reduction for all traffic, application independent, e.g. if an operator's network becomes severely overloaded, it may be of interest to signal directly general overload to the client.

In this case, since reacting node obtains affected application from the application message, we may need to extend OLR.

At least we got following options:



A)     Define a new optional AVP that could be included into OLR, like e.g.:

   OC-OLR ::= < AVP Header: TBD2 >

              < TimeStamp >

              [ Reduction-Percentage ]

              [ ValidityDuration ]

              [ ReportType ]

              [All applications]

            * [ AVP ]



B)      Extend  ReportTypes like e.g.:

   3  Destination-Host All Applications report.  Similar to Destination-Host report but it would apply to any application regardless the application message this report is received within.

   4  Realm (aggregated) All Applications report.  Similar to Realm report but it would apply to any application regardless the application message this report is received within.



I tend to prefer option A, but let me know your opinions and preferences.
Best regards
/MCruz