[Dime] endpoint determination

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Thu, 28 November 2013 12:21 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 842F01AE0B0 for <dime@ietfa.amsl.com>; Thu, 28 Nov 2013 04:21:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 PIaIt6eue1ZB for <dime@ietfa.amsl.com>; Thu, 28 Nov 2013 04:21:53 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id DFBAC1ADFA0 for <dime@ietf.org>; Thu, 28 Nov 2013 04:21:52 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rASCLoBH011555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Thu, 28 Nov 2013 13:21:50 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rASCLnHC031093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Thu, 28 Nov 2013 13:21:50 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 13:21:49 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: endpoint determination
Thread-Index: Ac7sNGlk8/aQM1p4QPOTYH1OvkMS+g==
Date: Thu, 28 Nov 2013 12:21:49 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519BD77@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.108]
Content-Type: text/plain; charset="us-ascii"
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: 1528
X-purgate-ID: 151667::1385641311-000022AE-790A77B3/0-0/0-0
Subject: [Dime] endpoint determination
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: Thu, 28 Nov 2013 12:21:55 -0000

Hi,

draft-ietf-dime-ovli-00 in Clause 5.1 says:

How the endpoints are determined is specific to a deployment, a Diameter node role in that deployment and local configuration.


In order to better address REQ  6 of RFC 7068 I would like to propose some principles that should be taken into account:

1. A client that supports the Diameter Overload Control Mechanism must (offer to) take the role of a reacting endpoint and hence includes the OC-Feature-Vector AVP when sending requests.
2. An Agent that - based on local configuration - takes the role of a reporting endpoint (towards the downstream reacting endpoint) must also (offer to) take the role of a reacting endpoint towards the server and hence replace the received OC-Feature-Vector AVP with its own OC-Featur-Vector AVP.
3. An agent that supports the Diameter Overload Control Mechanism and that - based on absence of local configuration - does not take the role of a reporting endpoint must be able to detect whether a downstream agent or client  already takes the role of the reacting endpoint (e.g. by checking the presence of an OC-Feature-Vector AVP in the received request). If it detects that no downstream node took the role of the reacting  endpoint, the agent must take the role of the reacting endpoint and hence insert an OC-Feature AVP to the request. I.e. determination of the reporting endpoint is done dynamically and does not rely on local configuration.

Comments are welcome.

Ulrich