From nobody Fri Mar 1 08:54:03 2019 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FCE130E9B; Fri, 1 Mar 2019 08:54:02 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 OpaBw_69EXIr; Fri, 1 Mar 2019 08:54:00 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01620130E90; Fri, 1 Mar 2019 08:53:59 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 88794B80A4E; Fri, 1 Mar 2019 08:53:38 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, dime@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190301165338.88794B80A4E@rfc-editor.org> Date: Fri, 1 Mar 2019 08:53:38 -0800 (PST) Archived-At: Subject: [Dime] =?utf-8?q?RFC_8506_on_Diameter_Credit-Control_Application?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 16:54:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8506 Title: Diameter Credit-Control Application Author: L. Bertz, Ed., D. Dolson, Ed., Y. Lifshitz, Ed. Status: Standards Track Stream: IETF Date: March 2019 Mailbox: lyleb551144@gmail.com, ddolson@acm.org, yuvalif@yahoo.com Pages: 130 Characters: 338474 Obsoletes: RFC 4006 I-D Tag: draft-ietf-dime-rfc4006bis-12.txt URL: https://www.rfc-editor.org/info/rfc8506 DOI: 10.17487/RFC8506 This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end-user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. The Diameter Credit- Control application as defined in this document obsoletes RFC 4006, and it must be supported by all new Diameter Credit-Control application implementations. This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat Mar 30 05:55:16 2019 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201441201A4 for ; Sat, 30 Mar 2019 05:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 VxSD9CyPMwbF for ; Sat, 30 Mar 2019 05:55:11 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150104.outbound.protection.outlook.com [40.107.15.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115131201A3 for ; Sat, 30 Mar 2019 05:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pq+lCs7bYR6JYiQuiU4AtdLhpaGa+U2nD5D2VKe1dK4=; b=QVFQ0d39YiBBVU1GqIHHfstXXywhTDSk6Oau5pDvMBgFJR2gguqnxAJhWavohckOltnKeIW+zNkd2VGYge6tqrbrMgKgX4Ps4OAzNNdupsldhsCh2bE0uw/3VCnbXI4Bd8BTqBqdJ3mt7GZQu7g0A7AODwvpglPH00Dv8zKtHak= Received: from AM0PR07MB5490.eurprd07.prod.outlook.com (20.178.23.91) by AM0PR07MB4787.eurprd07.prod.outlook.com (52.135.152.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.8; Sat, 30 Mar 2019 12:55:01 +0000 Received: from AM0PR07MB5490.eurprd07.prod.outlook.com ([fe80::51ef:1853:48c0:17de]) by AM0PR07MB5490.eurprd07.prod.outlook.com ([fe80::51ef:1853:48c0:17de%5]) with mapi id 15.20.1771.007; Sat, 30 Mar 2019 12:55:00 +0000 From: "Poscic, Kristian (Nokia - US/Mountain View)" To: "dime@ietf.org" Thread-Topic: clearing of the Destination-Host AVP in the retransmitted request Thread-Index: AdTmh7TwzN1E6HnzRjKZFmd70UeSTA== Date: Sat, 30 Mar 2019 12:55:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kristian.poscic@nokia.com; x-originating-ip: [135.245.20.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bd5a4b05-f7d5-44bc-173c-08d6b50eebcf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM0PR07MB4787; x-ms-traffictypediagnostic: AM0PR07MB4787: x-microsoft-antispam-prvs: x-forefront-prvs: 09928BEC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(136003)(376002)(396003)(366004)(199004)(189003)(316002)(99286004)(7736002)(74316002)(25786009)(86362001)(478600001)(9686003)(54896002)(6306002)(6506007)(14454004)(106356001)(55016002)(53936002)(2501003)(2351001)(6916009)(102836004)(105586002)(52536014)(14444005)(5640700003)(186003)(4743002)(6436002)(5660300002)(1730700003)(486006)(81156014)(66066001)(790700001)(8676002)(6116002)(256004)(8936002)(2906002)(97736004)(7696005)(26005)(33656002)(3846002)(81166006)(71200400001)(71190400001)(68736007)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4787; H:AM0PR07MB5490.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: UipS9AtQhu0fJi0QBUwDbOiXmnfG2vplm+nfsq5vqWvExm3AdnRfx/n8Z+FMBiybdtSKK/5zc3zgX1DKd6/WW9/HQMctkN5249/V9v53HwTJ3mrRrc4EveBEUlT57f3TdfwOsi+uYBRBtW8QFVd1FxLIkCYhL+JH73HJ7KU1/5tf24k1M6VK4qAIjWFmvzfUzo9q6QeMClpIvfmB3ejlcCq+2MHebYlYCcQxHMQCd4M8aLdO+l8qZD0FJOsDHxRz/SAhm9xEGpO0drdLj8tIsz62GeUf65xuGybJ5Gh4qOEV0cg4EcWrkUkzM57rh5AU/q1dyT7+DzcxCS/jYn4QVQ+bUZzpbYgyvTHo4Gp4/K5o8yvAVVNnRKGy9v1RubFzF8kc1tGXTfiRJW4Rh2/vCO9WgVliviTlOodeKtlFg1w= Content-Type: multipart/alternative; boundary="_000_AM0PR07MB5490C5A45B7C282661941E16ED5B0AM0PR07MB5490eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: bd5a4b05-f7d5-44bc-173c-08d6b50eebcf X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2019 12:55:00.8440 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4787 Archived-At: Subject: [Dime] clearing of the Destination-Host AVP in the retransmitted request X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 12:55:14 -0000 --_000_AM0PR07MB5490C5A45B7C282661941E16ED5B0AM0PR07MB5490eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can someone clarify in which case should a Diameter client (DC) clear the D= estination-Host AVP in the *retransmitted* request message: 1. When the peer failover occurs - say the connection to node 1 fails a= nd DC retransmit the request in the pending queue to node 2? Section 5.5.4 = in RFC 6733 is not specific about this, and it may even imply that the dest= ination-host should not be cleared. Even though the clearing it may be bene= ficial. 1. When the client receives Diameter_Unable_to_Deliver (with E-bit set) = error message, which indicates that the node to which the request is sent i= s unable to deliver the message to the destination-host (or realm). In this= case it would be beneficial to blacklist this peer for this particular Dia= meter session. The application (Gx/Gy/NASREQ) could then retransmit, but it= clearly does not make sense for Diam Base to send the message to the same = peer. Should the destination-host be cleared in this retransmit? Some of th= is is mentioned in RFC 4006, sec 6.5, but again, it is not clear. I assume that when the original request message times out (due to no answer= received) and it is retransmitted after Tx timer expires, the destination-= host is not cleared in the retransmit. Also, should the CC-Req-Num be the same on retransmit, or should the client= use a new one? +---------+ |Diameter | +---------------------| | +---------+ | | Node 1 | |Diameter |--+ +---------+ | | | Client |--+ +---------+ +---------+ | |Diameter | +---------------------| | | Node 2 | +---------+ Note: Diameter Node 1 and Node 2 could be relay agents OR the home servers = (say redundant PCRFs, each with it's own unique peer name). I assume that DC should not make a decision on how to react based on the kn= owledge whether it has peering connection with the RA or the server. This is in the context on plain Base, without any overload functionality (o= verload reports). Thanks, Kris --_000_AM0PR07MB5490C5A45B7C282661941E16ED5B0AM0PR07MB5490eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can someone clarify in which case should a Diameter = client (DC) clear the Destination-Host AVP in the *retransmitted* re= quest message:

 

  1. When the peer failover occurs - say the connection to node 1 fails &n= bsp;and DC retransmit the request in the pending queue to node 2? Section 5= .5.4 in RFC 6733 is not specific about this, and it may even imply that the destination-host should not be cleared. Eve= n though the clearing it may be beneficial.

 

  1. When the client receives Diameter_Unable_to_Deliver (with E-bit set) = error message, which indicates that the node to which the request is sent i= s unable to deliver the message to the destination-host (or realm). In this case it would be beneficial to blackl= ist this peer for this particular Diameter session. The application (Gx/Gy/= NASREQ) could then retransmit, but it clearly does not make sense for Diam = Base to send the message to the same peer. Should the destination-host be cleared in this retransmit? Some= of this is mentioned in RFC 4006, sec 6.5, but again, it is not clear.

 

I assume that when the original request message time= s out (due to no answer received) and it is retransmitted after Tx timer ex= pires, the destination-host is not cleared in the retransmit.   <= o:p>

 

Also, should the CC-Req-Num be the same on retransmi= t, or should the client use a new one?

=  

=             &nb= sp;            =             &nb= sp;      +---------+

=             &nb= sp;            =             &nb= sp;      |Diameter |

=             &nb= sp;         +------------------= ---|         |   &nb= sp;   

=          +---------+&n= bsp; |           &nb= sp;         | Node 1  | &= nbsp;  

=          |Diameter |--+&nb= sp;            =         +---------+  &= nbsp;

=          |   &n= bsp;     |       &nb= sp;            =             &nb= sp;     

=          | Client  |--= 3;            &= nbsp;        +---------+ &n= bsp;

=          +---------+&n= bsp; |           &nb= sp;         |Diameter |  =  

=             &nb= sp;         +-------------= --------|         |  &nbs= p;        

=             &nb= sp;            =             &nb= sp;      | Node 2  |

=             &nb= sp;            =             &nb= sp;      +---------+

=  

=  

Note: Diameter Node 1 and Node 2 could be relay agen= ts OR the home servers (say redundant PCRFs, each with it’s own uniqu= e peer name).

I assume that DC should not make a decision on how t= o react based on the knowledge whether it has peering connection with the R= A or the server.

 

This is in the context on plain Base, without any ov= erload functionality (overload reports).

Thanks,

Kris

--_000_AM0PR07MB5490C5A45B7C282661941E16ED5B0AM0PR07MB5490eurp_--