From dime-bounces@ietf.org Thu Jun 01 01:20:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flfc1-0007Sf-SK; Thu, 01 Jun 2006 01:20:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlfbB-0006no-Vv for dime@ietf.org; Thu, 01 Jun 2006 01:19:58 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlfXu-0000Qx-Vs for dime@ietf.org; Thu, 01 Jun 2006 01:16:36 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k515GYEZ017568 for ; Wed, 31 May 2006 22:16:34 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k515GWdu002091 for ; Thu, 1 Jun 2006 00:16:33 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jun 2006 13:16:31 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Disconnect-Peer-Request and connection reattempts Thread-Index: AcaFOoiv2dUj0/KLRiybenxfrYp8Sg== From: "Ram O V Vishnu-A14676" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Dime] Disconnect-Peer-Request and connection reattempts X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi All, We would like to clarify the reconnect behaviour of Diameter peers which receive DPR. The relevant section in the RFC is 5.4. Section 5.4 para-1 hints no connection reattempts in the following cases :=20 1. "shortage of internal resources" which we assume to correspond to "BUSY" value of Disconnect-Cause AVP (as in sec 5.4.3). Or =20 2. "node in question has no intentions of forwarding any Diameter messages to the peer in the foreseeable future" which we assume to correspond to "DO_NOT_WANT_TO_TALK_TO_YOU" value of Disconnect-Cause AVP. But hints connection reattempts in case: 3. "or that the peer has rebooted. In these cases, the peer may periodically attempt to reconnect, as stated in Section 2.1" which corresponds to "REBOOTING" value for Disconnect-Cause AVP. Is there a need for clarifying the mapping between the value of Disconnect-Cause AVP and expected behavior?=20 Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 01 01:48:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flg2X-0005fR-OJ; Thu, 01 Jun 2006 01:48:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flg2W-0005fC-Dq for dime@ietf.org; Thu, 01 Jun 2006 01:48:12 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flg2S-0004YH-QA for dime@ietf.org; Thu, 01 Jun 2006 01:48:12 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0600J8R3GEGI@szxga02-in.huawei.com> for dime@ietf.org; Thu, 01 Jun 2006 14:02:39 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J06006113GEO9@szxga02-in.huawei.com> for dime@ietf.org; Thu, 01 Jun 2006 14:02:38 +0800 (CST) Received: from huawei1515 ([10.18.5.169]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0600FML2S50A@szxml03-in.huawei.com> for dime@ietf.org; Thu, 01 Jun 2006 13:48:06 +0800 (CST) Date: Thu, 01 Jun 2006 11:17:12 +0530 From: Rajith R Subject: [Dime] Disconnect-Peer-Request handling In-reply-to: To: dime@ietf.org Message-id: <000001c6853e$d51b4ac0$a905120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi I have some more doubts on section 5.4-para 2 which describes DPR handling. It says the recipient SHOULD return a DPA with an error result code if messages are pending on the connection. Does this mean that in this case the recipient will not close the connection? (Because the CM state machine description says on receiving a DPR, the action is send DPA & Disc) Also when the sender receives the DPA with result code != DIAMETER_SUCCESS, can we assume it will also NOT close the connection? (Again, the state machine description says in closing state, on Rcv-DPA, the action is Disc) Regards Rajith *********************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] Sent: Thursday, June 01, 2006 10:47 AM To: dime@ietf.org Subject: [Dime] Disconnect-Peer-Request and connection reattempts Hi All, We would like to clarify the reconnect behaviour of Diameter peers which receive DPR. The relevant section in the RFC is 5.4. Section 5.4 para-1 hints no connection reattempts in the following cases : 1. "shortage of internal resources" which we assume to correspond to "BUSY" value of Disconnect-Cause AVP (as in sec 5.4.3). Or 2. "node in question has no intentions of forwarding any Diameter messages to the peer in the foreseeable future" which we assume to correspond to "DO_NOT_WANT_TO_TALK_TO_YOU" value of Disconnect-Cause AVP. But hints connection reattempts in case: 3. "or that the peer has rebooted. In these cases, the peer may periodically attempt to reconnect, as stated in Section 2.1" which corresponds to "REBOOTING" value for Disconnect-Cause AVP. Is there a need for clarifying the mapping between the value of Disconnect-Cause AVP and expected behavior? Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 01 02:09:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlgNT-0004zg-0P; Thu, 01 Jun 2006 02:09:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlgNR-0004wJ-CQ for dime@ietf.org; Thu, 01 Jun 2006 02:09:49 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlgFp-0006Tz-QC for dime@ietf.org; Thu, 01 Jun 2006 02:02:01 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J060013B36TPL@szxga01-in.huawei.com> for dime@ietf.org; Thu, 01 Jun 2006 13:56:53 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0600CPN36T8G@szxga01-in.huawei.com> for dime@ietf.org; Thu, 01 Jun 2006 13:56:53 +0800 (CST) Received: from SHRIKANT1508 ([10.18.5.126]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J060037A3LWIS@szxml04-in.huawei.com> for dime@ietf.org; Thu, 01 Jun 2006 14:05:57 +0800 (CST) Date: Thu, 01 Jun 2006 11:25:39 +0530 From: Shrikantm Subject: RE: [Dime] Disconnect-Peer-Request and connection reattempts In-reply-to: To: 'Ram O V Vishnu-A14676' , dime@ietf.org Message-id: <004201c68540$0343bd50$7e05120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: multipart/mixed; boundary="Boundary_(ID_jFo8VCsDeIYcSl5spPgIUw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-MS-TNEF-Correlator: 000000005DF8FE3CE1BBCE48B33290E1280B23A9C4DE2100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shrikantm@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_jFo8VCsDeIYcSl5spPgIUw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Ram, DPR are for graceful disconnect from a node. So section 5.4 explains about such graceful disconnections. On the other hand for non-graceful disconnection, other peer cannot know the reason for the disconnect (because it may not receive any DPR). So in such a situations, the peer may periodically attempt to reconnect, as stated in Section 2.1. Thanks, Shrikant This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] Sent: 2006, June 01, Thursday 10:47 AM To: dime@ietf.org Subject: [Dime] Disconnect-Peer-Request and connection reattempts Hi All, We would like to clarify the reconnect behaviour of Diameter peers which receive DPR. The relevant section in the RFC is 5.4. Section 5.4 para-1 hints no connection reattempts in the following cases : 1. "shortage of internal resources" which we assume to correspond to "BUSY" value of Disconnect-Cause AVP (as in sec 5.4.3). Or 2. "node in question has no intentions of forwarding any Diameter messages to the peer in the foreseeable future" which we assume to correspond to "DO_NOT_WANT_TO_TALK_TO_YOU" value of Disconnect-Cause AVP. But hints connection reattempts in case: 3. "or that the peer has rebooted. In these cases, the peer may periodically attempt to reconnect, as stated in Section 2.1" which corresponds to "REBOOTING" value for Disconnect-Cause AVP. Is there a need for clarifying the mapping between the value of Disconnect-Cause AVP and expected behavior? Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_jFo8VCsDeIYcSl5spPgIUw) Content-type: application/ms-tnef; name=winmail.dat Content-transfer-encoding: base64 Content-disposition: attachment; filename=winmail.dat eJ8+IigFAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANYHBgABAAsAGQAAAAQADAEB A5AGABwUAAAtAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAALACsAAAAAAAMALgAA AAAAAwA2AAAAAAAeAHAAAQAAADkAAABbRGltZV0gRGlzY29ubmVjdC1QZWVyLVJlcXVlc3QgYW5k IGNvbm5lY3Rpb24gcmVhdHRlbXB0cwAAAAACAXEAAQAAABYAAAABxoVAAp/+DA7uaXhEcqHTbFfQ huW1AAACAR0MAQAAABoAAABTTVRQOlNIUklLQU5UTUBIVUFXRUkuQ09NAAAACwABDgAAAABAAAYO AJIT6z+FxgECAQoOAQAAABgAAAAAAAAAXfj+POG7zkizMpDhKAsjqcKAAAADABQOAAAAAAsAHw4B AAAAHgAoDgEAAAAtAAAAMDAwMDAwMDIBc2hyaWthbnRtQGh1YXdlaS5jb20BcG9wLmh1YXdlaS5j b20AAAAAHgApDgEAAAAtAAAAMDAwMDAwMDIBc2hyaWthbnRtQGh1YXdlaS5jb20BcG9wLmh1YXdl aS5jb20AAAAAAgEJEAEAAAB/DwAAew8AAFcsAABMWkZ1uKmW0gMACgByY3BnOTM2DQxgYwBQAQRz dHNowQVwYmNoMTMO9AkAmw9wDuVoDeAQRmJpAUPBC2BuZzEwMw+gEbXkZmUB0DUyAfcCpANjRwIA D3AKwHNldALRcJRycRMxKgqhbm8U4GwgMAHQAdA2EjATEDDONBaxAdAWoDR9B20Cg1YyBEYUjTEV jDcWkTn/FjMXAhbgF2AIVQeyAoMPkfcC8hSHD5A0FS8WMRIgFoBPH/AWoBIgIEV9UwdwUzR1bhWC ZgdABUDLzsjM5X0CgzM4A8UUj30Vm2IWcRbgFqQW4BvxfapWBJBkAHBhAoM2AFBvHY8jvx+vILFA IOQmdDUtFB4yInIoEiAHbSBDfkUmdA5AK04W0CxvLXV57nImdCKBFDwxJsIvvwOCqkcJ0WsmdDkx rzYYwXsy/wOCVAhwAoMbMDUPN4Y3Nj8tdChIZWIJcPx3KTfUJtE4bixfOnYHEN8BoA3gO1UYwTHN OC5RPS/9A4JCIZEN4DfUHWExzh1ha0C/OqNWCJB0JlAHgWXdO1Q4KyEY/Sw2MS3AHGi/LcZAckbO L3VIPTEVOCKB7xj9MqZIPDRIODTxTN82JH9IPDemG3BP7zlGSDw66znfJtFTH0ffVTI+ijkYz0BX f0g8QgkOIFm/Q9ZUjUWONP40KyEivCw4JgUtxmBwLlH/YM0vd2JHMRVgcCKPMqhiRv80SGBwNPFm XjYmYkY3pmCA/1mhZl1Ad2JGQglggB1hZl5fQ/ZiRl9sApEI5jsJbzDzcq8S8DU1c9p08XSvdbn/ c8R14nRPeB933XdfdY9z3/BlMTI4fap+wX5/f4n/c8R/sn4fge+BrYEvf1+DJH9ZkYZ0WZF/81mQ AoIPAHkqbAeQaAngdAAAcWp9AzBsEYEFEAFAFeAD8GTYY3RsCrEAYHMKsIswIyMwi3JudW0hcWF1 xHRvAGBkanUPAAUQeGdodIpxCgGKQAoBaekBkHAwA7IyAFAR5xKo7FxrBJELgGdZoBASArK/EMIA YAEyD2GRoQ+RYwnA84rwjwNucI9ZkzATAgMw8HNuZXgjgAewBbAAwHMCcxWgY3MSIAMwjPBkOY5Q aXYWEA7wI2BtaecQwJYgCfAgRAEQjKAhoRpQCsBhCcCOcGggRncCIZVUDxAxAFAPEANgdycLMI1A AYBzV4rwdGjeQg+gjUAKsJYgbBIgZiB9msRymzgQAJqmAYCcp2KNnKdymqEE8GVsbIrh/5pwmhEB QA8QlnAAICGRmSH/OxCbwKAmCVCgRAyxoFOLYPmgRGRnoSaioKImkRCgRPp2AzBxAyGKRorvi/+N D/eOHKhREfMyJ+ASpKnEkP//kg+TFKnnrRSUZZlQlpyU9O9EYAGgiXCVVzWV+pewCND7GLCUYWKl 8AmAAiCV0olBayNQpWAzqeAxaQCOkEi8eXAEkI4BNIOVkzaxH/+AMLI/s0qYkJ7gitAJgLQL/5XA OWCkmorPpk+nX6hvthL/jw+QHyJTq0Uicavfkw+UFte2lbcSrnM3ty9QC2JEYC+UoXHTFaBywHYC USB7/lW0cLqBGGGVYw4ABTDIIn/JMgxAyUGONbn3oFAO4WF+MMeFs1HIEswTs4XMEzm7RoBD4DUX YAqhtCF3mVB/G3AOQM5DD4AxgCJxAMBy/6Kws7B9Ac/Cm9DQIQMwAWTGNAwBAYBuYmoAYAnwv5Yg ECACAZUQDyC8sGWrMH0FsHrSUqKgz8ILgaKgaM+7UZ7AgDABQWd21HRD4f/UQQWwvSALgDlAKSDU 8tX1782wJ+DUQtMwd1mg1QLXw/pqBaBtKBAHkCLw0lGJUEu0IFmgdgiQd2sLgGR/J+DZ0gTwB0Cq YQ7hC1B5/nTIsAuA0xDRsdtnvUAAwL+8cLtQDGAjYCGgtpBsC5D/3aECUdohufDbcNrButACYH+Z wdthAlEAIKNR3bA7EGvecpew0xAV4OAhd5rQCTL/lICOcLyAwsILgJ7C3dG4YepmCJBslzFk3VGl QJrQ/nAhILrQuzEHMOAXs0IDYHxvdM21AzEjciNgutBk+Qrhc3o08I4BlKABQNIh/m6JoHLA5jPn AsLCs4AOQLvmQ5eEY+FB5lHMunPRs8/JoRWhAIAFkGx2myDrgf8OYJUQ64IBkAAg7BLaIQnw/nQB weuBIzASAMmiAjCUsP1ioC7I5eulWaDsMiGguyD/7K/tv+7PnJG78AWB8H/xj//yn+vwJ+C78N7Q 8E/1H/YlvinvDCsg8+/43/YFYjrQ/wKR+g/rw87h97/8j/2f/q//6/A5YP/y7H8BXwJv+n1mIP// /wWPBp8Hr+vhNPAEjwov/ws/DEUVsXCwycDG47l/uo//u5+8r435ETIjQbeYvn+/j/+QmMHDwX/C j8OecgGyEMoA/w4QzLojIhc7Gw8cEcDms/BbIH8hi2kgbyF8UkXQLHQNChEyICaFJG8hi0S4UFIg E5CWgNKRIHHyvx5fH28nbyGLmDGewGaXsO8qDysfLC8tPyCWMJ6wmKC/lJDj4TE/MktC4ilwIBMA /9EQ7vAu3y/vs9EmhTZvN3+jMO80j1NvIOZCaZig+CA1Lq4wOT86TztfPG/7lKARk3M+bz9/QI9B nylw9mJLYJfQc/AgmHBDL0Q//0VPRl8uT0i/Sc9K3zKPE1DfTO9N/08PUB894XM2X1Lf/zh6OMYR OxJPE1UUxRX/Fw//jt8Zbxp0qy8cDx0fZdEbcd8YBVa/Uz9UTyGaT5dQmnD3loDlQOexIPWxmdBn P1Br/26CZH9lj2afap8iA9KRbA+fbR9uL28/UJgTAG4tcQ//ch9zL3Q/S992L3c/eE95X39Qnz20 e398j32ffq8hxyz/aWSBL4I/g0+EX2tvhteQVf+OMYd/iI+JnyHHtCBpodrA+zNg5UAgyIJpI9jw E8A98f8pwmkyUTuLf4yPjZ+Or4pPn5OflK+Vv5bPl98oYuZQ/xTg67CY/5oPmx+cL50/MvD1vhAg r+B5NgGRQNjw1KDPtaLkQKSQKUEpLqJfmB//nw+gH6EvOKqoL6k/qk+iPz88jyQwxxBH0zXw5CB0 df5hPdJDEqwfrS+uP69PhQ7/sr+zz7Tfte+2/zLwaTKQo/+kcs5hPeDh8NrB3oA14N9w/mXY0JFA FQC4L7k/uk+7X/+8b6ffwM/B38Lvw/8iIaTx/zNUhfATwD2QXSC/UOaAWkHCUz21Mi4xLsUvxj// x0+rDRE/Wo8TXxRvFX9dD/8Xn17vX/8az2H/Yw8d984PL88fOGvazyGLVPWxa3PXJnbhTzysaNVg a2ngUc//33/QP8vQ0c/S39Pv1P/WD//oGeZy2EDm3Fi+76TYZNdQl9jl8oPqsHA1sG9m5s9jx936 omJrbeNgDjIgpF9NWjBsQeyhU+1Q31mg5B/ibDMgQpAtpHD3AM+lYcvQvzFMgGhtDuHLYG/Kwe5Q WkHKwWbXIA7haT++4LFhkmGkcD3TNaNIVdBBV0VJhfB3YTIkMP/LYFpAy7AOwcvQzHC/AZJmb75h kiKScfwidKSQ/iBv0wQANeBkZCmQc/6Ry2C/6jAOIMvBR3GlQMzQQaWB+56haWBmaSP8mvtFy8GG Ma+lIFpQWkGlcnekgShaQN0JMHW+sNiAhfBiR6GRIv3qMG3uQMvB7LCF8Oyw7lC/6gCScesx/EH3 ryGLbAl/939/BrABQHUpkIXwKZDzof5kR+A90oXx4+AzET2gB+D6brJTKQcwvkOSIctgaXQfkqBp 4AO1/tWk8WlwaXn8ISdzD/D5ofOhYTBi6wfyzNBJA6B5R5Ck55Kg7/moWkHZsDWwcoXw0WCSAfOl UJEhaWakkJKiPaD+8b/j4BASATDK8ABzFWRt+uD/vrDLob8C+lH8EBZgy7CkMf4h8Wz0D/Uf9iP+ 4fbMGq+vG7/IHwvPRvUtI7JP7UHLD4HqAE0BwWFn+dAjsq/t4qVQId9oO0Y1sTolv4kMfFJhNdBP IFYqICUzIGjsMC1B8KA2N3g2IFsn72g7+fLssDqydipjQG1pcJJwb1og8i7KwG1d6hIlj+Tv/CEn J98MbdfwMDaF8Ep1ORhBMDGF8OMgDcBzZKOkgdigOjQ3AwBNLu+/Mi/jAS1wNc8MfvrgQBKQ6HRm LpJwZzVvOI+xITh1YmrMMTfPON1bRE850S7AP1CAdi1QkLEt8FJlcXUBwJFA+kKAiP+R4r9EsqIf 7+fv8S9C7yDv8z1/aFlIaTUwvvDjhuOfq0jPOYFXpVB3FEBsy9D/6jDeUL+hkOBaIO1AFwXKp/0H MGXr0C2QFEBLMAORP1D/KeAaMQjxkLHLYP4jSu9L/3/KdKUjpbHM0OMgkdIWYHYf5jEXYcxEWkGS olJGQ+H+cjUuNC5Kf1JfMIrHzERXAQkCYS0xacD+sf/LYOqwQW9Cc1YWkmC+8OrBd9iAkOEPUHNX v1jPOYE671evX49owszBIipwknDuUP8k4AOC/rLZwCRhAbFQAXsg/HMi/hX+EKVRAdDsQE30+5Jw AbFwzHAIImD/Yg85geAiQlVTWWVgVVAGwJsDcz+5Q56SNTBWUIAw3ijLUbFyzDBW8zOl4CoA/2fg RN1oD1k7zKBjYOqw/BD/sWJA0wSC69Bbc/6zsmMDgv+SYQZA0TBd8qVzUIVuL28//yzyJKTLYE4R vZddJwGxkLD/AqAWYP1A7KANwWVmZfp0jw91nzmBZstjYERPX05AT1RfV0FOfoBUIX5AVEFMS37i WU/+VWo/a0h6/3wPOYFr8Vc/+4IfWVlCB1FbNFvPXNZeMu46hI+FnzmBM2NRknOyUP+9iHHCDdAC sBDAE8IT8BFT/wFRXjMIYb2piV+KbzmBvmb/kB9ZO77typ/Lr8ywZWWPrweTH30bd0MiUkVCT/F+ cElOR3/W/5Jq74Pf+5hfWSxJd0EFYrHhlaACcd//kk5FXfJdUqRwcBKAXgH9T6B0ZfDdcL2Df/ae X59vzzmBnJ9r8vpCZXi+YJXA8wJxT6VyP22vpS9ZWUCw/mfRIeN/qw85YypUnd+tf31ZWU0uFbB/ n83+8PxQIF5FFmCVwCeg3oBjlhBQ4nYHoEx0ZLAfs585gUQrOVsQOTg0RIA3njjdsbZvt385gVsq LsDXsmeN4GRlVQFRT/9RROz3uZ+6rzmBX8D/wg/C2r6v87+/prNNRS0TXfICMsPvf8T/xgU6B8dP yF85ge1wdMBwczovL3fNMGNAzToWL/ny+fBuLwIy/JIOLznCRcy48DU2MzUn8rBD70VlfQDSYAAe AEIQAQAAAEEAAAA8QzgyQTlCMTFCRTI0N0M0RTk1MkRDNzMzRUE5OERBQTEwMTZGOEJCM0BaTVkx NkVYTTY2LmRzLm1vdC5jb20+AAAAAAMAkhABAAAAAwDeP59OAAADAAJZAAAWAAMACVkDAAAAAwBA ZQAAAAALABOACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAFYAIIAYAAAAAAMAAAAAAAABG AAAAABCFAAAAAAAAAwAbgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAABOgAQAeACqACCAGAAAAAADA AAAAAAAARgAAAABUhQAAAQAAAAUAAAAxMC4wAAAAAAsAK4AIIAYAAAAAAMAAAAAAAABGAAAAAAaF AAAAAAAAAwAsgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAABAAC6ACCAGAAAAAADAAAAAAAAA RgAAAABghQAAANB25dH//x8LADWACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAOIAIIAYA AAAAAMAAAAAAAABGAAAAABiFAAAAAAAACwBOgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAAC AfgPAQAAABAAAABd+P484bvOSLMykOEoCyOpAgH6DwEAAAAQAAAAXfj+POG7zkizMpDhKAsjqQMA /g8FAAAAAwANNP03AgACARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEAAAAxAAAAMDAw MDAwMDA1REY4RkUzQ0UxQkJDRTQ4QjMzMjkwRTEyODBCMjNBOUM0REUyMTAwAAAAAAMABhCeOquI AwAHENQGAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAASElSQU0sRFBSQVJFRk9SR1JBQ0VG VUxESVNDT05ORUNURlJPTUFOT0RFU09TRUNUSU9ONTRFWFBMQUlOU0FCT1VUU1VDSEdSQUNFRlVM RElTQ09OTkVDVElPTlNPTlRIRU9USAAAAAAu8w== --Boundary_(ID_jFo8VCsDeIYcSl5spPgIUw) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_jFo8VCsDeIYcSl5spPgIUw)-- From dime-bounces@ietf.org Thu Jun 01 05:58:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FljwI-0000MF-6m; Thu, 01 Jun 2006 05:58:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FljwG-0000Le-PM for dime@ietf.org; Thu, 01 Jun 2006 05:58:00 -0400 Received: from web38212.mail.mud.yahoo.com ([209.191.124.155]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FljwF-0005MJ-Ft for dime@ietf.org; Thu, 01 Jun 2006 05:58:00 -0400 Received: (qmail 72778 invoked by uid 60001); 1 Jun 2006 09:57:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3EIcsIp300LLjUxZuklWziCeOoKkN0tOmxKAnN/IYsAw9lOqM+i1plmWeCJkXr76xM7i4NRAHo8bBXicMt8BeH74MteE3qazLJ9sOkpq9EfnaB1z2+7sV4pxhtf1QpXzD6D0M58ABCcKFz7noIafki/e7GLK6llAdkAh1ANlY1s= ; Message-ID: <20060601095758.72776.qmail@web38212.mail.mud.yahoo.com> Received: from [193.49.124.107] by web38212.mail.mud.yahoo.com via HTTP; Thu, 01 Jun 2006 11:57:58 CEST Date: Thu, 1 Jun 2006 11:57:58 +0200 (CEST) From: "#:-\) seb" Subject: [Dime] RE: Protocol Action: 'Diameter Session Initiation Protocol (SIP) Application' to Proposed Standard To: dime@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hello, I see that a 'Diameter SIP application" for authorization and authentification is under draft. I want to know if a Diameter application dealing with accounting and SIP could exist. Thank you ___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 01 08:23:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlmDB-0002Qn-O2; Thu, 01 Jun 2006 08:23:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlmDA-0002Qi-EN for dime@ietf.org; Thu, 01 Jun 2006 08:23:36 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlmD8-0003Sy-0w for dime@ietf.org; Thu, 01 Jun 2006 08:23:36 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k51CNWPr021378; Thu, 1 Jun 2006 15:23:33 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 15:23:25 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 15:23:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RE: Protocol Action: 'Diameter Session Initiation Protocol(SIP) Application' to Proposed Standard Date: Thu, 1 Jun 2006 15:23:25 +0300 Message-ID: In-Reply-To: <20060601095758.72776.qmail@web38212.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Protocol Action: 'Diameter Session Initiation Protocol(SIP) Application' to Proposed Standard Thread-Index: AcaFYn13DbuU4Ed4TeK/z7J/s40WMwABon+w From: To: , X-OriginalArrivalTime: 01 Jun 2006 12:23:24.0881 (UTC) FILETIME=[2DDE3410:01C68576] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hello, > I see that a 'Diameter SIP application" for authorization and=20 > authentification is under draft.=20 This has just been approved as an RFC today, FYI. > I want to know if a Diameter=20 > application dealing with accounting and SIP could exist.=20 You might want to look at the Diameter Credit Control RFC. John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 01 11:00:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Floem-000583-Re; Thu, 01 Jun 2006 11:00:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Floel-00057r-Nl for dime@ietf.org; Thu, 01 Jun 2006 11:00:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flnfs-0005F2-1u for dime@ietf.org; Thu, 01 Jun 2006 09:57:20 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlnXO-0002yh-4n for dime@ietf.org; Thu, 01 Jun 2006 09:48:37 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k51Dm0dG087682; Thu, 1 Jun 2006 09:48:01 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <447EF016.4060206@tari.toshiba.com> Date: Thu, 01 Jun 2006 09:48:06 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: rajithr@huawei.com Subject: Re: [Dime] Disconnect-Peer-Request handling References: <000001c6853e$d51b4ac0$a905120a@china.huawei.com> In-Reply-To: <000001c6853e$d51b4ac0$a905120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Rajith, > Hi > > I have some more doubts on section 5.4-para 2 which describes > DPR handling. It says the recipient SHOULD return a DPA with an error > result code if messages are pending on the connection. > Does this mean that in this case the recipient will not close > the connection? This seems to be what is implied in 5.4 since it states that the DPR is "intent" to disconnect and attempts to provide some leniency to in-flight messages. One possible problem with this scheme is that on high traffic scenario it is less likely that the DPR/DPA exchange would really result in a disconnection. Continuing to exchange subsequent DPR/DPA may eventually result in graceful disconnection but I'm not sure if this is any better than just closing the connection as described in the fsm. regards, victor > (Because the CM state machine description says on > receiving a DPR, the action is send DPA & Disc) Also when the sender > receives the DPA with result code != DIAMETER_SUCCESS, can we assume it > will also NOT close the connection? (Again, the state machine > description says in closing state, on Rcv-DPA, the action is Disc) > > Regards > > Rajith > > *********************************************************************** > This e-mail and attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient's) is prohibited. If you receive this e-mail in error, please > notify the sender by phone or email immediately and delete it! > > -----Original Message----- > From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > Sent: Thursday, June 01, 2006 10:47 AM > To: dime@ietf.org > Subject: [Dime] Disconnect-Peer-Request and connection reattempts > > Hi All, > > We would like to clarify the reconnect behaviour of Diameter peers which > receive DPR. The relevant section in the RFC is 5.4. > > Section 5.4 para-1 hints no connection reattempts in the following cases > : > 1. "shortage of internal resources" which we assume to correspond to > "BUSY" value of Disconnect-Cause AVP (as in sec 5.4.3). Or > > 2. "node in question has no intentions of forwarding any Diameter > messages to the peer in the foreseeable future" which we assume to > correspond to "DO_NOT_WANT_TO_TALK_TO_YOU" value of Disconnect-Cause > AVP. > > But hints connection reattempts in case: > 3. "or that the peer has rebooted. In these cases, the peer may > periodically attempt to reconnect, as stated in Section 2.1" which > corresponds to "REBOOTING" value for Disconnect-Cause AVP. > > Is there a need for clarifying the mapping between the value of > Disconnect-Cause AVP and expected behavior? > > Regards, > Vishnu. > > Motorola India Electronics Pvt Ltd > +91 9844178052 > [*] Motorola Internal Use Only > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 01 22:50:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flzjz-00020u-IZ; Thu, 01 Jun 2006 22:50:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flzjx-00020j-Vh for dime@ietf.org; Thu, 01 Jun 2006 22:50:21 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flzjv-0000B4-Fk for dime@ietf.org; Thu, 01 Jun 2006 22:50:21 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k522oJQB006412 for ; Thu, 1 Jun 2006 19:50:19 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k522oH7V017666 for ; Thu, 1 Jun 2006 21:50:18 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Disconnect-Peer-Request and connection reattempts Date: Fri, 2 Jun 2006 10:50:16 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Disconnect-Peer-Request and connection reattempts Thread-Index: AcaFQAKf/gwO7ml4RHKh02xX0IbltQArcUqA From: "Ram O V Vishnu-A14676" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.1 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2001289324==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2001289324== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C685EF.47583AC8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C685EF.47583AC8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's what I thought too, till I read the para-1 of section 5.4 a little more carefully. Ideally, we would like to get comments from the authors. This is potentially a problem in deployments because of the following scenario: - A node (especially servers) does not initiate connections but expects peers (read clients) to know about it & connect to it. Such behaviour may be justified by the fact that dynamic peer discovery is not supported and that static configuration of large number of peers is considered unwieldy. - As per what you are saying such a node cannot send DPR, because if it does, the peers (read clients) will not attempt reconnection. This will result in a scenario where there is no connection at all & neither party is attempting too. - this deadlock can only be broken by restart of the peer (of no fault of its own!). Out intent to clarify the mapping between Disconnect-Cause AVP and the reconnect behaviour was to solve these kind of problems. Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only > -----Original Message----- > From: Shrikantm [mailto:shrikantm@huawei.com]=20 > Sent: Thursday, June 01, 2006 11:26 AM > To: Ram O V Vishnu-A14676; dime@ietf.org > Subject: RE: [Dime] Disconnect-Peer-Request and connection > reattempts >=20 > Hi Ram, >=20 > DPR are for graceful disconnect from a node. > So section 5.4 explains about such graceful disconnections. >=20 > On the other hand for non-graceful disconnection, other peer cannot > know the reason for the disconnect (because it may not receive any > DPR).=20 > So in such a situations, the peer may periodically attempt to > reconnect, as stated in Section 2.1. =20 >=20 > Thanks, > Shrikant >=20 >=20 > This e-mail and attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address > is listed above. Any use of the information contained herein in any > way (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient's) is prohibited. If you receive this e-mail in error, > please notify the sender by phone or email immediately and delete it! >=20 > -----Original Message----- > From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com]=20 > Sent: 2006, June 01, Thursday 10:47 AM > To: dime@ietf.org > Subject: [Dime] Disconnect-Peer-Request and connection reattempts >=20 > Hi All, >=20 > We would like to clarify the reconnect behaviour of Diameter peers > which > receive DPR. The relevant section in the RFC is 5.4. >=20 > Section 5.4 para-1 hints no connection reattempts in the following > cases > :=20 > 1. "shortage of internal resources" which we assume to correspond to > "BUSY" value of Disconnect-Cause AVP (as in sec 5.4.3). Or =20 >=20 > 2. "node in question has no intentions of forwarding any Diameter > messages to the peer in the foreseeable future" which we assume to > correspond to "DO_NOT_WANT_TO_TALK_TO_YOU" value of Disconnect-Cause > AVP. >=20 > But hints connection reattempts in case: > 3. "or that the peer has rebooted. In these cases, the peer may > periodically attempt to reconnect, as stated in Section 2.1" which > corresponds to "REBOOTING" value for Disconnect-Cause AVP. >=20 > Is there a need for clarifying the mapping between the value of > Disconnect-Cause AVP and expected behavior?=20 >=20 > Regards, > Vishnu. >=20 > Motorola India Electronics Pvt Ltd > +91 9844178052 > [*] Motorola Internal Use Only >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C685EF.47583AC8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Dime] Disconnect-Peer-Request and connection = reattempts

That’s what I = thought too, till I read the para-1 of section 5.4 a little more = carefully. Ideally, we would like to get comments from the = authors.

This is potentially a = problem in deployments because of the following scenario:
- A node (especially = servers) does not initiate connections but expects peers (read clients) = to know about it & connect to it. Such behaviour may be justified by = the fact that dynamic peer discovery is not supported and that static = configuration of large number of peers is considered = unwieldy.

- As per what you are = saying such a node cannot send DPR, because if it does, the peers (read = clients) will not attempt reconnection. This will result in a scenario = where there is no connection at all & neither party is attempting = too.

- this deadlock can = only be broken by restart of the peer (of no fault of its own!).

Out intent to clarify = the mapping between Disconnect-Cause AVP and the reconnect behaviour was = to solve these kind of problems.

Regards,
Vishnu.

Motorola India Electronics Pvt = Ltd
+91 9844178052
[*] Motorola Internal Use Only


     -----Original Message-----
    From:   Shrikantm [mailto:shrikantm@huawei.com]
    Sent:   Thursday, June 01, 2006 11:26 AM
    To:     Ram O V Vishnu-A14676; dime@ietf.org
    Subject:       = RE: [Dime] Disconnect-Peer-Request = and connection reattempts

    Hi Ram,

    DPR are for = graceful disconnect from a node.
    So section 5.4 = explains about such graceful disconnections.

    On the other hand = for non-graceful disconnection, other peer cannot know the reason for = the disconnect (because it may not receive any DPR).

    So in such a = situations, the peer may periodically attempt to reconnect, as stated in = Section 2.1. 

    Thanks,
    Shrikant


    This e-mail and = attachments contain confidential information from HUAWEI, which is = intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but = not limited to, total or partial disclosure, reproduction, or = dissemination) by persons other than the intended recipient's) is = prohibited. If you receive this e-mail in error, please notify the = sender by phone or email immediately and delete it!

    -----Original = Message-----
    From: Ram O V Vishnu-A14676 [    mailto:vishnu@motorola.com]
    Sent: 2006, June 01, Thursday 10:47 AM
    To: dime@ietf.org
    Subject: [Dime] Disconnect-Peer-Request and connection reattempts

    Hi All,

    We would like to = clarify the reconnect behaviour of Diameter peers which
    receive DPR. The = relevant section in the RFC is 5.4.

    Section 5.4 para-1 = hints no connection reattempts in the following cases
    :
    1. "shortage = of internal resources" which  we assume to correspond = to
    "BUSY" = value of Disconnect-Cause AVP  (as in sec 5.4.3). Or 

    2. "node in = question has no intentions of forwarding any Diameter
    messages to the = peer in the foreseeable future" which we assume to
    correspond to = "DO_NOT_WANT_TO_TALK_TO_YOU" value of Disconnect-Cause
    AVP.

    But hints = connection reattempts in case:
    3. "or that = the peer has rebooted.  In these cases, the peer may
    periodically = attempt to reconnect, as stated in Section 2.1" which
    corresponds to = "REBOOTING" value for Disconnect-Cause AVP.

    Is there a need for = clarifying the mapping between the value of
    Disconnect-Cause = AVP and expected behavior?

    Regards,
    Vishnu.

    Motorola India = Electronics Pvt Ltd
    +91 = 9844178052
    [*] Motorola = Internal Use Only


    _______________________________________________
    DiME mailing = list
    DiME@ietf.org
    https://www1.ietf.org/mailman/listinfo/dime

------_=_NextPart_001_01C685EF.47583AC8-- --===============2001289324== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============2001289324==-- From dime-bounces@ietf.org Thu Jun 01 22:54:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flzo2-0007Z4-9u; Thu, 01 Jun 2006 22:54:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flzo1-0007Yu-6V for dime@ietf.org; Thu, 01 Jun 2006 22:54:33 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flznz-0000mF-RH for dime@ietf.org; Thu, 01 Jun 2006 22:54:33 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k522sVNa007226 for ; Thu, 1 Jun 2006 19:54:31 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k522sUV2011400 for ; Thu, 1 Jun 2006 21:54:30 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Disconnect-Peer-Request handling Date: Fri, 2 Jun 2006 10:54:29 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Disconnect-Peer-Request handling Thread-Index: AcaFjCPBcdIeoGQ2RYq20jRVhxx9owAY0CmQ From: "Ram O V Vishnu-A14676" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Victor, We agree with your last sentence. We are not sure about the value in DPA carrying an error and receivers not disconnecting based on it. Because in many cases receivers may not be in a position to wait (say, in some cases of REBOOTING). Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 Sent: Thursday, June 01, 2006 7:18 PM To: rajithr@huawei.com Cc: dime@ietf.org Subject: Re: [Dime] Disconnect-Peer-Request handling Hi Rajith, > Hi > > I have some more doubts on section 5.4-para 2 which describes DPR=20 > handling. It says the recipient SHOULD return a DPA with an error=20 > result code if messages are pending on the connection. > Does this mean that in this case the recipient will not close the=20 > connection? This seems to be what is implied in 5.4 since it states that the DPR is=20 "intent" to disconnect and attempts to provide some leniency to=20 in-flight messages. One possible problem with this scheme is that on=20 high traffic scenario it is less likely that the DPR/DPA exchange would=20 really result in a disconnection. Continuing to exchange subsequent=20 DPR/DPA may eventually result in graceful disconnection but I'm not sure if this is any better than just closing the connection as described in=20 the fsm. regards, victor > (Because the CM state machine description says on > receiving a DPR, the action is send DPA & Disc) Also when the sender=20 > receives the DPA with result code !=3D DIAMETER_SUCCESS, can we assume = > it will also NOT close the connection? (Again, the state machine=20 > description says in closing state, on Rcv-DPA, the action is Disc) > > Regards > > Rajith > > ********************************************************************** > * > This e-mail and attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient's) is prohibited. If you receive this e-mail in error, please > notify the sender by phone or email immediately and delete it! > > -----Original Message----- > From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > Sent: Thursday, June 01, 2006 10:47 AM > To: dime@ietf.org > Subject: [Dime] Disconnect-Peer-Request and connection reattempts > > Hi All, > > We would like to clarify the reconnect behaviour of Diameter peers=20 > which receive DPR. The relevant section in the RFC is 5.4. > > Section 5.4 para-1 hints no connection reattempts in the following=20 > cases > :=20 > 1. "shortage of internal resources" which we assume to correspond to > "BUSY" value of Disconnect-Cause AVP (as in sec 5.4.3). Or =20 > > 2. "node in question has no intentions of forwarding any Diameter=20 > messages to the peer in the foreseeable future" which we assume to=20 > correspond to "DO_NOT_WANT_TO_TALK_TO_YOU" value of Disconnect-Cause=20 > AVP. > > But hints connection reattempts in case: > 3. "or that the peer has rebooted. In these cases, the peer may=20 > periodically attempt to reconnect, as stated in Section 2.1" which=20 > corresponds to "REBOOTING" value for Disconnect-Cause AVP. > > Is there a need for clarifying the mapping between the value of=20 > Disconnect-Cause AVP and expected behavior? > > Regards, > Vishnu. > > Motorola India Electronics Pvt Ltd > +91 9844178052 > [*] Motorola Internal Use Only > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 02 00:11:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm10C-0004RR-E7; Fri, 02 Jun 2006 00:11:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm0xZ-0000Es-Oa; Fri, 02 Jun 2006 00:08:29 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm0xY-0007nT-9D; Fri, 02 Jun 2006 00:08:29 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5248Lgw014308; Fri, 2 Jun 2006 07:08:27 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 07:08:26 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 07:08:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Jun 2006 07:08:25 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada Thread-Index: AcaF+WZhH9EgFo7gTBuFVa/fJ/m3RAAAKfCw From: Bcc: X-OriginalArrivalTime: 02 Jun 2006 04:08:26.0633 (UTC) FILETIME=[32BEEF90:01C685FA] X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-Mailman-Approved-At: Fri, 02 Jun 2006 00:11:10 -0400 Subject: [Dime] FW: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Here are the Internet cut-off dates for the next IETF. If you have any drafts that you think should be WG drafts (not individual submissions), please notify me, as these need special approval. thanks, John=20 >-----Original Message----- >From: ext ietf-announce-bounces@ietf.org=20 >[mailto:ietf-announce-bounces@ietf.org]=20 >Sent: 02 June, 2006 07:00 >To: ietf-announce@ietf.org >Subject: Internet-Drafts Submission Cutoff Dates for the 66th=20 >IETF Meeting in Montreal, Quebec, Canada=20 > > >There are two (2) Internet-Draft cutoff dates for the 66th=20 >IETF Meeting in Montreal, Quebec, Canada: > >June 19th: Cutoff Date for Initial (i.e., version -00)=20 >Internet-Draft Submissions=20 > >All initial Internet-Drafts (version -00) must be submitted by=20 >Monday, June 19th at 9:00 AM ET. As always, all initial=20 >submissions with a filename beginning with "draft-ietf" must=20 >be approved by the appropriate WG Chair before they can be=20 >processed or announced. The Secretariat would appreciate=20 >receiving WG Chair approval by Monday, June 12th at 9:00 AM ET. > >June 26th: Cutoff Date for Revised (i.e., version -01 and=20 >higher) Internet-Draft Submissions=20 > >All revised Internet-Drafts (version -01 and higher) must be=20 >submitted by Monday, June 26th at 9:00 AM ET. > >Initial and revised Internet-Drafts received after their=20 >respective cutoff dates will not be made available in the=20 >Internet-Drafts directory or announced until on or after=20 >Monday, July 10th at 9:00 AM ET, when Internet-Draft posting=20 >resumes. Please do not wait until the last minute to submit. > >Thank you for your understanding and cooperation. If you have=20 >any questions or concerns, then please send a message to=20 >internet-drafts@ietf.org. > >The IETF Secretariat > >FYI: The Internet-Draft cutoff dates as well as other=20 >significant dates for the 66th IETF Meeting can be found at=20 >http://www.ietf.org/meetings/cutoff_dates_66.html. > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 02 00:11:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm10C-0004RM-A0; Fri, 02 Jun 2006 00:11:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FltbX-000194-CP for dime@ietf.org; Thu, 01 Jun 2006 16:17:15 -0400 Received: from hu-out-0102.google.com ([72.14.214.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FltbW-0004Ej-1O for dime@ietf.org; Thu, 01 Jun 2006 16:17:15 -0400 Received: by hu-out-0102.google.com with SMTP id 28so264603hug for ; Thu, 01 Jun 2006 13:17:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=r5nBlXRYXk7s92xJDXBZuxaZBy7ptxEH69bCh/3MeeDgjYgQfysK/UUerckcGoHskOhlvu7LA22syxRIaEx78nswaCuI7WAjw/oG108v9iqo0wKVX15eD74K+Sm5eaaarpAGHLG0FlRgCWn66l3hzheNsvtWd+CEiAnOVw7Ao8w= Received: by 10.70.47.1 with SMTP id u1mr1282984wxu; Thu, 01 Jun 2006 13:17:12 -0700 (PDT) Received: by 10.70.100.5 with HTTP; Thu, 1 Jun 2006 13:17:12 -0700 (PDT) Message-ID: <13c12d6b0606011317i5c4c1c5ex9fe34bea78db428a@mail.gmail.com> Date: Thu, 1 Jun 2006 22:17:12 +0200 From: "Bartosz Baranowski" To: dime@ietf.org MIME-Version: 1.0 X-Spam-Score: 2.0 (++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Fri, 02 Jun 2006 00:11:11 -0400 Subject: [Dime] Diameter basics and Apps questions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2117642466==" Errors-To: dime-bounces@ietf.org --===============2117642466== Content-Type: multipart/alternative; boundary="----=_Part_8785_25122991.1149193032458" ------=_Part_8785_25122991.1149193032458 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi. I have few questions about diameter base protocol ( and overall diameter ) , avp values and some app questions ( Sh interface ). I got through TS's and rfc but thats plain technical knowledge, no examples, no place to start with. If someone could enlighten me i would be grateful. So here it goes. Is session always estabilished? According to TS's and rfc Session-Id is required AVP, but for instance Sh messages look a lot like request-reposnse oriented ( Session-Id is required AVP ) Sh doesnt have any means to estabilish session. Each time server receives request it checks if requesting enity has access to requested service/information. Or maybe session is estabilished only by sending request with session-id ?? what is corellation between header value of application Id and Auth-Application-Id and Acc-Application-Id ?? And Vendor-Specific-App-Id? If header value of application_id is Sh# does this imply that Auth-App-Id or Acc-App-id in Vendor-Spec-app-id will have Sh# value? ( Does it work the same for not grouped Auth-App-Id and Acc-App-id ) Regards -- Bartosz Baranowski ------=_Part_8785_25122991.1149193032458 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi. I have few questions about diameter base protocol ( and overall diameter ) , avp values and some app questions ( Sh interface ).
I got through TS's and rfc but thats plain technical knowledge, no examples, no place to start with.
If someone could enlighten me i would be grateful.

So here it goes.

Is session always estabilished? According to TS's and rfc Session-Id is required AVP, but for instance Sh messages look a lot like request-reposnse oriented ( Session-Id is required AVP ) Sh doesnt have any means to estabilish session. Each time server receives request it checks if requesting enity has access to requested service/information.
Or maybe session is estabilished only by sending request with session-id ??

what is corellation between header value of application Id and Auth-Application-Id and Acc-Application-Id ?? And Vendor-Specific-App-Id?
If header value of application_id is Sh# does this imply that Auth-App-Id or Acc-App-id in Vendor-Spec-app-id will have Sh#  value? ( Does it work the same for not grouped Auth-App-Id and Acc-App-id )

Regards
--
Bartosz Baranowski ------=_Part_8785_25122991.1149193032458-- --===============2117642466== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============2117642466==-- From dime-bounces@ietf.org Fri Jun 02 01:15:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm1zw-0000t2-UQ; Fri, 02 Jun 2006 01:15:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm1zu-0000XX-5F for dime@ietf.org; Fri, 02 Jun 2006 01:14:58 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm1zr-0005LZ-Pq for dime@ietf.org; Fri, 02 Jun 2006 01:14:58 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0700E53WHK9P@szxga02-in.huawei.com> for dime@ietf.org; Fri, 02 Jun 2006 13:27:20 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0700ES2WHJMH@szxga02-in.huawei.com> for dime@ietf.org; Fri, 02 Jun 2006 13:27:20 +0800 (CST) Received: from SHRIKANT1508 ([10.18.5.126]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0700C2OW8YE9@szxml04-in.huawei.com> for dime@ietf.org; Fri, 02 Jun 2006 13:22:12 +0800 (CST) Date: Fri, 02 Jun 2006 10:41:51 +0530 From: Shrikantm Subject: RE: [Dime] Disconnect-Peer-Request and connection reattempts In-reply-to: To: 'Ram O V Vishnu-A14676' , dime@ietf.org Message-id: <002a01c68603$0f4df930$7e05120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c8d1e86bb8f49de8156b6392faa4a63b Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shrikantm@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1684498463==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1684498463== Content-type: multipart/alternative; boundary="Boundary_(ID_c0FwxFMEg2lQQjEL1U+RkQ)" This is a multi-part message in MIME format. --Boundary_(ID_c0FwxFMEg2lQQjEL1U+RkQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Vishnu, My comments inline. -----Original Message----- From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] That's what I thought too, till I read the para-1 of section 5.4 a little more carefully. Ideally, we would like to get comments from the authors. This is potentially a problem in deployments because of the following scenario: - A node (especially servers) does not initiate connections but expects peers (read clients) to know about it & connect to it. Such behaviour may be justified by the fact that dynamic peer discovery is not supported and that static configuration of large number of peers is considered unwieldy. - As per what you are saying such a node cannot send DPR, because if it does, the peers (read clients) will not attempt reconnection. This will result in a scenario where there is no connection at all & neither party is attempting too. [Shrikant]: I think still you haven't read the section 5.4 clearly.It clearly says, " If a peer receives a DPR, then it shouldn't reconnect. However if peer has a valid reason (e.g., message to be forwarded) it can reconnect." - this deadlock can only be broken by restart of the peer (of no fault of its own!). [Shrikant]:: No need to restart the peer.If peer wants to communite for valid reson,then it can re-connect to a node neglecting DPR/DPA. I think we may be having the list of the scenarios which tells, when the peer can re-connect to a node after receiving DPR. Thanks, Shrikant - Out intent to clarify the mapping between Disconnect-Cause AVP and the reconnect behaviour was to solve these kind of problems. Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only -----Original Message----- From: Shrikantm [ mailto:shrikantm@huawei.com] Sent: Thursday, June 01, 2006 11:26 AM To: Ram O V Vishnu-A14676; dime@ietf.org Subject: RE: [Dime] Disconnect-Peer-Request and connection reattempts Hi Ram, DPR are for graceful disconnect from a node. So section 5.4 explains about such graceful disconnections. On the other hand for non-graceful disconnection, other peer cannot know the reason for the disconnect (because it may not receive any DPR). So in such a situations, the peer may periodically attempt to reconnect, as stated in Section 2.1. Thanks, Shrikant This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Ram O V Vishnu-A14676 [ mailto:vishnu@motorola.com] Sent: 2006, June 01, Thursday 10:47 AM To: dime@ietf.org Subject: [Dime] Disconnect-Peer-Request and connection reattempts Hi All, We would like to clarify the reconnect behaviour of Diameter peers which receive DPR. The relevant section in the RFC is 5.4. Section 5.4 para-1 hints no connection reattempts in the following cases : 1. "shortage of internal resources" which we assume to correspond to "BUSY" value of Disconnect-Cause AVP (as in sec 5.4.3). Or 2. "node in question has no intentions of forwarding any Diameter messages to the peer in the foreseeable future" which we assume to correspond to "DO_NOT_WANT_TO_TALK_TO_YOU" value of Disconnect-Cause AVP. But hints connection reattempts in case: 3. "or that the peer has rebooted. In these cases, the peer may periodically attempt to reconnect, as stated in Section 2.1" which corresponds to "REBOOTING" value for Disconnect-Cause AVP. Is there a need for clarifying the mapping between the value of Disconnect-Cause AVP and expected behavior? Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_c0FwxFMEg2lQQjEL1U+RkQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT RE: [Dime] Disconnect-Peer-Request and connection reattempts

Hi Vishnu,

 

My comments inline…

 

-----Original Message-----
From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com]

That’s what I thought too, till I read the para-1 of section 5.4 a little more carefully. Ideally, we would like to get comments from the authors.

This is potentially a problem in deployments because of the following scenario:
- A node (especially servers) does not initiate connections but expects peers (read clients) to know about it & connect to it. Such behaviour may be justified by the fact that dynamic peer discovery is not supported and that static configuration of large number of peers is considered unwieldy.

- As per what you are saying such a node cannot send DPR, because if it does, the peers (read clients) will not attempt reconnection. This will result in a scenario where there is no connection at all & neither party is attempting too.

[Shrikant]: I think still you haven’t read the section 5.4 clearly…It clearly says, “ If a peer receives a DPR, then it shouldn't reconnect.
However if peer has a valid reason (e.g., message to be forwarded) it can reconnect.”

-          this deadlock can only be broken by restart of the peer (of no fault of its own!).
[Shrikant]:: No need to restart the peer.If peer wants to communite for valid reson,then it can re-connect to a node neglecting DPR/DPA.

I think we may be having the list of the scenarios which tells, when the peer can re-connect to a node after receiving DPR.

Thanks,
Shrikant

 

 

-           Out intent to clarify the mapping between Disconnect-Cause AVP and the reconnect behaviour was to solve these kind of problems.

Regards,
Vishnu.

Motorola India Electronics Pvt Ltd
+91 9844178052
[*] Motorola Internal Use Only

 

 -----Original Message-----
From:   Shrikantm [mailto:shrikantm@huawei.com]
Sent:   Thursday, June 01, 2006 11:26 AM
To:     Ram O V Vishnu-A14676; dime@ietf.org
Subject:        RE: [Dime] Disconnect-Peer-Request and connection reattempts

Hi Ram,

DPR are for graceful disconnect from a node.
So section 5.4 explains about such graceful disconnections.

On the other hand for non-graceful disconnection, other peer cannot know the reason for the disconnect (because it may not receive any DPR).

So in such a situations, the peer may periodically attempt to reconnect, as stated in Section 2.1. 

Thanks,
Shrikant

 

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

-----Original Message-----
From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com]
Sent: 2006, June 01, Thursday 10:47 AM
To: dime@ietf.org
Subject: [Dime] Disconnect-Peer-Request and connection reattempts

Hi All,

We would like to clarify the reconnect behaviour of Diameter peers which
receive DPR. The relevant section in the RFC is 5.4.

Section 5.4 para-1 hints no connection reattempts in the following cases
:
1. "shortage of internal resources" which  we assume to correspond to
"BUSY" value of Disconnect-Cause AVP  (as in sec 5.4.3). Or 

2. "node in question has no intentions of forwarding any Diameter
messages to the peer in the foreseeable future" which we assume to
correspond to "DO_NOT_WANT_TO_TALK_TO_YOU" value of Disconnect-Cause
AVP.

But hints connection reattempts in case:
3. "or that the peer has rebooted.  In these cases, the peer may
periodically attempt to reconnect, as stated in Section 2.1" which
corresponds to "REBOOTING" value for Disconnect-Cause AVP.

Is there a need for clarifying the mapping between the value of
Disconnect-Cause AVP and expected behavior?

Regards,
Vishnu.

Motorola India Electronics Pvt Ltd
+91 9844178052
[*] Motorola Internal Use Only

 

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime

--Boundary_(ID_c0FwxFMEg2lQQjEL1U+RkQ)-- --===============1684498463== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1684498463==-- From dime-bounces@ietf.org Fri Jun 02 02:05:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm2nE-00039H-T3; Fri, 02 Jun 2006 02:05:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm2nD-000330-7I for dime@ietf.org; Fri, 02 Jun 2006 02:05:55 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm2n9-0002FM-DU for dime@ietf.org; Fri, 02 Jun 2006 02:05:55 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5265nXl020118; Fri, 2 Jun 2006 09:05:50 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 09:05:18 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 09:05:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Diameter basics and Apps questions Date: Fri, 2 Jun 2006 09:05:16 +0300 Message-ID: In-Reply-To: <13c12d6b0606011317i5c4c1c5ex9fe34bea78db428a@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter basics and Apps questions Thread-Index: AcaF+vhBOYOZXG8FTE+SycMmKKce0wAD10TA From: To: , X-OriginalArrivalTime: 02 Jun 2006 06:05:17.0731 (UTC) FILETIME=[85AF9730:01C6860A] X-Spam-Score: 0.3 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1540203178==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1540203178== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6860A.85319E0D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6860A.85319E0D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bartosz, =20 The question seems to be more about the Sh interface, which is actually standardized in 3GPP, so I think that 3GPP would be the place to ask your questions. I don't have the right mailing list for it, but maybe someone else on this mailing list does. =20 John ________________________________ From: ext Bartosz Baranowski [mailto:baranowb@gmail.com]=20 Sent: 01 June, 2006 23:17 To: dime@ietf.org Subject: [Dime] Diameter basics and Apps questions =09 =09 Hi. I have few questions about diameter base protocol ( and overall diameter ) , avp values and some app questions ( Sh interface ). I got through TS's and rfc but thats plain technical knowledge, no examples, no place to start with.=20 If someone could enlighten me i would be grateful. =09 So here it goes. =09 Is session always estabilished? According to TS's and rfc Session-Id is required AVP, but for instance Sh messages look a lot like request-reposnse oriented ( Session-Id is required AVP ) Sh doesnt have any means to estabilish session. Each time server receives request it checks if requesting enity has access to requested service/information.=20 Or maybe session is estabilished only by sending request with session-id ?? =09 what is corellation between header value of application Id and Auth-Application-Id and Acc-Application-Id ?? And Vendor-Specific-App-Id?=20 If header value of application_id is Sh# does this imply that Auth-App-Id or Acc-App-id in Vendor-Spec-app-id will have Sh# value? ( Does it work the same for not grouped Auth-App-Id and Acc-App-id )=20 =09 Regards --=20 Bartosz Baranowski=20 ------_=_NextPart_001_01C6860A.85319E0D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bartosz,
 
The question seems to be more about the Sh = interface, which=20 is actually standardized in 3GPP, so I think that 3GPP would be the = place to ask=20 your questions.  I don't have the right mailing list for it, but = maybe=20 someone else on this mailing list does.
 
John

From: ext Bartosz Baranowski=20 [mailto:baranowb@gmail.com]
Sent: 01 June, 2006 = 23:17
To:=20 dime@ietf.org
Subject: [Dime] Diameter basics and Apps=20 questions

Hi. I have few questions about diameter base protocol ( and = overall=20 diameter ) , avp values and some app questions ( Sh interface ).
I = got=20 through TS's and rfc but thats plain technical knowledge, no examples, = no=20 place to start with.
If someone could enlighten me i would be = grateful.
So here it goes.

Is session always = estabilished?=20 According to TS's and rfc Session-Id is required AVP, but for instance = Sh=20 messages look a lot like request-reposnse oriented ( Session-Id is = required=20 AVP ) Sh doesnt have any means to estabilish session. Each time server = receives request it checks if requesting enity has access to requested = service/information.
Or maybe session is estabilished only by = sending=20 request with session-id ??

what is corellation between header = value of=20 application Id and Auth-Application-Id and Acc-Application-Id ?? And=20 Vendor-Specific-App-Id?
If header value of application_id is Sh# = does this=20 imply that Auth-App-Id or Acc-App-id in Vendor-Spec-app-id will have = Sh# =20 value? ( Does it work the same for not grouped Auth-App-Id and = Acc-App-id )=20

Regards
--
Bartosz Baranowski = ------_=_NextPart_001_01C6860A.85319E0D-- --===============1540203178== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1540203178==-- From dime-bounces@ietf.org Fri Jun 02 02:32:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm3Ch-0004x7-Uv; Fri, 02 Jun 2006 02:32:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm3Cg-0004wK-Or for dime@ietf.org; Fri, 02 Jun 2006 02:32:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm3Cg-0004mr-F4 for dime@ietf.org; Fri, 02 Jun 2006 02:32:14 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fm39w-0006h8-NW for dime@ietf.org; Fri, 02 Jun 2006 02:29:39 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0700JSRZB2ZZ@szxga01-in.huawei.com> for dime@ietf.org; Fri, 02 Jun 2006 14:28:15 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0700FUOZB257@szxga01-in.huawei.com> for dime@ietf.org; Fri, 02 Jun 2006 14:28:14 +0800 (CST) Received: from huawei1515 ([10.18.5.169]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0700CQIZQ8E9@szxml04-in.huawei.com> for dime@ietf.org; Fri, 02 Jun 2006 14:37:21 +0800 (CST) Date: Fri, 02 Jun 2006 11:57:01 +0530 From: Rajith R Subject: RE: [Dime] Disconnect-Peer-Request handling In-reply-to: <447EF016.4060206@tari.toshiba.com> To: 'Victor Fajardo' Message-id: <001a01c6860d$8f2a2ac0$a905120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: -2.6 (--) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi In my opinion, the intention on DPR/DPA is only to avoid failbacks for graceful shutdown cases. However the pending requests may still be subjected to failover. I think DP is more suited to be a notification than a request-response exchange. Regards Rajith ************************************************************************ **** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] Sent: Thursday, June 01, 2006 7:18 PM To: rajithr@huawei.com Cc: dime@ietf.org Subject: Re: [Dime] Disconnect-Peer-Request handling Hi Rajith, > Hi > > I have some more doubts on section 5.4-para 2 which describes > DPR handling. It says the recipient SHOULD return a DPA with an error > result code if messages are pending on the connection. > Does this mean that in this case the recipient will not close > the connection? This seems to be what is implied in 5.4 since it states that the DPR is "intent" to disconnect and attempts to provide some leniency to in-flight messages. One possible problem with this scheme is that on high traffic scenario it is less likely that the DPR/DPA exchange would really result in a disconnection. Continuing to exchange subsequent DPR/DPA may eventually result in graceful disconnection but I'm not sure if this is any better than just closing the connection as described in the fsm. regards, victor > (Because the CM state machine description says on > receiving a DPR, the action is send DPA & Disc) Also when the sender > receives the DPA with result code != DIAMETER_SUCCESS, can we assume it > will also NOT close the connection? (Again, the state machine > description says in closing state, on Rcv-DPA, the action is Disc) > > Regards > > Rajith > > *********************************************************************** > This e-mail and attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient's) is prohibited. If you receive this e-mail in error, please > notify the sender by phone or email immediately and delete it! > > -----Original Message----- > From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > Sent: Thursday, June 01, 2006 10:47 AM > To: dime@ietf.org > Subject: [Dime] Disconnect-Peer-Request and connection reattempts > > Hi All, > > We would like to clarify the reconnect behaviour of Diameter peers which > receive DPR. The relevant section in the RFC is 5.4. > > Section 5.4 para-1 hints no connection reattempts in the following cases > : > 1. "shortage of internal resources" which we assume to correspond to > "BUSY" value of Disconnect-Cause AVP (as in sec 5.4.3). Or > > 2. "node in question has no intentions of forwarding any Diameter > messages to the peer in the foreseeable future" which we assume to > correspond to "DO_NOT_WANT_TO_TALK_TO_YOU" value of Disconnect-Cause > AVP. > > But hints connection reattempts in case: > 3. "or that the peer has rebooted. In these cases, the peer may > periodically attempt to reconnect, as stated in Section 2.1" which > corresponds to "REBOOTING" value for Disconnect-Cause AVP. > > Is there a need for clarifying the mapping between the value of > Disconnect-Cause AVP and expected behavior? > > Regards, > Vishnu. > > Motorola India Electronics Pvt Ltd > +91 9844178052 > [*] Motorola Internal Use Only > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 02 12:51:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCsN-0001Ee-KW; Fri, 02 Jun 2006 12:51:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCsM-0001BW-Au for dime@ietf.org; Fri, 02 Jun 2006 12:51:54 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmCsL-0003ay-0F for dime@ietf.org; Fri, 02 Jun 2006 12:51:54 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 02 Jun 2006 09:51:52 -0700 X-IronPort-AV: i="4.05,204,1146466800"; d="scan'208"; a="1818156266:sNHT112706930" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k52GpqJB004926; Fri, 2 Jun 2006 09:51:52 -0700 Received: from [161.44.55.58] (dhcp-161-44-55-58.cisco.com [161.44.55.58]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k52Gppku015402; Fri, 2 Jun 2006 12:51:51 -0400 (EDT) Message-ID: <44806CA5.1020901@cisco.com> Date: Fri, 02 Jun 2006 12:51:49 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bartosz Baranowski Subject: Re: [Dime] Diameter basics and Apps questions References: <13c12d6b0606011317i5c4c1c5ex9fe34bea78db428a@mail.gmail.com> In-Reply-To: <13c12d6b0606011317i5c4c1c5ex9fe34bea78db428a@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1943; t=1149267112; x=1150131112; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andersk@cisco.com; z=From:Anders=20Kristensen=20 |Subject:Re=3A=20[Dime]=20Diameter=20basics=20and=20Apps=20questions; X=v=3Dcisco.com=3B=20h=3DJG5m8w8i7UmcWe7vJ/LLK/g/jL0=3D; b=PwFlFL3c0ywYf/mC/MopkDW1EtSL2lAFT1DqoVeX6cjk6xi9Odf2ib2RWxfyk/BrmU0YJ3XV 7pBqoeFMfNWKHx8oNDsM1wywST1ySGOT5cNeflHBUuXNECT97r2SlRul; Authentication-Results: sj-dkim-2.cisco.com; header.From=andersk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Inline... Bartosz Baranowski wrote: > Hi. I have few questions about diameter base protocol ( and overall > diameter ) , avp values and some app questions ( Sh interface ). > I got through TS's and rfc but thats plain technical knowledge, no > examples, no place to start with. > If someone could enlighten me i would be grateful. > > So here it goes. > > Is session always estabilished? According to TS's and rfc Session-Id is > required AVP, but for instance Sh messages look a lot like > request-reposnse oriented ( Session-Id is required AVP ) Sh doesnt have > any means to estabilish session. Each time server receives request it > checks if requesting enity has access to requested service/information. > Or maybe session is estabilished only by sending request with session-id ?? The Session-Id is required in the messages but, I believe, is generally not used for anything. The client should just populate it with some random but valid value. > > what is corellation between header value of application Id and > Auth-Application-Id and Acc-Application-Id ?? And Vendor-Specific-App-Id? > If header value of application_id is Sh# does this imply that > Auth-App-Id or Acc-App-id in Vendor-Spec-app-id will have Sh# value? ( > Does it work the same for not grouped Auth-App-Id and Acc-App-id ) This is, in my view, a really sore point for Diameter. Specifically for Sh it seems pretty clear that the Sh app ID should go into both the message header and an Auth-Application-Id AVP within a Vendor-Specific-Application-Id but in general there doesn't seem to be a satisfying answer to your question. Anders > > Regards > -- > Bartosz Baranowski > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 02 18:37:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmIGa-0000NS-IV; Fri, 02 Jun 2006 18:37:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmIGZ-0000NN-Iq for dime@ietf.org; Fri, 02 Jun 2006 18:37:15 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmIGY-0006w2-9l for dime@ietf.org; Fri, 02 Jun 2006 18:37:15 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 9285EFF24C for ; Fri, 2 Jun 2006 18:37:13 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k52MbDMq023240 for ; Fri, 2 Jun 2006 18:37:13 -0400 (EDT) From: "Tolga Asveren" To: Date: Fri, 2 Jun 2006 18:14:59 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Dime] Guidelines for Diameter extensions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I want to get opinion/feedback -especially from WG-chairs + RFC3588 authors- about quidelines for extensions to Diameter protocol. In the last couple of months, a few issues have been discussed on the list and some of them may require enhancements on the existing specification -or people may want to propose new procedures about other issues- . I believe it could be useful to have a set of guidelines for such extensions. For example, how acceptable would the following approaches be, when defining new procedures: a) New base protocol messages b) New error-codes c) New AVPs for base protocol messages ... BTW, are we going to have a bis document? Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 05 03:30:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn9XZ-0001G7-U7; Mon, 05 Jun 2006 03:30:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn9XY-0001G1-7h for dime@ietf.org; Mon, 05 Jun 2006 03:30:20 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn9XX-0007Cd-Ot for dime@ietf.org; Mon, 05 Jun 2006 03:30:20 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k557UJRX002760 for ; Mon, 5 Jun 2006 00:30:19 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k557UGO3017876 for ; Mon, 5 Jun 2006 02:30:18 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Disconnect-Peer-Request and connection reattempts Date: Mon, 5 Jun 2006 15:30:13 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Disconnect-Peer-Request and connection reattempts Thread-Index: AcaGA1GjXLSsnaz8Sd2/w+ToVUmKOgCbKkAg From: "Ram O V Vishnu-A14676" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Shrikant, Thanks for your clarifications. But I think still there is a need to clarify the mapping between Disconnect-Cause AVP and the reconnect behaviour. Please see my comments. [Shrikant]: I think still you haven't read the section 5.4 clearly...It clearly says, " If a peer receives a DPR, then it shouldn't reconnect. However if peer has a valid reason (e.g., message to be forwarded) it can reconnect." Vishnu>> What happens in a high-traffic scenario? The peer (the client) will always have something to sent/forward. Hence it will always reconnect. This nullifies the DPR/DPA procedure. Hence there should be some DPR Disconnect causes which helps the peer to understand that now I should not reconnect. Say for example: if the Disconnect-Cause AVP is REBOOTING then reconnect. Else if the Disconnect-Cause AVP is BUSY || DO_NOT_WANT_TO_TALK_TO_YOU then do not reconnect. Please note that this is very similar to the scenario which Rajith/Victor described in another email thread where DPA with failure is sent. [Shirkant]: I think we may be having the list of the scenarios which tells, when the peer can re-connect to a node after receiving DPR. Vishnu>> All what we are saying is that such a list should contain certain conditions based on the DPR Disconnect causes as well. If you leave it to the peer alone to decide when to reconnect, there would be cases in which (say, in a high-traffic scenario) DPR is of no use and a BUSY node is swamped with reconnect attempts. Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only -----Original Message----- From: Shrikantm [mailto:shrikantm@huawei.com]=20 Sent: Friday, June 02, 2006 10:42 AM To: Ram O V Vishnu-A14676; dime@ietf.org Subject: RE: [Dime] Disconnect-Peer-Request and connection reattempts Hi Vishnu, My comments inline... -----Original Message----- From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com]=20 That's what I thought too, till I read the para-1 of section 5.4 a little more carefully. Ideally, we would like to get comments from the authors. This is potentially a problem in deployments because of the following scenario:=20 - A node (especially servers) does not initiate connections but expects peers (read clients) to know about it & connect to it. Such behaviour may be justified by the fact that dynamic peer discovery is not supported and that static configuration of large number of peers is considered unwieldy. - As per what you are saying such a node cannot send DPR, because if it does, the peers (read clients) will not attempt reconnection. This will result in a scenario where there is no connection at all & neither party is attempting too. [Shrikant]: I think still you haven't read the section 5.4 clearly...It clearly says, " If a peer receives a DPR, then it shouldn't reconnect. However if peer has a valid reason (e.g., message to be forwarded) it can reconnect." - this deadlock can only be broken by restart of the peer (of no fault of its own!).=20 [Shrikant]:: No need to restart the peer.If peer wants to communite for valid reson,then it can re-connect to a node neglecting DPR/DPA. I think we may be having the list of the scenarios which tells, when the peer can re-connect to a node after receiving DPR. Thanks, Shrikant - Out intent to clarify the mapping between Disconnect-Cause AVP and the reconnect behaviour was to solve these kind of problems. Regards,=20 Vishnu.=20 Motorola India Electronics Pvt Ltd=20 +91 9844178052=20 [*] Motorola Internal Use Only=20 -----Original Message-----=20 From: Shrikantm [mailto:shrikantm@huawei.com]=20 Sent: Thursday, June 01, 2006 11:26 AM=20 To: Ram O V Vishnu-A14676; dime@ietf.org=20 Subject: RE: [Dime] Disconnect-Peer-Request and connection reattempts=20 Hi Ram,=20 DPR are for graceful disconnect from a node.=20 So section 5.4 explains about such graceful disconnections.=20 On the other hand for non-graceful disconnection, other peer cannot know the reason for the disconnect (because it may not receive any DPR).=20 So in such a situations, the peer may periodically attempt to reconnect, as stated in Section 2.1. =20 Thanks,=20 Shrikant=20 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] Sent: 2006, June 01, Thursday 10:47 AM To: dime@ietf.org Subject: [Dime] Disconnect-Peer-Request and connection reattempts=20 Hi All,=20 We would like to clarify the reconnect behaviour of Diameter peers which receive DPR. The relevant section in the RFC is 5.4.=20 Section 5.4 para-1 hints no connection reattempts in the following cases :=20 1. "shortage of internal resources" which we assume to correspond to=20 "BUSY" value of Disconnect-Cause AVP (as in sec 5.4.3). Or =20 2. "node in question has no intentions of forwarding any Diameter=20 messages to the peer in the foreseeable future" which we assume to=20 correspond to "DO_NOT_WANT_TO_TALK_TO_YOU" value of Disconnect-Cause=20 AVP.=20 But hints connection reattempts in case:=20 3. "or that the peer has rebooted. In these cases, the peer may=20 periodically attempt to reconnect, as stated in Section 2.1" which=20 corresponds to "REBOOTING" value for Disconnect-Cause AVP.=20 Is there a need for clarifying the mapping between the value of=20 Disconnect-Cause AVP and expected behavior?=20 Regards,=20 Vishnu.=20 Motorola India Electronics Pvt Ltd=20 +91 9844178052=20 [*] Motorola Internal Use Only=20 _______________________________________________=20 DiME mailing list=20 DiME@ietf.org=20 https://www1.ietf.org/mailman/listinfo/dime=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 05 03:40:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn9hE-0000J8-HT; Mon, 05 Jun 2006 03:40:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn9hC-0000Iw-T8 for dime@ietf.org; Mon, 05 Jun 2006 03:40:18 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn9hB-0000UN-TU for dime@ietf.org; Mon, 05 Jun 2006 03:40:18 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k557eHw8004755 for ; Mon, 5 Jun 2006 00:40:17 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k557eEYt029380 for ; Mon, 5 Jun 2006 02:40:16 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] CER/CEA on an open connection Date: Mon, 5 Jun 2006 15:40:12 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] CER/CEA on an open connection Thread-Index: AcZcrSGKQBWdAQdeQkiT6HpMT06FDArxYM0A From: "Ram O V Vishnu-A14676" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org All, Below is the proposed text for peer capabilities update in Base Diameter (as discussed in this email list earlier).=20 John, Please advice us on the process for text proposals to *-biz versions. Regards, Vishnu. ------------------------------------------------------------ 5.3.8 Peer Capabilities Update Among the capabilities exchanged during Diameter connection initialization, list of supported applications by the node can change dynamically. Applications can be restarted for various reasons including maintenance and upgrades.=20 A Diameter node MUST initiate peer capabilities update by sending a Capabilities-Exchange-Req (CER) to all its peers which supports peer capabilities update and are in open state. Diameter nodes that implement peer capabilities update SHOULD check the version information advertised by its peer in the Diameter header of the previous CER/CEA exchange to determine if the peer supports peer capabilities update. The Diameter node MUST NOT send peer capabilities update to the peer if it determines that the peer has no support for such scheme, instead it SHOULD gracefully disconnect its current connection and attempt to establish a new connection towards that peer. In either case, the Diameter node is expected to advertise the most recent set of supported applications in a CER message, as specified by the peer state machine (see Section 5.6) while it is in the open state. The receiver of CER in open state MUST process and reply to the CER as a described in Section 5.3. The CEA which the receiver sends MUST contain its latest capabilities. Note that peers which successfully process the peer capabilities update SHOULD also update their routing tables to reflect the change. The receiver of the CEA, with a Result-Code AVP other than DIAMETER_SUCCESS, initiates the transport disconnect. Peer capabilities update in the open state SHOULD be limited to the advertisement of the new list of supported applications and MUST preclude re-negotiation of security mechanism or other parameters. ------------------------------------------------------------ Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 Sent: Monday, April 10, 2006 8:13 PM To: Tolga Asveren Cc: dime@ietf.org Subject: Re: [Dime] CER/CEA on an open connection Hi All, > I believe in general now we all have a good understanding about what=20 > the issues are for renegotiation. It could be an idea to have a new=20 > iteration of the proposed text, and to continue the discussions on the > new version. > =20 To that end, I'll plan on generating a new set of text maybe next week=20 as we let people digest and hopefully comment on the latest round of=20 discussion for the next couple of days. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime I believe in general now we all have a good understanding about what the issues are for renegotiation. It could be an idea to have a new iteration of the proposed text, and to continue the discussions on the new version. A few more comments/questions below. Thanks, Tolga > -----Original Message----- > From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > Sent: Monday, April 10, 2006 2:38 AM > To: dime@ietf.org > Cc: Nakhjiri Madjid-MNAKHJI1 > Subject: RE: [Dime] CER/CEA on an open connection > > > Hi Victor/Timothy, > > 1. Comments on Retry mechanism : > To summarize, we are sending CER in open state because our=20 > capabilities (supported apps) are changing and we would like to update > the peer about it. We will maintain open state. > > we may not receive a CEA due to the following possible reasons: > 1.1) The peer does not support CER in open state. In such a case, peer > might still originate unsupported app messages towards us which will=20 > result in "DIAMETER_APPLICATION_UNSUPPORTED" error from us. We can=20 > leave it to the peer implementation to "correct this error" as=20 > mentioned in sec 7.1.3 of RFC 3588. This will take care of the case=20 > where there is relay/proxy in between. > 1.2) Connection is lost with the peer, in which case the DWR/DWA=20 > mechanism should step in. > > The solution suggested by Timothy (to wait for for CEA & timer) will=20 > need changes to FSM, even though we agree that this is consistent with > the initial CER/CEA scenario. > > Ofcourse the use of "DIAMETER_APPLICATION_UNSUPPORTED" will result in=20 > added (unecessary traffic) incase the peer/proxy is not clever enough=20 > to correct its behaviour. This can be avoided by using the version=20 > number exchange as Victor pointed out. So, we will not attempt the CER > in open state to such a peer which doesnt support CERs in open state,=20 > and can go for a reconnection. [TOLGA]The problem case of a node not being clever enough to take action based on "DIAMETER_APPLICATION_UNSUPPORTED" is not limited to renegotiations. This could happen in existing systems developed according to RFC3588 as well. I would expect a node, whose DIAMETER_APPLICATION_UNSUPPORTED replies are not honored by its neighbor to drop the connection, but as said this is not limited to renegotiation case. For cases, where the neighbor does not support renegotiation, what would be the result code in CEA? DIAMETER_UNABLE_TO_COMPLY? We can say that such a result code in CEA should indicate that the neighbor does not support renegotiations and sender of CER should/may drop/reestablish the connection. Please note that with a properly behaving neighbor, dropping connection is probably not necessary because the first DIAMETER_APPLICATION_UNSUPPORTED should update its tables properly. I don't know whether we need to standardize how a node determines whether a neighbor honors DIAMETER_APPLICATION_UNSUPPORTED result code. > > 2. Comments on "re-negotiation" > We think that what we need is an advertisement mechanism and not a=20 > negotiation mechanism. The CER/CEA in open state allows us to do that. > We are proposing that the receiver of the CER takes the decision on=20 > the disconnection. Thus we are able to delay the disconnection=20 > (assuming that the point mentioned in my email before that the app=20 > changes are temporary). Since CER allows us to convey the latest set=20 > of supported apps to the peer, we favour the CER to the DPR. > > Following is a scenario where sending CER/CEA is better than the DPR=20 > mechanism. (Apologies if the figure is mangled due to tab settings). [TOLGA]Although the example case below is a race condition which probably won't happen very often -it relies on changing supported application set on two nodes more or less simultaneously-, I also prefer relying on CER in such a situation, so that there is a single way of handling renegotiations in terms of advertising changes to the neighbors. > > Initial exchanged app list: > A: 1,2,3 B:2 > 2 went down 3 came up just when 2 went down on A > ________ ________ > |A |----DPR---> |B | > | | | | > | |<---CER---- | | > |______| [3] |______| > <---DPA---- > > this in our understanding will result in reconnection even thou there=20 > is 3 in common. > > Initial exchanged app list: > A: 1,2,3 B:2 > 2 went down 3 came up just when 2 went down on A > ________ ________ > |A |----CER---> |B | > | | [1,3] | | > | |<---CER---- | | > |_______| [2,3] |_______| > ----CEA----> > [1,3] > <---CEA----- > [2,3] > This will avoid a reconnection, because 3 is in common. > > Regards, > Vishnu. > > Motorola India Electronics Pvt Ltd > +91 9844178052 > [*] Motorola Internal Use Only > > > -----Original Message----- > From: Timothy Smith [mailto:tjsmith@us.ibm.com] > Sent: Monday, April 10, 2006 7:11 AM > To: Victor Fajardo > Cc: dime@ietf.org; Nakhjiri Madjid-MNAKHJI1; Ram O V Vishnu-A14676 > Subject: Re: [Dime] CER/CEA on an open connection > > > > Hi Victor, > > Thanks for your response. Comments below" > >> > >> Good summary! I agree with most of your points. I'm not sure,=20 > >> however, that I distinguish between (1) and (2). I think whether=20 > >> temporary or not, we should handle CER/CEA exchanges in the same > manner. > >I'm just speculating but I think (2) refers to application change=20 > >requiring a reboot. > >> > >> I agree with your design goals (3) ,(4), and suggestions (5) , (6)=20 > >> , (8), and (9). > >If some are more in favor of scheme (5) , maybe we need more opinion > on > >whether the receiver of the CEA can always comply with the change=20 > >request regardless of any scenario. I think (6) and (9) can be=20 > >avoided regardless of which scheme we decide to use (see my previous=20 > >reply). > > > > Here is the text from your previous reply: > "This certainly simplifies things but it also implies that the sender=20 > of > > the CER mandates a change and the receiver has no choice but to accept > it. In some sense, the scheme is no longer a re-negotiation but merely > notifying the peer of a change. The proposed text was considering the=20 > case where the receiver of the CER cannot comply with the change for=20 > whatever reason." > > I tend to agree with the notion that the sender of the CER is=20 > mandating a change. The receiver does have a choice just as it has a=20 > choice in the original CER/CEA exchange. The receiver should respond=20 > with the list of > > App Ids that is the intersection of what was listed in the CER and of=20 > what App Ids it wishes to support. It is a renegotiation which may=20 > add or remove App Ids. But either way, it is telling the other side=20 > about its intentions. I don't thing the receiving side has any choice > but to participate > in the renegotiation. For example, if an app Id is being removed, the > side > where it is being removed renegotiates with a CER that does not include > that > App ID. It doesn't do the receiving side any good to decline this as > the App > will be shut down regardless. > > > >> Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont=20 > >> think there is a problem here. Cant find any race condition." I=20 > >> thought that there was a subtle problem here, but I think you are=20 > >> right. Given that the connection insures sequencing, the latest=20 > >> CER or CEA that you receive is what you should use as the list of=20 > >> negotiated App Ids. > >> > >Mmmm... i'm not sure that the connection itself ensures sequencing.=20 > >Anyway, majority rule favors removing this text. > >> Should there be some discussion on the retry mechanism? You send a > >> CER, and no response is received. Does this mean that the peer=20 > >> just doesn't know how to renegotiate? Should we ignore and retry=20 > >> every n seconds? Bring down the connection? Or do we just=20 > >> continue to use the apps from the initial negotiation? My=20 > >> preference on this is that we should require a CEA response to the=20 > >> CER. If the CEA is not received, we shutdown the connection and=20 > >> start over. This would address compatibility issues with existing=20 > >> implementations. It would > > >> also be consistent with the processing of the initial CER/CEA. > >> > >The current proposal has text mentioning the use of version number of > >initial CER/CEA exchange to determine whether a peer is capable of=20 > >renegotiating. If a node knows that its peer is not capable of=20 > >re-negotiating then the node should not initiate re-negotiation. In > this > >scheme, existing implementations will be spared of any change. > > I'm not sure I picked up the version number. I don't see a reason to=20 > do > > something special. I would simply like to renegotiate. If the other=20 > side does not respond to the CER, you shut down the connection and=20 > restart it > > after some period of time. This is what you would do if your initial=20 > CER did not get a response. How is this different? > > > Best Regards, > Timothy Smith > > Vishnu wrote: > > Hi, > > > > Some clarifications and comments on the discussion on this thread: > > > > We would like to clarify the following practical scenarios of this > > happenning: > > 1. there are a list of published applications which the box support=20 > > and these are installed in the box. Now, some of them go down/up.=20 > > This would get translated into change in peer capabilities. > > 2. there is a new application which is getting installed/removed from > > the box. > > > > We think that (1) is the most probable scenario. so, > > there is value in giving a simple solution assuming that this change > (in > > capabilities) > > is most probably temporary. If this is not the case, we are talking=20 > > about (2), which is a major change in the box anyways. So in (2), we > > assume it is ok to assume that > > the connections to be reestablished. > > > > We would like to say that our design goals are: > > 3. solution should be simple & as backward compatible as possible.=20 > > 4. minimize the FSM changes. > > > > We suggest: > > 5. Updating peer capabilities done only using a CER/CEA in the open=20 > > state. Sender of CER/CEA updates the local capabilities before=20 > > sending the message and > > hence is a local decision. > > > > 6. The rest of the processing of the CER/CEA will be as per the > current > > RFC. > > Say for example, if there are no > > common applications left with that peer, > DIAMETER_NO_COMMON_APPLICATION > > is sent in the > > CEA and the connection is closed. > > > > Problems in the email thread under discussion & some comments: 7.=20 > > Cross over and sequencing of CER/CEA exchange. We dont think there > is > > a problem > > here. Cant find any race condition. > > > > 8. Mutual agreement to bring down applications will not work due to=20 > > possible relays in between as Tolga has pointed out in the mailing=20 > > list. > > > > 9. The DPR solution in the suggested text is not a good idea.=20 > > Because DPR cannot advertise the latest local applications to the=20 > > peer. This may cause > the > > race condition > > and sequencing problem. This problem can be avoided by using the=20 > > approach which we suggested in (5). > > > > Regards, > > Vishnu. > > tjsmith@us.ibm.com > (919) 254-4723 > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 05 05:31:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnBRB-0006aG-0Q; Mon, 05 Jun 2006 05:31:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnBR9-0006Wq-Jr for dime@ietf.org; Mon, 05 Jun 2006 05:31:51 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnBR8-0004Pa-WD for dime@ietf.org; Mon, 05 Jun 2006 05:31:51 -0400 Received: (qmail invoked by alias); 05 Jun 2006 09:31:48 -0000 Received: from p54985954.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.89.84] by mail.gmx.net (mp036) with SMTP; 05 Jun 2006 11:31:48 +0200 X-Authenticated: #29516787 Message-ID: <4483FA0F.70906@gmx.net> Date: Mon, 05 Jun 2006 11:31:59 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Subject: Re: [Dime] Policy based Applications and QoS Application References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: isalekul@hotmail.com, dime@ietf.org, "Tschofenig, Hannes" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Avi, Avi Lior wrote: > Hi Hannes, > > The discussion on MIPv6 bootstrapping is different. We know that it is > an Application we were just debating whether or not we need to create a > new Application ID. > > QoS may be an application and it may also be an attribute that is used > by various applications. This is true but with QoS might might to accomplish good alignment with existing Diameter applications. From the scenario we looked at in the past we noticed that it is important to have QoS support for NASREQ, EAP, Accounting and DCC applications. > > While it may be difficult for the IETF to come up with a QoS application > that would work across many SDOs, it may be good enough for DIME to > define a standerdized QoS blob and have SDOs pick it up as they work on > SDO specific applications. This aspect also relates to the question raised by Dan (and I also believe that there is a relationship to the MIPv6 bootstrapping work). We have * a bunch of different applications (NASREQ, EAP, etc.) * different QoS scenarios (I pointed to the already in a previous mail) * QoS attribute (there we considered a generic QoS description) * a flow identifier (or set of flow identifiers) The application vs. attribute question might not be that important at the end. Even if we decide to compile attributes then there needs to be a mechanism to indicate QoS support either using an application-id or a service-type. > For vendors like us, providing products across SDOs, having a > standerdized QoS blob is adventageous. QoS Blob is relatively complex, > and requires a complex GUI for provisioning it and also complex API. That's a good point. As a manufacturer of AAA equipment you will only see QoS stuff and a few attributes being added to the messages. Ciao Hannes > > Avi > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Monday, May 29, 2006 4:52 PM >>To: Avi Lior >>Cc: dime@ietf.org; isalekul@hotmail.com; Tschofenig, Hannes >>Subject: Re: [Dime] Policy based Applications and QoS Application >> >>Hi Avi, >> >>thanks for raising this topic. Please find my response below; >> >>Avi Lior wrote: >> >>>Hi All, >>> >>>This email prompts me to start a discussion on Policy and >> >>QoS Application. >> >>> >>>As some of you are aware IMS Rel 7.0 has an entity called >> >>PCRF. This >> >>>PCRF is supposed to broker per flow based policy actions >> >>between the >> >>>IMS infrastructure and the Network. Initially this policy >> >>was QoS and >> >>>in release 7.0 it also brokers Charging Policy. In the >> >>future it will >> >>>probably broker other per flow policy. For example, it may >> >>instruct >> >>>the network to apply security policies to a flow or group of flows. >>> >>>The QoS Application that is being developed by the IETF (IMO) was >>>targeting the Policy entity in its IMS Rel 6.0 form when it >> >>was called >> >>>the PDF instead of PCRF and when it was only serving QoS policies. >>>Now in rel 7.0 the Diameter application being developed is serving >>>both QoS and Charging information and is based on the >> >>Diameter Credit >> >>>Control function. >>> >>>Also QoS policies are also delivered as part of Authentication. So >>>EAP Application may be used to deliver initial QoS policies to the >>>User session being authenticated and authorized. >> >>I agree with you. >> >> >>> >>>So I am raising the following questions: >>> >>>1) Is there any reason to create a QoS Application in Diameter? >> >>I guess your question is 'Does it need to be an application' >>and thereby referring to question 3. In some sense we also >>discussed this question in context of MIPv6 Bootstrapping as well. >> >>Are you concerned about the additional messaging or more >>about the degree of flexbility. >> >> >>> >>>2) Should we work on a Diameter Flow-based Policy >> >>Application that is >> >>>able to deliver QoS/Charging and in the future other flow >> >>based application? >> >>>-Should this work be done in the IETF? Do we get folks in >> >>3GPP/3GPP2 >> >>>and WiMAX to agree to work on this within the IETF. Or >> >>perhaps we can >> >>>agree to work on this together outside the IETF? >> >> > >> >>>3) Perhaps we should just define QoS based attributes that can be >>>pulled into various future Diameter Applications. >> >>The last two approaches sound like interesting approaches we >>should investigate. >> >> >>Ciao >>Hannes >> >> >>> >>> >>>Comments are welcome!!! >>> >>> >>> >>> >> >>-------------------------------------------------------------- >>---------- >> >>> *From:* Tschofenig, Hannes >> >>[mailto:hannes.tschofenig@siemens.com] >> >>> *Sent:* Monday, May 08, 2006 4:23 AM >>> *To:* john.loughney@nokia.com; dime@ietf.org >>> *Cc:* isalekul@hotmail.com >>> *Subject:* AW: [Dime] FW: [AAA-WG]: Policy >> >>representation for AAA server >> >>> Hi Salekul, >>> >>> could you formulate your question in more detail? >>> What type of policies are you talking about? E.g., policies that >>> represent the business logic at a AAA server or >> >>policies that are >> >>> conveyed from the AAA server to the AAA client? Are you >> >>looking for >> >>> a language to express these policies or rather for the >> >>content of >> >>> these policies? Do you have a specific application in >> >>mind (e.g., >> >>> policies regarding charging, QoS, location information) >>> >>> Ciao >>> Hannes >>> >>> >>> >> >>-------------------------------------------------------------- >>---------- >> >>> *Von:* john.loughney@nokia.com >> >>[mailto:john.loughney@nokia.com] >> >>> *Gesendet:* Montag, 8. Mai 2006 10:10 >>> *An:* dime@ietf.org >>> *Cc:* isalekul@hotmail.com >>> *Betreff:* [Dime] FW: [AAA-WG]: Policy >> >>representation for AAA server >> >>> Forward to the DiME WG, in case any one has >> >>opinions for Diameter. >> >>> >>> John >>> >>> >> >>-------------------------------------------------------------- >>---------- >> >>> *From:* owner-aaa-wg@merit.edu >>> [mailto:owner-aaa-wg@merit.edu] *On Behalf Of >> >>*ext Salekul Islam >> >>> *Sent:* 30 April, 2006 08:55 >>> *To:* aaa-wg@merit.edu >>> *Cc:* Salekul Islam >>> *Subject:* [AAA-WG]: Policy representation for >> >>AAA server >> >>> Hi, >>> >>> I am interested in policy representation or >> >>policy server in >> >>> Diameter architecture. Is there any Internet >> >>Draft or paper >> >>> addressing the issues related to policy >> >>representation for >> >>> AAA server? Is there any specific direction or >> >>goal of the >> >>> WG regarding this issue? >>> >>> Any sort of information will be very helpful for me. >>> >>> regards, >>> >>> Salekul Islam >>> PhD candidate, Concordia University >>> Montreal, Canada >>> >>> >>> >>> >> >>-------------------------------------------------------------- >>---------- >> >>>_______________________________________________ >>>DiME mailing list >>>DiME@ietf.org >>>https://www1.ietf.org/mailman/listinfo/dime >> >> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 05 08:39:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnEMN-0004w0-1k; Mon, 05 Jun 2006 08:39:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnEMM-0004vu-4f for dime@ietf.org; Mon, 05 Jun 2006 08:39:06 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnEML-0007ZY-C7 for dime@ietf.org; Mon, 05 Jun 2006 08:39:06 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 79A960E320 for ; Mon, 5 Jun 2006 08:39:04 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k55Ccx8V000963 for ; Mon, 5 Jun 2006 08:39:03 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] CER/CEA on an open connection Date: Mon, 5 Jun 2006 08:16:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-reply-to: Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Vishnu, I think this text proposal is fine. One comment/questions: What about the case, where shutdown of application causes the overlapping application set between the peers to be empty? AFAICS, the procedure described below will still work. Peer-1 will send CER, will receive CEA("No Common Application") and will tear down the transport connection. That Peer-A (or Peer-B) drops the transport connection immediately would work too. Do we want explicitly restrict the second approach? And one more minor question: - What do you mean with "gracefully disconnect its current connection", or better said why not "disconnect its current connection"? Thanks, Tolga > -----Original Message----- > From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > Sent: Monday, June 05, 2006 3:40 AM > To: john.loughney@nokia.com > Cc: dime@ietf.org > Subject: RE: [Dime] CER/CEA on an open connection > > > All, > > Below is the proposed text for peer capabilities update in Base Diameter > (as discussed in this email list earlier). > > John, Please advice us on the process for text proposals to *-biz > versions. > > Regards, > Vishnu. > > ------------------------------------------------------------ > 5.3.8 Peer Capabilities Update > > Among the capabilities exchanged during Diameter connection > initialization, list of supported applications by the node can change > dynamically. Applications can be restarted for various reasons including > maintenance and upgrades. > > A Diameter node MUST initiate peer capabilities update by sending a > Capabilities-Exchange-Req (CER) to all its peers which supports peer > capabilities update and are in open state. Diameter nodes that implement > peer capabilities update SHOULD check the version information advertised > by its peer in the Diameter header of the previous CER/CEA exchange to > determine if the peer supports peer capabilities update. The Diameter > node MUST NOT send peer capabilities update to the peer if it determines > that the peer has no support for such scheme, instead it SHOULD > gracefully disconnect its current connection and attempt to establish a > new connection towards that peer. In either case, the Diameter node is > expected to advertise the most recent set of supported applications in a > CER message, as specified by the peer state machine (see Section 5.6) > while it is in the open state. > > The receiver of CER in open state MUST process and reply to the CER as a > described in Section 5.3. The CEA which the receiver sends MUST contain > its latest capabilities. Note that peers which successfully process the > peer capabilities update SHOULD also update their routing tables to > reflect the change. The receiver of the CEA, with a Result-Code AVP > other than DIAMETER_SUCCESS, initiates the transport disconnect. Peer > capabilities update in the open state SHOULD be limited to the > advertisement of the new list of supported applications and MUST > preclude re-negotiation of security mechanism or other parameters. > ------------------------------------------------------------ > > Regards, > Vishnu. > > Motorola India Electronics Pvt Ltd > +91 9844178052 > [*] Motorola Internal Use Only > > > > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Monday, April 10, 2006 8:13 PM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] CER/CEA on an open connection > > > Hi All, > > > I believe in general now we all have a good understanding about what > > the issues are for renegotiation. It could be an idea to have a new > > iteration of the proposed text, and to continue the discussions on the > > > new version. > > > > To that end, I'll plan on generating a new set of text maybe next week > as we let people digest and hopefully comment on the latest round of > discussion for the next couple of days. > > best regards, > victor > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > I believe in general now we all have a good understanding about what the > issues are for renegotiation. It could be an idea to have a new > iteration of the proposed text, and to continue the discussions on the > new version. > > A few more comments/questions below. > > Thanks, > Tolga > > > -----Original Message----- > > From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > > Sent: Monday, April 10, 2006 2:38 AM > > To: dime@ietf.org > > Cc: Nakhjiri Madjid-MNAKHJI1 > > Subject: RE: [Dime] CER/CEA on an open connection > > > > > > Hi Victor/Timothy, > > > > 1. Comments on Retry mechanism : > > To summarize, we are sending CER in open state because our > > capabilities (supported apps) are changing and we would like to update > > > the peer about it. We will maintain open state. > > > > we may not receive a CEA due to the following possible reasons: > > 1.1) The peer does not support CER in open state. In such a case, peer > > > might still originate unsupported app messages towards us which will > > result in "DIAMETER_APPLICATION_UNSUPPORTED" error from us. We can > > leave it to the peer implementation to "correct this error" as > > mentioned in sec 7.1.3 of RFC 3588. This will take care of the case > > where there is relay/proxy in between. > > 1.2) Connection is lost with the peer, in which case the DWR/DWA > > mechanism should step in. > > > > The solution suggested by Timothy (to wait for for CEA & timer) will > > need changes to FSM, even though we agree that this is consistent with > > > the initial CER/CEA scenario. > > > > Ofcourse the use of "DIAMETER_APPLICATION_UNSUPPORTED" will result in > > added (unecessary traffic) incase the peer/proxy is not clever enough > > to correct its behaviour. This can be avoided by using the version > > number exchange as Victor pointed out. So, we will not attempt the CER > > > in open state to such a peer which doesnt support CERs in open state, > > and can go for a reconnection. > [TOLGA]The problem case of a node not being clever enough to take action > based on "DIAMETER_APPLICATION_UNSUPPORTED" is not limited to > renegotiations. This could happen in existing systems developed > according to RFC3588 as well. I would expect a node, whose > DIAMETER_APPLICATION_UNSUPPORTED replies are not honored by its neighbor > to drop the connection, but as said this is not limited to renegotiation > case. For cases, where the neighbor does not support renegotiation, what > would be the result code in CEA? DIAMETER_UNABLE_TO_COMPLY? We can say > that such a result code in CEA should indicate that the neighbor does > not support renegotiations and sender of CER should/may drop/reestablish > the connection. Please note that with a properly behaving neighbor, > dropping connection is probably not necessary because the first > DIAMETER_APPLICATION_UNSUPPORTED should update its tables properly. I > don't know whether we need to standardize how a node determines whether > a neighbor honors DIAMETER_APPLICATION_UNSUPPORTED result code. > > > > 2. Comments on "re-negotiation" > > We think that what we need is an advertisement mechanism and not a > > negotiation mechanism. The CER/CEA in open state allows us to do that. > > > We are proposing that the receiver of the CER takes the decision on > > the disconnection. Thus we are able to delay the disconnection > > (assuming that the point mentioned in my email before that the app > > changes are temporary). Since CER allows us to convey the latest set > > of supported apps to the peer, we favour the CER to the DPR. > > > > Following is a scenario where sending CER/CEA is better than the DPR > > mechanism. (Apologies if the figure is mangled due to tab settings). > [TOLGA]Although the example case below is a race condition which > probably won't happen very often -it relies on changing supported > application set on two nodes more or less simultaneously-, I also prefer > relying on CER in such a situation, so that there is a single way of > handling renegotiations in terms of advertising changes to the > neighbors. > > > > Initial exchanged app list: > > A: 1,2,3 B:2 > > 2 went down 3 came up just when 2 went down on A > > ________ ________ > > |A |----DPR---> |B | > > | | | | > > | |<---CER---- | | > > |______| [3] |______| > > <---DPA---- > > > > this in our understanding will result in reconnection even thou there > > is 3 in common. > > > > Initial exchanged app list: > > A: 1,2,3 B:2 > > 2 went down 3 came up just when 2 went down on A > > ________ ________ > > |A |----CER---> |B | > > | | [1,3] | | > > | |<---CER---- | | > > |_______| [2,3] |_______| > > ----CEA----> > > [1,3] > > <---CEA----- > > [2,3] > > This will avoid a reconnection, because 3 is in common. > > > > Regards, > > Vishnu. > > > > Motorola India Electronics Pvt Ltd > > +91 9844178052 > > [*] Motorola Internal Use Only > > > > > > -----Original Message----- > > From: Timothy Smith [mailto:tjsmith@us.ibm.com] > > Sent: Monday, April 10, 2006 7:11 AM > > To: Victor Fajardo > > Cc: dime@ietf.org; Nakhjiri Madjid-MNAKHJI1; Ram O V Vishnu-A14676 > > Subject: Re: [Dime] CER/CEA on an open connection > > > > > > > > Hi Victor, > > > > Thanks for your response. Comments below" > > >> > > >> Good summary! I agree with most of your points. I'm not sure, > > >> however, that I distinguish between (1) and (2). I think whether > > >> temporary or not, we should handle CER/CEA exchanges in the same > > manner. > > >I'm just speculating but I think (2) refers to application change > > >requiring a reboot. > > >> > > >> I agree with your design goals (3) ,(4), and suggestions (5) , (6) > > >> , (8), and (9). > > >If some are more in favor of scheme (5) , maybe we need more opinion > > on > > >whether the receiver of the CEA can always comply with the change > > >request regardless of any scenario. I think (6) and (9) can be > > >avoided regardless of which scheme we decide to use (see my previous > > >reply). > > > > > > > Here is the text from your previous reply: > > "This certainly simplifies things but it also implies that the sender > > of > > > > the CER mandates a change and the receiver has no choice but to accept > > > it. In some sense, the scheme is no longer a re-negotiation but merely > > > notifying the peer of a change. The proposed text was considering the > > case where the receiver of the CER cannot comply with the change for > > whatever reason." > > > > I tend to agree with the notion that the sender of the CER is > > mandating a change. The receiver does have a choice just as it has a > > choice in the original CER/CEA exchange. The receiver should respond > > with the list of > > > > App Ids that is the intersection of what was listed in the CER and of > > what App Ids it wishes to support. It is a renegotiation which may > > add or remove App Ids. But either way, it is telling the other side > > about its intentions. I don't thing the receiving side has any choice > > > but to participate > > in the renegotiation. For example, if an app Id is being removed, the > > side > > where it is being removed renegotiates with a CER that does not > include > > that > > App ID. It doesn't do the receiving side any good to decline this as > > the App > > will be shut down regardless. > > > > > > >> Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont > > >> think there is a problem here. Cant find any race condition." I > > >> thought that there was a subtle problem here, but I think you are > > >> right. Given that the connection insures sequencing, the latest > > >> CER or CEA that you receive is what you should use as the list of > > >> negotiated App Ids. > > >> > > >Mmmm... i'm not sure that the connection itself ensures sequencing. > > >Anyway, majority rule favors removing this text. > > >> Should there be some discussion on the retry mechanism? You send a > > > >> CER, and no response is received. Does this mean that the peer > > >> just doesn't know how to renegotiate? Should we ignore and retry > > >> every n seconds? Bring down the connection? Or do we just > > >> continue to use the apps from the initial negotiation? My > > >> preference on this is that we should require a CEA response to the > > >> CER. If the CEA is not received, we shutdown the connection and > > >> start over. This would address compatibility issues with existing > > >> implementations. It would > > > > >> also be consistent with the processing of the initial CER/CEA. > > >> > > >The current proposal has text mentioning the use of version number of > > > >initial CER/CEA exchange to determine whether a peer is capable of > > >renegotiating. If a node knows that its peer is not capable of > > >re-negotiating then the node should not initiate re-negotiation. In > > this > > >scheme, existing implementations will be spared of any change. > > > > I'm not sure I picked up the version number. I don't see a reason to > > do > > > > something special. I would simply like to renegotiate. If the other > > side does not respond to the CER, you shut down the connection and > > restart it > > > > after some period of time. This is what you would do if your initial > > CER did not get a response. How is this different? > > > > > > Best Regards, > > Timothy Smith > > > > Vishnu wrote: > > > Hi, > > > > > > Some clarifications and comments on the discussion on this thread: > > > > > > We would like to clarify the following practical scenarios of this > > > happenning: > > > 1. there are a list of published applications which the box support > > > and these are installed in the box. Now, some of them go down/up. > > > This would get translated into change in peer capabilities. > > > 2. there is a new application which is getting installed/removed > from > > > the box. > > > > > > We think that (1) is the most probable scenario. so, > > > there is value in giving a simple solution assuming that this change > > (in > > > capabilities) > > > is most probably temporary. If this is not the case, we are talking > > > about (2), which is a major change in the box anyways. So in (2), we > > > > assume it is ok to assume that > > > the connections to be reestablished. > > > > > > We would like to say that our design goals are: > > > 3. solution should be simple & as backward compatible as possible. > > > 4. minimize the FSM changes. > > > > > > We suggest: > > > 5. Updating peer capabilities done only using a CER/CEA in the open > > > state. Sender of CER/CEA updates the local capabilities before > > > sending the message and > > > hence is a local decision. > > > > > > 6. The rest of the processing of the CER/CEA will be as per the > > current > > > RFC. > > > Say for example, if there are no > > > common applications left with that peer, > > DIAMETER_NO_COMMON_APPLICATION > > > is sent in the > > > CEA and the connection is closed. > > > > > > Problems in the email thread under discussion & some comments: 7. > > > Cross over and sequencing of CER/CEA exchange. We dont think there > > is > > > a problem > > > here. Cant find any race condition. > > > > > > 8. Mutual agreement to bring down applications will not work due to > > > possible relays in between as Tolga has pointed out in the mailing > > > list. > > > > > > 9. The DPR solution in the suggested text is not a good idea. > > > Because DPR cannot advertise the latest local applications to the > > > peer. This may cause > > the > > > race condition > > > and sequencing problem. This problem can be avoided by using the > > > approach which we suggested in (5). > > > > > > Regards, > > > Vishnu. > > > > tjsmith@us.ibm.com > > (919) 254-4723 > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 05 08:57:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnEeV-00056z-PS; Mon, 05 Jun 2006 08:57:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnEeT-00056t-Vg for dime@ietf.org; Mon, 05 Jun 2006 08:57:49 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnEeT-0001Q7-6b for dime@ietf.org; Mon, 05 Jun 2006 08:57:49 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k55CvhhT002138; Mon, 5 Jun 2006 08:57:43 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44842602.4080702@tari.toshiba.com> Date: Mon, 05 Jun 2006 08:39:30 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] CER/CEA on an open connection References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e52c6009a9b39871b75233310d7f3490 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, > Vishnu, > > I think this text proposal is fine. > > One comment/questions: > What about the case, where shutdown of application causes the overlapping > application set between the peers to be empty? AFAICS, the procedure > described below will still work. Peer-1 will send CER, will receive CEA("No > Common Application") and will tear down the transport connection. That > Peer-A (or Peer-B) drops the transport connection immediately would work > too. Do we want explicitly restrict the second approach? > I remember that Ram mentioned a race condition regarding the second approach: 2. Comments on "re-negotiation" We think that what we need is an advertisement mechanism and not a negotiation mechanism. The CER/CEA in open state allows us to do that. We are proposing that the receiver of the CER takes the decision on the disconnection. Thus we are able to delay the disconnection (assuming that the point mentioned in my email before that the app changes are temporary). Since CER allows us to convey the latest set of supported apps to the peer, we favour the CER to the DPR. Following is a scenario where sending CER/CEA is better than the DPR mechanism. (Apologies if the figure is mangled due to tab settings). Initial exchanged app list: A: 1,2,3 B:2 2 went down 3 came up just when 2 went down on A ________ ________ |A |----DPR---> |B | | | | | | |<---CER---- | | |______| [3] |______| <---DPA---- this in our understanding will result in reconnection even thou there is 3 in common. Initial exchanged app list: A: 1,2,3 B:2 2 went down 3 came up just when 2 went down on A ________ ________ |A |----CER---> |B | | | [1,3] | | | |<---CER---- | | |_______| [2,3] |_______| ----CEA----> [1,3] <---CEA----- [2,3] This will avoid a reconnection, because 3 is in common. > And one more minor question: > - What do you mean with "gracefully disconnect its current connection", or > better said why not "disconnect its current connection"? > that works too. best regards, victor > Thanks, > Tolga > > > >> -----Original Message----- >> From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] >> Sent: Monday, June 05, 2006 3:40 AM >> To: john.loughney@nokia.com >> Cc: dime@ietf.org >> Subject: RE: [Dime] CER/CEA on an open connection >> >> >> All, >> >> Below is the proposed text for peer capabilities update in Base Diameter >> (as discussed in this email list earlier). >> >> John, Please advice us on the process for text proposals to *-biz >> versions. >> >> Regards, >> Vishnu. >> >> ------------------------------------------------------------ >> 5.3.8 Peer Capabilities Update >> >> Among the capabilities exchanged during Diameter connection >> initialization, list of supported applications by the node can change >> dynamically. Applications can be restarted for various reasons including >> maintenance and upgrades. >> >> A Diameter node MUST initiate peer capabilities update by sending a >> Capabilities-Exchange-Req (CER) to all its peers which supports peer >> capabilities update and are in open state. Diameter nodes that implement >> peer capabilities update SHOULD check the version information advertised >> by its peer in the Diameter header of the previous CER/CEA exchange to >> determine if the peer supports peer capabilities update. The Diameter >> node MUST NOT send peer capabilities update to the peer if it determines >> that the peer has no support for such scheme, instead it SHOULD >> gracefully disconnect its current connection and attempt to establish a >> new connection towards that peer. In either case, the Diameter node is >> expected to advertise the most recent set of supported applications in a >> CER message, as specified by the peer state machine (see Section 5.6) >> while it is in the open state. >> >> The receiver of CER in open state MUST process and reply to the CER as a >> described in Section 5.3. The CEA which the receiver sends MUST contain >> its latest capabilities. Note that peers which successfully process the >> peer capabilities update SHOULD also update their routing tables to >> reflect the change. The receiver of the CEA, with a Result-Code AVP >> other than DIAMETER_SUCCESS, initiates the transport disconnect. Peer >> capabilities update in the open state SHOULD be limited to the >> advertisement of the new list of supported applications and MUST >> preclude re-negotiation of security mechanism or other parameters. >> ------------------------------------------------------------ >> >> Regards, >> Vishnu. >> >> Motorola India Electronics Pvt Ltd >> +91 9844178052 >> [*] Motorola Internal Use Only >> >> >> >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: Monday, April 10, 2006 8:13 PM >> To: Tolga Asveren >> Cc: dime@ietf.org >> Subject: Re: [Dime] CER/CEA on an open connection >> >> >> Hi All, >> >> >>> I believe in general now we all have a good understanding about what >>> the issues are for renegotiation. It could be an idea to have a new >>> iteration of the proposed text, and to continue the discussions on the >>> >>> new version. >>> >>> >> To that end, I'll plan on generating a new set of text maybe next week >> as we let people digest and hopefully comment on the latest round of >> discussion for the next couple of days. >> >> best regards, >> victor >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> I believe in general now we all have a good understanding about what the >> issues are for renegotiation. It could be an idea to have a new >> iteration of the proposed text, and to continue the discussions on the >> new version. >> >> A few more comments/questions below. >> >> Thanks, >> Tolga >> >> >>> -----Original Message----- >>> From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] >>> Sent: Monday, April 10, 2006 2:38 AM >>> To: dime@ietf.org >>> Cc: Nakhjiri Madjid-MNAKHJI1 >>> Subject: RE: [Dime] CER/CEA on an open connection >>> >>> >>> Hi Victor/Timothy, >>> >>> 1. Comments on Retry mechanism : >>> To summarize, we are sending CER in open state because our >>> capabilities (supported apps) are changing and we would like to update >>> >>> the peer about it. We will maintain open state. >>> >>> we may not receive a CEA due to the following possible reasons: >>> 1.1) The peer does not support CER in open state. In such a case, peer >>> >>> might still originate unsupported app messages towards us which will >>> result in "DIAMETER_APPLICATION_UNSUPPORTED" error from us. We can >>> leave it to the peer implementation to "correct this error" as >>> mentioned in sec 7.1.3 of RFC 3588. This will take care of the case >>> where there is relay/proxy in between. >>> 1.2) Connection is lost with the peer, in which case the DWR/DWA >>> mechanism should step in. >>> >>> The solution suggested by Timothy (to wait for for CEA & timer) will >>> need changes to FSM, even though we agree that this is consistent with >>> >>> the initial CER/CEA scenario. >>> >>> Ofcourse the use of "DIAMETER_APPLICATION_UNSUPPORTED" will result in >>> added (unecessary traffic) incase the peer/proxy is not clever enough >>> to correct its behaviour. This can be avoided by using the version >>> number exchange as Victor pointed out. So, we will not attempt the CER >>> >>> in open state to such a peer which doesnt support CERs in open state, >>> and can go for a reconnection. >>> >> [TOLGA]The problem case of a node not being clever enough to take action >> based on "DIAMETER_APPLICATION_UNSUPPORTED" is not limited to >> renegotiations. This could happen in existing systems developed >> according to RFC3588 as well. I would expect a node, whose >> DIAMETER_APPLICATION_UNSUPPORTED replies are not honored by its neighbor >> to drop the connection, but as said this is not limited to renegotiation >> case. For cases, where the neighbor does not support renegotiation, what >> would be the result code in CEA? DIAMETER_UNABLE_TO_COMPLY? We can say >> that such a result code in CEA should indicate that the neighbor does >> not support renegotiations and sender of CER should/may drop/reestablish >> the connection. Please note that with a properly behaving neighbor, >> dropping connection is probably not necessary because the first >> DIAMETER_APPLICATION_UNSUPPORTED should update its tables properly. I >> don't know whether we need to standardize how a node determines whether >> a neighbor honors DIAMETER_APPLICATION_UNSUPPORTED result code. >> >>> 2. Comments on "re-negotiation" >>> We think that what we need is an advertisement mechanism and not a >>> negotiation mechanism. The CER/CEA in open state allows us to do that. >>> >>> We are proposing that the receiver of the CER takes the decision on >>> the disconnection. Thus we are able to delay the disconnection >>> (assuming that the point mentioned in my email before that the app >>> changes are temporary). Since CER allows us to convey the latest set >>> of supported apps to the peer, we favour the CER to the DPR. >>> >>> Following is a scenario where sending CER/CEA is better than the DPR >>> mechanism. (Apologies if the figure is mangled due to tab settings). >>> >> [TOLGA]Although the example case below is a race condition which >> probably won't happen very often -it relies on changing supported >> application set on two nodes more or less simultaneously-, I also prefer >> relying on CER in such a situation, so that there is a single way of >> handling renegotiations in terms of advertising changes to the >> neighbors. >> >>> Initial exchanged app list: >>> A: 1,2,3 B:2 >>> 2 went down 3 came up just when 2 went down on A >>> ________ ________ >>> |A |----DPR---> |B | >>> | | | | >>> | |<---CER---- | | >>> |______| [3] |______| >>> <---DPA---- >>> >>> this in our understanding will result in reconnection even thou there >>> is 3 in common. >>> >>> Initial exchanged app list: >>> A: 1,2,3 B:2 >>> 2 went down 3 came up just when 2 went down on A >>> ________ ________ >>> |A |----CER---> |B | >>> | | [1,3] | | >>> | |<---CER---- | | >>> |_______| [2,3] |_______| >>> ----CEA----> >>> [1,3] >>> <---CEA----- >>> [2,3] >>> This will avoid a reconnection, because 3 is in common. >>> >>> Regards, >>> Vishnu. >>> >>> Motorola India Electronics Pvt Ltd >>> +91 9844178052 >>> [*] Motorola Internal Use Only >>> >>> >>> -----Original Message----- >>> From: Timothy Smith [mailto:tjsmith@us.ibm.com] >>> Sent: Monday, April 10, 2006 7:11 AM >>> To: Victor Fajardo >>> Cc: dime@ietf.org; Nakhjiri Madjid-MNAKHJI1; Ram O V Vishnu-A14676 >>> Subject: Re: [Dime] CER/CEA on an open connection >>> >>> >>> >>> Hi Victor, >>> >>> Thanks for your response. Comments below" >>> >>>>> Good summary! I agree with most of your points. I'm not sure, >>>>> however, that I distinguish between (1) and (2). I think whether >>>>> temporary or not, we should handle CER/CEA exchanges in the same >>>>> >>> manner. >>> >>>> I'm just speculating but I think (2) refers to application change >>>> requiring a reboot. >>>> >>>>> I agree with your design goals (3) ,(4), and suggestions (5) , (6) >>>>> , (8), and (9). >>>>> >>>> If some are more in favor of scheme (5) , maybe we need more opinion >>>> >>> on >>> >>>> whether the receiver of the CEA can always comply with the change >>>> request regardless of any scenario. I think (6) and (9) can be >>>> avoided regardless of which scheme we decide to use (see my previous >>>> reply). >>>> >>>> >>> Here is the text from your previous reply: >>> "This certainly simplifies things but it also implies that the sender >>> of >>> >>> the CER mandates a change and the receiver has no choice but to accept >>> >>> it. In some sense, the scheme is no longer a re-negotiation but merely >>> >>> notifying the peer of a change. The proposed text was considering the >>> case where the receiver of the CER cannot comply with the change for >>> whatever reason." >>> >>> I tend to agree with the notion that the sender of the CER is >>> mandating a change. The receiver does have a choice just as it has a >>> choice in the original CER/CEA exchange. The receiver should respond >>> with the list of >>> >>> App Ids that is the intersection of what was listed in the CER and of >>> what App Ids it wishes to support. It is a renegotiation which may >>> add or remove App Ids. But either way, it is telling the other side >>> about its intentions. I don't thing the receiving side has any choice >>> >>> but to participate >>> in the renegotiation. For example, if an app Id is being removed, the >>> side >>> where it is being removed renegotiates with a CER that does not >>> >> include >> >>> that >>> App ID. It doesn't do the receiving side any good to decline this as >>> the App >>> will be shut down regardless. >>> >>> >>> >>>>> Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont >>>>> think there is a problem here. Cant find any race condition." I >>>>> thought that there was a subtle problem here, but I think you are >>>>> right. Given that the connection insures sequencing, the latest >>>>> CER or CEA that you receive is what you should use as the list of >>>>> negotiated App Ids. >>>>> >>>>> >>>> Mmmm... i'm not sure that the connection itself ensures sequencing. >>>> Anyway, majority rule favors removing this text. >>>> >>>>> Should there be some discussion on the retry mechanism? You send a >>>>> >>>>> CER, and no response is received. Does this mean that the peer >>>>> just doesn't know how to renegotiate? Should we ignore and retry >>>>> every n seconds? Bring down the connection? Or do we just >>>>> continue to use the apps from the initial negotiation? My >>>>> preference on this is that we should require a CEA response to the >>>>> CER. If the CEA is not received, we shutdown the connection and >>>>> start over. This would address compatibility issues with existing >>>>> implementations. It would >>>>> >>>>> also be consistent with the processing of the initial CER/CEA. >>>>> >>>>> >>>> The current proposal has text mentioning the use of version number of >>>> >>>> initial CER/CEA exchange to determine whether a peer is capable of >>>> renegotiating. If a node knows that its peer is not capable of >>>> re-negotiating then the node should not initiate re-negotiation. In >>>> >>> this >>> >>>> scheme, existing implementations will be spared of any change. >>>> >>> I'm not sure I picked up the version number. I don't see a reason to >>> do >>> >>> something special. I would simply like to renegotiate. If the other >>> side does not respond to the CER, you shut down the connection and >>> restart it >>> >>> after some period of time. This is what you would do if your initial >>> CER did not get a response. How is this different? >>> >>> >>> Best Regards, >>> Timothy Smith >>> >>> Vishnu wrote: >>> >>>> Hi, >>>> >>>> Some clarifications and comments on the discussion on this thread: >>>> >>>> We would like to clarify the following practical scenarios of this >>>> happenning: >>>> 1. there are a list of published applications which the box support >>>> and these are installed in the box. Now, some of them go down/up. >>>> This would get translated into change in peer capabilities. >>>> 2. there is a new application which is getting installed/removed >>>> >> from >> >>>> the box. >>>> >>>> We think that (1) is the most probable scenario. so, >>>> there is value in giving a simple solution assuming that this change >>>> >>> (in >>> >>>> capabilities) >>>> is most probably temporary. If this is not the case, we are talking >>>> about (2), which is a major change in the box anyways. So in (2), we >>>> >>>> assume it is ok to assume that >>>> the connections to be reestablished. >>>> >>>> We would like to say that our design goals are: >>>> 3. solution should be simple & as backward compatible as possible. >>>> 4. minimize the FSM changes. >>>> >>>> We suggest: >>>> 5. Updating peer capabilities done only using a CER/CEA in the open >>>> state. Sender of CER/CEA updates the local capabilities before >>>> sending the message and >>>> hence is a local decision. >>>> >>>> 6. The rest of the processing of the CER/CEA will be as per the >>>> >>> current >>> >>>> RFC. >>>> Say for example, if there are no >>>> common applications left with that peer, >>>> >>> DIAMETER_NO_COMMON_APPLICATION >>> >>>> is sent in the >>>> CEA and the connection is closed. >>>> >>>> Problems in the email thread under discussion & some comments: 7. >>>> Cross over and sequencing of CER/CEA exchange. We dont think there >>>> >>> is >>> >>>> a problem >>>> here. Cant find any race condition. >>>> >>>> 8. Mutual agreement to bring down applications will not work due to >>>> possible relays in between as Tolga has pointed out in the mailing >>>> list. >>>> >>>> 9. The DPR solution in the suggested text is not a good idea. >>>> Because DPR cannot advertise the latest local applications to the >>>> peer. This may cause >>>> >>> the >>> >>>> race condition >>>> and sequencing problem. This problem can be avoided by using the >>>> approach which we suggested in (5). >>>> >>>> Regards, >>>> Vishnu. >>>> >>> tjsmith@us.ibm.com >>> (919) 254-4723 >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 05 11:19:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnGrF-0000Me-Mz; Mon, 05 Jun 2006 11:19:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnGrD-0000MJ-Tr for dime@ietf.org; Mon, 05 Jun 2006 11:19:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnFYV-0001UK-OR for dime@ietf.org; Mon, 05 Jun 2006 09:55:43 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FnFR4-0000Hv-2p for dime@ietf.org; Mon, 05 Jun 2006 09:48:06 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 246945D0E0 for ; Mon, 5 Jun 2006 09:48:01 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k55DlwhD007380 for ; Mon, 5 Jun 2006 09:47:59 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] CER/CEA on an open connection Date: Mon, 5 Jun 2006 09:25:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-reply-to: <44842602.4080702@tari.toshiba.com> Importance: Normal Received-SPF: pass X-Spam-Score: -1.3 (-) X-Scan-Signature: 9724479da43a8325ad975c1a9b841870 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, The race condition presented is probably very unlikely but probably is still something to consider. Actually after thinking a bit more, I think the approach presented in the text is architecturally more clean as well, there is a full negotiation transaction and based on the result of it some action is taken. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Monday, June 05, 2006 8:40 AM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] CER/CEA on an open connection > > > Hi Tolga, > > Vishnu, > > > > I think this text proposal is fine. > > > > One comment/questions: > > What about the case, where shutdown of application causes the > overlapping > > application set between the peers to be empty? AFAICS, the procedure > > described below will still work. Peer-1 will send CER, will > receive CEA("No > > Common Application") and will tear down the transport connection. That > > Peer-A (or Peer-B) drops the transport connection immediately would work > > too. Do we want explicitly restrict the second approach? > > > > I remember that Ram mentioned a race condition regarding the second > approach: > > 2. Comments on "re-negotiation" > We think that what we need is an advertisement mechanism and not a > negotiation mechanism. The CER/CEA in open state allows us to do that. > We are proposing that the receiver of the CER takes the decision on the > disconnection. Thus we are able to delay the disconnection (assuming > that the point mentioned in my email before that the app changes are > temporary). > Since CER allows us to convey the latest set of supported apps to the > peer, we favour the CER to the DPR. > > Following is a scenario where sending CER/CEA is better than the DPR > mechanism. > (Apologies if the figure is mangled due to tab settings). > > Initial exchanged app list: > A: 1,2,3 B:2 > 2 went down 3 came up just when 2 went down on A > ________ ________ > |A |----DPR---> |B | > | | | | > | |<---CER---- | | > |______| [3] |______| > <---DPA---- > > this in our understanding will result in reconnection even thou there > is 3 in common. > > Initial exchanged app list: > A: 1,2,3 B:2 > 2 went down 3 came up just when 2 went down on A > ________ ________ > |A |----CER---> |B | > | | [1,3] | | > | |<---CER---- | | > |_______| [2,3] |_______| > ----CEA----> > [1,3] > <---CEA----- > [2,3] > This will avoid a reconnection, because 3 is in common. > > > And one more minor question: > > - What do you mean with "gracefully disconnect its current > connection", or > > better said why not "disconnect its current connection"? > > > > that works too. > > best regards, > victor > > > Thanks, > > Tolga > > > > > > > >> -----Original Message----- > >> From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > >> Sent: Monday, June 05, 2006 3:40 AM > >> To: john.loughney@nokia.com > >> Cc: dime@ietf.org > >> Subject: RE: [Dime] CER/CEA on an open connection > >> > >> > >> All, > >> > >> Below is the proposed text for peer capabilities update in > Base Diameter > >> (as discussed in this email list earlier). > >> > >> John, Please advice us on the process for text proposals to *-biz > >> versions. > >> > >> Regards, > >> Vishnu. > >> > >> ------------------------------------------------------------ > >> 5.3.8 Peer Capabilities Update > >> > >> Among the capabilities exchanged during Diameter connection > >> initialization, list of supported applications by the node can change > >> dynamically. Applications can be restarted for various reasons > including > >> maintenance and upgrades. > >> > >> A Diameter node MUST initiate peer capabilities update by sending a > >> Capabilities-Exchange-Req (CER) to all its peers which supports peer > >> capabilities update and are in open state. Diameter nodes that > implement > >> peer capabilities update SHOULD check the version information > advertised > >> by its peer in the Diameter header of the previous CER/CEA exchange to > >> determine if the peer supports peer capabilities update. The Diameter > >> node MUST NOT send peer capabilities update to the peer if it > determines > >> that the peer has no support for such scheme, instead it SHOULD > >> gracefully disconnect its current connection and attempt to establish a > >> new connection towards that peer. In either case, the Diameter node is > >> expected to advertise the most recent set of supported > applications in a > >> CER message, as specified by the peer state machine (see Section 5.6) > >> while it is in the open state. > >> > >> The receiver of CER in open state MUST process and reply to > the CER as a > >> described in Section 5.3. The CEA which the receiver sends MUST contain > >> its latest capabilities. Note that peers which successfully process the > >> peer capabilities update SHOULD also update their routing tables to > >> reflect the change. The receiver of the CEA, with a Result-Code AVP > >> other than DIAMETER_SUCCESS, initiates the transport disconnect. Peer > >> capabilities update in the open state SHOULD be limited to the > >> advertisement of the new list of supported applications and MUST > >> preclude re-negotiation of security mechanism or other parameters. > >> ------------------------------------------------------------ > >> > >> Regards, > >> Vishnu. > >> > >> Motorola India Electronics Pvt Ltd > >> +91 9844178052 > >> [*] Motorola Internal Use Only > >> > >> > >> > >> -----Original Message----- > >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > >> Sent: Monday, April 10, 2006 8:13 PM > >> To: Tolga Asveren > >> Cc: dime@ietf.org > >> Subject: Re: [Dime] CER/CEA on an open connection > >> > >> > >> Hi All, > >> > >> > >>> I believe in general now we all have a good understanding about what > >>> the issues are for renegotiation. It could be an idea to have a new > >>> iteration of the proposed text, and to continue the discussions on the > >>> > >>> new version. > >>> > >>> > >> To that end, I'll plan on generating a new set of text maybe next week > >> as we let people digest and hopefully comment on the latest round of > >> discussion for the next couple of days. > >> > >> best regards, > >> victor > >> > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> I believe in general now we all have a good understanding > about what the > >> issues are for renegotiation. It could be an idea to have a new > >> iteration of the proposed text, and to continue the discussions on the > >> new version. > >> > >> A few more comments/questions below. > >> > >> Thanks, > >> Tolga > >> > >> > >>> -----Original Message----- > >>> From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > >>> Sent: Monday, April 10, 2006 2:38 AM > >>> To: dime@ietf.org > >>> Cc: Nakhjiri Madjid-MNAKHJI1 > >>> Subject: RE: [Dime] CER/CEA on an open connection > >>> > >>> > >>> Hi Victor/Timothy, > >>> > >>> 1. Comments on Retry mechanism : > >>> To summarize, we are sending CER in open state because our > >>> capabilities (supported apps) are changing and we would like to update > >>> > >>> the peer about it. We will maintain open state. > >>> > >>> we may not receive a CEA due to the following possible reasons: > >>> 1.1) The peer does not support CER in open state. In such a case, peer > >>> > >>> might still originate unsupported app messages towards us which will > >>> result in "DIAMETER_APPLICATION_UNSUPPORTED" error from us. We can > >>> leave it to the peer implementation to "correct this error" as > >>> mentioned in sec 7.1.3 of RFC 3588. This will take care of the case > >>> where there is relay/proxy in between. > >>> 1.2) Connection is lost with the peer, in which case the DWR/DWA > >>> mechanism should step in. > >>> > >>> The solution suggested by Timothy (to wait for for CEA & timer) will > >>> need changes to FSM, even though we agree that this is consistent with > >>> > >>> the initial CER/CEA scenario. > >>> > >>> Ofcourse the use of "DIAMETER_APPLICATION_UNSUPPORTED" will result in > >>> added (unecessary traffic) incase the peer/proxy is not clever enough > >>> to correct its behaviour. This can be avoided by using the version > >>> number exchange as Victor pointed out. So, we will not attempt the CER > >>> > >>> in open state to such a peer which doesnt support CERs in open state, > >>> and can go for a reconnection. > >>> > >> [TOLGA]The problem case of a node not being clever enough to > take action > >> based on "DIAMETER_APPLICATION_UNSUPPORTED" is not limited to > >> renegotiations. This could happen in existing systems developed > >> according to RFC3588 as well. I would expect a node, whose > >> DIAMETER_APPLICATION_UNSUPPORTED replies are not honored by > its neighbor > >> to drop the connection, but as said this is not limited to > renegotiation > >> case. For cases, where the neighbor does not support > renegotiation, what > >> would be the result code in CEA? DIAMETER_UNABLE_TO_COMPLY? We can say > >> that such a result code in CEA should indicate that the neighbor does > >> not support renegotiations and sender of CER should/may > drop/reestablish > >> the connection. Please note that with a properly behaving neighbor, > >> dropping connection is probably not necessary because the first > >> DIAMETER_APPLICATION_UNSUPPORTED should update its tables properly. I > >> don't know whether we need to standardize how a node determines whether > >> a neighbor honors DIAMETER_APPLICATION_UNSUPPORTED result code. > >> > >>> 2. Comments on "re-negotiation" > >>> We think that what we need is an advertisement mechanism and not a > >>> negotiation mechanism. The CER/CEA in open state allows us to do that. > >>> > >>> We are proposing that the receiver of the CER takes the decision on > >>> the disconnection. Thus we are able to delay the disconnection > >>> (assuming that the point mentioned in my email before that the app > >>> changes are temporary). Since CER allows us to convey the latest set > >>> of supported apps to the peer, we favour the CER to the DPR. > >>> > >>> Following is a scenario where sending CER/CEA is better than the DPR > >>> mechanism. (Apologies if the figure is mangled due to tab settings). > >>> > >> [TOLGA]Although the example case below is a race condition which > >> probably won't happen very often -it relies on changing supported > >> application set on two nodes more or less simultaneously-, I > also prefer > >> relying on CER in such a situation, so that there is a single way of > >> handling renegotiations in terms of advertising changes to the > >> neighbors. > >> > >>> Initial exchanged app list: > >>> A: 1,2,3 B:2 > >>> 2 went down 3 came up just when 2 went down on A > >>> ________ ________ > >>> |A |----DPR---> |B | > >>> | | | | > >>> | |<---CER---- | | > >>> |______| [3] |______| > >>> <---DPA---- > >>> > >>> this in our understanding will result in reconnection even thou there > >>> is 3 in common. > >>> > >>> Initial exchanged app list: > >>> A: 1,2,3 B:2 > >>> 2 went down 3 came up just when 2 went down on A > >>> ________ ________ > >>> |A |----CER---> |B | > >>> | | [1,3] | | > >>> | |<---CER---- | | > >>> |_______| [2,3] |_______| > >>> ----CEA----> > >>> [1,3] > >>> <---CEA----- > >>> [2,3] > >>> This will avoid a reconnection, because 3 is in common. > >>> > >>> Regards, > >>> Vishnu. > >>> > >>> Motorola India Electronics Pvt Ltd > >>> +91 9844178052 > >>> [*] Motorola Internal Use Only > >>> > >>> > >>> -----Original Message----- > >>> From: Timothy Smith [mailto:tjsmith@us.ibm.com] > >>> Sent: Monday, April 10, 2006 7:11 AM > >>> To: Victor Fajardo > >>> Cc: dime@ietf.org; Nakhjiri Madjid-MNAKHJI1; Ram O V Vishnu-A14676 > >>> Subject: Re: [Dime] CER/CEA on an open connection > >>> > >>> > >>> > >>> Hi Victor, > >>> > >>> Thanks for your response. Comments below" > >>> > >>>>> Good summary! I agree with most of your points. I'm not sure, > >>>>> however, that I distinguish between (1) and (2). I think whether > >>>>> temporary or not, we should handle CER/CEA exchanges in the same > >>>>> > >>> manner. > >>> > >>>> I'm just speculating but I think (2) refers to application change > >>>> requiring a reboot. > >>>> > >>>>> I agree with your design goals (3) ,(4), and suggestions (5) , (6) > >>>>> , (8), and (9). > >>>>> > >>>> If some are more in favor of scheme (5) , maybe we need more opinion > >>>> > >>> on > >>> > >>>> whether the receiver of the CEA can always comply with the change > >>>> request regardless of any scenario. I think (6) and (9) can be > >>>> avoided regardless of which scheme we decide to use (see my previous > >>>> reply). > >>>> > >>>> > >>> Here is the text from your previous reply: > >>> "This certainly simplifies things but it also implies that the sender > >>> of > >>> > >>> the CER mandates a change and the receiver has no choice but to accept > >>> > >>> it. In some sense, the scheme is no longer a re-negotiation but merely > >>> > >>> notifying the peer of a change. The proposed text was considering the > >>> case where the receiver of the CER cannot comply with the change for > >>> whatever reason." > >>> > >>> I tend to agree with the notion that the sender of the CER is > >>> mandating a change. The receiver does have a choice just as it has a > >>> choice in the original CER/CEA exchange. The receiver should respond > >>> with the list of > >>> > >>> App Ids that is the intersection of what was listed in the CER and of > >>> what App Ids it wishes to support. It is a renegotiation which may > >>> add or remove App Ids. But either way, it is telling the other side > >>> about its intentions. I don't thing the receiving side has any choice > >>> > >>> but to participate > >>> in the renegotiation. For example, if an app Id is being removed, the > >>> side > >>> where it is being removed renegotiates with a CER that does not > >>> > >> include > >> > >>> that > >>> App ID. It doesn't do the receiving side any good to decline this as > >>> the App > >>> will be shut down regardless. > >>> > >>> > >>> > >>>>> Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont > >>>>> think there is a problem here. Cant find any race condition." I > >>>>> thought that there was a subtle problem here, but I think you are > >>>>> right. Given that the connection insures sequencing, the latest > >>>>> CER or CEA that you receive is what you should use as the list of > >>>>> negotiated App Ids. > >>>>> > >>>>> > >>>> Mmmm... i'm not sure that the connection itself ensures sequencing. > >>>> Anyway, majority rule favors removing this text. > >>>> > >>>>> Should there be some discussion on the retry mechanism? You send a > >>>>> > >>>>> CER, and no response is received. Does this mean that the peer > >>>>> just doesn't know how to renegotiate? Should we ignore and retry > >>>>> every n seconds? Bring down the connection? Or do we just > >>>>> continue to use the apps from the initial negotiation? My > >>>>> preference on this is that we should require a CEA response to the > >>>>> CER. If the CEA is not received, we shutdown the connection and > >>>>> start over. This would address compatibility issues with existing > >>>>> implementations. It would > >>>>> > >>>>> also be consistent with the processing of the initial CER/CEA. > >>>>> > >>>>> > >>>> The current proposal has text mentioning the use of version number of > >>>> > >>>> initial CER/CEA exchange to determine whether a peer is capable of > >>>> renegotiating. If a node knows that its peer is not capable of > >>>> re-negotiating then the node should not initiate re-negotiation. In > >>>> > >>> this > >>> > >>>> scheme, existing implementations will be spared of any change. > >>>> > >>> I'm not sure I picked up the version number. I don't see a reason to > >>> do > >>> > >>> something special. I would simply like to renegotiate. If the other > >>> side does not respond to the CER, you shut down the connection and > >>> restart it > >>> > >>> after some period of time. This is what you would do if your initial > >>> CER did not get a response. How is this different? > >>> > >>> > >>> Best Regards, > >>> Timothy Smith > >>> > >>> Vishnu wrote: > >>> > >>>> Hi, > >>>> > >>>> Some clarifications and comments on the discussion on this thread: > >>>> > >>>> We would like to clarify the following practical scenarios of this > >>>> happenning: > >>>> 1. there are a list of published applications which the box support > >>>> and these are installed in the box. Now, some of them go down/up. > >>>> This would get translated into change in peer capabilities. > >>>> 2. there is a new application which is getting installed/removed > >>>> > >> from > >> > >>>> the box. > >>>> > >>>> We think that (1) is the most probable scenario. so, > >>>> there is value in giving a simple solution assuming that this change > >>>> > >>> (in > >>> > >>>> capabilities) > >>>> is most probably temporary. If this is not the case, we are talking > >>>> about (2), which is a major change in the box anyways. So in (2), we > >>>> > >>>> assume it is ok to assume that > >>>> the connections to be reestablished. > >>>> > >>>> We would like to say that our design goals are: > >>>> 3. solution should be simple & as backward compatible as possible. > >>>> 4. minimize the FSM changes. > >>>> > >>>> We suggest: > >>>> 5. Updating peer capabilities done only using a CER/CEA in the open > >>>> state. Sender of CER/CEA updates the local capabilities before > >>>> sending the message and > >>>> hence is a local decision. > >>>> > >>>> 6. The rest of the processing of the CER/CEA will be as per the > >>>> > >>> current > >>> > >>>> RFC. > >>>> Say for example, if there are no > >>>> common applications left with that peer, > >>>> > >>> DIAMETER_NO_COMMON_APPLICATION > >>> > >>>> is sent in the > >>>> CEA and the connection is closed. > >>>> > >>>> Problems in the email thread under discussion & some comments: 7. > >>>> Cross over and sequencing of CER/CEA exchange. We dont think there > >>>> > >>> is > >>> > >>>> a problem > >>>> here. Cant find any race condition. > >>>> > >>>> 8. Mutual agreement to bring down applications will not work due to > >>>> possible relays in between as Tolga has pointed out in the mailing > >>>> list. > >>>> > >>>> 9. The DPR solution in the suggested text is not a good idea. > >>>> Because DPR cannot advertise the latest local applications to the > >>>> peer. This may cause > >>>> > >>> the > >>> > >>>> race condition > >>>> and sequencing problem. This problem can be avoided by using the > >>>> approach which we suggested in (5). > >>>> > >>>> Regards, > >>>> Vishnu. > >>>> > >>> tjsmith@us.ibm.com > >>> (919) 254-4723 > >>> > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/dime > >>> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 05 12:01:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHVq-0004e1-ED; Mon, 05 Jun 2006 12:01:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHVo-0004bh-Th for dime@ietf.org; Mon, 05 Jun 2006 12:01:04 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnHVo-0006H5-4T for dime@ietf.org; Mon, 05 Jun 2006 12:01:04 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k55G0wKM003094; Mon, 5 Jun 2006 12:00:59 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44845541.9080207@tari.toshiba.com> Date: Mon, 05 Jun 2006 12:01:05 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] CER/CEA on an open connection References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 713965ef965c5660ee5d9a664a73ef4a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, > Hi Victor, > > The race condition presented is probably very unlikely but probably is still > something to consider. Actually after thinking a bit more, I think the > approach presented in the text is architecturally more clean as well, there > is a full negotiation transaction and based on the result of it some action > is taken. > I agree. best regards, victor > Thanks, > Tolga > > >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: Monday, June 05, 2006 8:40 AM >> To: Tolga Asveren >> Cc: dime@ietf.org >> Subject: Re: [Dime] CER/CEA on an open connection >> >> >> Hi Tolga, >> >>> Vishnu, >>> >>> I think this text proposal is fine. >>> >>> One comment/questions: >>> What about the case, where shutdown of application causes the >>> >> overlapping >> >>> application set between the peers to be empty? AFAICS, the procedure >>> described below will still work. Peer-1 will send CER, will >>> >> receive CEA("No >> >>> Common Application") and will tear down the transport connection. That >>> Peer-A (or Peer-B) drops the transport connection immediately would work >>> too. Do we want explicitly restrict the second approach? >>> >>> >> I remember that Ram mentioned a race condition regarding the second >> approach: >> >> 2. Comments on "re-negotiation" >> We think that what we need is an advertisement mechanism and not a >> negotiation mechanism. The CER/CEA in open state allows us to do that. >> We are proposing that the receiver of the CER takes the decision on the >> disconnection. Thus we are able to delay the disconnection (assuming >> that the point mentioned in my email before that the app changes are >> temporary). >> Since CER allows us to convey the latest set of supported apps to the >> peer, we favour the CER to the DPR. >> >> Following is a scenario where sending CER/CEA is better than the DPR >> mechanism. >> (Apologies if the figure is mangled due to tab settings). >> >> Initial exchanged app list: >> A: 1,2,3 B:2 >> 2 went down 3 came up just when 2 went down on A >> ________ ________ >> |A |----DPR---> |B | >> | | | | >> | |<---CER---- | | >> |______| [3] |______| >> <---DPA---- >> >> this in our understanding will result in reconnection even thou there >> is 3 in common. >> >> Initial exchanged app list: >> A: 1,2,3 B:2 >> 2 went down 3 came up just when 2 went down on A >> ________ ________ >> |A |----CER---> |B | >> | | [1,3] | | >> | |<---CER---- | | >> |_______| [2,3] |_______| >> ----CEA----> >> [1,3] >> <---CEA----- >> [2,3] >> This will avoid a reconnection, because 3 is in common. >> >> >>> And one more minor question: >>> - What do you mean with "gracefully disconnect its current >>> >> connection", or >> >>> better said why not "disconnect its current connection"? >>> >>> >> that works too. >> >> best regards, >> victor >> >> >>> Thanks, >>> Tolga >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] >>>> Sent: Monday, June 05, 2006 3:40 AM >>>> To: john.loughney@nokia.com >>>> Cc: dime@ietf.org >>>> Subject: RE: [Dime] CER/CEA on an open connection >>>> >>>> >>>> All, >>>> >>>> Below is the proposed text for peer capabilities update in >>>> >> Base Diameter >> >>>> (as discussed in this email list earlier). >>>> >>>> John, Please advice us on the process for text proposals to *-biz >>>> versions. >>>> >>>> Regards, >>>> Vishnu. >>>> >>>> ------------------------------------------------------------ >>>> 5.3.8 Peer Capabilities Update >>>> >>>> Among the capabilities exchanged during Diameter connection >>>> initialization, list of supported applications by the node can change >>>> dynamically. Applications can be restarted for various reasons >>>> >> including >> >>>> maintenance and upgrades. >>>> >>>> A Diameter node MUST initiate peer capabilities update by sending a >>>> Capabilities-Exchange-Req (CER) to all its peers which supports peer >>>> capabilities update and are in open state. Diameter nodes that >>>> >> implement >> >>>> peer capabilities update SHOULD check the version information >>>> >> advertised >> >>>> by its peer in the Diameter header of the previous CER/CEA exchange to >>>> determine if the peer supports peer capabilities update. The Diameter >>>> node MUST NOT send peer capabilities update to the peer if it >>>> >> determines >> >>>> that the peer has no support for such scheme, instead it SHOULD >>>> gracefully disconnect its current connection and attempt to establish a >>>> new connection towards that peer. In either case, the Diameter node is >>>> expected to advertise the most recent set of supported >>>> >> applications in a >> >>>> CER message, as specified by the peer state machine (see Section 5.6) >>>> while it is in the open state. >>>> >>>> The receiver of CER in open state MUST process and reply to >>>> >> the CER as a >> >>>> described in Section 5.3. The CEA which the receiver sends MUST contain >>>> its latest capabilities. Note that peers which successfully process the >>>> peer capabilities update SHOULD also update their routing tables to >>>> reflect the change. The receiver of the CEA, with a Result-Code AVP >>>> other than DIAMETER_SUCCESS, initiates the transport disconnect. Peer >>>> capabilities update in the open state SHOULD be limited to the >>>> advertisement of the new list of supported applications and MUST >>>> preclude re-negotiation of security mechanism or other parameters. >>>> ------------------------------------------------------------ >>>> >>>> Regards, >>>> Vishnu. >>>> >>>> Motorola India Electronics Pvt Ltd >>>> +91 9844178052 >>>> [*] Motorola Internal Use Only >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >>>> Sent: Monday, April 10, 2006 8:13 PM >>>> To: Tolga Asveren >>>> Cc: dime@ietf.org >>>> Subject: Re: [Dime] CER/CEA on an open connection >>>> >>>> >>>> Hi All, >>>> >>>> >>>> >>>>> I believe in general now we all have a good understanding about what >>>>> the issues are for renegotiation. It could be an idea to have a new >>>>> iteration of the proposed text, and to continue the discussions on the >>>>> >>>>> new version. >>>>> >>>>> >>>>> >>>> To that end, I'll plan on generating a new set of text maybe next week >>>> as we let people digest and hopefully comment on the latest round of >>>> discussion for the next couple of days. >>>> >>>> best regards, >>>> victor >>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> I believe in general now we all have a good understanding >>>> >> about what the >> >>>> issues are for renegotiation. It could be an idea to have a new >>>> iteration of the proposed text, and to continue the discussions on the >>>> new version. >>>> >>>> A few more comments/questions below. >>>> >>>> Thanks, >>>> Tolga >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] >>>>> Sent: Monday, April 10, 2006 2:38 AM >>>>> To: dime@ietf.org >>>>> Cc: Nakhjiri Madjid-MNAKHJI1 >>>>> Subject: RE: [Dime] CER/CEA on an open connection >>>>> >>>>> >>>>> Hi Victor/Timothy, >>>>> >>>>> 1. Comments on Retry mechanism : >>>>> To summarize, we are sending CER in open state because our >>>>> capabilities (supported apps) are changing and we would like to update >>>>> >>>>> the peer about it. We will maintain open state. >>>>> >>>>> we may not receive a CEA due to the following possible reasons: >>>>> 1.1) The peer does not support CER in open state. In such a case, peer >>>>> >>>>> might still originate unsupported app messages towards us which will >>>>> result in "DIAMETER_APPLICATION_UNSUPPORTED" error from us. We can >>>>> leave it to the peer implementation to "correct this error" as >>>>> mentioned in sec 7.1.3 of RFC 3588. This will take care of the case >>>>> where there is relay/proxy in between. >>>>> 1.2) Connection is lost with the peer, in which case the DWR/DWA >>>>> mechanism should step in. >>>>> >>>>> The solution suggested by Timothy (to wait for for CEA & timer) will >>>>> need changes to FSM, even though we agree that this is consistent with >>>>> >>>>> the initial CER/CEA scenario. >>>>> >>>>> Ofcourse the use of "DIAMETER_APPLICATION_UNSUPPORTED" will result in >>>>> added (unecessary traffic) incase the peer/proxy is not clever enough >>>>> to correct its behaviour. This can be avoided by using the version >>>>> number exchange as Victor pointed out. So, we will not attempt the CER >>>>> >>>>> in open state to such a peer which doesnt support CERs in open state, >>>>> and can go for a reconnection. >>>>> >>>>> >>>> [TOLGA]The problem case of a node not being clever enough to >>>> >> take action >> >>>> based on "DIAMETER_APPLICATION_UNSUPPORTED" is not limited to >>>> renegotiations. This could happen in existing systems developed >>>> according to RFC3588 as well. I would expect a node, whose >>>> DIAMETER_APPLICATION_UNSUPPORTED replies are not honored by >>>> >> its neighbor >> >>>> to drop the connection, but as said this is not limited to >>>> >> renegotiation >> >>>> case. For cases, where the neighbor does not support >>>> >> renegotiation, what >> >>>> would be the result code in CEA? DIAMETER_UNABLE_TO_COMPLY? We can say >>>> that such a result code in CEA should indicate that the neighbor does >>>> not support renegotiations and sender of CER should/may >>>> >> drop/reestablish >> >>>> the connection. Please note that with a properly behaving neighbor, >>>> dropping connection is probably not necessary because the first >>>> DIAMETER_APPLICATION_UNSUPPORTED should update its tables properly. I >>>> don't know whether we need to standardize how a node determines whether >>>> a neighbor honors DIAMETER_APPLICATION_UNSUPPORTED result code. >>>> >>>> >>>>> 2. Comments on "re-negotiation" >>>>> We think that what we need is an advertisement mechanism and not a >>>>> negotiation mechanism. The CER/CEA in open state allows us to do that. >>>>> >>>>> We are proposing that the receiver of the CER takes the decision on >>>>> the disconnection. Thus we are able to delay the disconnection >>>>> (assuming that the point mentioned in my email before that the app >>>>> changes are temporary). Since CER allows us to convey the latest set >>>>> of supported apps to the peer, we favour the CER to the DPR. >>>>> >>>>> Following is a scenario where sending CER/CEA is better than the DPR >>>>> mechanism. (Apologies if the figure is mangled due to tab settings). >>>>> >>>>> >>>> [TOLGA]Although the example case below is a race condition which >>>> probably won't happen very often -it relies on changing supported >>>> application set on two nodes more or less simultaneously-, I >>>> >> also prefer >> >>>> relying on CER in such a situation, so that there is a single way of >>>> handling renegotiations in terms of advertising changes to the >>>> neighbors. >>>> >>>> >>>>> Initial exchanged app list: >>>>> A: 1,2,3 B:2 >>>>> 2 went down 3 came up just when 2 went down on A >>>>> ________ ________ >>>>> |A |----DPR---> |B | >>>>> | | | | >>>>> | |<---CER---- | | >>>>> |______| [3] |______| >>>>> <---DPA---- >>>>> >>>>> this in our understanding will result in reconnection even thou there >>>>> is 3 in common. >>>>> >>>>> Initial exchanged app list: >>>>> A: 1,2,3 B:2 >>>>> 2 went down 3 came up just when 2 went down on A >>>>> ________ ________ >>>>> |A |----CER---> |B | >>>>> | | [1,3] | | >>>>> | |<---CER---- | | >>>>> |_______| [2,3] |_______| >>>>> ----CEA----> >>>>> [1,3] >>>>> <---CEA----- >>>>> [2,3] >>>>> This will avoid a reconnection, because 3 is in common. >>>>> >>>>> Regards, >>>>> Vishnu. >>>>> >>>>> Motorola India Electronics Pvt Ltd >>>>> +91 9844178052 >>>>> [*] Motorola Internal Use Only >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Timothy Smith [mailto:tjsmith@us.ibm.com] >>>>> Sent: Monday, April 10, 2006 7:11 AM >>>>> To: Victor Fajardo >>>>> Cc: dime@ietf.org; Nakhjiri Madjid-MNAKHJI1; Ram O V Vishnu-A14676 >>>>> Subject: Re: [Dime] CER/CEA on an open connection >>>>> >>>>> >>>>> >>>>> Hi Victor, >>>>> >>>>> Thanks for your response. Comments below" >>>>> >>>>> >>>>>>> Good summary! I agree with most of your points. I'm not sure, >>>>>>> however, that I distinguish between (1) and (2). I think whether >>>>>>> temporary or not, we should handle CER/CEA exchanges in the same >>>>>>> >>>>>>> >>>>> manner. >>>>> >>>>> >>>>>> I'm just speculating but I think (2) refers to application change >>>>>> requiring a reboot. >>>>>> >>>>>> >>>>>>> I agree with your design goals (3) ,(4), and suggestions (5) , (6) >>>>>>> , (8), and (9). >>>>>>> >>>>>>> >>>>>> If some are more in favor of scheme (5) , maybe we need more opinion >>>>>> >>>>>> >>>>> on >>>>> >>>>> >>>>>> whether the receiver of the CEA can always comply with the change >>>>>> request regardless of any scenario. I think (6) and (9) can be >>>>>> avoided regardless of which scheme we decide to use (see my previous >>>>>> reply). >>>>>> >>>>>> >>>>>> >>>>> Here is the text from your previous reply: >>>>> "This certainly simplifies things but it also implies that the sender >>>>> of >>>>> >>>>> the CER mandates a change and the receiver has no choice but to accept >>>>> >>>>> it. In some sense, the scheme is no longer a re-negotiation but merely >>>>> >>>>> notifying the peer of a change. The proposed text was considering the >>>>> case where the receiver of the CER cannot comply with the change for >>>>> whatever reason." >>>>> >>>>> I tend to agree with the notion that the sender of the CER is >>>>> mandating a change. The receiver does have a choice just as it has a >>>>> choice in the original CER/CEA exchange. The receiver should respond >>>>> with the list of >>>>> >>>>> App Ids that is the intersection of what was listed in the CER and of >>>>> what App Ids it wishes to support. It is a renegotiation which may >>>>> add or remove App Ids. But either way, it is telling the other side >>>>> about its intentions. I don't thing the receiving side has any choice >>>>> >>>>> but to participate >>>>> in the renegotiation. For example, if an app Id is being removed, the >>>>> side >>>>> where it is being removed renegotiates with a CER that does not >>>>> >>>>> >>>> include >>>> >>>> >>>>> that >>>>> App ID. It doesn't do the receiving side any good to decline this as >>>>> the App >>>>> will be shut down regardless. >>>>> >>>>> >>>>> >>>>> >>>>>>> Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont >>>>>>> think there is a problem here. Cant find any race condition." I >>>>>>> thought that there was a subtle problem here, but I think you are >>>>>>> right. Given that the connection insures sequencing, the latest >>>>>>> CER or CEA that you receive is what you should use as the list of >>>>>>> negotiated App Ids. >>>>>>> >>>>>>> >>>>>>> >>>>>> Mmmm... i'm not sure that the connection itself ensures sequencing. >>>>>> Anyway, majority rule favors removing this text. >>>>>> >>>>>> >>>>>>> Should there be some discussion on the retry mechanism? You send a >>>>>>> >>>>>>> CER, and no response is received. Does this mean that the peer >>>>>>> just doesn't know how to renegotiate? Should we ignore and retry >>>>>>> every n seconds? Bring down the connection? Or do we just >>>>>>> continue to use the apps from the initial negotiation? My >>>>>>> preference on this is that we should require a CEA response to the >>>>>>> CER. If the CEA is not received, we shutdown the connection and >>>>>>> start over. This would address compatibility issues with existing >>>>>>> implementations. It would >>>>>>> >>>>>>> also be consistent with the processing of the initial CER/CEA. >>>>>>> >>>>>>> >>>>>>> >>>>>> The current proposal has text mentioning the use of version number of >>>>>> >>>>>> initial CER/CEA exchange to determine whether a peer is capable of >>>>>> renegotiating. If a node knows that its peer is not capable of >>>>>> re-negotiating then the node should not initiate re-negotiation. In >>>>>> >>>>>> >>>>> this >>>>> >>>>> >>>>>> scheme, existing implementations will be spared of any change. >>>>>> >>>>>> >>>>> I'm not sure I picked up the version number. I don't see a reason to >>>>> do >>>>> >>>>> something special. I would simply like to renegotiate. If the other >>>>> side does not respond to the CER, you shut down the connection and >>>>> restart it >>>>> >>>>> after some period of time. This is what you would do if your initial >>>>> CER did not get a response. How is this different? >>>>> >>>>> >>>>> Best Regards, >>>>> Timothy Smith >>>>> >>>>> Vishnu wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> Some clarifications and comments on the discussion on this thread: >>>>>> >>>>>> We would like to clarify the following practical scenarios of this >>>>>> happenning: >>>>>> 1. there are a list of published applications which the box support >>>>>> and these are installed in the box. Now, some of them go down/up. >>>>>> This would get translated into change in peer capabilities. >>>>>> 2. there is a new application which is getting installed/removed >>>>>> >>>>>> >>>> from >>>> >>>> >>>>>> the box. >>>>>> >>>>>> We think that (1) is the most probable scenario. so, >>>>>> there is value in giving a simple solution assuming that this change >>>>>> >>>>>> >>>>> (in >>>>> >>>>> >>>>>> capabilities) >>>>>> is most probably temporary. If this is not the case, we are talking >>>>>> about (2), which is a major change in the box anyways. So in (2), we >>>>>> >>>>>> assume it is ok to assume that >>>>>> the connections to be reestablished. >>>>>> >>>>>> We would like to say that our design goals are: >>>>>> 3. solution should be simple & as backward compatible as possible. >>>>>> 4. minimize the FSM changes. >>>>>> >>>>>> We suggest: >>>>>> 5. Updating peer capabilities done only using a CER/CEA in the open >>>>>> state. Sender of CER/CEA updates the local capabilities before >>>>>> sending the message and >>>>>> hence is a local decision. >>>>>> >>>>>> 6. The rest of the processing of the CER/CEA will be as per the >>>>>> >>>>>> >>>>> current >>>>> >>>>> >>>>>> RFC. >>>>>> Say for example, if there are no >>>>>> common applications left with that peer, >>>>>> >>>>>> >>>>> DIAMETER_NO_COMMON_APPLICATION >>>>> >>>>> >>>>>> is sent in the >>>>>> CEA and the connection is closed. >>>>>> >>>>>> Problems in the email thread under discussion & some comments: 7. >>>>>> Cross over and sequencing of CER/CEA exchange. We dont think there >>>>>> >>>>>> >>>>> is >>>>> >>>>> >>>>>> a problem >>>>>> here. Cant find any race condition. >>>>>> >>>>>> 8. Mutual agreement to bring down applications will not work due to >>>>>> possible relays in between as Tolga has pointed out in the mailing >>>>>> list. >>>>>> >>>>>> 9. The DPR solution in the suggested text is not a good idea. >>>>>> Because DPR cannot advertise the latest local applications to the >>>>>> peer. This may cause >>>>>> >>>>>> >>>>> the >>>>> >>>>> >>>>>> race condition >>>>>> and sequencing problem. This problem can be avoided by using the >>>>>> approach which we suggested in (5). >>>>>> >>>>>> Regards, >>>>>> Vishnu. >>>>>> >>>>>> >>>>> tjsmith@us.ibm.com >>>>> (919) 254-4723 >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>> >>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> >>> >>> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 06 05:49:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnYCB-0008B8-5M; Tue, 06 Jun 2006 05:49:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnYCA-0008B1-4w for dime@ietf.org; Tue, 06 Jun 2006 05:49:54 -0400 Received: from web38201.mail.mud.yahoo.com ([209.191.124.144]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FnYC6-0002Br-Ih for dime@ietf.org; Tue, 06 Jun 2006 05:49:54 -0400 Received: (qmail 99471 invoked by uid 60001); 6 Jun 2006 09:49:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WIALx6MVbaOcAASTNcMC111tUhmstd+KmUGDhF1MUBHYyQmhkGrPjmsvC9Kkcx4VCnApDANR82s4WC0vKOB1vBESl8bTYK+mHevvpKm88cwR38xC/r5lVqD+5EjaMbDq6RS4YKb0QaU+yEmw+P2gYFZyjYW3fP6MclrwAHn85YU= ; Message-ID: <20060606094949.99469.qmail@web38201.mail.mud.yahoo.com> Received: from [193.49.124.107] by web38201.mail.mud.yahoo.com via HTTP; Tue, 06 Jun 2006 11:49:49 CEST Date: Tue, 6 Jun 2006 11:49:49 +0200 (CEST) From: "#:-\) seb" To: dime@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Dime] Grouped AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hello, I want to know if it's possible to send an AVP which is a member of a Grouped AVP without this last? thanks ___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 06 09:43:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnbqJ-0001wr-I6; Tue, 06 Jun 2006 09:43:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnbqJ-0001wm-12 for dime@ietf.org; Tue, 06 Jun 2006 09:43:35 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnbqH-0001k1-IG for dime@ietf.org; Tue, 06 Jun 2006 09:43:35 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k56DhUEq020980; Tue, 6 Jun 2006 16:43:32 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 16:43:32 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 16:43:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 16:43:31 +0300 Message-ID: In-Reply-To: <20060606115124.67961.qmail@web55413.mail.re4.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: AAA Performance evaluation Thread-Index: AcaJYAzB7Zy/7iXJQxaxE1bqzA4DTgADxzVw From: To: X-OriginalArrivalTime: 06 Jun 2006 13:43:31.0482 (UTC) FILETIME=[32E40FA0:01C6896F] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: johnmagson@yahoo.com Subject: [Dime] RE: [AAA-WG]: AAA Performance evaluation X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1378018371==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1378018371== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6896F.32D8492D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6896F.32D8492D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Has anyone done any studies about this? =20 John ________________________________ From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf = Of ext John Magson Sent: 06 June, 2006 14:51 To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA Performance evaluation =09 =09 Hi=20 =20 What are the performance evaluation techniques suitable for AAA = Protocols? =20 Mostly AAA is coupled with mobility or key mnageent techniques for any = form of performance evaluation. is there any specific = techniques/mechanism anyone has performed any performance evalutaion and = comparison of AAA protocols.=20 =20 Thank you in advance. =20 John=20 =09 ________________________________ Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great = rates starting at 1=A2/min. = =20 ------_=_NextPart_001_01C6896F.32D8492D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Has anyone done any studies about = this?
 
John

From: owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu] On Behalf Of ext John=20 Magson
Sent: 06 June, 2006 14:51
To:=20 aaa-wg@merit.edu
Subject: [AAA-WG]: AAA Performance=20 evaluation

Hi
 
What are the performance evaluation techniques suitable for AAA=20 Protocols?
 
Mostly AAA is coupled with mobility or key mnageent = techniques for=20 any form of performance evaluation. is there any specific = techniques/mechanism=20 anyone has performed any performance evalutaion and comparison of AAA=20 protocols.
 
Thank you in advance.
 
John

Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great=20 rates starting at 1=A2/min. ------_=_NextPart_001_01C6896F.32D8492D-- --===============1378018371== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1378018371==-- From dime-bounces@ietf.org Tue Jun 06 11:16:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FndHw-0002iT-2z; Tue, 06 Jun 2006 11:16:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FndHv-0002iO-2f for dime@ietf.org; Tue, 06 Jun 2006 11:16:11 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FndHs-0004me-PU for dime@ietf.org; Tue, 06 Jun 2006 11:16:11 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 06 Jun 2006 08:16:07 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208"; a="324312991:sNHT4903414204" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k56FG5g9021971; Tue, 6 Jun 2006 08:16:06 -0700 Received: from [161.44.55.58] (dhcp-161-44-55-58.cisco.com [161.44.55.58]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k56FG5Is022739; Tue, 6 Jun 2006 11:16:05 -0400 (EDT) Message-ID: <44859C35.7050401@cisco.com> Date: Tue, 06 Jun 2006 11:16:05 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "#:-) seb" Subject: Re: [Dime] Grouped AVPs References: <20060606094949.99469.qmail@web38201.mail.mud.yahoo.com> In-Reply-To: <20060606094949.99469.qmail@web38201.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: a=rsa-sha1; q=dns; l=722; t=1149606966; x=1150470966; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andersk@cisco.com; z=From:Anders=20Kristensen=20 |Subject:Re=3A=20[Dime]=20Grouped=20AVPs; X=v=3Dcisco.com=3B=20h=3Dyer4pDbd/i5ESKpqKLY2dSBadv8=3D; b=tDOeMIwShHSQdUjEBNLVljrwSlPy5ikXhGQ8h52dld1DKJJz97MMkQOjJ3TwCdR3adN6sQHS fG0fgDfHEepMvdEjm1b/9Qd+U343beHyYOOCRi7tVRghk7tljcbL0SOk; Authentication-Results: sj-dkim-4.cisco.com; header.From=andersk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org When you define an AVP you don't designate it to be just part of another grouped AVP so yes it's possible to include such an AVP in a message or a different grouped AVP. Anders #:-) seb wrote: > Hello, > > I want to know if it's possible to send an AVP which > is a member of a Grouped AVP without this last? > > thanks > > > > > > > ___________________________________________________________________________ > Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. > http://fr.mail.yahoo.com > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 06 23:53:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnp75-00086A-D2; Tue, 06 Jun 2006 23:53:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnp74-000865-LO for dime@ietf.org; Tue, 06 Jun 2006 23:53:46 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnp73-0008Iw-1B for dime@ietf.org; Tue, 06 Jun 2006 23:53:46 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0H00E1A20PN0@szxga02-in.huawei.com> for dime@ietf.org; Wed, 07 Jun 2006 12:05:13 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0H00BPU20P6U@szxga02-in.huawei.com> for dime@ietf.org; Wed, 07 Jun 2006 12:05:13 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0H002JV1CKJS@szxml03-in.huawei.com> for dime@ietf.org; Wed, 07 Jun 2006 11:50:44 +0800 (CST) Date: Wed, 07 Jun 2006 11:49:38 +0800 From: zhangtao To: dime@ietf.org Message-id: <006601c689e5$66af7a10$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: jo.hermans@gmail.com Subject: [Dime] Fw: [AAA-WG]: why is Digest-Nextnonce mandatory ? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org ----- Original Message ----- From: "Jo Hermans" To: Cc: ; ; ; ; ; Sent: Tuesday, June 06, 2006 10:42 PM Subject: [AAA-WG]: why is Digest-Nextnonce mandatory ? > I have a problem with the Digest-Nextnonce parameter in the > Sip-Authentication-Info attribute in the MAA, which becomes the > AuthenticationInfo header in the 200 OK of SIP. We've recently seen an > issue with Nokia terminals that are insisting that this is a mandatory > parameter (according to draft-ietf-aaa-diameter-sip-app-12.txt, but > originating from RFC2617 section 3.2.3). Our code is more based on > draft-ietf-radext-digest-auth-09.txt, where it is optional. > > I agree that those Nokia terminals are according to the spec, but I > have to deal with our HSS that does not want to send back a nextnonce, > mostly out of fear of the remark in RFC2617 section 3.2.2 (about > problems in pipelining requests). At the same time, those people > insist on having mutual authentication between client and server, so > we need to Authentication-Info header in the 200 OK. Because the > nextnonce is mandatory, we can't send that header at all. I'm stuck > between a rock and a hard place at the moment. I now have to make the > decision to either remove the entire header (removing mutual > authentication), or adding a dummy nextnonce (which will cause a 401 > later on). > > I want to know if there's a reason why the nextnonce is mandatory in > the spec. Is it only RFC2617 ? As far as I can see (changes from > RFC2069), it looks like a typo to me, and it should be optional. If it > was really mandatory, the next paragraph would have been changed too > ("if the nextnonce field is present ..."). And you still have the > problem with the pipelining (we've already encountered them, for > instance in a phone that send 2 INVITE's in parallel, in order to set > up a conference). > > I know it's very late, and Last-Call of > draft-ietf-aaa-diameter-sip-app is already past. But INHO, > Digest-Nextnonce should be an optional parameter, so that > Authentication-Info can be used for mutual authentication, without a > Next-Nonce. RFC2617 is probably incorrect, and conflicts with RFC3261 > anyway. What's your opinion ? > > The issue has been mentioned in : > - http://www1.ietf.org/mail-archive/web/sipping/current/msg08387.html > (no response) > - http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue45 > (rejected by Miguel, but he answered me that it's possibly wrong) > > -- > Jo Hermans > > "Eagles may soar, but weasels aren't sucked into jet engines" > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 06 23:56:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnp9T-0002TS-Oc; Tue, 06 Jun 2006 23:56:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnp9S-0002P1-GE for dime@ietf.org; Tue, 06 Jun 2006 23:56:14 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnp9Q-00005V-Uv for dime@ietf.org; Tue, 06 Jun 2006 23:56:14 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0H00H681P6XH@szxga03-in.huawei.com> for dime@ietf.org; Wed, 07 Jun 2006 11:58:18 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0H00DG91P6HT@szxga03-in.huawei.com> for dime@ietf.org; Wed, 07 Jun 2006 11:58:18 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0H001P21C0ON@szxml03-in.huawei.com> for dime@ietf.org; Wed, 07 Jun 2006 11:50:25 +0800 (CST) Date: Wed, 07 Jun 2006 11:49:19 +0800 From: zhangtao To: dime@ietf.org Message-id: <005b01c689e5$5af35390$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: John Magson Subject: [Dime] Fw: [AAA-WG]: AAA Performance evaluation X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1415892955==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1415892955== Content-type: multipart/alternative; boundary="Boundary_(ID_2xXJPORBgY3F7Ab76RSgpg)" This is a multi-part message in MIME format. --Boundary_(ID_2xXJPORBgY3F7Ab76RSgpg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogSm9obiBNYWdzb24gDQpUbzog YWFhLXdnQG1lcml0LmVkdSANClNlbnQ6IFR1ZXNkYXksIEp1bmUgMDYsIDIwMDYgNzo1MSBQTQ0K U3ViamVjdDogW0FBQS1XR106IEFBQSBQZXJmb3JtYW5jZSBldmFsdWF0aW9uDQoNCg0KSGkgDQoN CldoYXQgYXJlIHRoZSBwZXJmb3JtYW5jZSBldmFsdWF0aW9uIHRlY2huaXF1ZXMgc3VpdGFibGUg Zm9yIEFBQSBQcm90b2NvbHM/DQoNCk1vc3RseSBBQUEgaXMgY291cGxlZCB3aXRoIG1vYmlsaXR5 IG9yIGtleSBtbmFnZWVudCB0ZWNobmlxdWVzIGZvciBhbnkgZm9ybSBvZiBwZXJmb3JtYW5jZSBl dmFsdWF0aW9uLiBpcyB0aGVyZSBhbnkgc3BlY2lmaWMgdGVjaG5pcXVlcy9tZWNoYW5pc20gYW55 b25lIGhhcyBwZXJmb3JtZWQgYW55IHBlcmZvcm1hbmNlIGV2YWx1dGFpb24gYW5kIGNvbXBhcmlz b24gb2YgQUFBIHByb3RvY29scy4gDQoNClRoYW5rIHlvdSBpbiBhZHZhbmNlLg0KDQpKb2huIA0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUYWxrIGlzIGNoZWFwLiBVc2UgWWFob28hIE1l c3NlbmdlciB0byBtYWtlIFBDLXRvLVBob25lIGNhbGxzLiBHcmVhdCByYXRlcyBzdGFydGluZyBh dCAxoi9taW4uIA== --Boundary_(ID_2xXJPORBgY3F7Ab76RSgpg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xNTQzIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVYgc3R5bGU9 IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t IA0KPERJViBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgZm9udC1jb2xvcjogYmxhY2siPjxC PkZyb206PC9CPiA8QSANCnRpdGxlPWpvaG5tYWdzb25AeWFob28uY29tIGhyZWY9Im1haWx0bzpq b2hubWFnc29uQHlhaG9vLmNvbSI+Sm9obiBNYWdzb248L0E+IA0KPC9ESVY+DQo8RElWPjxCPlRv OjwvQj4gPEEgdGl0bGU9YWFhLXdnQG1lcml0LmVkdSANCmhyZWY9Im1haWx0bzphYWEtd2dAbWVy aXQuZWR1Ij5hYWEtd2dAbWVyaXQuZWR1PC9BPiA8L0RJVj4NCjxESVY+PEI+U2VudDo8L0I+IFR1 ZXNkYXksIEp1bmUgMDYsIDIwMDYgNzo1MSBQTTwvRElWPg0KPERJVj48Qj5TdWJqZWN0OjwvQj4g W0FBQS1XR106IEFBQSBQZXJmb3JtYW5jZSBldmFsdWF0aW9uPC9ESVY+PC9ESVY+DQo8RElWPjxC Uj48L0RJVj4NCjxESVY+SGkgPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5XaGF0IGFy ZSB0aGUgcGVyZm9ybWFuY2UgZXZhbHVhdGlvbiB0ZWNobmlxdWVzIHN1aXRhYmxlIGZvciBBQUEg DQpQcm90b2NvbHM/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5Nb3N0bHkgQUFBIGlz IGNvdXBsZWQgd2l0aCBtb2JpbGl0eSBvciBrZXkgbW5hZ2VlbnQgdGVjaG5pcXVlcyZuYnNwO2Zv ciBhbnkgDQpmb3JtIG9mIHBlcmZvcm1hbmNlIGV2YWx1YXRpb24uIGlzIHRoZXJlIGFueSBzcGVj aWZpYyB0ZWNobmlxdWVzL21lY2hhbmlzbSANCmFueW9uZSBoYXMgcGVyZm9ybWVkIGFueSBwZXJm b3JtYW5jZSBldmFsdXRhaW9uIGFuZCBjb21wYXJpc29uIG9mIEFBQSBwcm90b2NvbHMuIA0KPC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5UaGFuayB5b3UgaW4gYWR2YW5jZS48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkpvaG4gPC9ESVY+DQo8UD4NCjxIUiBTSVpFPTE+DQpU YWxrIGlzIGNoZWFwLiBVc2UgWWFob28hIE1lc3NlbmdlciB0byBtYWtlIFBDLXRvLVBob25lIGNh bGxzLiA8QSANCmhyZWY9Imh0dHA6Ly91cy5yZC55YWhvby5jb20vbWFpbF91cy90YWdsaW5lcy9w b3N0bWFuNy8qaHR0cDovL3VzLnJkLnlhaG9vLmNvbS9ldnQ9Mzk2NjYvKmh0dHA6Ly9tZXNzZW5n ZXIueWFob28uY29tIj5HcmVhdCANCnJhdGVzIHN0YXJ0aW5nIGF0IDGiL21pbi4gPC9BPjwvQk9E WT48L0hUTUw+DQo= --Boundary_(ID_2xXJPORBgY3F7Ab76RSgpg)-- --===============1415892955== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1415892955==-- From dime-bounces@ietf.org Wed Jun 07 05:10:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnu3a-0005hS-BE; Wed, 07 Jun 2006 05:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnu3Z-0005hI-Cn for dime@ietf.org; Wed, 07 Jun 2006 05:10:29 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnu3W-0004mM-Q5 for dime@ietf.org; Wed, 07 Jun 2006 05:10:29 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0H00MDTGBQ7T@szxga03-in.huawei.com> for dime@ietf.org; Wed, 07 Jun 2006 17:14:15 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0H00JLTGBQBJ@szxga03-in.huawei.com> for dime@ietf.org; Wed, 07 Jun 2006 17:14:14 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0H00CI8GE46Y@szxml04-in.huawei.com> for dime@ietf.org; Wed, 07 Jun 2006 17:15:41 +0800 (CST) Date: Wed, 07 Jun 2006 17:05:14 +0800 From: zhangtao Subject: Re: [Dime] Fw: [AAA-WG]: AAA Performance evaluation To: dime@ietf.org Message-id: <006f01c68a11$7d5fdf30$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal References: <005b01c689e5$5af35390$3791460a@china.huawei.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: John Magson X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1591705817==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1591705817== Content-type: multipart/alternative; boundary="Boundary_(ID_ZZAxrCAe9nn5yFV7YOvJ9A)" This is a multi-part message in MIME format. --Boundary_(ID_ZZAxrCAe9nn5yFV7YOvJ9A) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGkgSm9objoNCiAgIEluIG15IHVuZGVyc3RhbmRpbmcsdGhlIEFBQSBQcm90b2NvbHMsYWxtb3N0 IGluY2x1ZGUgYmFzZSBwcm90b2NvbCBwYXJ0IGFuZCBhcHBsaWNhdGlvbiBwYXJ0Lg0Kd2hlbiBk byBwZXJmb3JtYW5jZSBldmFsdWF0aW9uLG9ubHkgZXZhbHVhdGlvbiBiYXNlIHByb3RvY29sIHBh cnQuDQogICBiYXNlIHByb3RvY29sIHBhcnQgb25seSBpbmxjdWRlIGJlbG93IGZ1bmNhdGlvbiBh Y3Rpdml0eToNCiAgIFJvdXRlLA0KICAgRW5jb2RlIGFuZCBkZWNvZGUsDQogICBTZW5kIGFuZCBy ZWNlaXZlIG1lc3NhZ2UuDQogICANCkFwcGxpY2F0aW9uIFBhcnQgd2lsbCBpbiBjaGFyZ2Ugb2Yg bW9iaWxpdHkgb3Iga2V5IG1hbmdlbWVudC4NCg0KQmVzdCBSZWdhcmRzLg0KIA0KLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogemhhbmd0YW8gDQogIFRvOiBkaW1lQGlldGYu b3JnIA0KICBDYzogSm9obiBNYWdzb24gDQogIFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAwNywgMjAw NiAxMTo0OSBBTQ0KICBTdWJqZWN0OiBbRGltZV0gRnc6IFtBQUEtV0ddOiBBQUEgUGVyZm9ybWFu Y2UgZXZhbHVhdGlvbg0KDQoNCg0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBG cm9tOiBKb2huIE1hZ3NvbiANCiAgVG86IGFhYS13Z0BtZXJpdC5lZHUgDQogIFNlbnQ6IFR1ZXNk YXksIEp1bmUgMDYsIDIwMDYgNzo1MSBQTQ0KICBTdWJqZWN0OiBbQUFBLVdHXTogQUFBIFBlcmZv cm1hbmNlIGV2YWx1YXRpb24NCg0KDQogIEhpIA0KDQogIFdoYXQgYXJlIHRoZSBwZXJmb3JtYW5j ZSBldmFsdWF0aW9uIHRlY2huaXF1ZXMgc3VpdGFibGUgZm9yIEFBQSBQcm90b2NvbHM/DQoNCiAg TW9zdGx5IEFBQSBpcyBjb3VwbGVkIHdpdGggbW9iaWxpdHkgb3Iga2V5IG1uYWdlZW50IHRlY2hu aXF1ZXMgZm9yIGFueSBmb3JtIG9mIHBlcmZvcm1hbmNlIGV2YWx1YXRpb24uIGlzIHRoZXJlIGFu eSBzcGVjaWZpYyB0ZWNobmlxdWVzL21lY2hhbmlzbSBhbnlvbmUgaGFzIHBlcmZvcm1lZCBhbnkg cGVyZm9ybWFuY2UgZXZhbHV0YWlvbiBhbmQgY29tcGFyaXNvbiBvZiBBQUEgcHJvdG9jb2xzLiAN Cg0KICBUaGFuayB5b3UgaW4gYWR2YW5jZS4NCg0KICBKb2huIA0KDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KICBUYWxrIGlzIGNoZWFwLiBVc2UgWWFob28hIE1lc3NlbmdlciB0byBtYWtlIFBD LXRvLVBob25lIGNhbGxzLiBHcmVhdCByYXRlcyBzdGFydGluZyBhdCAxoi9taW4uIA0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgRGlNRSBtYWlsaW5nIGxpc3QNCiAgRGlNRUBpZXRmLm9yZw0K ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo= --Boundary_(ID_ZZAxrCAe9nn5yFV7YOvJ9A) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xNTQzIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw Nzsgc2l6ZT0yPkhpIEpvaG46PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7 JiMyMDMwNzsgc2l6ZT0yPiZuYnNwOyZuYnNwOyBJbiBteSB1bmRlcnN0YW5kaW5nLHRoZSBBQUEg DQpQcm90b2NvbHMsYWxtb3N0IGluY2x1ZGUgYmFzZSBwcm90b2NvbCBwYXJ0IGFuZCBhcHBsaWNh dGlvbiBwYXJ0LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7 IHNpemU9Mj53aGVuIGRvIHBlcmZvcm1hbmNlIGV2YWx1YXRpb24sb25seSBldmFsdWF0aW9uIGJh c2UgDQpwcm90b2NvbCBwYXJ0LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1 OyYjMjAzMDc7IHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDtiYXNlIHByb3RvY29sIHBhcnQgb25s eSBpbmxjdWRlIA0KYmVsb3cgZnVuY2F0aW9uIGFjdGl2aXR5OjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj4mbmJzcDsmbmJzcDsgUm91dGUsPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPiZuYnNw OyZuYnNwOyBFbmNvZGUgYW5kIGRlY29kZSw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7IFNlbmQgYW5kIHJlY2VpdmUgbWVz c2FnZS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXpl PTI+Jm5ic3A7Jm5ic3A7IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYj MjAzMDc7IHNpemU9Mj5BcHBsaWNhdGlvbiBQYXJ0IHdpbGwgaW4gY2hhcmdlIG9mIG1vYmlsaXR5 IG9yIGtleSANCm1hbmdlbWVudC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQz NTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYj MjM0MzU7JiMyMDMwNzsgc2l6ZT0yPkJlc3QgUmVnYXJkcy48L0ZPTlQ+PC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KPEJM T0NLUVVPVEUgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsg TUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4t UklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDlw dCAmIzIzNDM1OyYjMjAzMDc7OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8 QSB0aXRsZT16aGFuZ3Rhb19od0BodWF3ZWkuY29tIA0KICBocmVmPSJtYWlsdG86emhhbmd0YW9f aHdAaHVhd2VpLmNvbSI+emhhbmd0YW88L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5 cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9CPiA8QSB0aXRsZT1kaW1lQGlldGYub3JnIA0K ICBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvQT4gPC9ESVY+DQog IDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5DYzo8L0I+IDxBIHRp dGxlPWpvaG5tYWdzb25AeWFob28uY29tIA0KICBocmVmPSJtYWlsdG86am9obm1hZ3NvbkB5YWhv by5jb20iPkpvaG4gTWFnc29uPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYj MjM0MzU7JiMyMDMwNzsiPjxCPlNlbnQ6PC9CPiBXZWRuZXNkYXksIEp1bmUgMDcsIDIwMDYgMTE6 NDkgQU08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxC PlN1YmplY3Q6PC9CPiBbRGltZV0gRnc6IFtBQUEtV0ddOiBBQUEgUGVyZm9ybWFuY2UgDQogIGV2 YWx1YXRpb248L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVY+Jm5ic3A7PC9ESVY+DQog IDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIA0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBmb250LWNv bG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IDxBIA0KICB0aXRsZT1qb2hubWFnc29uQHlhaG9vLmNv bSBocmVmPSJtYWlsdG86am9obm1hZ3NvbkB5YWhvby5jb20iPkpvaG4gTWFnc29uPC9BPiANCiAg PC9ESVY+DQogIDxESVY+PEI+VG86PC9CPiA8QSB0aXRsZT1hYWEtd2dAbWVyaXQuZWR1IA0KICBo cmVmPSJtYWlsdG86YWFhLXdnQG1lcml0LmVkdSI+YWFhLXdnQG1lcml0LmVkdTwvQT4gPC9ESVY+ DQogIDxESVY+PEI+U2VudDo8L0I+IFR1ZXNkYXksIEp1bmUgMDYsIDIwMDYgNzo1MSBQTTwvRElW Pg0KICA8RElWPjxCPlN1YmplY3Q6PC9CPiBbQUFBLVdHXTogQUFBIFBlcmZvcm1hbmNlIGV2YWx1 YXRpb248L0RJVj48L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVY+SGkgPC9ESVY+DQog IDxESVY+Jm5ic3A7PC9ESVY+DQogIDxESVY+V2hhdCBhcmUgdGhlIHBlcmZvcm1hbmNlIGV2YWx1 YXRpb24gdGVjaG5pcXVlcyBzdWl0YWJsZSBmb3IgQUFBIA0KICBQcm90b2NvbHM/PC9ESVY+DQog IDxESVY+Jm5ic3A7PC9ESVY+DQogIDxESVY+TW9zdGx5IEFBQSBpcyBjb3VwbGVkIHdpdGggbW9i aWxpdHkgb3Iga2V5IG1uYWdlZW50IHRlY2huaXF1ZXMmbmJzcDtmb3IgDQogIGFueSBmb3JtIG9m IHBlcmZvcm1hbmNlIGV2YWx1YXRpb24uIGlzIHRoZXJlIGFueSBzcGVjaWZpYyB0ZWNobmlxdWVz L21lY2hhbmlzbSANCiAgYW55b25lIGhhcyBwZXJmb3JtZWQgYW55IHBlcmZvcm1hbmNlIGV2YWx1 dGFpb24gYW5kIGNvbXBhcmlzb24gb2YgQUFBIA0KICBwcm90b2NvbHMuIDwvRElWPg0KICA8RElW PiZuYnNwOzwvRElWPg0KICA8RElWPlRoYW5rIHlvdSBpbiBhZHZhbmNlLjwvRElWPg0KICA8RElW PiZuYnNwOzwvRElWPg0KICA8RElWPkpvaG4gPC9ESVY+DQogIDxQPg0KICA8SFIgU0laRT0xPg0K ICBUYWxrIGlzIGNoZWFwLiBVc2UgWWFob28hIE1lc3NlbmdlciB0byBtYWtlIFBDLXRvLVBob25l IGNhbGxzLiA8QSANCiAgaHJlZj0iaHR0cDovL3VzLnJkLnlhaG9vLmNvbS9tYWlsX3VzL3RhZ2xp bmVzL3Bvc3RtYW43LypodHRwOi8vdXMucmQueWFob28uY29tL2V2dD0zOTY2Ni8qaHR0cDovL21l c3Nlbmdlci55YWhvby5jb20iPkdyZWF0IA0KICByYXRlcyBzdGFydGluZyBhdCAxoi9taW4uIDwv QT4NCiAgPFA+DQogIDxIUj4NCg0KICA8UD48L1A+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188QlI+RGlNRSBtYWlsaW5nIA0KICBsaXN0PEJSPkRpTUVAaWV0 Zi5vcmc8QlI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTxCUj48 L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_ZZAxrCAe9nn5yFV7YOvJ9A)-- --===============1591705817== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1591705817==-- From dime-bounces@ietf.org Wed Jun 07 05:52:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnui4-0001GY-A1; Wed, 07 Jun 2006 05:52:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnui3-0001EZ-7W for dime@ietf.org; Wed, 07 Jun 2006 05:52:19 -0400 Received: from grerelbas03.net.external.hp.com ([192.6.111.87] helo=grerelbas03.bastion.europe.hp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnuhx-0000zt-SL for dime@ietf.org; Wed, 07 Jun 2006 05:52:19 -0400 Received: from idaexg11.emea.cpqcorp.net (idaexg11.emea.cpqcorp.net [16.16.5.24]) by grerelbas03.bastion.europe.hp.com (Postfix) with ESMTP id D5B37341CC for ; Wed, 7 Jun 2006 11:52:12 +0200 (CEST) Received: from idaexc01.emea.cpqcorp.net ([16.16.5.56]) by idaexg11.emea.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 11:52:04 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 7 Jun 2006 11:50:29 +0200 Message-ID: <1AB048BB58C35849AD36CDE65F16C11002DB17AA@idaexc01.emea.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open Source (GPL) test tool available for Diameter Thread-Index: AcaKF88vN6sqcMZYRPybOeYIS6CzkA== From: "Jacques, Olivier \(OpenCall Test Infra\)" To: X-OriginalArrivalTime: 07 Jun 2006 09:52:04.0194 (UTC) FILETIME=[07D5D420:01C68A18] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Dime] Open Source (GPL) test tool available for Diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hello, I think that the members of the dime mailing-list will find this information useful. Seagull is a free, Open Source (GPL) multi-protocol traffic generator test=20 tool, sponsored by HP OpenCall Software as well as Atos Origin and the COMET consortium. Primary aimed at IMS protocols (and thus being the perfect complement to SIPp - http://sipp.sourceforge.net/), Seagull=20 is a powerful traffic generator for functional, load, endurance,=20 stress and performance tests for almost any kind of protocol. Seagull-1.3.0, which is the first public release, comes with the following protocols: - Diameter (base and Cx+Cc applications) over TCP or SCTP (IPv4 or IPv6), - XCAP over HTTP, - Radius, - any protocol over TCAP (Camel, Win, MAP, IS41, INAP - using HP OpenCall SS7) - A generic synchronization protocol. Seagull is very flexible, and adding new or proprietary Diameter applications,=20 commands or AVPs to Seagull is just a matter of editing an XML dictionary file. We hope that you will find it useful. Seagull's web site: http://gull.sourceforge.net/ Don't hesitate to contact me if you have any question. Olivier. -- HP OpenCall Software http://www.hp.com/go/opencall/ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 07 21:11:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo93n-0005Wn-Hi; Wed, 07 Jun 2006 21:11:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo93m-0005Wf-Os for dime@ietf.org; Wed, 07 Jun 2006 21:11:42 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo93k-0008LL-Fg for dime@ietf.org; Wed, 07 Jun 2006 21:11:42 -0400 Received: by py-out-1112.google.com with SMTP id s49so377682pyc for ; Wed, 07 Jun 2006 18:11:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=I5EDSediPtzs6op7iqWUQBuXHFeJ38ApFeq9BC3QehwJfXrXyyu4aAIEvaiky3zomIzIsT/lsEeFTuBhAon1kBGgyVmObU2Mlq8756fRvZOxny/2eDTLQXu55ryzedp6oownYfiNiSsC4xLK6aMWV0En3K0B4je1f/Yq6J5iE2c= Received: by 10.35.99.5 with SMTP id b5mr1585782pym; Wed, 07 Jun 2006 18:11:39 -0700 (PDT) Received: by 10.35.9.17 with HTTP; Wed, 7 Jun 2006 18:11:39 -0700 (PDT) Message-ID: <20be0ff80606071811g12258f6fha88f3282df3d5dfc@mail.gmail.com> Date: Wed, 7 Jun 2006 20:11:39 -0500 From: "Ivelin Ivanov" To: "Jacques, Olivier (OpenCall Test Infra)" Subject: Re: [Dime] Open Source (GPL) test tool available for Diameter In-Reply-To: <1AB048BB58C35849AD36CDE65F16C11002DB17AA@idaexc01.emea.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1AB048BB58C35849AD36CDE65F16C11002DB17AA@idaexc01.emea.cpqcorp.net> X-Google-Sender-Auth: ef64ce40f3532401 X-Spam-Score: 1.9 (+) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Congratulations to the Seagull team and its sponsors! An open source IMS testing tool can help ensure interoperability between vendors, which is critical to IMS adoption. sipp has proven a very valuable compliance and benchmarking tool; I am glad that Seagull continues the legacy. A few question regarding the Diameter plugin: From the documentation it does not become apparent whether Sh dictionary is currently implemented. Can you please clarify? Also, does the roadmap include a script to cover the interop use cases described in: http://www.ietf.org/internet-drafts/draft-fajardo-dime-interop-test-suite-00.txt Thank you, Ivelin On 6/7/06, Jacques, Olivier (OpenCall Test Infra) wrote: > Hello, > > I think that the members of the dime mailing-list will find this > information > useful. > > Seagull is a free, Open Source (GPL) multi-protocol traffic generator > test > tool, sponsored by HP OpenCall Software as well as Atos Origin and the > COMET consortium. Primary aimed at IMS protocols (and thus being the > perfect complement to SIPp - http://sipp.sourceforge.net/), Seagull > is a powerful traffic generator for functional, load, endurance, > stress and performance tests for almost any kind of protocol. > > Seagull-1.3.0, which is the first public release, comes with the > following protocols: > - Diameter (base and Cx+Cc applications) over TCP or SCTP (IPv4 or > IPv6), > - XCAP over HTTP, > - Radius, > - any protocol over TCAP (Camel, Win, MAP, IS41, INAP - using HP > OpenCall SS7) > - A generic synchronization protocol. > > Seagull is very flexible, and adding new or proprietary Diameter > applications, > commands or AVPs to Seagull is just a matter of editing an XML > dictionary file. > > We hope that you will find it useful. > > Seagull's web site: http://gull.sourceforge.net/ > > Don't hesitate to contact me if you have any question. > Olivier. > -- > HP OpenCall Software > http://www.hp.com/go/opencall/ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 08 03:45:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoFCY-0002KB-P1; Thu, 08 Jun 2006 03:45:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoFCX-0002K6-Nr for dime@ietf.org; Thu, 08 Jun 2006 03:45:09 -0400 Received: from grerelbas02.net.external.hp.com ([192.6.111.86] helo=grerelbas02.bastion.europe.hp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoFCS-00073l-6q for dime@ietf.org; Thu, 08 Jun 2006 03:45:09 -0400 Received: from IDAEXG12.emea.cpqcorp.net (idaexg12.emea.cpqcorp.net [16.16.5.39]) by grerelbas02.bastion.europe.hp.com (Postfix) with ESMTP id 6123C3407C; Thu, 8 Jun 2006 09:45:03 +0200 (CEST) Received: from idaexc01.emea.cpqcorp.net ([16.16.5.56]) by IDAEXG12.emea.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 09:45:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Open Source (GPL) test tool available for Diameter Date: Thu, 8 Jun 2006 09:43:25 +0200 Message-ID: <1AB048BB58C35849AD36CDE65F16C11002DB1BF3@idaexc01.emea.cpqcorp.net> In-Reply-To: <20be0ff80606071811g12258f6fha88f3282df3d5dfc@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Open Source (GPL) test tool available for Diameter Thread-Index: AcaKmLum4J/WqJd4QOKgCMjMx0AikQANIyAw From: "Jacques, Olivier \(OpenCall Test Infra\)" To: "Ivelin Ivanov" X-OriginalArrivalTime: 08 Jun 2006 07:45:02.0612 (UTC) FILETIME=[736E7540:01C68ACF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hello Ivelin, Thanks for the kudos. We also believe that easing IMS testing will greatly help the adoption. For your question, Sh dictionary is not implemented. But as you can see from the base + Cx dictionary (base_cx.xml file), adding Sh should be a matter of less than an hour work. http://svn.sourceforge.net/viewcvs.cgi/gull/seagull/trunk/src/exe-env/di ameter-env/config/base_cx.xml?view=3Dmarkup If someone wants to try, please send the dictionary to Seagull-users mailing list so that it can be integrated. In terms of scenarios, what we are doing with Seagull is to implement, for each dictionary, one server (first message in the scenario received) and one client scenario (first message in the scenario sent). This is to demo the dictionary and to ease the writing of the first custom scenario. We do not currently include any compliance or interoperability test suite. _but_, as it has been done with SIPp (http://sipp.sourceforge.net/wiki/index.php/Scenarios), Seagull's Wiki could be a good place for that. In any case, if someone wants to contribute a Diameter test suite for Seagull, we will be happy to include it. I also think that Seagull could be of great help in interop/plugtests events by emulating missing nodes or help reproducing interop issues. Olivier.=20 HP OpenCall Software > -----Original Message----- > From: ivelin.atanasoff.ivanov@gmail.com=20 > [mailto:ivelin.atanasoff.ivanov@gmail.com] On Behalf Of Ivelin Ivanov > Sent: jeudi 8 juin 2006 03:12 > To: Jacques, Olivier (OpenCall Test Infra) > Cc: dime@ietf.org > Subject: Re: [Dime] Open Source (GPL) test tool available for Diameter >=20 > Congratulations to the Seagull team and its sponsors! >=20 > An open source IMS testing tool can help ensure=20 > interoperability between vendors, which is critical to IMS=20 > adoption. sipp has proven a very valuable compliance and=20 > benchmarking tool; I am glad that Seagull continues the legacy. >=20 > A few question regarding the Diameter plugin: From the=20 > documentation it does not become apparent whether Sh=20 > dictionary is currently implemented. Can you please clarify?=20 > Also, does the roadmap include a script to cover the interop=20 > use cases described in: > http://www.ietf.org/internet-drafts/draft-fajardo-dime-interop > -test-suite-00.txt >=20 > Thank you, >=20 > Ivelin >=20 > On 6/7/06, Jacques, Olivier (OpenCall Test Infra)=20 > wrote: > > Hello, > > > > I think that the members of the dime mailing-list will find this=20 > > information useful. > > > > Seagull is a free, Open Source (GPL) multi-protocol traffic=20 > generator=20 > > test tool, sponsored by HP OpenCall Software as well as Atos Origin=20 > > and the COMET consortium. Primary aimed at IMS protocols (and thus=20 > > being the perfect complement to SIPp -=20 > http://sipp.sourceforge.net/),=20 > > Seagull is a powerful traffic generator for functional, load,=20 > > endurance, stress and performance tests for almost any kind of=20 > > protocol. > > > > Seagull-1.3.0, which is the first public release, comes with the=20 > > following protocols: > > - Diameter (base and Cx+Cc applications) over TCP or SCTP (IPv4 or=20 > > IPv6), > > - XCAP over HTTP, > > - Radius, > > - any protocol over TCAP (Camel, Win, MAP, IS41, INAP - using HP=20 > > OpenCall SS7) > > - A generic synchronization protocol. > > > > Seagull is very flexible, and adding new or proprietary Diameter=20 > > applications, commands or AVPs to Seagull is just a matter=20 > of editing=20 > > an XML dictionary file. > > > > We hope that you will find it useful. > > > > Seagull's web site: http://gull.sourceforge.net/ > > > > Don't hesitate to contact me if you have any question. > > Olivier. > > -- > > HP OpenCall Software > > http://www.hp.com/go/opencall/ > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 08 08:50:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoJxg-0001eF-DC; Thu, 08 Jun 2006 08:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoJxf-0001eA-R5 for dime@ietf.org; Thu, 08 Jun 2006 08:50:07 -0400 Received: from web38209.mail.mud.yahoo.com ([209.191.124.152]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FoJxe-0000zo-8h for dime@ietf.org; Thu, 08 Jun 2006 08:50:07 -0400 Received: (qmail 8505 invoked by uid 60001); 8 Jun 2006 12:50:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=26HNsqsnNdlfK3I/EEw6fWtByoUQuNNnEQuIYYV3HNU8xDqIJhW0eXKyvjoRuDXs2rJV7oxALdmjKeue3/HTXF5/OfB08OYRRGYRti/1Zg5u/HdppE+exnPnSfKUlGGTj7oDeubxH0+Q+Qat9ZiOLMlPP1mXeyessVoIKUeeINU= ; Message-ID: <20060608125005.8503.qmail@web38209.mail.mud.yahoo.com> Received: from [193.49.124.107] by web38209.mail.mud.yahoo.com via HTTP; Thu, 08 Jun 2006 14:50:05 CEST Date: Thu, 8 Jun 2006 14:50:05 +0200 (CEST) From: "#:-\) seb" To: dime@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Dime] diameter in IMS X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hello, I have a little question about Diameter in the Ip Multimedia Subsystem architecture (IMS). Why the creator of this architecture have decided to use the Diameter protocol and not an other as radius ? What's the main purpose ? best regards __________________________________________________ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités http://mail.yahoo.fr Yahoo! Mail _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 08 08:59:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoK6v-0007IR-1k; Thu, 08 Jun 2006 08:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoK6t-0007IM-S4 for dime@ietf.org; Thu, 08 Jun 2006 08:59:39 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoK6s-0002Ps-Dv for dime@ietf.org; Thu, 08 Jun 2006 08:59:39 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k58CxbG4031257; Thu, 8 Jun 2006 15:59:37 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 15:59:33 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 15:59:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] diameter in IMS Date: Thu, 8 Jun 2006 15:59:33 +0300 Message-ID: In-Reply-To: <20060608125005.8503.qmail@web38209.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] diameter in IMS Thread-Index: AcaK+pR/EAiExtwbTvW/jrt3wifuuQAABWrg From: To: , X-OriginalArrivalTime: 08 Jun 2006 12:59:34.0513 (UTC) FILETIME=[63F60610:01C68AFB] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org > I have a little question about Diameter in the Ip Multimedia=20 >Subsystem architecture (IMS). Why the creator of this=20 >architecture have decided to use the Diameter protocol and not=20 >an other as radius ? What's the main purpose ? You should probably ask from 3GPP. However, you might want to look at RFC 3127 - http://www.ietf.org/rfc/rfc3127.txt. Different AAA protocols were evaluated, it decided that Diameter would be the AAA protocol for the future. John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 08 09:04:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoKB9-0001qr-BH; Thu, 08 Jun 2006 09:04:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoKB8-0001qm-GI for dime@ietf.org; Thu, 08 Jun 2006 09:04:02 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoKB7-0002eP-39 for dime@ietf.org; Thu, 08 Jun 2006 09:04:02 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k58D3xOd005025 for ; Thu, 8 Jun 2006 16:04:00 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 16:03:59 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 16:03:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Jun 2006 16:03:59 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DiME Working Group Secretary Thread-Index: AcaK/ADZEV8icJpcQhWDjnagnYeuPQ== From: To: X-OriginalArrivalTime: 08 Jun 2006 13:03:59.0561 (UTC) FILETIME=[01F12390:01C68AFC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Dime] DiME Working Group Secretary X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Dear WG, I'd like to announce that Victor Fajardo will be the DiME secretary. In practice, this means he will help the chairs prepare WG meetings, WG minutes and manage the issue trackers. Hannes & I will get is name added to the WG charter & look forward to productive work! thanks, John & Hannes. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 08 09:08:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoKFO-0003g6-KS; Thu, 08 Jun 2006 09:08:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoKFN-0003g1-Ej for dime@ietf.org; Thu, 08 Jun 2006 09:08:25 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoKFM-00034w-13 for dime@ietf.org; Thu, 08 Jun 2006 09:08:25 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k58D8LLf000413; Thu, 8 Jun 2006 16:08:22 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 16:08:22 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 16:08:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Guidelines for Diameter extensions Date: Thu, 8 Jun 2006 16:08:22 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Guidelines for Diameter extensions Thread-Index: AcaGlS/tdO7S0yzITYeCnR05J8VRowEZtmdw From: To: , X-OriginalArrivalTime: 08 Jun 2006 13:08:23.0472 (UTC) FILETIME=[9F3EC300:01C68AFC] X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, >I want to get opinion/feedback -especially from WG-chairs +=20 >RFC3588 authors- about quidelines for extensions to Diameter protocol. > >In the last couple of months, a few issues have been discussed=20 >on the list and some of them may require enhancements on the=20 >existing specification -or people may want to propose new=20 >procedures about other issues- . I believe it could be useful=20 >to have a set of guidelines for such extensions. So, we have an item about explaining the role of Diameter Applications, I think we should should discuss this. However ... >For example, how acceptable would the following approaches be,=20 >when defining new procedures: >a) New base protocol messages >b) New error-codes >c) New AVPs for base protocol messages >... The 3588 IANA considerations should have all of this information, do you have any questions on what is in there? >BTW, are we going to have a bis document? When we have some strong consensus on what should be in there, yes, of course. But see my next mail. John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 08 09:20:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoKR6-0001nh-4h; Thu, 08 Jun 2006 09:20:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoKR5-0001nc-Ed for dime@ietf.org; Thu, 08 Jun 2006 09:20:31 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoKR3-0003v8-1m for dime@ietf.org; Thu, 08 Jun 2006 09:20:31 -0400 Received: by py-out-1112.google.com with SMTP id n25so522875pyg for ; Thu, 08 Jun 2006 06:20:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=U5v1nEbRFt0p8uYrOLaBxI9msPl6fB/IpSsuGCQzG7VucPkXdg+ZNR9aJC2soJBn/WMbsWtvlg9495WdQouzh1K7cUp9Kyl9ArI7WKE02P3AnJYQwMRI+A87s+ls0Bsq1JJ9vTJt6zKf2CVRkc9gdK4aEc7Ytcg8TTXkA8cqMmg= Received: by 10.35.61.2 with SMTP id o2mr2370027pyk; Thu, 08 Jun 2006 06:20:28 -0700 (PDT) Received: by 10.35.9.17 with HTTP; Thu, 8 Jun 2006 06:20:28 -0700 (PDT) Message-ID: <20be0ff80606080620s73c439daje586c8d479452e5d@mail.gmail.com> Date: Thu, 8 Jun 2006 08:20:28 -0500 From: "Ivelin Ivanov" To: "Jacques, Olivier (OpenCall Test Infra)" Subject: Re: [Dime] Open Source (GPL) test tool available for Diameter In-Reply-To: <1AB048BB58C35849AD36CDE65F16C11002DB1BF3@idaexc01.emea.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20be0ff80606071811g12258f6fha88f3282df3d5dfc@mail.gmail.com> <1AB048BB58C35849AD36CDE65F16C11002DB1BF3@idaexc01.emea.cpqcorp.net> X-Google-Sender-Auth: 75621a0adc4f1fd2 X-Spam-Score: 1.9 (+) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: dime@ietf.org, "Bartek \(PL\)" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Oliver, Thank your for the clarification. We are in the process of developing an Open Source JSLEE Diameter RA for Sh app. The effort is lead by Bartek (in CC). As soon as we complete the prototype we would like to start testing interoperability and will probably contribute an Sh dictionary. http://wiki.java.net/bin/view/Communications/MobicentsDiameterRA We will continue this discussion on the Seagull and Mobicents forums. Regards, Ivelin On 6/8/06, Jacques, Olivier (OpenCall Test Infra) wrote: > Hello Ivelin, > > Thanks for the kudos. We also believe that easing IMS testing will > greatly help the adoption. > > For your question, Sh dictionary is not implemented. But as you can see > from the base + Cx dictionary (base_cx.xml file), adding Sh should be a > matter of less than an hour work. > http://svn.sourceforge.net/viewcvs.cgi/gull/seagull/trunk/src/exe-env/di > ameter-env/config/base_cx.xml?view=markup > If someone wants to try, please send the dictionary to Seagull-users > mailing list so that it can be integrated. > > In terms of scenarios, what we are doing with Seagull is to implement, > for each dictionary, one server (first message in the scenario received) > and one client scenario (first message in the scenario sent). This is to > demo the dictionary and to ease the writing of the first custom > scenario. > We do not currently include any compliance or interoperability test > suite. > _but_, as it has been done with SIPp > (http://sipp.sourceforge.net/wiki/index.php/Scenarios), Seagull's Wiki > could be a good place for that. > In any case, if someone wants to contribute a Diameter test suite for > Seagull, we will be happy to include it. > > I also think that Seagull could be of great help in interop/plugtests > events by emulating missing nodes or help reproducing interop issues. > > Olivier. > HP OpenCall Software > > > -----Original Message----- > > From: ivelin.atanasoff.ivanov@gmail.com > > [mailto:ivelin.atanasoff.ivanov@gmail.com] On Behalf Of Ivelin Ivanov > > Sent: jeudi 8 juin 2006 03:12 > > To: Jacques, Olivier (OpenCall Test Infra) > > Cc: dime@ietf.org > > Subject: Re: [Dime] Open Source (GPL) test tool available for Diameter > > > > Congratulations to the Seagull team and its sponsors! > > > > An open source IMS testing tool can help ensure > > interoperability between vendors, which is critical to IMS > > adoption. sipp has proven a very valuable compliance and > > benchmarking tool; I am glad that Seagull continues the legacy. > > > > A few question regarding the Diameter plugin: From the > > documentation it does not become apparent whether Sh > > dictionary is currently implemented. Can you please clarify? > > Also, does the roadmap include a script to cover the interop > > use cases described in: > > http://www.ietf.org/internet-drafts/draft-fajardo-dime-interop > > -test-suite-00.txt > > > > Thank you, > > > > Ivelin > > > > On 6/7/06, Jacques, Olivier (OpenCall Test Infra) > > wrote: > > > Hello, > > > > > > I think that the members of the dime mailing-list will find this > > > information useful. > > > > > > Seagull is a free, Open Source (GPL) multi-protocol traffic > > generator > > > test tool, sponsored by HP OpenCall Software as well as Atos Origin > > > and the COMET consortium. Primary aimed at IMS protocols (and thus > > > being the perfect complement to SIPp - > > http://sipp.sourceforge.net/), > > > Seagull is a powerful traffic generator for functional, load, > > > endurance, stress and performance tests for almost any kind of > > > protocol. > > > > > > Seagull-1.3.0, which is the first public release, comes with the > > > following protocols: > > > - Diameter (base and Cx+Cc applications) over TCP or SCTP (IPv4 or > > > IPv6), > > > - XCAP over HTTP, > > > - Radius, > > > - any protocol over TCAP (Camel, Win, MAP, IS41, INAP - using HP > > > OpenCall SS7) > > > - A generic synchronization protocol. > > > > > > Seagull is very flexible, and adding new or proprietary Diameter > > > applications, commands or AVPs to Seagull is just a matter > > of editing > > > an XML dictionary file. > > > > > > We hope that you will find it useful. > > > > > > Seagull's web site: http://gull.sourceforge.net/ > > > > > > Don't hesitate to contact me if you have any question. > > > Olivier. > > > -- > > > HP OpenCall Software > > > http://www.hp.com/go/opencall/ > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 09 05:54:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fodh4-0002Wf-2d; Fri, 09 Jun 2006 05:54:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fodh2-0002WX-Rb for dime@ietf.org; Fri, 09 Jun 2006 05:54:16 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fodh1-0004m3-EP for dime@ietf.org; Fri, 09 Jun 2006 05:54:16 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k599EOjg009755 for ; Fri, 9 Jun 2006 12:14:26 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 12:14:22 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 12:14:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Jun 2006 12:14:21 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3588-bis Thread-Index: AcaLpRg8pDQv4VAQTviD4yCpAgtm8w== From: To: X-OriginalArrivalTime: 09 Jun 2006 09:14:22.0244 (UTC) FILETIME=[186F2640:01C68BA5] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Dime] 3588-bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, We've discussed both a 3588-bis (Diameter Base) & a 4005-bis (NASREQ). Before starting to produce such documents, I would like to get some feedback on some ground-rules. IANA considerations in 3588 explain the mechanisms to extend Diameter. As there are existing deployments of Diameter, I think we should not add new features to 3588-bis, just focusing on either removing features that are not used and correcting mistakes. =20 I'd like discussion to be very focused, having proposed text changes. General statements like "wouldn't it be nice if feature x could do this?" aren't very helpful. I think that we should spend time in Montreal talking about this - I think we should prepare a list of issues with 3588. There are a number of issues in the issue tracker, I suggest we start from that. comments? John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 09 10:27:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FohxG-0005Bx-2e; Fri, 09 Jun 2006 10:27:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FohxF-0005Bs-6F for dime@ietf.org; Fri, 09 Jun 2006 10:27:17 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FohxB-0004NO-RQ for dime@ietf.org; Fri, 09 Jun 2006 10:27:17 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id B0FE2BB6E7 for ; Fri, 9 Jun 2006 10:27:10 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k59ER9CM027235 for ; Fri, 9 Jun 2006 10:27:09 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] 3588-bis Date: Fri, 9 Jun 2006 10:04:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-reply-to: Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi John, Just my two cents: 1)I also believe that it is a good idea to clean up/fix first, what is already defined, with focused text changes. Especially for the bis document, this may be all what is needed. 2)OTOH, there may be featues, which are not currently defined in RFC3588 but which are usefull for certain real-life deployment cases. Rather than ending up with multiple proprietary -and non-interoperable- solutions, it could be nice to standardize them . I hope WG will have time/interest at least to discuss such concerns as well -not necessarily as part of the bis effort-. 3)RFC3588 11 "IANA Considerations" addresses extensibility of Diameter protocol, but more from defining new objects point of view, e.g. defining new applications. I was wondering, what the approach should be when fixing/adding stuff for the base protocol itself. Actually not big deal, hopefully we will have some feeling about that, once we start to discuss the issues. 4)IMHO, it could be good to start discussing issues on the mailing list. It may be the case that a good number of people which actually implemented the protocol couldn't/wouldn't make it to IETF meeting. Thanks, Tolga > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Friday, June 09, 2006 5:14 AM > To: dime@ietf.org > Subject: [Dime] 3588-bis > > > Hi all, > > We've discussed both a 3588-bis (Diameter Base) & a 4005-bis (NASREQ). > Before starting to produce such > documents, I would like to get some feedback on some ground-rules. > > IANA considerations in 3588 explain the mechanisms to extend Diameter. > As there are existing deployments of Diameter, I think we should not add > new features to 3588-bis, just focusing on either removing features that > are not used and correcting mistakes. > > I'd like discussion to be very focused, having proposed text changes. > General statements like "wouldn't it be nice if feature x could do > this?" aren't very helpful. > > I think that we should spend time in Montreal talking about this - I > think we should prepare a list of issues with 3588. There are a number > of issues in the issue tracker, I suggest we start from that. > > comments? > John > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 09 17:43:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fool5-0002qZ-9E; Fri, 09 Jun 2006 17:43:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fool3-0002q8-I7 for dime@ietf.org; Fri, 09 Jun 2006 17:43:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fonsh-0005ON-48 for dime@ietf.org; Fri, 09 Jun 2006 16:46:59 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fonku-0007rU-2P for dime@ietf.org; Fri, 09 Jun 2006 16:39:00 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 16:38:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Jun 2006 16:38:51 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219282@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RADIUS extensions Diameter compatibility considerations Thread-Index: AcaMBLfKl8EXl9rAR9STs4RH0nWvWw== From: "Nelson, David" To: X-OriginalArrivalTime: 09 Jun 2006 20:38:52.0657 (UTC) FILETIME=[B84ED610:01C68C04] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Dime] RADIUS extensions Diameter compatibility considerations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org For those DIME WG list members who are not also subscribed to the RADEXT = WG list, we are currently having a discussion of the appropriate = template text for the Diameter Compatibility sections of RADEXT WG = documents. Such issues as Diameter code points (new RADIUS attributes continue to = be "imported" to Diameter via the RFC 4005 NAS Application method), use = of the "M" mandatory flag bit, and Diameter Application-IDs are part of = that discussion. Regards, =A0 Dave Nelson =A0 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 09 18:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foph7-0007xg-3Z; Fri, 09 Jun 2006 18:43:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foph5-0007xW-W2 for dime@ietf.org; Fri, 09 Jun 2006 18:43:07 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foph2-0001F4-Nh for dime@ietf.org; Fri, 09 Jun 2006 18:43:07 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Jun 2006 15:43:04 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,225,1146466800"; d="scan'208"; a="29168987:sNHT21043824" Received: from [161.44.55.106] (dhcp-161-44-55-106.cisco.com [161.44.55.106]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k59Mh4YL017273 for ; Fri, 9 Jun 2006 18:43:04 -0400 (EDT) Message-ID: <4489F977.10303@cisco.com> Date: Fri, 09 Jun 2006 18:43:03 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Dime] Support for Class AVP mandatory in session based apps? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org The Class AVP defined in the base Diameter spec allows a server to pass a "cookie" to the client and receive it back in subsequent requests from the client to the server belonging to the same session. However, a number of applications do not explicitly list the Class AVP in the definition of session-creating answers or in mid-session messages. This is true, for example, for the Credit-Control-Answer in RFC 4006 and for the AA-Answer in 3GPP TS 29.209 (IMS's Gq app). While the Class AVP is not explicitly listed the grammars of both these answers do include *[AVP] so at least according to the grammar it's OK to include the Class AVP. My question is whether a client that does not honor the Class AVP in these cases can claim to be standards compliant. In my view it would be preferable if support for the Class AVP was required for all session based apps unless possibly if an application explicitly says otherwise (and not just in the grammar). Thanks, Anders _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 12 03:19:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpgi8-0001rp-NC; Mon, 12 Jun 2006 03:19:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpgi7-0001re-LQ for dime@ietf.org; Mon, 12 Jun 2006 03:19:43 -0400 Received: from mail12.opentransfer.com ([69.6.255.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fpgi5-0005X7-TC for dime@ietf.org; Mon, 12 Jun 2006 03:19:43 -0400 Received: (qmail 2920 invoked by uid 399); 12 Jun 2006 07:19:40 -0000 Received: from unknown (HELO prasad) (61.95.206.132) by mail.opentransfer.com with SMTP; 12 Jun 2006 07:19:40 -0000 From: To: Date: Mon, 12 Jun 2006 12:49:45 +0530 Message-ID: <000601c68df0$964b69f0$0801a8c0@prasad> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Subject: [Dime] Answer message processing by a relay agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1481973084==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1481973084== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C68E1E.B005EFE0" This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C68E1E.B005EFE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have a question regarding the answer message processing by a relay agent. In RFC 3588 it is mentioned that realm routing table is used to route/forward an incoming REQUEST message. Is the same realm routing look-ups are used to processes the ANSWER messages? In section 2.8.1 it is simply mentioned that the replies are routed back using stored state, but it is not clear that even the answer messages processing also needs route table look-up. Also, can Proxy-Info AVP is used by relay agent or it is only for proxy? Your help is really appreciated. Thanks Prasad. Condor Networks Bangalore India. ------=_NextPart_000_0007_01C68E1E.B005EFE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 I have = a question regarding the answer message processing by a relay agent. In = RFC 3588 it is mentioned that realm routing table is used to route/forward an = incoming REQUEST message. Is the same realm routing look-ups are used to processes the = ANSWER messages? In section 2.8.1 it is simply mentioned that the replies are = routed back using stored state, but it is not clear that even the answer = messages processing also needs route table look-up.

 

Also, can Proxy-Info AVP is used by relay agent or it = is only for proxy?

 

Your help is really = appreciated.

 

Thanks

Prasad.=

Condor Networks

Bangalore

India.

------=_NextPart_000_0007_01C68E1E.B005EFE0-- --===============1481973084== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1481973084==-- From dime-bounces@ietf.org Mon Jun 12 10:15:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpnCS-0003kt-7U; Mon, 12 Jun 2006 10:15:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpnCQ-0003ko-PC for dime@ietf.org; Mon, 12 Jun 2006 10:15:26 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpnCP-0002sk-Uv for dime@ietf.org; Mon, 12 Jun 2006 10:15:26 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id CD6479C16D for ; Mon, 12 Jun 2006 10:15:25 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5CEFN0k006050 for ; Mon, 12 Jun 2006 10:15:24 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] CER/CEA on an open connection Date: Mon, 12 Jun 2006 09:52:08 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-reply-to: Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 23336e92cd9b2f166f17126afcdd84ec X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org After rereading the proposed text, I have some comments/questions, mainly initiated by the sentence "Applications can be restarted for various reasons including maintenance and upgrades." This again makes me think about graceful shutdown of applications, which I biefly mentioned before on the mailing list. I see threee different scenarios, where application set supported by a node chnages: a) Application is taken out for maintenance/upgrade, this I will call controlled shutdown. b) Application crashes etc..., this I will call uncontrolled shutdown. c) Application starts, maybe it is newly installed, or it restarted after a)/b). For c), I think CER is appropriate. Also for b), I think the same. OTOH for a), IMO the more useful approach is to gracefully shutdown the application. This means, waiting till all pending sessions are over and only then shutting down the application. As an example consider a credit control server, where several session-based credit control sessions are going on. I wouldn't think operators would be happy to sacrifice all of those sessions when the application needs to be shutdown for maintenence purposes. This issue can be addressed by introducing a new error code in protocol errors class. If the server is in process of being gracefully shutdown, it could reply with this error code for requests initiating a new session. Requests for existing sessions would be answered regularly. When the immediate neighbor of the server -which could be a client or a relay/proxy- receives an answer with this new error code, it shouldn't send new session requests to the server anymore -for relays/proxies this probably corresponds to not to send messages which don't have a Destination-Host AVP to the server-. When the server has no more pending sessions, it can send CER. What do people think about this? Thanks, Tolga > -----Original Message----- > From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > Sent: Monday, June 05, 2006 3:40 AM > To: john.loughney@nokia.com > Cc: dime@ietf.org > Subject: RE: [Dime] CER/CEA on an open connection > > > All, > > Below is the proposed text for peer capabilities update in Base Diameter > (as discussed in this email list earlier). > > John, Please advice us on the process for text proposals to *-biz > versions. > > Regards, > Vishnu. > > ------------------------------------------------------------ > 5.3.8 Peer Capabilities Update > > Among the capabilities exchanged during Diameter connection > initialization, list of supported applications by the node can change > dynamically. Applications can be restarted for various reasons including > maintenance and upgrades. > > A Diameter node MUST initiate peer capabilities update by sending a > Capabilities-Exchange-Req (CER) to all its peers which supports peer > capabilities update and are in open state. Diameter nodes that implement > peer capabilities update SHOULD check the version information advertised > by its peer in the Diameter header of the previous CER/CEA exchange to > determine if the peer supports peer capabilities update. The Diameter > node MUST NOT send peer capabilities update to the peer if it determines > that the peer has no support for such scheme, instead it SHOULD > gracefully disconnect its current connection and attempt to establish a > new connection towards that peer. In either case, the Diameter node is > expected to advertise the most recent set of supported applications in a > CER message, as specified by the peer state machine (see Section 5.6) > while it is in the open state. > > The receiver of CER in open state MUST process and reply to the CER as a > described in Section 5.3. The CEA which the receiver sends MUST contain > its latest capabilities. Note that peers which successfully process the > peer capabilities update SHOULD also update their routing tables to > reflect the change. The receiver of the CEA, with a Result-Code AVP > other than DIAMETER_SUCCESS, initiates the transport disconnect. Peer > capabilities update in the open state SHOULD be limited to the > advertisement of the new list of supported applications and MUST > preclude re-negotiation of security mechanism or other parameters. > ------------------------------------------------------------ > > Regards, > Vishnu. > > Motorola India Electronics Pvt Ltd > +91 9844178052 > [*] Motorola Internal Use Only > > > > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Monday, April 10, 2006 8:13 PM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] CER/CEA on an open connection > > > Hi All, > > > I believe in general now we all have a good understanding about what > > the issues are for renegotiation. It could be an idea to have a new > > iteration of the proposed text, and to continue the discussions on the > > > new version. > > > > To that end, I'll plan on generating a new set of text maybe next week > as we let people digest and hopefully comment on the latest round of > discussion for the next couple of days. > > best regards, > victor > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > I believe in general now we all have a good understanding about what the > issues are for renegotiation. It could be an idea to have a new > iteration of the proposed text, and to continue the discussions on the > new version. > > A few more comments/questions below. > > Thanks, > Tolga > > > -----Original Message----- > > From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > > Sent: Monday, April 10, 2006 2:38 AM > > To: dime@ietf.org > > Cc: Nakhjiri Madjid-MNAKHJI1 > > Subject: RE: [Dime] CER/CEA on an open connection > > > > > > Hi Victor/Timothy, > > > > 1. Comments on Retry mechanism : > > To summarize, we are sending CER in open state because our > > capabilities (supported apps) are changing and we would like to update > > > the peer about it. We will maintain open state. > > > > we may not receive a CEA due to the following possible reasons: > > 1.1) The peer does not support CER in open state. In such a case, peer > > > might still originate unsupported app messages towards us which will > > result in "DIAMETER_APPLICATION_UNSUPPORTED" error from us. We can > > leave it to the peer implementation to "correct this error" as > > mentioned in sec 7.1.3 of RFC 3588. This will take care of the case > > where there is relay/proxy in between. > > 1.2) Connection is lost with the peer, in which case the DWR/DWA > > mechanism should step in. > > > > The solution suggested by Timothy (to wait for for CEA & timer) will > > need changes to FSM, even though we agree that this is consistent with > > > the initial CER/CEA scenario. > > > > Ofcourse the use of "DIAMETER_APPLICATION_UNSUPPORTED" will result in > > added (unecessary traffic) incase the peer/proxy is not clever enough > > to correct its behaviour. This can be avoided by using the version > > number exchange as Victor pointed out. So, we will not attempt the CER > > > in open state to such a peer which doesnt support CERs in open state, > > and can go for a reconnection. > [TOLGA]The problem case of a node not being clever enough to take action > based on "DIAMETER_APPLICATION_UNSUPPORTED" is not limited to > renegotiations. This could happen in existing systems developed > according to RFC3588 as well. I would expect a node, whose > DIAMETER_APPLICATION_UNSUPPORTED replies are not honored by its neighbor > to drop the connection, but as said this is not limited to renegotiation > case. For cases, where the neighbor does not support renegotiation, what > would be the result code in CEA? DIAMETER_UNABLE_TO_COMPLY? We can say > that such a result code in CEA should indicate that the neighbor does > not support renegotiations and sender of CER should/may drop/reestablish > the connection. Please note that with a properly behaving neighbor, > dropping connection is probably not necessary because the first > DIAMETER_APPLICATION_UNSUPPORTED should update its tables properly. I > don't know whether we need to standardize how a node determines whether > a neighbor honors DIAMETER_APPLICATION_UNSUPPORTED result code. > > > > 2. Comments on "re-negotiation" > > We think that what we need is an advertisement mechanism and not a > > negotiation mechanism. The CER/CEA in open state allows us to do that. > > > We are proposing that the receiver of the CER takes the decision on > > the disconnection. Thus we are able to delay the disconnection > > (assuming that the point mentioned in my email before that the app > > changes are temporary). Since CER allows us to convey the latest set > > of supported apps to the peer, we favour the CER to the DPR. > > > > Following is a scenario where sending CER/CEA is better than the DPR > > mechanism. (Apologies if the figure is mangled due to tab settings). > [TOLGA]Although the example case below is a race condition which > probably won't happen very often -it relies on changing supported > application set on two nodes more or less simultaneously-, I also prefer > relying on CER in such a situation, so that there is a single way of > handling renegotiations in terms of advertising changes to the > neighbors. > > > > Initial exchanged app list: > > A: 1,2,3 B:2 > > 2 went down 3 came up just when 2 went down on A > > ________ ________ > > |A |----DPR---> |B | > > | | | | > > | |<---CER---- | | > > |______| [3] |______| > > <---DPA---- > > > > this in our understanding will result in reconnection even thou there > > is 3 in common. > > > > Initial exchanged app list: > > A: 1,2,3 B:2 > > 2 went down 3 came up just when 2 went down on A > > ________ ________ > > |A |----CER---> |B | > > | | [1,3] | | > > | |<---CER---- | | > > |_______| [2,3] |_______| > > ----CEA----> > > [1,3] > > <---CEA----- > > [2,3] > > This will avoid a reconnection, because 3 is in common. > > > > Regards, > > Vishnu. > > > > Motorola India Electronics Pvt Ltd > > +91 9844178052 > > [*] Motorola Internal Use Only > > > > > > -----Original Message----- > > From: Timothy Smith [mailto:tjsmith@us.ibm.com] > > Sent: Monday, April 10, 2006 7:11 AM > > To: Victor Fajardo > > Cc: dime@ietf.org; Nakhjiri Madjid-MNAKHJI1; Ram O V Vishnu-A14676 > > Subject: Re: [Dime] CER/CEA on an open connection > > > > > > > > Hi Victor, > > > > Thanks for your response. Comments below" > > >> > > >> Good summary! I agree with most of your points. I'm not sure, > > >> however, that I distinguish between (1) and (2). I think whether > > >> temporary or not, we should handle CER/CEA exchanges in the same > > manner. > > >I'm just speculating but I think (2) refers to application change > > >requiring a reboot. > > >> > > >> I agree with your design goals (3) ,(4), and suggestions (5) , (6) > > >> , (8), and (9). > > >If some are more in favor of scheme (5) , maybe we need more opinion > > on > > >whether the receiver of the CEA can always comply with the change > > >request regardless of any scenario. I think (6) and (9) can be > > >avoided regardless of which scheme we decide to use (see my previous > > >reply). > > > > > > > Here is the text from your previous reply: > > "This certainly simplifies things but it also implies that the sender > > of > > > > the CER mandates a change and the receiver has no choice but to accept > > > it. In some sense, the scheme is no longer a re-negotiation but merely > > > notifying the peer of a change. The proposed text was considering the > > case where the receiver of the CER cannot comply with the change for > > whatever reason." > > > > I tend to agree with the notion that the sender of the CER is > > mandating a change. The receiver does have a choice just as it has a > > choice in the original CER/CEA exchange. The receiver should respond > > with the list of > > > > App Ids that is the intersection of what was listed in the CER and of > > what App Ids it wishes to support. It is a renegotiation which may > > add or remove App Ids. But either way, it is telling the other side > > about its intentions. I don't thing the receiving side has any choice > > > but to participate > > in the renegotiation. For example, if an app Id is being removed, the > > side > > where it is being removed renegotiates with a CER that does not > include > > that > > App ID. It doesn't do the receiving side any good to decline this as > > the App > > will be shut down regardless. > > > > > > >> Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont > > >> think there is a problem here. Cant find any race condition." I > > >> thought that there was a subtle problem here, but I think you are > > >> right. Given that the connection insures sequencing, the latest > > >> CER or CEA that you receive is what you should use as the list of > > >> negotiated App Ids. > > >> > > >Mmmm... i'm not sure that the connection itself ensures sequencing. > > >Anyway, majority rule favors removing this text. > > >> Should there be some discussion on the retry mechanism? You send a > > > >> CER, and no response is received. Does this mean that the peer > > >> just doesn't know how to renegotiate? Should we ignore and retry > > >> every n seconds? Bring down the connection? Or do we just > > >> continue to use the apps from the initial negotiation? My > > >> preference on this is that we should require a CEA response to the > > >> CER. If the CEA is not received, we shutdown the connection and > > >> start over. This would address compatibility issues with existing > > >> implementations. It would > > > > >> also be consistent with the processing of the initial CER/CEA. > > >> > > >The current proposal has text mentioning the use of version number of > > > >initial CER/CEA exchange to determine whether a peer is capable of > > >renegotiating. If a node knows that its peer is not capable of > > >re-negotiating then the node should not initiate re-negotiation. In > > this > > >scheme, existing implementations will be spared of any change. > > > > I'm not sure I picked up the version number. I don't see a reason to > > do > > > > something special. I would simply like to renegotiate. If the other > > side does not respond to the CER, you shut down the connection and > > restart it > > > > after some period of time. This is what you would do if your initial > > CER did not get a response. How is this different? > > > > > > Best Regards, > > Timothy Smith > > > > Vishnu wrote: > > > Hi, > > > > > > Some clarifications and comments on the discussion on this thread: > > > > > > We would like to clarify the following practical scenarios of this > > > happenning: > > > 1. there are a list of published applications which the box support > > > and these are installed in the box. Now, some of them go down/up. > > > This would get translated into change in peer capabilities. > > > 2. there is a new application which is getting installed/removed > from > > > the box. > > > > > > We think that (1) is the most probable scenario. so, > > > there is value in giving a simple solution assuming that this change > > (in > > > capabilities) > > > is most probably temporary. If this is not the case, we are talking > > > about (2), which is a major change in the box anyways. So in (2), we > > > > assume it is ok to assume that > > > the connections to be reestablished. > > > > > > We would like to say that our design goals are: > > > 3. solution should be simple & as backward compatible as possible. > > > 4. minimize the FSM changes. > > > > > > We suggest: > > > 5. Updating peer capabilities done only using a CER/CEA in the open > > > state. Sender of CER/CEA updates the local capabilities before > > > sending the message and > > > hence is a local decision. > > > > > > 6. The rest of the processing of the CER/CEA will be as per the > > current > > > RFC. > > > Say for example, if there are no > > > common applications left with that peer, > > DIAMETER_NO_COMMON_APPLICATION > > > is sent in the > > > CEA and the connection is closed. > > > > > > Problems in the email thread under discussion & some comments: 7. > > > Cross over and sequencing of CER/CEA exchange. We dont think there > > is > > > a problem > > > here. Cant find any race condition. > > > > > > 8. Mutual agreement to bring down applications will not work due to > > > possible relays in between as Tolga has pointed out in the mailing > > > list. > > > > > > 9. The DPR solution in the suggested text is not a good idea. > > > Because DPR cannot advertise the latest local applications to the > > > peer. This may cause > > the > > > race condition > > > and sequencing problem. This problem can be avoided by using the > > > approach which we suggested in (5). > > > > > > Regards, > > > Vishnu. > > > > tjsmith@us.ibm.com > > (919) 254-4723 > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 12 10:24:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpnLb-0002bA-GP; Mon, 12 Jun 2006 10:24:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpnLb-0002b2-76 for dime@ietf.org; Mon, 12 Jun 2006 10:24:55 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpnLZ-0003oh-Sg for dime@ietf.org; Mon, 12 Jun 2006 10:24:55 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 9AA0EF1C39 for ; Mon, 12 Jun 2006 10:24:53 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5CEOqR1007241 for ; Mon, 12 Jun 2006 10:24:52 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] Support for Class AVP mandatory in session based apps? Date: Mon, 12 Jun 2006 10:01:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-reply-to: <4489F977.10303@cisco.com> Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org ... resending .... Anders, > -----Original Message----- > From: Anders Kristensen [mailto:andersk@cisco.com] > Sent: Friday, June 09, 2006 6:43 PM > To: dime@ietf.org > Subject: [Dime] Support for Class AVP mandatory in session based apps? > > > The Class AVP defined in the base Diameter spec allows a server to pass > a "cookie" to the client and receive it back in subsequent requests from > the client to the server belonging to the same session. > > However, a number of applications do not explicitly list the Class AVP > in the definition of session-creating answers or in mid-session > messages. This is true, for example, for the Credit-Control-Answer in > RFC 4006 and for the AA-Answer in 3GPP TS 29.209 (IMS's Gq app). While > the Class AVP is not explicitly listed the grammars of both these > answers do include *[AVP] so at least according to the grammar it's OK > to include the Class AVP. [TOLGA]I believe the point is that server MAY include Class AVP and in such a case it MUST be present in the subsequent messages. If server chooses not to make use of Class AVP, it won't be used in subsequent messages. I don't know what is the best way to convey this information in ABNF. Like you have said, *[AVP] allows pretty my much anything but [Class] may have been used as well. > > My question is whether a client that does not honor the Class AVP in > these cases can claim to be standards compliant. In my view it would be > preferable if support for the Class AVP was required for all session > based apps unless possibly if an application explicitly says otherwise > (and not just in the grammar). [TOLGA]IMO, such a client is violating the specification. For required support of Class AVP, if what you mean is that servers SHOULD make use of it, IMHO it is better to leave that decision to the server. If what you mean is that Class AVP should be present in subsequent messages if server includes it in the answer, I agree with you -but isn't this what 8.20 is already saying?- _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 12 10:56:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpnqU-00068a-Py; Mon, 12 Jun 2006 10:56:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpnqU-00068M-95 for dime@ietf.org; Mon, 12 Jun 2006 10:56:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpmLV-0008CB-5m for dime@ietf.org; Mon, 12 Jun 2006 09:20:45 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fpm6E-0007Xt-8c for dime@ietf.org; Mon, 12 Jun 2006 09:05:01 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id C6001994C9 for ; Mon, 12 Jun 2006 09:04:57 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5CD4uvA027082 for ; Mon, 12 Jun 2006 09:04:57 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] Support for Class AVP mandatory in session based apps? Date: Mon, 12 Jun 2006 08:41:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-reply-to: <4489F977.10303@cisco.com> Importance: Normal Received-SPF: pass X-Spam-Score: -2.2 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Anders, > -----Original Message----- > From: Anders Kristensen [mailto:andersk@cisco.com] > Sent: Friday, June 09, 2006 6:43 PM > To: dime@ietf.org > Subject: [Dime] Support for Class AVP mandatory in session based apps? > > > The Class AVP defined in the base Diameter spec allows a server to pass > a "cookie" to the client and receive it back in subsequent requests from > the client to the server belonging to the same session. > > However, a number of applications do not explicitly list the Class AVP > in the definition of session-creating answers or in mid-session > messages. This is true, for example, for the Credit-Control-Answer in > RFC 4006 and for the AA-Answer in 3GPP TS 29.209 (IMS's Gq app). While > the Class AVP is not explicitly listed the grammars of both these > answers do include *[AVP] so at least according to the grammar it's OK > to include the Class AVP. [TOLGA]I believe the point is that server MAY include Class AVP and in such a case it MUST be present in the subsequent messages. If server chooses not to make use of Class AVP, it won't be used in subsequent messages. I don't know what is the best way to convey this information in ABNF. Like you have said, *[AVP] allows pretty my much anything but [Class] may have been used as well. > > My question is whether a client that does not honor the Class AVP in > these cases can claim to be standards compliant. In my view it would be > preferable if support for the Class AVP was required for all session > based apps unless possibly if an application explicitly says otherwise > (and not just in the grammar). [TOLGA]IMO, such a client is violating the specification. For required support of Class AVP, if what you mean is that servers SHOULD make use of it, IMHO it is better to leave that decision to the server. If what you mean is that Class AVP should be present in subsequent messages if server includes it in the answer, I agree with you -but isn't this what 8.20 is already saying?- > > Thanks, > Anders > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 12 11:06:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpnzd-0003kG-0j; Mon, 12 Jun 2006 11:06:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpnzb-0003k1-3h for dime@ietf.org; Mon, 12 Jun 2006 11:06:15 -0400 Received: from lhrga01-in.huawei.com ([57.66.76.5] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpnzZ-00014g-Jc for dime@ietf.org; Mon, 12 Jun 2006 11:06:15 -0400 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0R004DR5AS98@lhrga01-in.huawei.com> for dime@ietf.org; Mon, 12 Jun 2006 15:52:05 +0100 (BST) Received: from IBM4307EA0CEF3 ([217.167.117.51]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0R0021N5AS22@lhrga01-in.huawei.com> for dime@ietf.org; Mon, 12 Jun 2006 15:52:04 +0100 (BST) Date: Mon, 12 Jun 2006 23:06:03 +0800 From: Tina TSOU Subject: [Dime]draft-tsou-dime-base-routing-ext-00.txt To: dime@ietf.org Message-id: <019601c68e31$ba01f530$3375a7d9@IBM4307EA0CEF3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0192474961==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0192474961== Content-type: multipart/alternative; boundary="Boundary_(ID_740bxfZt+HJfWDSG4gbfKw)" This is a multi-part message in MIME format. --Boundary_(ID_740bxfZt+HJfWDSG4gbfKw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Dear all, An Individual I-D draft-tsou-dime-base-routing-ext-00.txt has been published as below. http://www.ietf.org/internet-drafts/draft-tsou-dime-base-routing-ext-00.txt B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org --Boundary_(ID_740bxfZt+HJfWDSG4gbfKw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Dear all,
An Individual I-D draft-tsou-dime-base-routing-ext-00.txt has been published as below.
 
B. R.
Tina
Messengers:
MSN: tinatsou6@hotmail.com   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: tina@jabber.org
--Boundary_(ID_740bxfZt+HJfWDSG4gbfKw)-- --===============0192474961== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0192474961==-- From dime-bounces@ietf.org Mon Jun 12 11:19:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpoCB-0004fm-H4; Mon, 12 Jun 2006 11:19:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpoC9-0004co-E4 for dime@ietf.org; Mon, 12 Jun 2006 11:19:13 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpoC7-0002d2-Th for dime@ietf.org; Mon, 12 Jun 2006 11:19:13 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k5CFJAhi025179 for ; Mon, 12 Jun 2006 17:19:11 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k5CFJAJi009840 for ; Mon, 12 Jun 2006 17:19:10 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jun 2006 17:19:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C68E33.8E17EA24" Date: Mon, 12 Jun 2006 17:19:10 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt thread-index: AcaOL7/Ge7SsHuD1Scmk/tXsrUB8LAAAtu2Q From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 12 Jun 2006 15:19:10.0739 (UTC) FILETIME=[8E3BAE30:01C68E33] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Subject: [Dime] WG: I-D ACTION:draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C68E33.8E17EA24 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, a relevant draft for the mobility work in DIME. Ciao Hannes =20 -----Urspr=FCngliche Nachricht----- Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Gesendet: Montag, 12. Juni 2006 16:50 An: i-d-announce@ietf.org Cc: mip6@ietf.org Betreff: I-D ACTION:draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Mobility for IPv6 Working Group of the = IETF. Title : MIP6-bootstrapping via DHCPv6 for the Integrated Scenario Author(s) : K. Chowdhury, A. Yegin Filename : draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt Pages : 23 Date : 2006-6-12 =09 The Mobile IPv6 bootstrapping problem statement describes two main scenarios. In the first scenario (i.e. the split scenario), the mobile node's mobility service is authorized by a different service authorizer than the basic network access authorizer. In the second scenario (i.e. the integrated scenario), the mobile node's mobility service is authorized by the same service authorizer as the basic network access service authorizer. This document defines a method for home agent information discovery based on DHCPv6 for the integrated scenario. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integra= ted-dhc-01.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE = /internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C68E33.8E17EA24 Content-Type: application/octet-stream; name="draft-ietf-mip6-bootstrapping-integrated-dhc-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-mip6-bootstrapping-integrated-dhc-01.URL Content-Disposition: attachment; filename="draft-ietf-mip6-bootstrapping-integrated-dhc-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW1pcDYtYm9vdHN0cmFwcGluZy1pbnRlZ3JhdGVkLWRoYy0wMS50eHQNCg== ------_=_NextPart_001_01C68E33.8E17EA24 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C68E33.8E17EA24-- From dime-bounces@ietf.org Mon Jun 12 21:41:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpxuW-0004DZ-UL; Mon, 12 Jun 2006 21:41:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpxuV-0004DU-Sr for dime@ietf.org; Mon, 12 Jun 2006 21:41:39 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpxuP-0000cU-Fr for dime@ietf.org; Mon, 12 Jun 2006 21:41:39 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0R008VWZ9KUE@szxga01-in.huawei.com> for dime@ietf.org; Tue, 13 Jun 2006 09:39:21 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0R007QDZ9KKI@szxga01-in.huawei.com> for dime@ietf.org; Tue, 13 Jun 2006 09:39:20 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0R00GFBZ99FK@szxml03-in.huawei.com> for dime@ietf.org; Tue, 13 Jun 2006 09:39:09 +0800 (CST) Date: Tue, 13 Jun 2006 09:37:51 +0800 From: zhangtao Subject: Re: [Dime] Answer message processing by a relay agent To: prasadsv@condornetworks.com, dime@ietf.org Message-id: <005801c68e89$fbdbfd40$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal References: <000601c68df0$964b69f0$0801a8c0@prasad> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2026966605==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2026966605== Content-type: multipart/alternative; boundary="Boundary_(ID_otoRHYcLu/yF0AZ6PYGOAw)" This is a multi-part message in MIME format. --Boundary_(ID_otoRHYcLu/yF0AZ6PYGOAw) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Proxy-Info AVP can used in relay agent. see below information:(come from rfc3588): A relay or proxy agent MAY include the Proxy-Info AVP in requests if it requires access to any local state information when the corresponding response is received. the answer message no need realm routing look-ups,see below information:(come from rfc3588) The agent MUST then send the answer to the host that it received the original request from. ----- Original Message ----- From: prasadsv@condornetworks.com To: dime@ietf.org Sent: Monday, June 12, 2006 3:19 PM Subject: [Dime] Answer message processing by a relay agent Hi, I have a question regarding the answer message processing by a relay agent. In RFC 3588 it is mentioned that realm routing table is used to route/forward an incoming REQUEST message. Is the same realm routing look-ups are used to processes the ANSWER messages? In section 2.8.1 it is simply mentioned that the replies are routed back using stored state, but it is not clear that even the answer messages processing also needs route table look-up. Also, can Proxy-Info AVP is used by relay agent or it is only for proxy? Your help is really appreciated. Thanks Prasad. Condor Networks Bangalore India. ------------------------------------------------------------------------------ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_otoRHYcLu/yF0AZ6PYGOAw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Proxy-Info AVP can used in relay agent. see below information:(come from rfc3588):
 
   A relay or proxy agent MAY include the Proxy-Info AVP in requests if
   it requires access to any local state information when the
   corresponding response is received.
 
the answer message no need realm routing look-ups,see below information:(come from rfc3588)
 
   The agent MUST then send the answer to the host that it received the
   original request from.
 
----- Original Message -----
Sent: Monday, June 12, 2006 3:19 PM
Subject: [Dime] Answer message processing by a relay agent

Hi,

 I have a question regarding the answer message processing by a relay agent. In RFC 3588 it is mentioned that realm routing table is used to route/forward an incoming REQUEST message. Is the same realm routing look-ups are used to processes the ANSWER messages? In section 2.8.1 it is simply mentioned that the replies are routed back using stored state, but it is not clear that even the answer messages processing also needs route table look-up.

 

Also, can Proxy-Info AVP is used by relay agent or it is only for proxy?

 

Your help is really appreciated.

 

Thanks

Prasad.

Condor Networks

Bangalore

India.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
--Boundary_(ID_otoRHYcLu/yF0AZ6PYGOAw)-- --===============2026966605== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============2026966605==-- From dime-bounces@ietf.org Mon Jun 12 22:38:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpynd-0004Ty-Aw; Mon, 12 Jun 2006 22:38:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpync-0004Ru-Bx for dime@ietf.org; Mon, 12 Jun 2006 22:38:36 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpynZ-0006wA-20 for dime@ietf.org; Mon, 12 Jun 2006 22:38:36 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 12 Jun 2006 19:38:32 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,124,1149490800"; d="scan'208"; a="29347353:sNHT22459288" Received: from [161.44.55.106] (dhcp-161-44-55-106.cisco.com [161.44.55.106]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5D2cWYL012922; Mon, 12 Jun 2006 22:38:32 -0400 (EDT) Message-ID: <448E2528.1030207@cisco.com> Date: Mon, 12 Jun 2006 22:38:32 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Support for Class AVP mandatory in session based apps? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tolga, Inline... Tolga Asveren wrote: > Anders, > > > >>-----Original Message----- >>From: Anders Kristensen [mailto:andersk@cisco.com] >>Sent: Friday, June 09, 2006 6:43 PM >>To: dime@ietf.org >>Subject: [Dime] Support for Class AVP mandatory in session based apps? >> >> >>The Class AVP defined in the base Diameter spec allows a server to pass >>a "cookie" to the client and receive it back in subsequent requests from >>the client to the server belonging to the same session. >> >>However, a number of applications do not explicitly list the Class AVP >>in the definition of session-creating answers or in mid-session >>messages. This is true, for example, for the Credit-Control-Answer in >>RFC 4006 and for the AA-Answer in 3GPP TS 29.209 (IMS's Gq app). While >>the Class AVP is not explicitly listed the grammars of both these >>answers do include *[AVP] so at least according to the grammar it's OK >>to include the Class AVP. > > [TOLGA]I believe the point is that server MAY include Class AVP and in such > a case it MUST be present in the subsequent messages. Right, that's what I'd like to be the answer too. It's not spelled out sufficiently in the spec, though. If server chooses not > to make use of Class AVP, it won't be used in subsequent messages. I don't > know what is the best way to convey this information in ABNF. Well, if "*[Class]" is listed explicitly in the definition of the relevant messages there can't be any doubt that it's allowed. The ABNF can't and shouldn't go beyond that. Like you have > said, *[AVP] allows pretty my much anything but [Class] may have been used > as well. > >>My question is whether a client that does not honor the Class AVP in >>these cases can claim to be standards compliant. In my view it would be >>preferable if support for the Class AVP was required for all session >>based apps unless possibly if an application explicitly says otherwise >>(and not just in the grammar). > > [TOLGA]IMO, such a client is violating the specification. This is what I'd like to see spelled out in the base spec. For required > support of Class AVP, if what you mean is that servers SHOULD make use of > it, IMHO it is better to leave that decision to the server. If what you mean > is that Class AVP should be present in subsequent messages if server > includes it in the answer, I agree with you -but isn't this what 8.20 is > already saying?- Well, yes it is but then when this is reinforced by explicitly including *[Class] in the grammar of some apps but leaving it out in others it invites the interpretation that support is predicated on the AVP being listed explicitly. Or so it seems to me. I'd be surprised if all clients of the credit control app supports the Class AVP. Thanks, Anders > >>Thanks, >>Anders >> >>_______________________________________________ >>DiME mailing list >>DiME@ietf.org >>https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 12 23:16:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpzNz-0003l5-9K; Mon, 12 Jun 2006 23:16:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpzNx-0003l0-EA for dime@ietf.org; Mon, 12 Jun 2006 23:16:09 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpzNv-00028F-0j for dime@ietf.org; Mon, 12 Jun 2006 23:16:09 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0S00G9840WET@szxga03-in.huawei.com> for dime@ietf.org; Tue, 13 Jun 2006 11:22:09 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0S00AA340VKV@szxga03-in.huawei.com> for dime@ietf.org; Tue, 13 Jun 2006 11:22:08 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0S00H5Z43B0I@szxml04-in.huawei.com> for dime@ietf.org; Tue, 13 Jun 2006 11:23:35 +0800 (CST) Date: Tue, 13 Jun 2006 11:13:01 +0800 From: zhangtao Subject: Re: [Dime] CER/CEA on an open connection To: Tolga Asveren , dime@ietf.org Message-id: <00f501c68e97$4797e2a0$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I also agree with support Application graceful shutdown is better. But if use error code ,it is cannot use to restore application.if ask the proxy agent or relay agent process the error code, maybe not so good. In my idea,when Application graceful shutdown,Firstly use CER notify, Actual existed session have nothing impact,because existed session have Destion Host AVP,so no need use routing table. if application graceful shutdown ,almost have a delay timer,before the timer fire,the application should use ASR end the session. if application want immediately shutdown,also should send ASR to existed session. The CER command is HOP by HOP,only ASR can assure will notify to client node. USE the CER,just notify donnot send new session to the server,(so recommend start session only use destion realm routing ). When Application restore, also CER can notify. Application crash should check useing interim event of session, account application already support this,other application recommend support this also. Thanks, Tony Zhang ----- Original Message ----- From: "Tolga Asveren" To: Sent: Monday, June 12, 2006 9:52 PM Subject: RE: [Dime] CER/CEA on an open connection > After rereading the proposed text, I have some comments/questions, mainly > initiated by the sentence "Applications can be restarted for various reasons > including maintenance and upgrades." This again makes me think about > graceful shutdown of applications, which I biefly mentioned before on the > mailing list. > > I see threee different scenarios, where application set supported by a node > chnages: > a) Application is taken out for maintenance/upgrade, this I will call > controlled shutdown. > b) Application crashes etc..., this I will call uncontrolled shutdown. > c) Application starts, maybe it is newly installed, or it restarted after > a)/b). > > For c), I think CER is appropriate. Also for b), I think the same. OTOH for > a), IMO the more useful approach is to gracefully shutdown the application. > This means, waiting till all pending sessions are over and only then > shutting down the application. As an example consider a credit control > server, where several session-based credit control sessions are going on. I > wouldn't think operators would be happy to sacrifice all of those sessions > when the application needs to be shutdown for maintenence purposes. > > This issue can be addressed by introducing a new error code in protocol > errors class. If the server is in process of being gracefully shutdown, it > could reply with this error code for requests initiating a new session. > Requests for existing sessions would be answered regularly. When the > immediate neighbor of the server -which could be a client or a relay/proxy- > receives an answer with this new error code, it shouldn't send new session > requests to the server anymore -for relays/proxies this probably corresponds > to not to send messages which don't have a Destination-Host AVP to the > server-. When the server has no more pending sessions, it can send CER. > > What do people think about this? > > Thanks, > Tolga > > > -----Original Message----- > > From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > > Sent: Monday, June 05, 2006 3:40 AM > > To: john.loughney@nokia.com > > Cc: dime@ietf.org > > Subject: RE: [Dime] CER/CEA on an open connection > > > > > > All, > > > > Below is the proposed text for peer capabilities update in Base Diameter > > (as discussed in this email list earlier). > > > > John, Please advice us on the process for text proposals to *-biz > > versions. > > > > Regards, > > Vishnu. > > > > ------------------------------------------------------------ > > 5.3.8 Peer Capabilities Update > > > > Among the capabilities exchanged during Diameter connection > > initialization, list of supported applications by the node can change > > dynamically. Applications can be restarted for various reasons including > > maintenance and upgrades. > > > > A Diameter node MUST initiate peer capabilities update by sending a > > Capabilities-Exchange-Req (CER) to all its peers which supports peer > > capabilities update and are in open state. Diameter nodes that implement > > peer capabilities update SHOULD check the version information advertised > > by its peer in the Diameter header of the previous CER/CEA exchange to > > determine if the peer supports peer capabilities update. The Diameter > > node MUST NOT send peer capabilities update to the peer if it determines > > that the peer has no support for such scheme, instead it SHOULD > > gracefully disconnect its current connection and attempt to establish a > > new connection towards that peer. In either case, the Diameter node is > > expected to advertise the most recent set of supported applications in a > > CER message, as specified by the peer state machine (see Section 5.6) > > while it is in the open state. > > > > The receiver of CER in open state MUST process and reply to the CER as a > > described in Section 5.3. The CEA which the receiver sends MUST contain > > its latest capabilities. Note that peers which successfully process the > > peer capabilities update SHOULD also update their routing tables to > > reflect the change. The receiver of the CEA, with a Result-Code AVP > > other than DIAMETER_SUCCESS, initiates the transport disconnect. Peer > > capabilities update in the open state SHOULD be limited to the > > advertisement of the new list of supported applications and MUST > > preclude re-negotiation of security mechanism or other parameters. > > ------------------------------------------------------------ > > > > Regards, > > Vishnu. > > > > Motorola India Electronics Pvt Ltd > > +91 9844178052 > > [*] Motorola Internal Use Only > > > > > > > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: Monday, April 10, 2006 8:13 PM > > To: Tolga Asveren > > Cc: dime@ietf.org > > Subject: Re: [Dime] CER/CEA on an open connection > > > > > > Hi All, > > > > > I believe in general now we all have a good understanding about what > > > the issues are for renegotiation. It could be an idea to have a new > > > iteration of the proposed text, and to continue the discussions on the > > > > > new version. > > > > > > > To that end, I'll plan on generating a new set of text maybe next week > > as we let people digest and hopefully comment on the latest round of > > discussion for the next couple of days. > > > > best regards, > > victor > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > I believe in general now we all have a good understanding about what the > > issues are for renegotiation. It could be an idea to have a new > > iteration of the proposed text, and to continue the discussions on the > > new version. > > > > A few more comments/questions below. > > > > Thanks, > > Tolga > > > > > -----Original Message----- > > > From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > > > Sent: Monday, April 10, 2006 2:38 AM > > > To: dime@ietf.org > > > Cc: Nakhjiri Madjid-MNAKHJI1 > > > Subject: RE: [Dime] CER/CEA on an open connection > > > > > > > > > Hi Victor/Timothy, > > > > > > 1. Comments on Retry mechanism : > > > To summarize, we are sending CER in open state because our > > > capabilities (supported apps) are changing and we would like to update > > > > > the peer about it. We will maintain open state. > > > > > > we may not receive a CEA due to the following possible reasons: > > > 1.1) The peer does not support CER in open state. In such a case, peer > > > > > might still originate unsupported app messages towards us which will > > > result in "DIAMETER_APPLICATION_UNSUPPORTED" error from us. We can > > > leave it to the peer implementation to "correct this error" as > > > mentioned in sec 7.1.3 of RFC 3588. This will take care of the case > > > where there is relay/proxy in between. > > > 1.2) Connection is lost with the peer, in which case the DWR/DWA > > > mechanism should step in. > > > > > > The solution suggested by Timothy (to wait for for CEA & timer) will > > > need changes to FSM, even though we agree that this is consistent with > > > > > the initial CER/CEA scenario. > > > > > > Ofcourse the use of "DIAMETER_APPLICATION_UNSUPPORTED" will result in > > > added (unecessary traffic) incase the peer/proxy is not clever enough > > > to correct its behaviour. This can be avoided by using the version > > > number exchange as Victor pointed out. So, we will not attempt the CER > > > > > in open state to such a peer which doesnt support CERs in open state, > > > and can go for a reconnection. > > [TOLGA]The problem case of a node not being clever enough to take action > > based on "DIAMETER_APPLICATION_UNSUPPORTED" is not limited to > > renegotiations. This could happen in existing systems developed > > according to RFC3588 as well. I would expect a node, whose > > DIAMETER_APPLICATION_UNSUPPORTED replies are not honored by its neighbor > > to drop the connection, but as said this is not limited to renegotiation > > case. For cases, where the neighbor does not support renegotiation, what > > would be the result code in CEA? DIAMETER_UNABLE_TO_COMPLY? We can say > > that such a result code in CEA should indicate that the neighbor does > > not support renegotiations and sender of CER should/may drop/reestablish > > the connection. Please note that with a properly behaving neighbor, > > dropping connection is probably not necessary because the first > > DIAMETER_APPLICATION_UNSUPPORTED should update its tables properly. I > > don't know whether we need to standardize how a node determines whether > > a neighbor honors DIAMETER_APPLICATION_UNSUPPORTED result code. > > > > > > 2. Comments on "re-negotiation" > > > We think that what we need is an advertisement mechanism and not a > > > negotiation mechanism. The CER/CEA in open state allows us to do that. > > > > > We are proposing that the receiver of the CER takes the decision on > > > the disconnection. Thus we are able to delay the disconnection > > > (assuming that the point mentioned in my email before that the app > > > changes are temporary). Since CER allows us to convey the latest set > > > of supported apps to the peer, we favour the CER to the DPR. > > > > > > Following is a scenario where sending CER/CEA is better than the DPR > > > mechanism. (Apologies if the figure is mangled due to tab settings). > > [TOLGA]Although the example case below is a race condition which > > probably won't happen very often -it relies on changing supported > > application set on two nodes more or less simultaneously-, I also prefer > > relying on CER in such a situation, so that there is a single way of > > handling renegotiations in terms of advertising changes to the > > neighbors. > > > > > > Initial exchanged app list: > > > A: 1,2,3 B:2 > > > 2 went down 3 came up just when 2 went down on A > > > ________ ________ > > > |A |----DPR---> |B | > > > | | | | > > > | |<---CER---- | | > > > |______| [3] |______| > > > <---DPA---- > > > > > > this in our understanding will result in reconnection even thou there > > > is 3 in common. > > > > > > Initial exchanged app list: > > > A: 1,2,3 B:2 > > > 2 went down 3 came up just when 2 went down on A > > > ________ ________ > > > |A |----CER---> |B | > > > | | [1,3] | | > > > | |<---CER---- | | > > > |_______| [2,3] |_______| > > > ----CEA----> > > > [1,3] > > > <---CEA----- > > > [2,3] > > > This will avoid a reconnection, because 3 is in common. > > > > > > Regards, > > > Vishnu. > > > > > > Motorola India Electronics Pvt Ltd > > > +91 9844178052 > > > [*] Motorola Internal Use Only > > > > > > > > > -----Original Message----- > > > From: Timothy Smith [mailto:tjsmith@us.ibm.com] > > > Sent: Monday, April 10, 2006 7:11 AM > > > To: Victor Fajardo > > > Cc: dime@ietf.org; Nakhjiri Madjid-MNAKHJI1; Ram O V Vishnu-A14676 > > > Subject: Re: [Dime] CER/CEA on an open connection > > > > > > > > > > > > Hi Victor, > > > > > > Thanks for your response. Comments below" > > > >> > > > >> Good summary! I agree with most of your points. I'm not sure, > > > >> however, that I distinguish between (1) and (2). I think whether > > > >> temporary or not, we should handle CER/CEA exchanges in the same > > > manner. > > > >I'm just speculating but I think (2) refers to application change > > > >requiring a reboot. > > > >> > > > >> I agree with your design goals (3) ,(4), and suggestions (5) , (6) > > > >> , (8), and (9). > > > >If some are more in favor of scheme (5) , maybe we need more opinion > > > on > > > >whether the receiver of the CEA can always comply with the change > > > >request regardless of any scenario. I think (6) and (9) can be > > > >avoided regardless of which scheme we decide to use (see my previous > > > >reply). > > > > > > > > > > Here is the text from your previous reply: > > > "This certainly simplifies things but it also implies that the sender > > > of > > > > > > the CER mandates a change and the receiver has no choice but to accept > > > > > it. In some sense, the scheme is no longer a re-negotiation but merely > > > > > notifying the peer of a change. The proposed text was considering the > > > case where the receiver of the CER cannot comply with the change for > > > whatever reason." > > > > > > I tend to agree with the notion that the sender of the CER is > > > mandating a change. The receiver does have a choice just as it has a > > > choice in the original CER/CEA exchange. The receiver should respond > > > with the list of > > > > > > App Ids that is the intersection of what was listed in the CER and of > > > what App Ids it wishes to support. It is a renegotiation which may > > > add or remove App Ids. But either way, it is telling the other side > > > about its intentions. I don't thing the receiving side has any choice > > > > > but to participate > > > in the renegotiation. For example, if an app Id is being removed, the > > > side > > > where it is being removed renegotiates with a CER that does not > > include > > > that > > > App ID. It doesn't do the receiving side any good to decline this as > > > the App > > > will be shut down regardless. > > > > > > > > > >> Item 7, "7. Cross over and sequencing of CER/CEA exchange. We dont > > > >> think there is a problem here. Cant find any race condition." I > > > >> thought that there was a subtle problem here, but I think you are > > > >> right. Given that the connection insures sequencing, the latest > > > >> CER or CEA that you receive is what you should use as the list of > > > >> negotiated App Ids. > > > >> > > > >Mmmm... i'm not sure that the connection itself ensures sequencing. > > > >Anyway, majority rule favors removing this text. > > > >> Should there be some discussion on the retry mechanism? You send a > > > > > >> CER, and no response is received. Does this mean that the peer > > > >> just doesn't know how to renegotiate? Should we ignore and retry > > > >> every n seconds? Bring down the connection? Or do we just > > > >> continue to use the apps from the initial negotiation? My > > > >> preference on this is that we should require a CEA response to the > > > >> CER. If the CEA is not received, we shutdown the connection and > > > >> start over. This would address compatibility issues with existing > > > >> implementations. It would > > > > > > >> also be consistent with the processing of the initial CER/CEA. > > > >> > > > >The current proposal has text mentioning the use of version number of > > > > > >initial CER/CEA exchange to determine whether a peer is capable of > > > >renegotiating. If a node knows that its peer is not capable of > > > >re-negotiating then the node should not initiate re-negotiation. In > > > this > > > >scheme, existing implementations will be spared of any change. > > > > > > I'm not sure I picked up the version number. I don't see a reason to > > > do > > > > > > something special. I would simply like to renegotiate. If the other > > > side does not respond to the CER, you shut down the connection and > > > restart it > > > > > > after some period of time. This is what you would do if your initial > > > CER did not get a response. How is this different? > > > > > > > > > Best Regards, > > > Timothy Smith > > > > > > Vishnu wrote: > > > > Hi, > > > > > > > > Some clarifications and comments on the discussion on this thread: > > > > > > > > We would like to clarify the following practical scenarios of this > > > > happenning: > > > > 1. there are a list of published applications which the box support > > > > and these are installed in the box. Now, some of them go down/up. > > > > This would get translated into change in peer capabilities. > > > > 2. there is a new application which is getting installed/removed > > from > > > > the box. > > > > > > > > We think that (1) is the most probable scenario. so, > > > > there is value in giving a simple solution assuming that this change > > > (in > > > > capabilities) > > > > is most probably temporary. If this is not the case, we are talking > > > > about (2), which is a major change in the box anyways. So in (2), we > > > > > > assume it is ok to assume that > > > > the connections to be reestablished. > > > > > > > > We would like to say that our design goals are: > > > > 3. solution should be simple & as backward compatible as possible. > > > > 4. minimize the FSM changes. > > > > > > > > We suggest: > > > > 5. Updating peer capabilities done only using a CER/CEA in the open > > > > state. Sender of CER/CEA updates the local capabilities before > > > > sending the message and > > > > hence is a local decision. > > > > > > > > 6. The rest of the processing of the CER/CEA will be as per the > > > current > > > > RFC. > > > > Say for example, if there are no > > > > common applications left with that peer, > > > DIAMETER_NO_COMMON_APPLICATION > > > > is sent in the > > > > CEA and the connection is closed. > > > > > > > > Problems in the email thread under discussion & some comments: 7. > > > > Cross over and sequencing of CER/CEA exchange. We dont think there > > > is > > > > a problem > > > > here. Cant find any race condition. > > > > > > > > 8. Mutual agreement to bring down applications will not work due to > > > > possible relays in between as Tolga has pointed out in the mailing > > > > list. > > > > > > > > 9. The DPR solution in the suggested text is not a good idea. > > > > Because DPR cannot advertise the latest local applications to the > > > > peer. This may cause > > > the > > > > race condition > > > > and sequencing problem. This problem can be avoided by using the > > > > approach which we suggested in (5). > > > > > > > > Regards, > > > > Vishnu. > > > > > > tjsmith@us.ibm.com > > > (919) 254-4723 > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 12 23:54:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpzzH-0005AC-Lt; Mon, 12 Jun 2006 23:54:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpzzG-00059A-J1 for dime@ietf.org; Mon, 12 Jun 2006 23:54:42 -0400 Received: from mail12.opentransfer.com ([69.6.255.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FpzzD-00059G-UZ for dime@ietf.org; Mon, 12 Jun 2006 23:54:42 -0400 Received: (qmail 30830 invoked by uid 399); 13 Jun 2006 03:54:17 -0000 Received: from unknown (HELO prasad) (61.95.206.132) by mail.opentransfer.com with SMTP; 13 Jun 2006 03:54:17 -0000 From: To: "'zhangtao'" , Subject: RE: [Dime] Answer message processing by a relay agent Date: Tue, 13 Jun 2006 09:24:14 +0530 Message-ID: <000501c68e9d$0b3d8a70$0801a8c0@prasad> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <005801c68e89$fbdbfd40$3791460a@china.huawei.com> Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: f45599941caef2d9ac4ed98df73589d5 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1884548429==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1884548429== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C68ECB.24F5C670" This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C68ECB.24F5C670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Thanks for your response. I understand that the relay must send the answer to the original host from where the request came from. But my problem is this: when a node is acting as both client and a relay agent ( I hope this is not against RFC 3588), when the answer message comes-in, how will it know whether the message is for local consumption or it needs to be relayed. Does Proxy-Info AVP can be used for this purpose? i.e if the relay agent finds its own identity in the Proxy-Info list, then can it assume that corresponding request message to relayed and so the answer message is to be forwarded? Otherwise the answer message is for local consumption. Is this assumption is true? Thanks Prasad. -----Original Message----- From: zhangtao [mailto:zhangtao_hw@huawei.com] Sent: Tuesday, June 13, 2006 7:08 AM To: prasadsv@condornetworks.com; dime@ietf.org Subject: Re: [Dime] Answer message processing by a relay agent Proxy-Info AVP can used in relay agent. see below information:(come from rfc3588): A relay or proxy agent MAY include the Proxy-Info AVP in requests if it requires access to any local state information when the corresponding response is received. the answer message no need realm routing look-ups,see below information:(come from rfc3588) The agent MUST then send the answer to the host that it received the original request from. ----- Original Message ----- From: prasadsv@condornetworks.com To: dime@ietf.org Sent: Monday, June 12, 2006 3:19 PM Subject: [Dime] Answer message processing by a relay agent Hi, I have a question regarding the answer message processing by a relay agent. In RFC 3588 it is mentioned that realm routing table is used to route/forward an incoming REQUEST message. Is the same realm routing look-ups are used to processes the ANSWER messages? In section 2.8.1 it is simply mentioned that the replies are routed back using stored state, but it is not clear that even the answer messages processing also needs route table look-up. Also, can Proxy-Info AVP is used by relay agent or it is only for proxy? Your help is really appreciated. Thanks Prasad. Condor Networks Bangalore India. _____ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ------=_NextPart_000_0006_01C68ECB.24F5C670 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Thanks for your response. I = understand that the relay must send the answer to the original host from where the = request came from. But my problem is this: when a node is acting as both client and a = relay agent ( I hope this is not against RFC 3588), = when the answer message comes-in, how will it know whether the message is for = local consumption or it needs to be relayed. Does Proxy-Info AVP can be used = for this purpose? i.e if the relay agent finds its = own identity in the Proxy-Info list, then can it assume that corresponding = request message to relayed and so the answer message is to be forwarded? = Otherwise the answer message is for local consumption. Is this assumption is = true?

 

Thanks

Prasad.

 

 

 

-----Original = Message-----
From: zhangtao [mailto:zhangtao_hw@huawei.com]
Sent: = Tuesday, June 13, = 2006 7:08 AM
To: = prasadsv@condornetworks.com; dime@ietf.org
Subject: Re: [Dime] = Answer message processing by a relay agent

 

Proxy-Info AVP can used in = relay agent. see below information:(come from = rfc3588):

 

   A relay or = proxy agent MAY include the Proxy-Info AVP in requests if
   it requires access to any local state information when = the
   corresponding response is received. =

 

the answer message no need = realm routing look-ups,see below information:(come from = rfc3588)

 

   The agent MUST = then send the answer to the host that it received the
   original request from.

 

----- Original Message = -----

To:<= /font> dime@ietf.org =

Sent: Monday, June 12, = 2006 3:19 PM

Subject: [Dime] Answer message processing by a relay agent

 

Hi,=

 I have a question regarding the = answer message processing by a relay agent. In RFC 3588 it is mentioned that = realm routing table is used to route/forward an incoming REQUEST message. Is = the same realm routing look-ups are used to processes the ANSWER messages? In = section 2.8.1 it is simply mentioned that the replies are routed back using = stored state, but it is not clear that even the answer messages processing also = needs route table look-up.

 

Also, can Proxy-Info AVP is = used by relay agent or it is only for proxy?

 

Your help is really = appreciated.

 

Thanks

Prasad.

Condor = Networks

Bangalore

India.

______________________________________________= _
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime

------=_NextPart_000_0006_01C68ECB.24F5C670-- --===============1884548429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1884548429==-- From dime-bounces@ietf.org Tue Jun 13 02:02:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq1z6-0002g5-GQ; Tue, 13 Jun 2006 02:02:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq1z5-0002g0-PY for dime@ietf.org; Tue, 13 Jun 2006 02:02:39 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq1z2-0000Kj-11 for dime@ietf.org; Tue, 13 Jun 2006 02:02:39 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0S007F9BODRS@szxga03-in.huawei.com> for dime@ietf.org; Tue, 13 Jun 2006 14:07:25 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0S007O1BOC4J@szxga03-in.huawei.com> for dime@ietf.org; Tue, 13 Jun 2006 14:07:25 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0S00MVJBBC5Q@szxml03-in.huawei.com> for dime@ietf.org; Tue, 13 Jun 2006 13:59:37 +0800 (CST) Date: Tue, 13 Jun 2006 13:58:17 +0800 From: Tony Zhang Subject: Re: [Dime] Answer message processing by a relay agent To: prasadsv@condornetworks.com, dime@ietf.org Message-id: <000d01c68eae$5e0e0a70$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal References: <000501c68e9d$0b3d8a70$0801a8c0@prasad> X-Spam-Score: 0.1 (/) X-Scan-Signature: d4a1871e876bd836d4c351e861e8720d Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0365262376==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0365262376== Content-type: multipart/alternative; boundary="Boundary_(ID_Xuo+K/NW1WTo7UYIYwfvhg)" This is a multi-part message in MIME format. --Boundary_(ID_Xuo+K/NW1WTo7UYIYwfvhg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT You can Record cookie in proxy info AVP. the other choice is record some information in local node.when answer receive ,you can find save information,then know how to process the answer. Thanks. Tony Zhang ----- Original Message ----- From: prasadsv@condornetworks.com To: 'zhangtao' ; dime@ietf.org Sent: Tuesday, June 13, 2006 11:54 AM Subject: RE: [Dime] Answer message processing by a relay agent Hi, Thanks for your response. I understand that the relay must send the answer to the original host from where the request came from. But my problem is this: when a node is acting as both client and a relay agent ( I hope this is not against RFC 3588), when the answer message comes-in, how will it know whether the message is for local consumption or it needs to be relayed. Does Proxy-Info AVP can be used for this purpose? i.e if the relay agent finds its own identity in the Proxy-Info list, then can it assume that corresponding request message to relayed and so the answer message is to be forwarded? Otherwise the answer message is for local consumption. Is this assumption is true? Thanks Prasad. -----Original Message----- From: zhangtao [mailto:zhangtao_hw@huawei.com] Sent: Tuesday, June 13, 2006 7:08 AM To: prasadsv@condornetworks.com; dime@ietf.org Subject: Re: [Dime] Answer message processing by a relay agent Proxy-Info AVP can used in relay agent. see below information:(come from rfc3588): A relay or proxy agent MAY include the Proxy-Info AVP in requests if it requires access to any local state information when the corresponding response is received. the answer message no need realm routing look-ups,see below information:(come from rfc3588) The agent MUST then send the answer to the host that it received the original request from. ----- Original Message ----- From: prasadsv@condornetworks.com To: dime@ietf.org Sent: Monday, June 12, 2006 3:19 PM Subject: [Dime] Answer message processing by a relay agent Hi, I have a question regarding the answer message processing by a relay agent. In RFC 3588 it is mentioned that realm routing table is used to route/forward an incoming REQUEST message. Is the same realm routing look-ups are used to processes the ANSWER messages? In section 2.8.1 it is simply mentioned that the replies are routed back using stored state, but it is not clear that even the answer messages processing also needs route table look-up. Also, can Proxy-Info AVP is used by relay agent or it is only for proxy? Your help is really appreciated. Thanks Prasad. Condor Networks Bangalore India. ---------------------------------------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_Xuo+K/NW1WTo7UYIYwfvhg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
You can Record cookie in proxy info AVP.
the other choice is record some information in local node.when answer receive ,you can find save information,then know how to process the answer.
 
Thanks.
 
Tony Zhang
----- Original Message -----
Sent: Tuesday, June 13, 2006 11:54 AM
Subject: RE: [Dime] Answer message processing by a relay agent

Hi,

Thanks for your response. I understand that the relay must send the answer to the original host from where the request came from. But my problem is this: when a node is acting as both client and a relay agent ( I hope this is not against RFC 3588), when the answer message comes-in, how will it know whether the message is for local consumption or it needs to be relayed. Does Proxy-Info AVP can be used for this purpose? i.e if the relay agent finds its own identity in the Proxy-Info list, then can it assume that corresponding request message to relayed and so the answer message is to be forwarded? Otherwise the answer message is for local consumption. Is this assumption is true?

 

Thanks

Prasad.

 

 

 

-----Original Message-----
From: zhangtao [mailto:zhangtao_hw@huawei.com]
Sent: Tuesday, June 13, 2006 7:08 AM
To: prasadsv@condornetworks.com; dime@ietf.org
Subject: Re: [Dime] Answer message processing by a relay agent

 

Proxy-Info AVP can used in relay agent. see below information:(come from rfc3588):

 

   A relay or proxy agent MAY include the Proxy-Info AVP in requests if
   it requires access to any local state information when the
   corresponding response is received.

 

the answer message no need realm routing look-ups,see below information:(come from rfc3588)

 

   The agent MUST then send the answer to the host that it received the
   original request from.

 

----- Original Message -----

Sent: Monday, June 12, 2006 3:19 PM

Subject: [Dime] Answer message processing by a relay agent

 

Hi,

 I have a question regarding the answer message processing by a relay agent. In RFC 3588 it is mentioned that realm routing table is used to route/forward an incoming REQUEST message. Is the same realm routing look-ups are used to processes the ANSWER messages? In section 2.8.1 it is simply mentioned that the replies are routed back using stored state, but it is not clear that even the answer messages processing also needs route table look-up.

 

Also, can Proxy-Info AVP is used by relay agent or it is only for proxy?

 

Your help is really appreciated.

 

Thanks

Prasad.

Condor Networks

Bangalore

India.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime

--Boundary_(ID_Xuo+K/NW1WTo7UYIYwfvhg)-- --===============0365262376== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0365262376==-- From dime-bounces@ietf.org Tue Jun 13 09:11:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq8gN-0004kx-St; Tue, 13 Jun 2006 09:11:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq8gM-0004ks-CX for dime@ietf.org; Tue, 13 Jun 2006 09:11:46 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq8gL-0007nT-F6 for dime@ietf.org; Tue, 13 Jun 2006 09:11:46 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id A101F449E8 for ; Tue, 13 Jun 2006 09:11:44 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5DDBeSk004990 for ; Tue, 13 Jun 2006 09:11:43 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] CER/CEA on an open connection Date: Tue, 13 Jun 2006 08:48:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-reply-to: <00f501c68e97$4797e2a0$3791460a@china.huawei.com> Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: c3d1fcc6feccbcc611b6c309986f05f7 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tony, Please see for comments below. Tolga > -----Original Message----- > From: zhangtao [mailto:zhangtao_hw@huawei.com] > Sent: Monday, June 12, 2006 11:13 PM > To: Tolga Asveren; dime@ietf.org > Subject: Re: [Dime] CER/CEA on an open connection > > > I also agree with support Application graceful shutdown is better. > But if use error code ,it is cannot use to restore application.if > ask the proxy agent or relay agent process the error code, > maybe not so good. > > In my idea,when Application graceful shutdown,Firstly use CER notify, > Actual existed session have nothing impact,because existed > session have Destion Host AVP,so no need use routing table. [TOLGA]Actually I oversaw that and yes this should solve the issue -with no extra text-. > if application graceful shutdown ,almost have a delay > timer,before the timer fire,the application should use ASR end > the session. > if application want immediately shutdown,also should send ASR to > existed session. > The CER command is HOP by HOP,only ASR can assure will notify to > client node. [TOLGA]IMO, the server needs to wait, till the sessions are over, e.g user ends her call for a prepaid scenario, and then go offline -a timer still could be utilized for sessions, which do last longer than expected-, but this is probably not something to be standardized and better left implementation dependent. As you said, CER can be send the moment server decides not to receive new sessions for a particular application. There still is a little issue related with client behavior: When server decides to send CER, there may be already initial requests on the fly between the immediate neighbor of the server and the server. When server receives those requests, it will reply with "DIAMETER APPLICATION UNSUPPORTED" and this answer will be received by the client. Hopefully, client won't decide that the corresponding application is no more there on the server, based on that answer message -which for example would make the client cleanup all sessions to that server- > > USE the CER,just notify donnot send new session to the server,(so > recommend start session only use destion realm routing ). > When Application restore, also CER can notify. > > Application crash should check useing interim event of session, > account application already support this,other application > recommend support this also. > > Thanks, > Tony Zhang > > ----- Original Message ----- > From: "Tolga Asveren" > To: > Sent: Monday, June 12, 2006 9:52 PM > Subject: RE: [Dime] CER/CEA on an open connection > > > > After rereading the proposed text, I have some > comments/questions, mainly > > initiated by the sentence "Applications can be restarted for > various reasons > > including maintenance and upgrades." This again makes me think about > > graceful shutdown of applications, which I biefly mentioned > before on the > > mailing list. > > > > I see threee different scenarios, where application set > supported by a node > > chnages: > > a) Application is taken out for maintenance/upgrade, this I will call > > controlled shutdown. > > b) Application crashes etc..., this I will call uncontrolled shutdown. > > c) Application starts, maybe it is newly installed, or it > restarted after > > a)/b). > > > > For c), I think CER is appropriate. Also for b), I think the > same. OTOH for > > a), IMO the more useful approach is to gracefully shutdown the > application. > > This means, waiting till all pending sessions are over and only then > > shutting down the application. As an example consider a credit control > > server, where several session-based credit control sessions are > going on. I > > wouldn't think operators would be happy to sacrifice all of > those sessions > > when the application needs to be shutdown for maintenence purposes. > > > > This issue can be addressed by introducing a new error code in protocol > > errors class. If the server is in process of being gracefully > shutdown, it > > could reply with this error code for requests initiating a new session. > > Requests for existing sessions would be answered regularly. When the > > immediate neighbor of the server -which could be a client or a > relay/proxy- > > receives an answer with this new error code, it shouldn't send > new session > > requests to the server anymore -for relays/proxies this > probably corresponds > > to not to send messages which don't have a Destination-Host AVP to the > > server-. When the server has no more pending sessions, it can send CER. > > > > What do people think about this? > > > > Thanks, > > Tolga > > > > > -----Original Message----- > > > From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > > > Sent: Monday, June 05, 2006 3:40 AM > > > To: john.loughney@nokia.com > > > Cc: dime@ietf.org > > > Subject: RE: [Dime] CER/CEA on an open connection > > > > > > > > > All, > > > > > > Below is the proposed text for peer capabilities update in > Base Diameter > > > (as discussed in this email list earlier). > > > > > > John, Please advice us on the process for text proposals to *-biz > > > versions. > > > > > > Regards, > > > Vishnu. > > > > > > ------------------------------------------------------------ > > > 5.3.8 Peer Capabilities Update > > > > > > Among the capabilities exchanged during Diameter connection > > > initialization, list of supported applications by the node can change > > > dynamically. Applications can be restarted for various > reasons including > > > maintenance and upgrades. > > > > > > A Diameter node MUST initiate peer capabilities update by sending a > > > Capabilities-Exchange-Req (CER) to all its peers which supports peer > > > capabilities update and are in open state. Diameter nodes > that implement > > > peer capabilities update SHOULD check the version information > advertised > > > by its peer in the Diameter header of the previous CER/CEA exchange to > > > determine if the peer supports peer capabilities update. The Diameter > > > node MUST NOT send peer capabilities update to the peer if it > determines > > > that the peer has no support for such scheme, instead it SHOULD > > > gracefully disconnect its current connection and attempt to > establish a > > > new connection towards that peer. In either case, the Diameter node is > > > expected to advertise the most recent set of supported > applications in a > > > CER message, as specified by the peer state machine (see Section 5.6) > > > while it is in the open state. > > > > > > The receiver of CER in open state MUST process and reply to > the CER as a > > > described in Section 5.3. The CEA which the receiver sends > MUST contain > > > its latest capabilities. Note that peers which successfully > process the > > > peer capabilities update SHOULD also update their routing tables to > > > reflect the change. The receiver of the CEA, with a Result-Code AVP > > > other than DIAMETER_SUCCESS, initiates the transport disconnect. Peer > > > capabilities update in the open state SHOULD be limited to the > > > advertisement of the new list of supported applications and MUST > > > preclude re-negotiation of security mechanism or other parameters. > > > ------------------------------------------------------------ > > > > > > Regards, > > > Vishnu. > > > > > > Motorola India Electronics Pvt Ltd > > > +91 9844178052 > > > [*] Motorola Internal Use Only > > > > > > > > > > > > -----Original Message----- > > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > > Sent: Monday, April 10, 2006 8:13 PM > > > To: Tolga Asveren > > > Cc: dime@ietf.org > > > Subject: Re: [Dime] CER/CEA on an open connection > > > > > > > > > Hi All, > > > > > > > I believe in general now we all have a good understanding about what > > > > the issues are for renegotiation. It could be an idea to have a new > > > > iteration of the proposed text, and to continue the > discussions on the > > > > > > > new version. > > > > > > > > > > To that end, I'll plan on generating a new set of text maybe next week > > > as we let people digest and hopefully comment on the latest round of > > > discussion for the next couple of days. > > > > > > best regards, > > > victor > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > I believe in general now we all have a good understanding > about what the > > > issues are for renegotiation. It could be an idea to have a new > > > iteration of the proposed text, and to continue the discussions on the > > > new version. > > > > > > A few more comments/questions below. > > > > > > Thanks, > > > Tolga > > > > > > > -----Original Message----- > > > > From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > > > > Sent: Monday, April 10, 2006 2:38 AM > > > > To: dime@ietf.org > > > > Cc: Nakhjiri Madjid-MNAKHJI1 > > > > Subject: RE: [Dime] CER/CEA on an open connection > > > > > > > > > > > > Hi Victor/Timothy, > > > > > > > > 1. Comments on Retry mechanism : > > > > To summarize, we are sending CER in open state because our > > > > capabilities (supported apps) are changing and we would > like to update > > > > > > > the peer about it. We will maintain open state. > > > > > > > > we may not receive a CEA due to the following possible reasons: > > > > 1.1) The peer does not support CER in open state. In such a > case, peer > > > > > > > might still originate unsupported app messages towards us which will > > > > result in "DIAMETER_APPLICATION_UNSUPPORTED" error from us. We can > > > > leave it to the peer implementation to "correct this error" as > > > > mentioned in sec 7.1.3 of RFC 3588. This will take care of the case > > > > where there is relay/proxy in between. > > > > 1.2) Connection is lost with the peer, in which case the DWR/DWA > > > > mechanism should step in. > > > > > > > > The solution suggested by Timothy (to wait for for CEA & timer) will > > > > need changes to FSM, even though we agree that this is > consistent with > > > > > > > the initial CER/CEA scenario. > > > > > > > > Ofcourse the use of "DIAMETER_APPLICATION_UNSUPPORTED" will > result in > > > > added (unecessary traffic) incase the peer/proxy is not > clever enough > > > > to correct its behaviour. This can be avoided by using the version > > > > number exchange as Victor pointed out. So, we will not > attempt the CER > > > > > > > in open state to such a peer which doesnt support CERs in > open state, > > > > and can go for a reconnection. > > > [TOLGA]The problem case of a node not being clever enough to > take action > > > based on "DIAMETER_APPLICATION_UNSUPPORTED" is not limited to > > > renegotiations. This could happen in existing systems developed > > > according to RFC3588 as well. I would expect a node, whose > > > DIAMETER_APPLICATION_UNSUPPORTED replies are not honored by > its neighbor > > > to drop the connection, but as said this is not limited to > renegotiation > > > case. For cases, where the neighbor does not support > renegotiation, what > > > would be the result code in CEA? DIAMETER_UNABLE_TO_COMPLY? We can say > > > that such a result code in CEA should indicate that the neighbor does > > > not support renegotiations and sender of CER should/may > drop/reestablish > > > the connection. Please note that with a properly behaving neighbor, > > > dropping connection is probably not necessary because the first > > > DIAMETER_APPLICATION_UNSUPPORTED should update its tables properly. I > > > don't know whether we need to standardize how a node > determines whether > > > a neighbor honors DIAMETER_APPLICATION_UNSUPPORTED result code. > > > > > > > > 2. Comments on "re-negotiation" > > > > We think that what we need is an advertisement mechanism and not a > > > > negotiation mechanism. The CER/CEA in open state allows us > to do that. > > > > > > > We are proposing that the receiver of the CER takes the decision on > > > > the disconnection. Thus we are able to delay the disconnection > > > > (assuming that the point mentioned in my email before that the app > > > > changes are temporary). Since CER allows us to convey the latest set > > > > of supported apps to the peer, we favour the CER to the DPR. > > > > > > > > Following is a scenario where sending CER/CEA is better than the DPR > > > > mechanism. (Apologies if the figure is mangled due to tab settings). > > > [TOLGA]Although the example case below is a race condition which > > > probably won't happen very often -it relies on changing supported > > > application set on two nodes more or less simultaneously-, I > also prefer > > > relying on CER in such a situation, so that there is a single way of > > > handling renegotiations in terms of advertising changes to the > > > neighbors. > > > > > > > > Initial exchanged app list: > > > > A: 1,2,3 B:2 > > > > 2 went down 3 came up just when 2 went down on A > > > > ________ ________ > > > > |A |----DPR---> |B | > > > > | | | | > > > > | |<---CER---- | | > > > > |______| [3] |______| > > > > <---DPA---- > > > > > > > > this in our understanding will result in reconnection even > thou there > > > > is 3 in common. > > > > > > > > Initial exchanged app list: > > > > A: 1,2,3 B:2 > > > > 2 went down 3 came up just when 2 went down on A > > > > ________ ________ > > > > |A |----CER---> |B | > > > > | | [1,3] | | > > > > | |<---CER---- | | > > > > |_______| [2,3] |_______| > > > > ----CEA----> > > > > [1,3] > > > > <---CEA----- > > > > [2,3] > > > > This will avoid a reconnection, because 3 is in common. > > > > > > > > Regards, > > > > Vishnu. > > > > > > > > Motorola India Electronics Pvt Ltd > > > > +91 9844178052 > > > > [*] Motorola Internal Use Only > > > > > > > > > > > > -----Original Message----- > > > > From: Timothy Smith [mailto:tjsmith@us.ibm.com] > > > > Sent: Monday, April 10, 2006 7:11 AM > > > > To: Victor Fajardo > > > > Cc: dime@ietf.org; Nakhjiri Madjid-MNAKHJI1; Ram O V Vishnu-A14676 > > > > Subject: Re: [Dime] CER/CEA on an open connection > > > > > > > > > > > > > > > > Hi Victor, > > > > > > > > Thanks for your response. Comments below" > > > > >> > > > > >> Good summary! I agree with most of your points. I'm not sure, > > > > >> however, that I distinguish between (1) and (2). I think whether > > > > >> temporary or not, we should handle CER/CEA exchanges in the same > > > > manner. > > > > >I'm just speculating but I think (2) refers to application change > > > > >requiring a reboot. > > > > >> > > > > >> I agree with your design goals (3) ,(4), and suggestions > (5) , (6) > > > > >> , (8), and (9). > > > > >If some are more in favor of scheme (5) , maybe we need > more opinion > > > > on > > > > >whether the receiver of the CEA can always comply with the change > > > > >request regardless of any scenario. I think (6) and (9) can be > > > > >avoided regardless of which scheme we decide to use (see > my previous > > > > >reply). > > > > > > > > > > > > > Here is the text from your previous reply: > > > > "This certainly simplifies things but it also implies that > the sender > > > > of > > > > > > > > the CER mandates a change and the receiver has no choice > but to accept > > > > > > > it. In some sense, the scheme is no longer a re-negotiation > but merely > > > > > > > notifying the peer of a change. The proposed text was > considering the > > > > case where the receiver of the CER cannot comply with the change for > > > > whatever reason." > > > > > > > > I tend to agree with the notion that the sender of the CER is > > > > mandating a change. The receiver does have a choice just > as it has a > > > > choice in the original CER/CEA exchange. The receiver > should respond > > > > with the list of > > > > > > > > App Ids that is the intersection of what was listed in the > CER and of > > > > what App Ids it wishes to support. It is a renegotiation which may > > > > add or remove App Ids. But either way, it is telling the other side > > > > about its intentions. I don't thing the receiving side has > any choice > > > > > > > but to participate > > > > in the renegotiation. For example, if an app Id is being > removed, the > > > > side > > > > where it is being removed renegotiates with a CER that does not > > > include > > > > that > > > > App ID. It doesn't do the receiving side any good to > decline this as > > > > the App > > > > will be shut down regardless. > > > > > > > > > > > > >> Item 7, "7. Cross over and sequencing of CER/CEA > exchange. We dont > > > > >> think there is a problem here. Cant find any race condition." I > > > > >> thought that there was a subtle problem here, but I think you are > > > > >> right. Given that the connection insures sequencing, the latest > > > > >> CER or CEA that you receive is what you should use as the list of > > > > >> negotiated App Ids. > > > > >> > > > > >Mmmm... i'm not sure that the connection itself ensures sequencing. > > > > >Anyway, majority rule favors removing this text. > > > > >> Should there be some discussion on the retry mechanism? > You send a > > > > > > > >> CER, and no response is received. Does this mean that the peer > > > > >> just doesn't know how to renegotiate? Should we ignore and retry > > > > >> every n seconds? Bring down the connection? Or do we just > > > > >> continue to use the apps from the initial negotiation? My > > > > >> preference on this is that we should require a CEA > response to the > > > > >> CER. If the CEA is not received, we shutdown the connection and > > > > >> start over. This would address compatibility issues > with existing > > > > >> implementations. It would > > > > > > > > >> also be consistent with the processing of the initial CER/CEA. > > > > >> > > > > >The current proposal has text mentioning the use of > version number of > > > > > > > >initial CER/CEA exchange to determine whether a peer is capable of > > > > >renegotiating. If a node knows that its peer is not capable of > > > > >re-negotiating then the node should not initiate re-negotiation. In > > > > this > > > > >scheme, existing implementations will be spared of any change. > > > > > > > > I'm not sure I picked up the version number. I don't see a > reason to > > > > do > > > > > > > > something special. I would simply like to renegotiate. If > the other > > > > side does not respond to the CER, you shut down the connection and > > > > restart it > > > > > > > > after some period of time. This is what you would do if > your initial > > > > CER did not get a response. How is this different? > > > > > > > > > > > > Best Regards, > > > > Timothy Smith > > > > > > > > Vishnu wrote: > > > > > Hi, > > > > > > > > > > Some clarifications and comments on the discussion on this thread: > > > > > > > > > > We would like to clarify the following practical scenarios of this > > > > > happenning: > > > > > 1. there are a list of published applications which the > box support > > > > > and these are installed in the box. Now, some of them go down/up. > > > > > This would get translated into change in peer capabilities. > > > > > 2. there is a new application which is getting installed/removed > > > from > > > > > the box. > > > > > > > > > > We think that (1) is the most probable scenario. so, > > > > > there is value in giving a simple solution assuming that > this change > > > > (in > > > > > capabilities) > > > > > is most probably temporary. If this is not the case, we > are talking > > > > > about (2), which is a major change in the box anyways. So > in (2), we > > > > > > > > assume it is ok to assume that > > > > > the connections to be reestablished. > > > > > > > > > > We would like to say that our design goals are: > > > > > 3. solution should be simple & as backward compatible as possible. > > > > > 4. minimize the FSM changes. > > > > > > > > > > We suggest: > > > > > 5. Updating peer capabilities done only using a CER/CEA > in the open > > > > > state. Sender of CER/CEA updates the local capabilities before > > > > > sending the message and > > > > > hence is a local decision. > > > > > > > > > > 6. The rest of the processing of the CER/CEA will be as per the > > > > current > > > > > RFC. > > > > > Say for example, if there are no > > > > > common applications left with that peer, > > > > DIAMETER_NO_COMMON_APPLICATION > > > > > is sent in the > > > > > CEA and the connection is closed. > > > > > > > > > > Problems in the email thread under discussion & some comments: 7. > > > > > Cross over and sequencing of CER/CEA exchange. We dont think there > > > > is > > > > > a problem > > > > > here. Cant find any race condition. > > > > > > > > > > 8. Mutual agreement to bring down applications will not > work due to > > > > > possible relays in between as Tolga has pointed out in the mailing > > > > > list. > > > > > > > > > > 9. The DPR solution in the suggested text is not a good idea. > > > > > Because DPR cannot advertise the latest local applications to the > > > > > peer. This may cause > > > > the > > > > > race condition > > > > > and sequencing problem. This problem can be avoided by using the > > > > > approach which we suggested in (5). > > > > > > > > > > Regards, > > > > > Vishnu. > > > > > > > > tjsmith@us.ibm.com > > > > (919) 254-4723 > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 13 22:08:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqKnZ-0001Vu-Hm; Tue, 13 Jun 2006 22:08:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqKnY-0001Vp-MR for dime@ietf.org; Tue, 13 Jun 2006 22:08:00 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqKnV-0007CV-Nl for dime@ietf.org; Tue, 13 Jun 2006 22:08:00 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0T00BM3VON97@szxga02-in.huawei.com> for dime@ietf.org; Wed, 14 Jun 2006 10:17:11 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0T00G64VOL7X@szxga02-in.huawei.com> for dime@ietf.org; Wed, 14 Jun 2006 10:17:11 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0T002Z1VFXHH@szxml04-in.huawei.com> for dime@ietf.org; Wed, 14 Jun 2006 10:11:58 +0800 (CST) Date: Wed, 14 Jun 2006 10:01:22 +0800 From: Tony Zhang Subject: Re: [Dime] CER/CEA on an open connection To: Tolga Asveren , dime@ietf.org Message-id: <003001c68f56$6f5727a0$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 94ddbad0060c343c23e74ba9bbebbccf Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org TOLGA, Please see inline comments. Regards Tony Zhang > > > > I also agree with support Application graceful shutdown is better. > > But if use error code ,it is cannot use to restore application.if > > ask the proxy agent or relay agent process the error code, > > maybe not so good. > > > > In my idea,when Application graceful shutdown,Firstly use CER notify, > > Actual existed session have nothing impact,because existed > > session have Destion Host AVP,so no need use routing table. > [TOLGA]Actually I oversaw that and yes this should solve the issue -with no > extra text-. > > if application graceful shutdown ,almost have a delay > > timer,before the timer fire,the application should use ASR end > > the session. > > if application want immediately shutdown,also should send ASR to > > existed session. > > The CER command is HOP by HOP,only ASR can assure will notify to > > client node. > [TOLGA]IMO, the server needs to wait, till the sessions are over, e.g user > ends her call for a prepaid scenario, and then go offline -a timer still > could be utilized for sessions, which do last longer than expected-, but > this is probably not something to be standardized and better left > implementation dependent. As you said, CER can be send the moment server > decides not to receive new sessions for a particular application. > > There still is a little issue related with client behavior: > When server decides to send CER, there may be already initial requests on > the fly between the immediate neighbor of the server and the server. When > server receives those requests, it will reply with "DIAMETER APPLICATION > UNSUPPORTED" and this answer will be received by the client. Hopefully, > client won't decide that the corresponding application is no more there on > the server, based on that answer message -which for example would make the > client cleanup all sessions to that server- [Tony]Maybe Relay with Transient Failure is better,like "DIAMETER_AUTHENTICATION_REJECTED", "DIAMETER APPLICATION_UNSUPPORTED" is protocol Error > > > > USE the CER,just notify donnot send new session to the server,(so > > recommend start session only use destion realm routing ). > > When Application restore, also CER can notify. > > > > Application crash should check useing interim event of session, > > account application already support this,other application > > recommend support this also. > > > > Thanks, > > Tony Zhang > > > > ----- Original Message ----- > > From: "Tolga Asveren" > > To: > > Sent: Monday, June 12, 2006 9:52 PM > > Subject: RE: [Dime] CER/CEA on an open connection > > > > > > > After rereading the proposed text, I have some > > comments/questions, mainly > > > initiated by the sentence "Applications can be restarted for > > various reasons > > > including maintenance and upgrades." This again makes me think about > > > graceful shutdown of applications, which I biefly mentioned > > before on the > > > mailing list. > > > > > > I see threee different scenarios, where application set > > supported by a node > > > chnages: > > > a) Application is taken out for maintenance/upgrade, this I will call > > > controlled shutdown. > > > b) Application crashes etc..., this I will call uncontrolled shutdown. > > > c) Application starts, maybe it is newly installed, or it > > restarted after > > > a)/b). > > > > > > For c), I think CER is appropriate. Also for b), I think the > > same. OTOH for > > > a), IMO the more useful approach is to gracefully shutdown the > > application. > > > This means, waiting till all pending sessions are over and only then > > > shutting down the application. As an example consider a credit control > > > server, where several session-based credit control sessions are > > going on. I > > > wouldn't think operators would be happy to sacrifice all of > > those sessions > > > when the application needs to be shutdown for maintenence purposes. > > > > > > This issue can be addressed by introducing a new error code in protocol > > > errors class. If the server is in process of being gracefully > > shutdown, it > > > could reply with this error code for requests initiating a new session. > > > Requests for existing sessions would be answered regularly. When the > > > immediate neighbor of the server -which could be a client or a > > relay/proxy- > > > receives an answer with this new error code, it shouldn't send > > new session > > > requests to the server anymore -for relays/proxies this > > probably corresponds > > > to not to send messages which don't have a Destination-Host AVP to the > > > server-. When the server has no more pending sessions, it can send CER. > > > > > > What do people think about this? > > > > > > Thanks, > > > Tolga > > > > > > > -----Original Message----- > > > > From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > > > > Sent: Monday, June 05, 2006 3:40 AM > > > > To: john.loughney@nokia.com > > > > Cc: dime@ietf.org > > > > Subject: RE: [Dime] CER/CEA on an open connection > > > > > > > > > > > > All, > > > > > > > > Below is the proposed text for peer capabilities update in > > Base Diameter > > > > (as discussed in this email list earlier). > > > > > > > > John, Please advice us on the process for text proposals to *-biz > > > > versions. > > > > > > > > Regards, > > > > Vishnu. > > > > > > > > ------------------------------------------------------------ > > > > 5.3.8 Peer Capabilities Update > > > > > > > > Among the capabilities exchanged during Diameter connection > > > > initialization, list of supported applications by the node can change > > > > dynamically. Applications can be restarted for various > > reasons including > > > > maintenance and upgrades. > > > > > > > > A Diameter node MUST initiate peer capabilities update by sending a > > > > Capabilities-Exchange-Req (CER) to all its peers which supports peer > > > > capabilities update and are in open state. Diameter nodes > > that implement > > > > peer capabilities update SHOULD check the version information > > advertised > > > > by its peer in the Diameter header of the previous CER/CEA exchange to > > > > determine if the peer supports peer capabilities update. The Diameter > > > > node MUST NOT send peer capabilities update to the peer if it > > determines > > > > that the peer has no support for such scheme, instead it SHOULD > > > > gracefully disconnect its current connection and attempt to > > establish a > > > > new connection towards that peer. In either case, the Diameter node is > > > > expected to advertise the most recent set of supported > > applications in a > > > > CER message, as specified by the peer state machine (see Section 5.6) > > > > while it is in the open state. > > > > > > > > The receiver of CER in open state MUST process and reply to > > the CER as a > > > > described in Section 5.3. The CEA which the receiver sends > > MUST contain > > > > its latest capabilities. Note that peers which successfully > > process the > > > > peer capabilities update SHOULD also update their routing tables to > > > > reflect the change. The receiver of the CEA, with a Result-Code AVP > > > > other than DIAMETER_SUCCESS, initiates the transport disconnect. Peer > > > > capabilities update in the open state SHOULD be limited to the > > > > advertisement of the new list of supported applications and MUST > > > > preclude re-negotiation of security mechanism or other parameters. > > > > ------------------------------------------------------------ > > > > > > > > Regards, > > > > Vishnu. > > > > > > > > Motorola India Electronics Pvt Ltd > > > > +91 9844178052 > > > > [*] Motorola Internal Use Only > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > > > Sent: Monday, April 10, 2006 8:13 PM > > > > To: Tolga Asveren > > > > Cc: dime@ietf.org > > > > Subject: Re: [Dime] CER/CEA on an open connection > > > > > > > > > > > > Hi All, > > > > > > > > > I believe in general now we all have a good understanding about what > > > > > the issues are for renegotiation. It could be an idea to have a new > > > > > iteration of the proposed text, and to continue the > > discussions on the > > > > > > > > > new version. > > > > > > > > > > > > > To that end, I'll plan on generating a new set of text maybe next week > > > > as we let people digest and hopefully comment on the latest round of > > > > discussion for the next couple of days. > > > > > > > > best regards, > > > > victor > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > I believe in general now we all have a good understanding > > about what the > > > > issues are for renegotiation. It could be an idea to have a new > > > > iteration of the proposed text, and to continue the discussions on the > > > > new version. > > > > > > > > A few more comments/questions below. > > > > > > > > Thanks, > > > > Tolga > > > > > > > > > -----Original Message----- > > > > > From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > > > > > Sent: Monday, April 10, 2006 2:38 AM > > > > > To: dime@ietf.org > > > > > Cc: Nakhjiri Madjid-MNAKHJI1 > > > > > Subject: RE: [Dime] CER/CEA on an open connection > > > > > > > > > > > > > > > Hi Victor/Timothy, > > > > > > > > > > 1. Comments on Retry mechanism : > > > > > To summarize, we are sending CER in open state because our > > > > > capabilities (supported apps) are changing and we would > > like to update > > > > > > > > > the peer about it. We will maintain open state. > > > > > > > > > > we may not receive a CEA due to the following possible reasons: > > > > > 1.1) The peer does not support CER in open state. In such a > > case, peer > > > > > > > > > might still originate unsupported app messages towards us which will > > > > > result in "DIAMETER_APPLICATION_UNSUPPORTED" error from us. We can > > > > > leave it to the peer implementation to "correct this error" as > > > > > mentioned in sec 7.1.3 of RFC 3588. This will take care of the case > > > > > where there is relay/proxy in between. > > > > > 1.2) Connection is lost with the peer, in which case the DWR/DWA > > > > > mechanism should step in. > > > > > > > > > > The solution suggested by Timothy (to wait for for CEA & timer) will > > > > > need changes to FSM, even though we agree that this is > > consistent with > > > > > > > > > the initial CER/CEA scenario. > > > > > > > > > > Ofcourse the use of "DIAMETER_APPLICATION_UNSUPPORTED" will > > result in > > > > > added (unecessary traffic) incase the peer/proxy is not > > clever enough > > > > > to correct its behaviour. This can be avoided by using the version > > > > > number exchange as Victor pointed out. So, we will not > > attempt the CER > > > > > > > > > in open state to such a peer which doesnt support CERs in > > open state, > > > > > and can go for a reconnection. > > > > [TOLGA]The problem case of a node not being clever enough to > > take action > > > > based on "DIAMETER_APPLICATION_UNSUPPORTED" is not limited to > > > > renegotiations. This could happen in existing systems developed > > > > according to RFC3588 as well. I would expect a node, whose > > > > DIAMETER_APPLICATION_UNSUPPORTED replies are not honored by > > its neighbor > > > > to drop the connection, but as said this is not limited to > > renegotiation > > > > case. For cases, where the neighbor does not support > > renegotiation, what > > > > would be the result code in CEA? DIAMETER_UNABLE_TO_COMPLY? We can say > > > > that such a result code in CEA should indicate that the neighbor does > > > > not support renegotiations and sender of CER should/may > > drop/reestablish > > > > the connection. Please note that with a properly behaving neighbor, > > > > dropping connection is probably not necessary because the first > > > > DIAMETER_APPLICATION_UNSUPPORTED should update its tables properly. I > > > > don't know whether we need to standardize how a node > > determines whether > > > > a neighbor honors DIAMETER_APPLICATION_UNSUPPORTED result code. > > > > > > > > > > 2. Comments on "re-negotiation" > > > > > We think that what we need is an advertisement mechanism and not a > > > > > negotiation mechanism. The CER/CEA in open state allows us > > to do that. > > > > > > > > > We are proposing that the receiver of the CER takes the decision on > > > > > the disconnection. Thus we are able to delay the disconnection > > > > > (assuming that the point mentioned in my email before that the app > > > > > changes are temporary). Since CER allows us to convey the latest set > > > > > of supported apps to the peer, we favour the CER to the DPR. > > > > > > > > > > Following is a scenario where sending CER/CEA is better than the DPR > > > > > mechanism. (Apologies if the figure is mangled due to tab settings). > > > > [TOLGA]Although the example case below is a race condition which > > > > probably won't happen very often -it relies on changing supported > > > > application set on two nodes more or less simultaneously-, I > > also prefer > > > > relying on CER in such a situation, so that there is a single way of > > > > handling renegotiations in terms of advertising changes to the > > > > neighbors. > > > > > > > > > > Initial exchanged app list: > > > > > A: 1,2,3 B:2 > > > > > 2 went down 3 came up just when 2 went down on A > > > > > ________ ________ > > > > > |A |----DPR---> |B | > > > > > | | | | > > > > > | |<---CER---- | | > > > > > |______| [3] |______| > > > > > <---DPA---- > > > > > > > > > > this in our understanding will result in reconnection even > > thou there > > > > > is 3 in common. > > > > > > > > > > Initial exchanged app list: > > > > > A: 1,2,3 B:2 > > > > > 2 went down 3 came up just when 2 went down on A > > > > > ________ ________ > > > > > |A |----CER---> |B | > > > > > | | [1,3] | | > > > > > | |<---CER---- | | > > > > > |_______| [2,3] |_______| > > > > > ----CEA----> > > > > > [1,3] > > > > > <---CEA----- > > > > > [2,3] > > > > > This will avoid a reconnection, because 3 is in common. > > > > > > > > > > Regards, > > > > > Vishnu. > > > > > > > > > > Motorola India Electronics Pvt Ltd > > > > > +91 9844178052 > > > > > [*] Motorola Internal Use Only > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Timothy Smith [mailto:tjsmith@us.ibm.com] > > > > > Sent: Monday, April 10, 2006 7:11 AM > > > > > To: Victor Fajardo > > > > > Cc: dime@ietf.org; Nakhjiri Madjid-MNAKHJI1; Ram O V Vishnu-A14676 > > > > > Subject: Re: [Dime] CER/CEA on an open connection > > > > > > > > > > > > > > > > > > > > Hi Victor, > > > > > > > > > > Thanks for your response. Comments below" > > > > > >> > > > > > >> Good summary! I agree with most of your points. I'm not sure, > > > > > >> however, that I distinguish between (1) and (2). I think whether > > > > > >> temporary or not, we should handle CER/CEA exchanges in the same > > > > > manner. > > > > > >I'm just speculating but I think (2) refers to application change > > > > > >requiring a reboot. > > > > > >> > > > > > >> I agree with your design goals (3) ,(4), and suggestions > > (5) , (6) > > > > > >> , (8), and (9). > > > > > >If some are more in favor of scheme (5) , maybe we need > > more opinion > > > > > on > > > > > >whether the receiver of the CEA can always comply with the change > > > > > >request regardless of any scenario. I think (6) and (9) can be > > > > > >avoided regardless of which scheme we decide to use (see > > my previous > > > > > >reply). > > > > > > > > > > > > > > > > Here is the text from your previous reply: > > > > > "This certainly simplifies things but it also implies that > > the sender > > > > > of > > > > > > > > > > the CER mandates a change and the receiver has no choice > > but to accept > > > > > > > > > it. In some sense, the scheme is no longer a re-negotiation > > but merely > > > > > > > > > notifying the peer of a change. The proposed text was > > considering the > > > > > case where the receiver of the CER cannot comply with the change for > > > > > whatever reason." > > > > > > > > > > I tend to agree with the notion that the sender of the CER is > > > > > mandating a change. The receiver does have a choice just > > as it has a > > > > > choice in the original CER/CEA exchange. The receiver > > should respond > > > > > with the list of > > > > > > > > > > App Ids that is the intersection of what was listed in the > > CER and of > > > > > what App Ids it wishes to support. It is a renegotiation which may > > > > > add or remove App Ids. But either way, it is telling the other side > > > > > about its intentions. I don't thing the receiving side has > > any choice > > > > > > > > > but to participate > > > > > in the renegotiation. For example, if an app Id is being > > removed, the > > > > > side > > > > > where it is being removed renegotiates with a CER that does not > > > > include > > > > > that > > > > > App ID. It doesn't do the receiving side any good to > > decline this as > > > > > the App > > > > > will be shut down regardless. > > > > > > > > > > > > > > > >> Item 7, "7. Cross over and sequencing of CER/CEA > > exchange. We dont > > > > > >> think there is a problem here. Cant find any race condition." I > > > > > >> thought that there was a subtle problem here, but I think you are > > > > > >> right. Given that the connection insures sequencing, the latest > > > > > >> CER or CEA that you receive is what you should use as the list of > > > > > >> negotiated App Ids. > > > > > >> > > > > > >Mmmm... i'm not sure that the connection itself ensures sequencing. > > > > > >Anyway, majority rule favors removing this text. > > > > > >> Should there be some discussion on the retry mechanism? > > You send a > > > > > > > > > >> CER, and no response is received. Does this mean that the peer > > > > > >> just doesn't know how to renegotiate? Should we ignore and retry > > > > > >> every n seconds? Bring down the connection? Or do we just > > > > > >> continue to use the apps from the initial negotiation? My > > > > > >> preference on this is that we should require a CEA > > response to the > > > > > >> CER. If the CEA is not received, we shutdown the connection and > > > > > >> start over. This would address compatibility issues > > with existing > > > > > >> implementations. It would > > > > > > > > > > >> also be consistent with the processing of the initial CER/CEA. > > > > > >> > > > > > >The current proposal has text mentioning the use of > > version number of > > > > > > > > > >initial CER/CEA exchange to determine whether a peer is capable of > > > > > >renegotiating. If a node knows that its peer is not capable of > > > > > >re-negotiating then the node should not initiate re-negotiation. In > > > > > this > > > > > >scheme, existing implementations will be spared of any change. > > > > > > > > > > I'm not sure I picked up the version number. I don't see a > > reason to > > > > > do > > > > > > > > > > something special. I would simply like to renegotiate. If > > the other > > > > > side does not respond to the CER, you shut down the connection and > > > > > restart it > > > > > > > > > > after some period of time. This is what you would do if > > your initial > > > > > CER did not get a response. How is this different? > > > > > > > > > > > > > > > Best Regards, > > > > > Timothy Smith > > > > > > > > > > Vishnu wrote: > > > > > > Hi, > > > > > > > > > > > > Some clarifications and comments on the discussion on this thread: > > > > > > > > > > > > We would like to clarify the following practical scenarios of this > > > > > > happenning: > > > > > > 1. there are a list of published applications which the > > box support > > > > > > and these are installed in the box. Now, some of them go down/up. > > > > > > This would get translated into change in peer capabilities. > > > > > > 2. there is a new application which is getting installed/removed > > > > from > > > > > > the box. > > > > > > > > > > > > We think that (1) is the most probable scenario. so, > > > > > > there is value in giving a simple solution assuming that > > this change > > > > > (in > > > > > > capabilities) > > > > > > is most probably temporary. If this is not the case, we > > are talking > > > > > > about (2), which is a major change in the box anyways. So > > in (2), we > > > > > > > > > > assume it is ok to assume that > > > > > > the connections to be reestablished. > > > > > > > > > > > > We would like to say that our design goals are: > > > > > > 3. solution should be simple & as backward compatible as possible. > > > > > > 4. minimize the FSM changes. > > > > > > > > > > > > We suggest: > > > > > > 5. Updating peer capabilities done only using a CER/CEA > > in the open > > > > > > state. Sender of CER/CEA updates the local capabilities before > > > > > > sending the message and > > > > > > hence is a local decision. > > > > > > > > > > > > 6. The rest of the processing of the CER/CEA will be as per the > > > > > current > > > > > > RFC. > > > > > > Say for example, if there are no > > > > > > common applications left with that peer, > > > > > DIAMETER_NO_COMMON_APPLICATION > > > > > > is sent in the > > > > > > CEA and the connection is closed. > > > > > > > > > > > > Problems in the email thread under discussion & some comments: 7. > > > > > > Cross over and sequencing of CER/CEA exchange. We dont think there > > > > > is > > > > > > a problem > > > > > > here. Cant find any race condition. > > > > > > > > > > > > 8. Mutual agreement to bring down applications will not > > work due to > > > > > > possible relays in between as Tolga has pointed out in the mailing > > > > > > list. > > > > > > > > > > > > 9. The DPR solution in the suggested text is not a good idea. > > > > > > Because DPR cannot advertise the latest local applications to the > > > > > > peer. This may cause > > > > > the > > > > > > race condition > > > > > > and sequencing problem. This problem can be avoided by using the > > > > > > approach which we suggested in (5). > > > > > > > > > > > > Regards, > > > > > > Vishnu. > > > > > > > > > > tjsmith@us.ibm.com > > > > > (919) 254-4723 > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 14 10:06:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqW0n-0007nX-Kk; Wed, 14 Jun 2006 10:06:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqW0l-0007nO-Sm for dime@ietf.org; Wed, 14 Jun 2006 10:06:23 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqW0k-00072n-Cm for dime@ietf.org; Wed, 14 Jun 2006 10:06:23 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5EE6LSN019458 for ; Wed, 14 Jun 2006 17:06:21 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 17:06:21 +0300 Received: from [127.0.0.1] ([172.21.35.108]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 14 Jun 2006 17:06:20 +0300 Message-ID: <449017DC.8010908@nokia.com> Date: Wed, 14 Jun 2006 17:06:20 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2006 14:06:20.0795 (UTC) FILETIME=[B65EA4B0:01C68FBB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Dime] AAA URI draft submitted X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi: One of the milestones that we have in our charter relates to the AAA URI draft, a draft that some time ago was a WG item in the AAA WG, and we decided to postpone it to maintenance. I have now resubmitted the original draft. I have just done an update, since a few RFCs have been revisted (e.g., ABNF, Generic URI syntax), but essentially, there aren't changes with respect the version we used to have in the AAA WG. While the document is posted, you can download it from: http://people.nokia.net/~miguel/drafts/draft-garcia-dime-aaa-uri-00.txt http://people.nokia.net/~miguel/drafts/draft-garcia-dime-aaa-uri-00.html Now, I would like to have a discussion on a few topics. 1) Are people interested on fixing the AAA URI? 2) Are people interested on registering the AAA URI scheme with IANA. 3) Do people think that an incompatible change is the approach we should follow? I believe in a YES for 1 and 2. However, I think that this isn't anymore a quick update to RFC 3588, which was the original intention of the draft. Instead, we should have a compatible change that allows a smooth transition in existing Diameter implementations. Perhaps we should be looking at a Diameter URI after all, something that could be even advertised in CER/CEA and deprecate the AAA URI. Well, I would like to hear opinions on the topic. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 14 17:03:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqcWH-0000FA-KJ; Wed, 14 Jun 2006 17:03:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqcWG-0000F1-Od for dime@ietf.org; Wed, 14 Jun 2006 17:03:20 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqcWF-0000Yf-Fr for dime@ietf.org; Wed, 14 Jun 2006 17:03:20 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id D8416E8548 for ; Wed, 14 Jun 2006 17:03:19 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5EL3IAR026947 for ; Wed, 14 Jun 2006 17:03:18 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] CER/CEA on an open connection Date: Wed, 14 Jun 2006 16:40:46 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-reply-to: <003001c68f56$6f5727a0$3791460a@china.huawei.com> Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org inline.... [.. snip ..] > > There still is a little issue related with client behavior: > > When server decides to send CER, there may be already initial > requests on > > the fly between the immediate neighbor of the server and the > server. When > > server receives those requests, it will reply with "DIAMETER APPLICATION > > UNSUPPORTED" and this answer will be received by the client. Hopefully, > > client won't decide that the corresponding application is no > more there on > > the server, based on that answer message -which for example > would make the > > client cleanup all sessions to that server- > [Tony]Maybe Relay with Transient Failure is better,like > "DIAMETER_AUTHENTICATION_REJECTED", > "DIAMETER APPLICATION_UNSUPPORTED" is protocol Error [TOLGA]I see two problems with that approach: a)"DIAMETER_AUTHENTICATION_REJECTED" has a misleading meaning for such a case. Client would interprete this that for some reason -which is related with the user itself- the user is not permitted to receive the service. b)A Protocol Error would allow a relay agent to retry another server, which I would think is a nice way of handling this situation. IMO, among the existing error codes "DIAMETER_UNABLE_TO_DELIVER" seem to be the least unsuitable one to use for this scenario (I know it is supposed to be used by intermediares but as said it is the least of the many evils). Actually I would prefer a new error code -or at least rewording the description for DIAMETER_UNABLE_TO_DELIVER-. Whatever decision we are going to have, IMO the behavior about handling initial requests during a graceful shutdown needs to be documented, the reply generated will be received/processed by relays/clients and correct interpretation of this reply is important, hence it is a protocol issue. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 14 20:01:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqfIy-0007o3-UI; Wed, 14 Jun 2006 20:01:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqfIy-0007ny-FI for dime@ietf.org; Wed, 14 Jun 2006 20:01:48 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqfIx-0006qI-47 for dime@ietf.org; Wed, 14 Jun 2006 20:01:48 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 14 Jun 2006 17:01:45 -0700 X-IronPort-AV: i="4.06,133,1149490800"; d="scan'208"; a="294922462:sNHT1895646046" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5F01jjE015858; Wed, 14 Jun 2006 17:01:45 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5F01jke008311; Wed, 14 Jun 2006 17:01:45 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 17:01:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Jun 2006 17:01:44 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625022AF3DE@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Contradiction in RFC 4006 Thread-Index: AcaQDuLSTdT4GsAXTuOoy9vH8jO4yA== From: "Glen Zorn \(gwz\)" To: X-OriginalArrivalTime: 15 Jun 2006 00:01:45.0431 (UTC) FILETIME=[E3E97E70:01C6900E] DKIM-Signature: a=rsa-sha1; q=dns; l=986; t=1150329705; x=1151193705; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:Contradiction=20in=20RFC=204006; X=v=3Dcisco.com=3B=20h=3DkqSv0/r0YgZAnV5i2FgvF4E9OBI=3D; b=LyFQDp1LLmHXhj+NZJQRjw7HkhtKMki/7AUXOwlaMYWn6xeMamynnUi3bLIVu/46R5TBS2kt JXH6v8xrrQzDtnbKmZsuBUWCJhLbFgwLipK7P8WXaqlfGPbaAkpkPRyz; Authentication-Results: sj-dkim-1.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: dime@ietf.org, "Glen Zorn \(gwz\)" Subject: [Dime] Contradiction in RFC 4006 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Section 5.6.3 says=20 "A Final-Unit-Indication AVP with the Final-Unit-Action RESTRICT_ACCESS [in the CCA message] indicates to the=20 device supporting this action that the user's access MUST be restricted according to the IP packet filters given in the Restriction-Filter-Rule AVP(s) or according to the IP packet filters identified by the Filter-Id AVP(s)." However, the next sentence says "The credit-control server SHOULD include either the Restriction-Filter- Rule AVP or the Filter-Id AVP in the Credit-Control-Answer message." So, what happens if the referenced AVPs are not included in the CCA? ~gwz Treat the Earth well.=20 It was not given to you by your parents. It was loaned to you by your children. -- Kenyan Proverb Humankind has not woven the web of life. We are but one thread within it. Whatever we do to the web, we do to ourselves. All things are bound together. All things connect. -- Chief Seattle _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 14 20:58:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqgC5-0006kH-Bi; Wed, 14 Jun 2006 20:58:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqgC4-0006k0-Fi for dime@ietf.org; Wed, 14 Jun 2006 20:58:44 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqgC3-0003kV-6N for dime@ietf.org; Wed, 14 Jun 2006 20:58:44 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 14 Jun 2006 17:58:42 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5F0wgvS013424; Wed, 14 Jun 2006 17:58:42 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5F0wgCU023868; Wed, 14 Jun 2006 17:58:42 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 17:58:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Jun 2006 17:58:41 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625022AF416@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter base protocol messages used by DCCA Thread-Index: AcaQFtdWbbQIqFPKQrKpALl9+xwUdA== From: "Glen Zorn \(gwz\)" To: , , , , X-OriginalArrivalTime: 15 Jun 2006 00:58:42.0122 (UTC) FILETIME=[D86B2AA0:01C69016] DKIM-Signature: a=rsa-sha1; q=dns; l=971; t=1150333122; x=1151197122; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:Diameter=20base=20protocol=20messages=20used=20by=20DCCA; X=v=3Dcisco.com=3B=20h=3DkKGMDndThaQh9+mGb7YQFduWJNI=3D; b=ebdwiYNbkK6VhkJFQvOz9WrTjQmIMatd4FcuAF9vxC+S6udBE/71d77axicexx5Pt6n1pJyN Ogja0IP2jE0fPVOdtlmjVlobP5iFzo4OqE0/GrY+UmBMCXHb3UUjbSG0; Authentication-Results: sj-dkim-3.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: aaa-wg@merit.edu, dime@ietf.org, "Glen Zorn \(gwz\)" Subject: [Dime] Diameter base protocol messages used by DCCA X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org In the process of attempting to construct a MIB for the credit control application, I have been trying to figure out which messages from Diameter base are used by DCCA, so that they can be counted appropriately. Some are obvious: STR/STA & RAR/RAA, for example. One has me rather puzzled, though: the AAR/AAA exchange is explicitly listed in the first state machine in section 7 as being sent/received by the CCA client, but the AVPs allowed in AAR/AAA are not listed in section 10 (though the APS for RAR/RAA ARE). Does the CCA client actually send/receive AAR/AAA (i.e., should the be counted in the DCCA MIB) or not? ~gwz Treat the Earth well.=20 It was not given to you by your parents. It was loaned to you by your children. -- Kenyan Proverb Humankind has not woven the web of life. We are but one thread within it. Whatever we do to the web, we do to ourselves. All things are bound together. All things connect. -- Chief Seattle _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 15 03:18:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqm7l-00068a-9V; Thu, 15 Jun 2006 03:18:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqm7j-00068R-Ug for dime@ietf.org; Thu, 15 Jun 2006 03:18:39 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqm0u-0003L2-PY for dime@ietf.org; Thu, 15 Jun 2006 03:11:38 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B8CDB4F0087; Thu, 15 Jun 2006 09:11:12 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 09:11:11 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 09:11:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Contradiction in RFC 4006 Date: Thu, 15 Jun 2006 09:11:10 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Contradiction in RFC 4006 Thread-Index: AcaQDuLSTdT4GsAXTuOoy9vH8jO4yAAO1lGw From: "Harri Hakala \(TU/LMF\)" To: "Glen Zorn \(gwz\)" , X-OriginalArrivalTime: 15 Jun 2006 07:11:11.0273 (UTC) FILETIME=[E18CF990:01C6904A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Glen, I agree, the RFC is not clear in this. But the section 8.35 says=20 that the access device must drop all packets not matching the filters, so I think that if Restriction-Filter-Rule AVP(s) or the Filter-Id = AVP(s)=20 are not included in the CCA, then the access device must drop all = packets. =20 regards........Harri > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 > Sent: 15. kes=E4kuuta 2006 3:02 > To: aaa-wg@merit.edu > Cc: dime@ietf.org; Glen Zorn (gwz) > Subject: [Dime] Contradiction in RFC 4006 >=20 > Section 5.6.3 says=20 >=20 > "A Final-Unit-Indication AVP with the Final-Unit-Action > RESTRICT_ACCESS [in the CCA message] indicates to the=20 > device supporting this action that > the user's access MUST be restricted according to the IP packet > filters given in the Restriction-Filter-Rule AVP(s) or according to > the IP packet filters identified by the Filter-Id AVP(s)." >=20 > However, the next sentence says >=20 > "The credit-control server SHOULD include either the > Restriction-Filter- > Rule AVP or the Filter-Id AVP in the Credit-Control-Answer=20 > message." >=20 > So, what happens if the referenced AVPs are not included in the CCA? >=20 > ~gwz >=20 > Treat the Earth well.=20 > It was not given to you by your parents. > It was loaned to you by your children. > -- Kenyan Proverb >=20 > Humankind has not woven the web of life. > We are but one thread within it. > Whatever we do to the web, we do to ourselves. > All things are bound together. > All things connect. > -- Chief Seattle >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 15 03:19:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqm8p-0006PL-6G; Thu, 15 Jun 2006 03:19:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqm8o-0006NZ-9G for dime@ietf.org; Thu, 15 Jun 2006 03:19:46 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqlve-0002om-Rd for dime@ietf.org; Thu, 15 Jun 2006 03:06:12 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AF7EF4F03E2; Thu, 15 Jun 2006 09:06:09 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 09:06:09 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 09:06:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Jun 2006 09:06:08 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter base protocol messages used by DCCA Thread-Index: AcaQFtdWbbQIqFPKQrKpALl9+xwUdAAMMRuA From: "Harri Hakala \(TU/LMF\)" To: "Glen Zorn \(gwz\)" , "Leena Mattila \(TU/LMF\)" , , , X-OriginalArrivalTime: 15 Jun 2006 07:06:09.0091 (UTC) FILETIME=[2D6FA930:01C6904A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: aaa-wg@merit.edu, dime@ietf.org Subject: [Dime] RE: Diameter base protocol messages used by DCCA X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Glen, The DCCA document defines two different approaches to perform the first = credit control=20 interrogation to be used in different network architectures. The first = approach=20 uses credit-control messages after the user's authorization and = authentication=20 takes place. The second approach uses service specific authorization = messages=20 (such as AAA/AAR) to perform the first interrogation during the user's=20 authorization/authentication phase, and credit-control messages for the=20 intermediate and final interrogations.=20 AA Request/AA Answer are not necessarily equal to AAR/AAA messages in = NASREQ but=20 they mean in DCCA document a general authorization/authentication = request/answer=20 in any Diameter authorization/authentication application. Bad name = example, as it=20 seems to collide with the message name in NASREQ. If the CCA client supports the second approach and e.g. NASREQ is used = for service authorization, then the CCA client sends/receives AAR/AAA messages. As this "AA Request/AA Answer" is a general message, not explicit NASREQ = message,=20 we did not include it the table in section 10.=20 regards............Harri > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 > Sent: 15. kes=E4kuuta 2006 3:59 > To: Harri Hakala (TU/LMF); Leena Mattila (TU/LMF);=20 > juha-pekka.koskinen@nokia.com; marco.stura@nokia.com;=20 > John.Loughney@nokia.com > Cc: Glen Zorn (gwz); aaa-wg@merit.edu; dime@ietf.org > Subject: Diameter base protocol messages used by DCCA >=20 > In the process of attempting to construct a MIB for the=20 > credit control application, I have been trying to figure out=20 > which messages from Diameter base are used by DCCA, so that=20 > they can be counted appropriately. Some are obvious: STR/STA=20 > & RAR/RAA, for example. One has me rather puzzled, though:=20 > the AAR/AAA exchange is explicitly listed in the first state=20 > machine in section 7 as being sent/received by the CCA=20 > client, but the AVPs allowed in AAR/AAA are not listed in=20 > section 10 (though the APS for RAR/RAA ARE). Does the CCA=20 > client actually send/receive AAR/AAA (i.e., should the be=20 > counted in the DCCA MIB) or not? >=20 > ~gwz >=20 > Treat the Earth well.=20 > It was not given to you by your parents. > It was loaned to you by your children. > -- Kenyan Proverb >=20 > Humankind has not woven the web of life. > We are but one thread within it. > Whatever we do to the web, we do to ourselves. > All things are bound together. > All things connect. > -- Chief Seattle >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 15 12:48:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqv1b-000605-T0; Thu, 15 Jun 2006 12:48:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqv1b-000600-21 for dime@ietf.org; Thu, 15 Jun 2006 12:48:55 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqv1Y-0001YB-DM for dime@ietf.org; Thu, 15 Jun 2006 12:48:55 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 86B290C19B for ; Thu, 15 Jun 2006 12:48:49 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5FGmmlI012508 for ; Thu, 15 Jun 2006 12:48:48 -0400 (EDT) From: "Tolga Asveren" To: Date: Thu, 15 Jun 2006 12:26:11 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Dime] RFC3588 7.2 Misleading ABNF X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org RFC3588 7.2 defines the ABNF to be used for answer messages with a protocol error return result. It is quite confusing/misleading/not-optimal (or I got it wrong what it should be). As the starting assumption, I believe Protocol Errors must be related only with routing, i.e. erorrs which are interesting from intermediares point of view. Currently there a few errors classiefed as protocl errors, which aren't, and hopefully we can have some cleanup there. I think the idea in 7.2 is: a)Protocol error answer message must include the original message, e.g. so that a relay agent can route it to some other peer. I assume *[ AVP ] stands for that. b)Protocol error answer message must include Result-Code, so that an intermediary can decide what to do with that answer. This is why we have { Result Code }. So far so good.... c) { Origin-Host } { Origin-Realm } I assume those are *not* the Origin-Host Origin-Realm AVP of the original message -7.4 Error-Reporting hints that they aren't-. Why do we need them? If for troubleshooting, I would opt for Error-Reporting-Host AVP. When a relay agent receives a protocol error answer, how does it know which Origin-Host/Origin-Realm AVP to remove -there is also a pair for the original message, which should be kept intact-. d) [ Error-Reporting-Host ] It is a good idea to have an AVP for troubleshooting purposes -as specified in 7.4-. IMHO, it is better to have this as optional rather than a MUST. I think, it is a better idea not ise Origin-Host/Origin-Realm for debugging and rely on this specific AVP. e) [ Origin-state-Id ] [ Proxy-Info ] Why are they explicitly mentioned? Overall, IMO, 7.2 should have said that protocol error answers must include the original message, Result-Code AVP and may include Error-Reporting-Host AVP. Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 15 13:32:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqvhj-0004WY-ST; Thu, 15 Jun 2006 13:32:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqvhi-0004Oy-Cr for dime@ietf.org; Thu, 15 Jun 2006 13:32:26 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqvhh-00073M-38 for dime@ietf.org; Thu, 15 Jun 2006 13:32:26 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 15 Jun 2006 10:32:24 -0700 X-IronPort-AV: i="4.06,137,1149490800"; d="scan'208"; a="295372137:sNHT80225010" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k5FHWOxW012584; Thu, 15 Jun 2006 10:32:24 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5FHWOcL025220; Thu, 15 Jun 2006 10:32:24 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Jun 2006 10:32:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Jun 2006 10:32:22 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625022AF5F6@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter base protocol messages used by DCCA Thread-Index: AcaQFtdWbbQIqFPKQrKpALl9+xwUdAAMMRuAABZKJHA= From: "Glen Zorn \(gwz\)" To: "Harri Hakala \(TU/LMF\)" , "Leena Mattila \(TU/LMF\)" , , , X-OriginalArrivalTime: 15 Jun 2006 17:32:23.0900 (UTC) FILETIME=[A9C481C0:01C690A1] DKIM-Signature: a=rsa-sha1; q=dns; l=952; t=1150392744; x=1151256744; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20Diameter=20base=20protocol=20messages=20used=20by=20DCCA; X=v=3Dcisco.com=3B=20h=3DTivVj/SoKN3WihEDB3EnSdXCEvE=3D; b=hPGAITho3vFbboEwOnlJrifua9NyaZD5OOkKOlZZEeIVavndcRyEBeyVXuzCt7tuBkRWw2wm phJwzjE6KVx37TKK+wc6Ha6GM1eF0yBc39dYKr7vrrwU36WTLj8QuqMY; Authentication-Results: sj-dkim-6.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: aaa-wg@merit.edu, dime@ietf.org, "Glen Zorn \(gwz\)" Subject: [Dime] RE: Diameter base protocol messages used by DCCA X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Harri Hakala (TU/LMF) supposedly = scribbled: ... > AA Request/AA Answer are not necessarily equal to AAR/AAA messages in > NASREQ but they mean in DCCA document a general > authorization/authentication request/answer in any Diameter > authorization/authentication application. Bad name example, as it > seems to collide with the message name in NASREQ. =20 >=20 This would seem to make it quite difficult to monitor/manage DCCA via = SNMP, since presumably one would wish to keep track of all the = interrogations & the generic auth message is actually the first = interrogation. This implies that all & any such messages should be = allocated a counter in the DCCA MIB, but the membership of this set of = messages is not static. Any suggestions?=20 =20 ... ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 15 16:13:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyDJ-0008IF-Dm; Thu, 15 Jun 2006 16:13:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyDI-0008Hc-Li for dime@ietf.org; Thu, 15 Jun 2006 16:13:12 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqyDH-0005Yy-Du for dime@ietf.org; Thu, 15 Jun 2006 16:13:12 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Jun 2006 13:13:11 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,138,1149490800"; d="scan'208"; a="29616626:sNHT22294324" Received: from [10.86.242.168] (che-vpn-cluster-2-168.cisco.com [10.86.242.168]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5FKDAYL002107; Thu, 15 Jun 2006 16:13:10 -0400 (EDT) Message-ID: <4491BF56.3090609@cisco.com> Date: Thu, 15 Jun 2006 16:13:10 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Glen Zorn (gwz)" Subject: Re: [Dime] RE: Diameter base protocol messages used by DCCA References: <4C0FAAC489C8B74F96BEAD85EAEB2625022AF5F6@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625022AF5F6@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: John.Loughney@nokia.com, aaa-wg@merit.edu, juha-pekka.koskinen@nokia.com, dime@ietf.org, marco.stura@nokia.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Glen Zorn (gwz) wrote: > Harri Hakala (TU/LMF) supposedly scribbled: > > ... > > >>AA Request/AA Answer are not necessarily equal to AAR/AAA messages in >>NASREQ but they mean in DCCA document a general >>authorization/authentication request/answer in any Diameter >>authorization/authentication application. Bad name example, as it >>seems to collide with the message name in NASREQ. >> > > > This would seem to make it quite difficult to monitor/manage DCCA via SNMP, since presumably one would wish to keep track of all the interrogations & the generic auth message is actually the first interrogation. This implies that all & any such messages should be allocated a counter in the DCCA MIB, but the membership of this set of messages is not static. Any suggestions? Have clients include an Auth-Application-Id AVP in the AAR with the DCC app id? It's not clear to me from the specs whether this is the intention or not but IMHO there really ought to be a way for the server to tell whether the AAR is for a NAS or DCC session - not just for management reasons. Anders > > ... > > ~gwz > > Why is it that most of the world's problems can't be solved by simply > listening to John Coltrane? -- Henry Gabriel > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 15 16:19:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyJN-0004tA-MC; Thu, 15 Jun 2006 16:19:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyJM-0004sz-58 for dime@ietf.org; Thu, 15 Jun 2006 16:19:28 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqyJK-0005qO-Pw for dime@ietf.org; Thu, 15 Jun 2006 16:19:28 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 70BD9D8554; Thu, 15 Jun 2006 16:19:26 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5FKJPAW000505; Thu, 15 Jun 2006 16:19:25 -0400 (EDT) From: "Tolga Asveren" To: , Subject: RE: [Dime] RE: Diameter base protocol messages used by DCCA Date: Thu, 15 Jun 2006 15:56:47 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-reply-to: <4491BF56.3090609@cisco.com> Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org RFC4006 5.2.2 states that Credit-Control AVP MUST be added to AAR to indicate credit-control capabilities. > -----Original Message----- > From: Anders Kristensen [mailto:andersk@cisco.com] > Sent: Thursday, June 15, 2006 4:13 PM > To: Glen Zorn (gwz) > Cc: John.Loughney@nokia.com; aaa-wg@merit.edu; > juha-pekka.koskinen@nokia.com; dime@ietf.org; marco.stura@nokia.com > Subject: Re: [Dime] RE: Diameter base protocol messages used by DCCA > > > > > Glen Zorn (gwz) wrote: > > Harri Hakala (TU/LMF) > supposedly scribbled: > > > > ... > > > > > >>AA Request/AA Answer are not necessarily equal to AAR/AAA messages in > >>NASREQ but they mean in DCCA document a general > >>authorization/authentication request/answer in any Diameter > >>authorization/authentication application. Bad name example, as it > >>seems to collide with the message name in NASREQ. > >> > > > > > > This would seem to make it quite difficult to monitor/manage > DCCA via SNMP, since presumably one would wish to keep track of > all the interrogations & the generic auth message is actually the > first interrogation. This implies that all & any such messages > should be allocated a counter in the DCCA MIB, but the membership > of this set of messages is not static. Any suggestions? > > Have clients include an Auth-Application-Id AVP in the AAR with the DCC > app id? It's not clear to me from the specs whether this is the > intention or not but IMHO there really ought to be a way for the server > to tell whether the AAR is for a NAS or DCC session - not just for > management reasons. > > Anders > > > > > ... > > > > ~gwz > > > > Why is it that most of the world's problems can't be solved by simply > > listening to John Coltrane? -- Henry Gabriel > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 15 16:38:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqybT-0008ES-Gr; Thu, 15 Jun 2006 16:38:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqybS-0008EN-J4 for dime@ietf.org; Thu, 15 Jun 2006 16:38:10 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqybR-0006rl-A9 for dime@ietf.org; Thu, 15 Jun 2006 16:38:10 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 15 Jun 2006 13:37:44 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,138,1149490800"; d="scan'208"; a="29619387:sNHT66376865754" Received: from [10.86.242.168] (che-vpn-cluster-2-168.cisco.com [10.86.242.168]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5FKbhno003826; Thu, 15 Jun 2006 16:37:44 -0400 (EDT) Message-ID: <4491C516.4060808@cisco.com> Date: Thu, 15 Jun 2006 16:37:42 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] RE: Diameter base protocol messages used by DCCA References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: aaa-wg@merit.edu, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org OK, so at least there's a way to tell which app the AAR really is for. In my view it's a poor solution, though, since the code maintaining peg counts could very well belong to a generic Diameter stack which doesn't necessarily know about the particulars of DCCA. It's sort of reasonable to expect the stack to do something on the basis of Auth-Application-Id but not really for DCCA specific AVPs. It makes it unnecessarily difficult to layer the server code. Thanks, Anders Tolga Asveren wrote: > RFC4006 5.2.2 states that Credit-Control AVP MUST be added to AAR to > indicate credit-control capabilities. > > >>-----Original Message----- >>From: Anders Kristensen [mailto:andersk@cisco.com] >>Sent: Thursday, June 15, 2006 4:13 PM >>To: Glen Zorn (gwz) >>Cc: John.Loughney@nokia.com; aaa-wg@merit.edu; >>juha-pekka.koskinen@nokia.com; dime@ietf.org; marco.stura@nokia.com >>Subject: Re: [Dime] RE: Diameter base protocol messages used by DCCA >> >> >> >> >>Glen Zorn (gwz) wrote: >> >>>Harri Hakala (TU/LMF) >> >>supposedly scribbled: >> >>>... >>> >>> >>> >>>>AA Request/AA Answer are not necessarily equal to AAR/AAA messages in >>>>NASREQ but they mean in DCCA document a general >>>>authorization/authentication request/answer in any Diameter >>>>authorization/authentication application. Bad name example, as it >>>>seems to collide with the message name in NASREQ. >>>> >>> >>> >>>This would seem to make it quite difficult to monitor/manage >> >>DCCA via SNMP, since presumably one would wish to keep track of >>all the interrogations & the generic auth message is actually the >>first interrogation. This implies that all & any such messages >>should be allocated a counter in the DCCA MIB, but the membership >>of this set of messages is not static. Any suggestions? >> >>Have clients include an Auth-Application-Id AVP in the AAR with the DCC >>app id? It's not clear to me from the specs whether this is the >>intention or not but IMHO there really ought to be a way for the server >>to tell whether the AAR is for a NAS or DCC session - not just for >>management reasons. >> >>Anders >> >> >>>... >>> >>>~gwz >>> >>>Why is it that most of the world's problems can't be solved by simply >>> listening to John Coltrane? -- Henry Gabriel >>> >>>_______________________________________________ >>>DiME mailing list >>>DiME@ietf.org >>>https://www1.ietf.org/mailman/listinfo/dime >>> >> >>_______________________________________________ >>DiME mailing list >>DiME@ietf.org >>https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 15 16:44:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyhA-0005Dq-KT; Thu, 15 Jun 2006 16:44:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqyh9-0005Dg-H3 for dime@ietf.org; Thu, 15 Jun 2006 16:44:03 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqyh8-0008FH-5v for dime@ietf.org; Thu, 15 Jun 2006 16:44:03 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 237496B66D; Thu, 15 Jun 2006 16:44:01 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5FKi0nl002646; Thu, 15 Jun 2006 16:44:01 -0400 (EDT) From: "Tolga Asveren" To: "Anders Kristensen" Subject: RE: [Dime] RE: Diameter base protocol messages used by DCCA Date: Thu, 15 Jun 2006 16:21:22 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-reply-to: <4491C516.4060808@cisco.com> Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: aaa-wg@merit.edu, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Actualy, shouldn't ApplicationId in the message header be 4 (ApplicationId for DCCA) , for such an AAR? Tolga > -----Original Message----- > From: Anders Kristensen [mailto:andersk@cisco.com] > Sent: Thursday, June 15, 2006 4:38 PM > To: Tolga Asveren > Cc: aaa-wg@merit.edu; dime@ietf.org > Subject: Re: [Dime] RE: Diameter base protocol messages used by DCCA > > > OK, so at least there's a way to tell which app the AAR really is for. > In my view it's a poor solution, though, since the code maintaining peg > counts could very well belong to a generic Diameter stack which doesn't > necessarily know about the particulars of DCCA. It's sort of reasonable > to expect the stack to do something on the basis of Auth-Application-Id > but not really for DCCA specific AVPs. It makes it unnecessarily > difficult to layer the server code. > > Thanks, > Anders > > Tolga Asveren wrote: > > > RFC4006 5.2.2 states that Credit-Control AVP MUST be added to AAR to > > indicate credit-control capabilities. > > > > > >>-----Original Message----- > >>From: Anders Kristensen [mailto:andersk@cisco.com] > >>Sent: Thursday, June 15, 2006 4:13 PM > >>To: Glen Zorn (gwz) > >>Cc: John.Loughney@nokia.com; aaa-wg@merit.edu; > >>juha-pekka.koskinen@nokia.com; dime@ietf.org; marco.stura@nokia.com > >>Subject: Re: [Dime] RE: Diameter base protocol messages used by DCCA > >> > >> > >> > >> > >>Glen Zorn (gwz) wrote: > >> > >>>Harri Hakala (TU/LMF) > >> > >>supposedly scribbled: > >> > >>>... > >>> > >>> > >>> > >>>>AA Request/AA Answer are not necessarily equal to AAR/AAA messages in > >>>>NASREQ but they mean in DCCA document a general > >>>>authorization/authentication request/answer in any Diameter > >>>>authorization/authentication application. Bad name example, as it > >>>>seems to collide with the message name in NASREQ. > >>>> > >>> > >>> > >>>This would seem to make it quite difficult to monitor/manage > >> > >>DCCA via SNMP, since presumably one would wish to keep track of > >>all the interrogations & the generic auth message is actually the > >>first interrogation. This implies that all & any such messages > >>should be allocated a counter in the DCCA MIB, but the membership > >>of this set of messages is not static. Any suggestions? > >> > >>Have clients include an Auth-Application-Id AVP in the AAR with the DCC > >>app id? It's not clear to me from the specs whether this is the > >>intention or not but IMHO there really ought to be a way for the server > >>to tell whether the AAR is for a NAS or DCC session - not just for > >>management reasons. > >> > >>Anders > >> > >> > >>>... > >>> > >>>~gwz > >>> > >>>Why is it that most of the world's problems can't be solved by simply > >>> listening to John Coltrane? -- Henry Gabriel > >>> > >>>_______________________________________________ > >>>DiME mailing list > >>>DiME@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/dime > >>> > >> > >>_______________________________________________ > >>DiME mailing list > >>DiME@ietf.org > >>https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 16 04:48:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrA02-00078L-Tc; Fri, 16 Jun 2006 04:48:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrA01-00078F-Ot for dime@ietf.org; Fri, 16 Jun 2006 04:48:17 -0400 Received: from mailout-2.omnitel.it ([194.20.71.226] helo=fmis837.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrA01-00052L-29 for dime@ietf.org; Fri, 16 Jun 2006 04:48:17 -0400 Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k5G8mFI7007760 for ; Fri, 16 Jun 2006 10:48:15 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.11]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Jun 2006 10:48:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RE: Diameter base protocol messages used by DCCA Date: Fri, 16 Jun 2006 10:48:10 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC207713364@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter base protocol messages used by DCCA Thread-Index: AcaQvHRLCzEvKzDHRWSkW/O26V/ALwAWLJYw From: "STURA, Marco, VF-IT" To: "Tolga Asveren" , "Anders Kristensen" , "Glen Zorn \(gwz\)" X-OriginalArrivalTime: 16 Jun 2006 08:48:11.0674 (UTC) FILETIME=[99316FA0:01C69121] X-Spam-Score: 0.1 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: aaa-wg@merit.edu, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org >Actualy, shouldn't ApplicationId in the message header be 4 = (ApplicationId >for DCCA) , for such an AAR? No, that is not what RFC4006 specifies. See below from section 5.2.2 The Diameter credit-control client in the service element MUST actively co-operate with the authorization/authentication client in the construction of the AA request by adding appropriate credit- control AVPs. The credit-control client MUST add the Credit-Control AVP to indicate credit-control capabilities and MAY add other relevant credit-control specific AVPs to the proper authorization/authentication command to perform the first interrogation toward the home Diameter AAA server. The Auth- Application-Id is set to the appropriate value, as defined in the relevant service specific authorization/authentication application document (e.g., [NASREQ], [DIAMMIP]). The home Diameter AAA server authenticates/authorizes the subscriber and determines whether credit-control is required.=20 The reason we introduced use of service specific AA request for the = first interrogation is for protocol efficiency reasons in case in = certain environments there is a need to perform credit check at the same = time service specific authentication/authorization is executed (e.g. = access authentication/authorization). Essentially this is to avoid = several round trips before granting access to a user (i.e. one for = service specific AA and one for credit control). Messages may need to = traverse a number of "domains" to reach the home domain in roaming = circumstances, hence significant delay may occur. So, the AA message is = used for both service specific and credit control processes but there is = no means to indicate this to the server other than AVP based. However, = after the first interrogation there will be an independent credit = control stream if so required. Would it then make sense to monitor AA messages and CC messages = independently also for the first interrogation performed during service = specific AA? If the model above is used there will be e.g. NASREQ MIB + = DCCA MIB in the same node. E.g. A successful AAR/AAA (NASREQ Application-Id) may or may not lead to = an independent credit control stream. If it does there will be zero or = more CCR updates (DCCA Application-Id) and a CCR termination (DCCA = Application-id) when the AA session is closed. Therefore, in a NASREQ + = DCCA example, if credit control is used for a subscriber successful = AAR/AAA will result at least in the CCR termination counter incremented = and that would mean that AAR/AAA was used to perform first = interrogation.=20 In other cases, where the model described in section 5.2.2 is not used, = a CCR initial counter would be incremented. BTW, do you plan to have different counters for different CCR types = (initial, update, termination)? Regards Marco -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: gioved=EC 15 giugno 2006 22.21 To: Anders Kristensen Cc: aaa-wg@merit.edu; dime@ietf.org Subject: RE: [Dime] RE: Diameter base protocol messages used by DCCA Actualy, shouldn't ApplicationId in the message header be 4 = (ApplicationId for DCCA) , for such an AAR? Tolga > -----Original Message----- > From: Anders Kristensen [mailto:andersk@cisco.com] > Sent: Thursday, June 15, 2006 4:38 PM > To: Tolga Asveren > Cc: aaa-wg@merit.edu; dime@ietf.org > Subject: Re: [Dime] RE: Diameter base protocol messages used by DCCA > > > OK, so at least there's a way to tell which app the AAR really is for. > In my view it's a poor solution, though, since the code maintaining = peg > counts could very well belong to a generic Diameter stack which = doesn't > necessarily know about the particulars of DCCA. It's sort of = reasonable > to expect the stack to do something on the basis of = Auth-Application-Id > but not really for DCCA specific AVPs. It makes it unnecessarily > difficult to layer the server code. > > Thanks, > Anders > > Tolga Asveren wrote: > > > RFC4006 5.2.2 states that Credit-Control AVP MUST be added to AAR = to > > indicate credit-control capabilities. > > > > > >>-----Original Message----- > >>From: Anders Kristensen [mailto:andersk@cisco.com] > >>Sent: Thursday, June 15, 2006 4:13 PM > >>To: Glen Zorn (gwz) > >>Cc: John.Loughney@nokia.com; aaa-wg@merit.edu; > >>juha-pekka.koskinen@nokia.com; dime@ietf.org; marco.stura@nokia.com > >>Subject: Re: [Dime] RE: Diameter base protocol messages used by DCCA > >> > >> > >> > >> > >>Glen Zorn (gwz) wrote: > >> > >>>Harri Hakala (TU/LMF) > >> > >>supposedly scribbled: > >> > >>>... > >>> > >>> > >>> > >>>>AA Request/AA Answer are not necessarily equal to AAR/AAA messages = in > >>>>NASREQ but they mean in DCCA document a general > >>>>authorization/authentication request/answer in any Diameter > >>>>authorization/authentication application. Bad name example, as it > >>>>seems to collide with the message name in NASREQ. > >>>> > >>> > >>> > >>>This would seem to make it quite difficult to monitor/manage > >> > >>DCCA via SNMP, since presumably one would wish to keep track of > >>all the interrogations & the generic auth message is actually the > >>first interrogation. This implies that all & any such messages > >>should be allocated a counter in the DCCA MIB, but the membership > >>of this set of messages is not static. Any suggestions? > >> > >>Have clients include an Auth-Application-Id AVP in the AAR with the = DCC > >>app id? It's not clear to me from the specs whether this is the > >>intention or not but IMHO there really ought to be a way for the = server > >>to tell whether the AAR is for a NAS or DCC session - not just for > >>management reasons. > >> > >>Anders > >> > >> > >>>... > >>> > >>>~gwz > >>> > >>>Why is it that most of the world's problems can't be solved by = simply > >>> listening to John Coltrane? -- Henry Gabriel > >>> > >>>_______________________________________________ > >>>DiME mailing list > >>>DiME@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/dime > >>> > >> > >>_______________________________________________ > >>DiME mailing list > >>DiME@ietf.org > >>https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 16 13:36:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIFd-00088k-JC; Fri, 16 Jun 2006 13:36:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIFc-000881-5o for dime@ietf.org; Fri, 16 Jun 2006 13:36:56 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrIEF-0004Wv-Cd for dime@ietf.org; Fri, 16 Jun 2006 13:35:33 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k5GHZRdH022053; Sat, 17 Jun 2006 02:35:27 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k5GHaram000350; Sat, 17 Jun 2006 02:36:53 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id CAA00343; Sat, 17 Jun 2006 02:36:53 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k5GHZQfK029354; Sat, 17 Jun 2006 02:35:26 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k5GHZP06018144; Sat, 17 Jun 2006 02:35:25 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0Y00E9ARITYI50@mail.po.toshiba.co.jp>; Sat, 17 Jun 2006 02:35:25 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FrGNP-0007Sc-VI; Fri, 16 Jun 2006 08:36:51 -0700 Date: Fri, 16 Jun 2006 11:36:51 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] RFC3588 7.2 Misleading ABNF In-reply-to: To: Tolga Asveren Message-id: <20060616153651.GA27074@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, On Thu, Jun 15, 2006 at 12:26:11PM -0400, Tolga Asveren wrote: > RFC3588 7.2 defines the ABNF to be used for answer messages with a protocol > error return result. It is quite confusing/misleading/not-optimal (or I got > it wrong what it should be). > > As the starting assumption, I believe Protocol Errors must be related only > with routing, i.e. erorrs which are interesting from intermediares point of > view. Currently there a few errors classiefed as protocl errors, which > aren't, and hopefully we can have some cleanup there. Can you eraborate on why protocols errors must be related only to routing? > > > I think the idea in 7.2 is: > a)Protocol error answer message must include the original message, e.g. so > that a relay agent can route it to some other peer. I assume *[ AVP ] stands > for that. Since the node that received the answer message would need to keep the original request (e.g., to deal with redirect or failover), I don't see a need for the original message to be included in the protocol error answer message, but I may be missing something. > > b)Protocol error answer message must include Result-Code, so that an > intermediary can decide what to do with that answer. This is why we have { > Result Code }. > > So far so good.... > > c) { Origin-Host } { Origin-Realm } > I assume those are *not* the Origin-Host Origin-Realm AVP of the original > message -7.4 Error-Reporting hints that they aren't-. Why do we need them? > If for troubleshooting, I would opt for Error-Reporting-Host AVP. When a > relay agent receives a protocol error answer, how does it know which > Origin-Host/Origin-Realm AVP to remove -there is also a pair for the > original message, which should be kept intact-. Origin-Host AVP and Error-Reporting-Host AVP may point to different nodes, since Origin-Host and Origin-Realm AVPs may be replaced by a proxy. > > d) [ Error-Reporting-Host ] > It is a good idea to have an AVP for troubleshooting purposes -as specified > in 7.4-. IMHO, it is better to have this as optional rather than a MUST. I > think, it is a better idea not ise Origin-Host/Origin-Realm for debugging > and rely on this specific AVP. Please see my comment above. > > e) [ Origin-state-Id ] [ Proxy-Info ] > Why are they explicitly mentioned? I guess the reason is that those AVPs are generic enough to be included in any answer message regardless of E-bit. Yoshihiro Ohba > > > Overall, IMO, 7.2 should have said that protocol error answers must include > the original message, Result-Code AVP and may include Error-Reporting-Host > AVP. > > Thanks, > Tolga > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 16 14:15:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIqq-00084V-RF; Fri, 16 Jun 2006 14:15:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIqp-00082f-R9 for dime@ietf.org; Fri, 16 Jun 2006 14:15:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrHSs-0001JF-JU for dime@ietf.org; Fri, 16 Jun 2006 12:46:34 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FrHPy-0005nY-6r for dime@ietf.org; Fri, 16 Jun 2006 12:43:35 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 16 Jun 2006 09:43:34 -0700 X-IronPort-AV: i="4.06,143,1149490800"; d="scan'208"; a="1826997190:sNHT86900080" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5GGhXLZ021762; Fri, 16 Jun 2006 09:43:33 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5GGhWke013532; Fri, 16 Jun 2006 09:43:32 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Jun 2006 09:43:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RE: Diameter base protocol messages used by DCCA Date: Fri, 16 Jun 2006 09:43:30 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625022AFA18@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter base protocol messages used by DCCA Thread-Index: AcaQvHRLCzEvKzDHRWSkW/O26V/ALwAWLJYwABK/jSA= From: "Glen Zorn \(gwz\)" To: "STURA, Marco, VF-IT" , "Tolga Asveren" , "Anders Kristensen" X-OriginalArrivalTime: 16 Jun 2006 16:43:32.0551 (UTC) FILETIME=[00F5E570:01C69164] DKIM-Signature: a=rsa-sha1; q=dns; l=4087; t=1150476213; x=1151340213; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Dime]=20RE=3A=20Diameter=20base=20protocol=20messages=20used=20 by=20DCCA; X=v=3Dcisco.com=3B=20h=3DHwsi7c48XQRfyiH8lUrRpE1X9Jg=3D; b=DNVpCU2kVyAGeP2sli62SyfPeDuzZaiLJx13NgzrAaErhjoBfgLnxxoy/yBagecRyePw3FKx /oD4/HQJ4XqiWQwnjdc/Qu2oyIiOZ40Y8j9KsNE2TVSOfd/GRwhMWmNI; Authentication-Results: sj-dkim-5.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: aaa-wg@merit.edu, dime@ietf.org, "Glen Zorn \(gwz\)" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org STURA, Marco, VF-IT supposedly = scribbled: >> Actualy, shouldn't ApplicationId in the message header be 4 >> (ApplicationId for DCCA) , for such an AAR? >=20 > No, that is not what RFC4006 specifies. See below from section 5.2.2 >=20 > The Diameter credit-control client in the service element MUST > actively co-operate with the authorization/authentication client in > the construction of the AA request by adding appropriate credit- > control AVPs. The credit-control client MUST add the > Credit-Control AVP to indicate credit-control capabilities and MAY > add other relevant credit-control specific AVPs to the proper > authorization/authentication command to perform the first > interrogation toward the home Diameter AAA server. The Auth- > Application-Id is set to the appropriate value, as defined in the > relevant service specific authorization/authentication application > document (e.g., [NASREQ], [DIAMMIP]). The home Diameter AAA server > authenticates/authorizes the subscriber and determines whether > credit-control is required. >=20 > The reason we introduced use of service specific AA request for the > first interrogation is for protocol efficiency reasons in case in > certain environments there is a need to perform credit check at the > same time service specific authentication/authorization is executed > (e.g. access authentication/authorization). Essentially this is to > avoid several round trips before granting access to a user (i.e. one > for service specific AA and one for credit control). Messages may > need to traverse a number of "domains" to reach the home domain in > roaming circumstances, hence significant delay may occur. So, the AA > message is used for both service specific and credit control > processes but there is no means to indicate this to the server other > than AVP based.=20 So, in other words, in order to implement a e.g., [NASREQ], [DIAMMIP] = peer intended for general distribution, one must include CCA client = functionality. > However, after the first interrogation there will be > an independent credit control stream if so required. =20 >=20 > Would it then make sense to monitor AA messages and CC messages > independently also for the first interrogation performed during > service specific AA? If the model above is used there will be e.g. > NASREQ MIB + DCCA MIB in the same node. =20 >=20 > E.g. A successful AAR/AAA (NASREQ Application-Id) may or may not lead > to an independent credit control stream. If it does there will be > zero or more CCR updates (DCCA Application-Id) and a CCR termination > (DCCA Application-id) when the AA session is closed. Therefore, in a > NASREQ + DCCA example, if credit control is used for a subscriber > successful AAR/AAA will result at least in the CCR termination > counter incremented and that would mean that AAR/AAA was used to > perform first interrogation. =20 Or, that there were no intermediate interrogations; also, what about the = case of a one-time event (balance check, etc.)? Although this kind of = activity doesn't seem to be included in any of the examples in RFC 4006, = neither does it appear to be prohibited. If a balance check or other = type of one-time event was included in the AAR it seems that there would = be no client-side counter incremented. =20 >=20 > In other cases, where the model described in section 5.2.2 is not > used, a CCR initial counter would be incremented.=20 >=20 > BTW, do you plan to have different counters for different CCR types > (initial, update, termination)?=20 I hadn't planned to, no. However, if it is necessary to use this data = to infer the existence of an initial interrogation from its absence = (does anybody else see something odd about this?), I suppose I will have = to do so. ... Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 16 14:19:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIuj-0003FE-9z; Fri, 16 Jun 2006 14:19:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIuh-0003Dl-Qj for dime@ietf.org; Fri, 16 Jun 2006 14:19:23 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrIug-0008Fb-EU for dime@ietf.org; Fri, 16 Jun 2006 14:19:23 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 16 Jun 2006 11:19:05 -0700 X-IronPort-AV: i="4.06,143,1149490800"; d="scan'208"; a="1827060041:sNHT5306522608" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5GIJ4Zx017625; Fri, 16 Jun 2006 11:19:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5GIJ4cL028365; Fri, 16 Jun 2006 11:19:04 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Jun 2006 11:19:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [Dime] RFC3588 7.2 Misleading ABNF Date: Fri, 16 Jun 2006 11:19:02 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250230F947@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RFC3588 7.2 Misleading ABNF Thread-Index: AcaRa40vvljieH54SVCIeMTPIxbtbgABFZhw From: "Glen Zorn \(gwz\)" To: "Yoshihiro Ohba" X-OriginalArrivalTime: 16 Jun 2006 18:19:04.0165 (UTC) FILETIME=[5944C950:01C69171] DKIM-Signature: a=rsa-sha1; q=dns; l=1927; t=1150481944; x=1151345944; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Dime]=20RFC3588=207.2=20Misleading=20ABNF; X=v=3Dcisco.com=3B=20h=3DXBkg3l3XuvTF8ZhXOzUCXGF5Rew=3D; b=p+P66JZP8e6NUKzt3ym9KfA9WnXYUEIS3UGSP7FDH74vshM6mT6r/nxtEVhrEb8aHAM4Lj2w eS7rP0cYZ8+xfTYI8FBXZR9CzWEG8yWcVT00V7nXnWu7NAWZ5ufl/Cp6; Authentication-Results: sj-dkim-5.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Yoshihiro Ohba supposedly scribbled: ... >> As the starting assumption, I believe Protocol Errors must be related >> only with routing, i.e. erorrs which are interesting from >> intermediares point of view. Currently there a few errors classiefed >> as protocl errors, which aren't, and hopefully we can have some >> cleanup there. > > Can you eraborate on why protocols errors must be related only to > routing? I don't believe that they do; protocol errors only are generated from the base protocol, but the base protocol does things besides message routing (notably capabilities notification). ... >> >> c) { Origin-Host } { Origin-Realm } >> I assume those are *not* the Origin-Host Origin-Realm AVP of the >> original message -7.4 Error-Reporting hints that they aren't-. Why >> do we need them? If for troubleshooting, I would opt for >> Error-Reporting-Host AVP. When >> a relay agent receives a protocol error answer, how does it know >> which Origin-Host/Origin-Realm AVP to remove -there is also a pair >> for the >> original message, which should be kept intact-. > > Origin-Host AVP and Error-Reporting-Host AVP may point to different > nodes, since Origin-Host and Origin-Realm AVPs may be replaced by a > proxy. I believe that you are mistaken on this: section 6.3 of RFC 3588 states "The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and MUST be present in all Diameter messages. This AVP identifies the endpoint that originated the Diameter message. Relay agents MUST NOT modify this AVP.", while section 1.1 says "A Diameter agent is a node that does not authenticate and/or authorize messages locally; agents include proxies, redirects and relay agents." ... Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 16 14:25:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrJ12-0005wg-VE; Fri, 16 Jun 2006 14:25:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrJ12-0005vn-5p for dime@ietf.org; Fri, 16 Jun 2006 14:25:56 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrJ10-0000D8-H0 for dime@ietf.org; Fri, 16 Jun 2006 14:25:56 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k5GIPoO9024296; Sat, 17 Jun 2006 03:25:50 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k5GIPpoY008238; Sat, 17 Jun 2006 03:25:51 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id DAA08207; Sat, 17 Jun 2006 03:25:51 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k5GIPo8k016868; Sat, 17 Jun 2006 03:25:50 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k5GIPnwU020444; Sat, 17 Jun 2006 03:25:49 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0Y00E0STUWYG60@mail.po.toshiba.co.jp>; Sat, 17 Jun 2006 03:25:49 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FrJ0P-0007yV-KL; Fri, 16 Jun 2006 11:25:17 -0700 Date: Fri, 16 Jun 2006 14:25:17 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] RFC3588 7.2 Misleading ABNF In-reply-to: <4C0FAAC489C8B74F96BEAD85EAEB26250230F947@xmb-sjc-215.amer.cisco.com> To: "Glen Zorn (gwz)" Message-id: <20060616182517.GC29773@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <4C0FAAC489C8B74F96BEAD85EAEB26250230F947@xmb-sjc-215.amer.cisco.com> User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Glen, On Fri, Jun 16, 2006 at 11:19:02AM -0700, Glen Zorn (gwz) wrote: > >> > >> c) { Origin-Host } { Origin-Realm } > >> I assume those are *not* the Origin-Host Origin-Realm AVP of the > >> original message -7.4 Error-Reporting hints that they aren't-. Why > >> do we need them? If for troubleshooting, I would opt for > >> Error-Reporting-Host AVP. When > >> a relay agent receives a protocol error answer, how does it know > >> which Origin-Host/Origin-Realm AVP to remove -there is also a pair > >> for the > >> original message, which should be kept intact-. > > > > Origin-Host AVP and Error-Reporting-Host AVP may point to different > > nodes, since Origin-Host and Origin-Realm AVPs may be replaced by a > > proxy. > > I believe that you are mistaken on this: section 6.3 of RFC 3588 states "The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and MUST be present in all Diameter messages. This AVP identifies the endpoint that originated the Diameter message. Relay agents MUST NOT modify this AVP.", while section 1.1 says "A Diameter agent is a node that does not authenticate and/or authorize messages locally; agents include proxies, redirects and relay agents." Is a proxy a relay agent? I could not find such an explicit statement in RFC 3588, but I could be wrong. Yoshihiro Ohba > > ... > > Hope this helps, > > ~gwz > > Why is it that most of the world's problems can't be solved by simply > listening to John Coltrane? -- Henry Gabriel > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 16 14:34:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrJ9c-0005ju-2D; Fri, 16 Jun 2006 14:34:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrJ9a-0005jo-Ey for dime@ietf.org; Fri, 16 Jun 2006 14:34:46 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrJ9X-00010D-3S for dime@ietf.org; Fri, 16 Jun 2006 14:34:46 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id F1854DD06C for ; Fri, 16 Jun 2006 14:34:41 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5GIYdtD026922 for ; Fri, 16 Jun 2006 14:34:39 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] RFC3588 7.2 Misleading ABNF Date: Fri, 16 Jun 2006 14:11:55 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-reply-to: <20060616153651.GA27074@steelhead> Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Yoshihiro, Please see my responses inline. Thanks, Tolga > On Thu, Jun 15, 2006 at 12:26:11PM -0400, Tolga Asveren wrote: > > RFC3588 7.2 defines the ABNF to be used for answer messages > with a protocol > > error return result. It is quite > confusing/misleading/not-optimal (or I got > > it wrong what it should be). > > > > As the starting assumption, I believe Protocol Errors must be > related only > > with routing, i.e. erorrs which are interesting from > intermediares point of > > view. Currently there a few errors classiefed as protocl errors, which > > aren't, and hopefully we can have some cleanup there. > > Can you eraborate on why protocols errors must be related only to routing? [TOLGA]Mainly because I think it is a good idea to have a separate category only for routing errors ("Routing Erros" would probably be more appropriate as a name), which is easily detectable by intermediares (I am not claiming that this is currently the case based on RFC3588, this is just what I think as a better solution). It is really handy/fast just to check the E-bit on answers to decide whether Result-Code needs to be examined and wether there should be another attempt to route the corresponding request. I may be missing something but I don't see any good reason for a relay agent to process an error answer message, unless it is related with a routing decision. IMHO, it is better to send any other type of error answer to the originator of the request, i.e. DIAMETER_COMMAND_UNSUPPORTED, DIAMETER_INVALID_HDR_BITS, DIAMETER_INVALID_AVP_BITS are better not treated on a per-hop basis. > > > > > > > I think the idea in 7.2 is: > > a)Protocol error answer message must include the original > message, e.g. so > > that a relay agent can route it to some other peer. I assume *[ > AVP ] stands > > for that. > > Since the node that received the answer message would need to keep the > original request (e.g., to deal with redirect or failover), I don't > see a need for the original message to be included in the protocol > error answer message, but I may be missing something. [TOLGA]I have the impression that pending request queue is mainly to deal with transport errors rather than with errors on Diameter level. RFC3588 speaks also of removing a request from the pending queue, when an answer is received for it. It is not spelled clearly but my understanding is that this removing of request happens regardless of the Result-Code value.( My understanding on this is based on 5.5.4) > > > > > b)Protocol error answer message must include Result-Code, so that an > > intermediary can decide what to do with that answer. This is > why we have { > > Result Code }. > > > > So far so good.... > > > > c) { Origin-Host } { Origin-Realm } > > I assume those are *not* the Origin-Host Origin-Realm AVP of > the original > > message -7.4 Error-Reporting hints that they aren't-. Why do we > need them? > > If for troubleshooting, I would opt for Error-Reporting-Host AVP. When a > > relay agent receives a protocol error answer, how does it know which > > Origin-Host/Origin-Realm AVP to remove -there is also a pair for the > > original message, which should be kept intact-. > > Origin-Host AVP and Error-Reporting-Host AVP may point to different > nodes, since Origin-Host and Origin-Realm AVPs may be replaced by a > proxy. [TOLGA]If we consider only routing type of errors (my original comment was based on this assumption), why would we care about the value in Origin-Host/Origin-Realm AVP at all? They won't be used for further routing decisions. Even Error-Reporting-Host seems to be useful only for troubleshooting purposes. Maybe the reason is that all answer messages are supposed to have Origin-Host/Origin-Realm AVPs? > > > > > d) [ Error-Reporting-Host ] > > It is a good idea to have an AVP for troubleshooting purposes > -as specified > > in 7.4-. IMHO, it is better to have this as optional rather > than a MUST. I > > think, it is a better idea not ise Origin-Host/Origin-Realm for > debugging > > and rely on this specific AVP. > > Please see my comment above. > > > > > e) [ Origin-state-Id ] [ Proxy-Info ] > > Why are they explicitly mentioned? > > I guess the reason is that those AVPs are generic enough to be > included in any answer message regardless of E-bit. > > Yoshihiro Ohba > > > > > > > > Overall, IMO, 7.2 should have said that protocol error answers > must include > > the original message, Result-Code AVP and may include > Error-Reporting-Host > > AVP. > > > > Thanks, > > Tolga > > > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 16 14:36:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrJBJ-0006x9-1m; Fri, 16 Jun 2006 14:36:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrJBH-0006sR-Ra for dime@ietf.org; Fri, 16 Jun 2006 14:36:31 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrJBG-0001ER-IK for dime@ietf.org; Fri, 16 Jun 2006 14:36:31 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 16 Jun 2006 11:36:28 -0700 X-IronPort-AV: i="4.06,143,1149490800"; d="scan'208"; a="296037600:sNHT3508942130" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5GIaR6H017720; Fri, 16 Jun 2006 11:36:27 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5GIaRke024839; Fri, 16 Jun 2006 11:36:27 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Jun 2006 11:36:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [Dime] RFC3588 7.2 Misleading ABNF Date: Fri, 16 Jun 2006 11:36:25 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250230F964@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RFC3588 7.2 Misleading ABNF Thread-Index: AcaRclCA5DVxEY3QQFOWqfW6tSsNUwAAD23w From: "Glen Zorn \(gwz\)" To: "Yoshihiro Ohba" X-OriginalArrivalTime: 16 Jun 2006 18:36:27.0224 (UTC) FILETIME=[C6FAF580:01C69173] DKIM-Signature: a=rsa-sha1; q=dns; l=591; t=1150482987; x=1151346987; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Dime]=20RFC3588=207.2=20Misleading=20ABNF; X=v=3Dcisco.com=3B=20h=3DXBkg3l3XuvTF8ZhXOzUCXGF5Rew=3D; b=GvqDKV0LxrFpzHiQuxhCq2158Jtb5MQIevckQlGoXatirO4H4/Aol6S87sFYMfBeAyr4GjSa uo7y9Jpxgo1UJlrqh8YkLHI0qga8AsTDl1CviotBEDR6MMKYhQLxj93n; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Yoshihiro Ohba supposedly scribbled: ... > > Is a proxy a relay agent? I could not find such an explicit > statement in RFC 3588, but I could be wrong. Be that as it may, consider the case described in section 5.5.4. If the both the agents (used prior to & after failover) modify the Origin-Host AVP (say, setting it to their own identifier), how can duplicate detection be performed? ... Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 16 15:34:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrK58-000489-NY; Fri, 16 Jun 2006 15:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrK56-000484-Qh for dime@ietf.org; Fri, 16 Jun 2006 15:34:12 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrK55-00084N-4H for dime@ietf.org; Fri, 16 Jun 2006 15:34:12 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k5GJY90V005047; Sat, 17 Jun 2006 04:34:09 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k5GJYAdh014347; Sat, 17 Jun 2006 04:34:10 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id EAA14312; Sat, 17 Jun 2006 04:34:10 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k5GJY87H017061; Sat, 17 Jun 2006 04:34:08 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k5GJY8Db025658; Sat, 17 Jun 2006 04:34:08 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0Y00E01X0QYH60@mail.po.toshiba.co.jp>; Sat, 17 Jun 2006 04:34:08 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FrK4g-0008Bs-Gy; Fri, 16 Jun 2006 12:33:46 -0700 Date: Fri, 16 Jun 2006 15:33:46 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] RFC3588 7.2 Misleading ABNF In-reply-to: To: Tolga Asveren Message-id: <20060616193346.GD29773@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20060616153651.GA27074@steelhead> User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, On Fri, Jun 16, 2006 at 02:11:55PM -0400, Tolga Asveren wrote: > Hi Yoshihiro, > > Please see my responses inline. > > Thanks, > Tolga > > > On Thu, Jun 15, 2006 at 12:26:11PM -0400, Tolga Asveren wrote: > > > RFC3588 7.2 defines the ABNF to be used for answer messages > > with a protocol > > > error return result. It is quite > > confusing/misleading/not-optimal (or I got > > > it wrong what it should be). > > > > > > As the starting assumption, I believe Protocol Errors must be > > related only > > > with routing, i.e. erorrs which are interesting from > > intermediares point of > > > view. Currently there a few errors classiefed as protocl errors, which > > > aren't, and hopefully we can have some cleanup there. > > > > Can you eraborate on why protocols errors must be related only to routing? > [TOLGA]Mainly because I think it is a good idea to have a separate category > only for routing errors ("Routing Erros" would probably be more appropriate > as a name), which is easily detectable by intermediares (I am not claiming > that this is currently the case based on RFC3588, this is just what I think > as a better solution). It is really handy/fast just to check the E-bit on > answers to decide whether Result-Code needs to be examined and wether there > should be another attempt to route the corresponding request. I may be > missing something but I don't see any good reason for a relay agent to > process an error answer message, unless it is related with a routing > decision. IMHO, it is better to send any other type of error answer to the > originator of the request, i.e. DIAMETER_COMMAND_UNSUPPORTED, > DIAMETER_INVALID_HDR_BITS, DIAMETER_INVALID_AVP_BITS are better not treated > on a per-hop basis. The purpose of E-bit is to indicate that an error is detected AND the answer message does not contain the set of AVPs supposed to be included for normal answer. What you are suggesting here is changing the purpose of E-bit to indicate that a *routing error* is detected AND the answer message does not contain the set of AVPs supposed to be included for normal answer. What happens if a *non-routing error* is detected AND the answer message does not contain the set of AVPs supposed to be included for normal answer? > > > > > > > > > > > I think the idea in 7.2 is: > > > a)Protocol error answer message must include the original > > message, e.g. so > > > that a relay agent can route it to some other peer. I assume *[ > > AVP ] stands > > > for that. > > > > Since the node that received the answer message would need to keep the > > original request (e.g., to deal with redirect or failover), I don't > > see a need for the original message to be included in the protocol > > error answer message, but I may be missing something. > [TOLGA]I have the impression that pending request queue is mainly to deal > with transport errors rather than with errors on Diameter level. RFC3588 > speaks also of removing a request from the pending queue, when an answer is > received for it. It is not spelled clearly but my understanding is that this > removing of request happens regardless of the Result-Code value.( My > understanding on this is based on 5.5.4) When the node remove the request from the queue when it receives an answer, the node can extract the original message. So again I don't see a need for the original message to be included in the protocol error answer message. Yoshihiro Ohba _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 16 15:41:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKCb-00014u-BQ; Fri, 16 Jun 2006 15:41:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKCa-00014o-BI for dime@ietf.org; Fri, 16 Jun 2006 15:41:56 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrKCY-0008Nx-Mg for dime@ietf.org; Fri, 16 Jun 2006 15:41:56 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k5GJflRr000130; Sat, 17 Jun 2006 04:41:47 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k5GJhDxp010763; Sat, 17 Jun 2006 04:43:13 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id EAA10736; Sat, 17 Jun 2006 04:43:13 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k5GJfk60026592; Sat, 17 Jun 2006 04:41:46 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k5GJfkow028647; Sat, 17 Jun 2006 04:41:46 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0Y00E33XDGYH60@mail.po.toshiba.co.jp>; Sat, 17 Jun 2006 04:41:46 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FrKBa-0008DR-6t; Fri, 16 Jun 2006 12:40:54 -0700 Date: Fri, 16 Jun 2006 15:40:54 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] RFC3588 7.2 Misleading ABNF In-reply-to: <4C0FAAC489C8B74F96BEAD85EAEB26250230F964@xmb-sjc-215.amer.cisco.com> To: "Glen Zorn (gwz)" Message-id: <20060616194054.GE29773@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <4C0FAAC489C8B74F96BEAD85EAEB26250230F964@xmb-sjc-215.amer.cisco.com> User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org On Fri, Jun 16, 2006 at 11:36:25AM -0700, Glen Zorn (gwz) wrote: > Yoshihiro Ohba supposedly scribbled: > > ... > > > > > Is a proxy a relay agent? I could not find such an explicit > > statement in RFC 3588, but I could be wrong. > > Be that as it may, consider the case described in section 5.5.4. If the both the agents (used prior to & after failover) modify the Origin-Host AVP (say, setting it to their own identifier), how can duplicate detection be performed? This is a good point. I agree. I think we need to explicitly describe that Origin-Host AVP MUST NOT be modified by any node. Going back to the original discussion, I don't see a need for Error-Reporting-Host AVP. Yoshihiro Ohba > > ... > > Hope this helps, > > ~gwz > > Why is it that most of the world's problems can't be solved by simply > listening to John Coltrane? -- Henry Gabriel > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 16 17:47:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMAI-0004fZ-Pg; Fri, 16 Jun 2006 17:47:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMAH-0004fR-3d for dime@ietf.org; Fri, 16 Jun 2006 17:47:41 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrMAF-0006Dr-Oz for dime@ietf.org; Fri, 16 Jun 2006 17:47:41 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 84C84558B1 for ; Fri, 16 Jun 2006 17:47:39 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5GLlctj010224 for ; Fri, 16 Jun 2006 17:47:38 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] RFC3588 7.2 Misleading ABNF Date: Fri, 16 Jun 2006 17:24:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-reply-to: <20060616193346.GD29773@steelhead> Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Yoshihiro, [..snip..] > The purpose of E-bit is to indicate that an error is detected AND the > answer message does not contain the set of AVPs supposed to be > included for normal answer. > > What you are suggesting here is changing the purpose of E-bit to > indicate that a *routing error* is detected AND the answer message > does not contain the set of AVPs supposed to be included for normal > answer. What happens if a *non-routing error* is detected AND the > answer message does not contain the set of AVPs supposed to be > included for normal answer? [TOLGA]The way you described seems to be the case and I don't have a strong opinion on using E-bit to detect routing errors. I strongly believe that relay agents shouldn't care about non-routing errors though, E-bit was just an easy way to detect such errors but relays can investigate Result-Code AVP as well. One problem with the grouping in 7.1.3 is that it ties use of E-bit with per-hop treatment, which is not a good idea AFAICS. The use of E-bit seems quite arbitrary as well. What makes "DIAMETER INVALID AVP BITS" answers not to contain necessary answer AVPs whereas "DIAMETER INVALID AVP BIT COMBO" answers do contain such AVPs? What is the criteria to decide whether an answer should comply or not with expected answer ABNF? I would think as a general rule for error answers, there is no need to conform to the ABNF specification for the command, unless the AVPs in that ABNF are necessary to interprete the error, e.g. we probably wouldn't need the whole set of AVPs if there is a missing AVP, just the missing AVP in Failed-AVP AVP. Does this make sense? If the answer is "yes", it seems almost every error in base protocol would fall into E-bit category -probably except errors which are more related with application logic rather than the core base functionality like decoding/encoding/routing messages, e.g. "DIAMETER AUTHENTICATION REJECTED". > > > > > > > > > > > > > > > > I think the idea in 7.2 is: > > > > a)Protocol error answer message must include the original > > > message, e.g. so > > > > that a relay agent can route it to some other peer. I assume *[ > > > AVP ] stands > > > > for that. > > > > > > Since the node that received the answer message would need to keep the > > > original request (e.g., to deal with redirect or failover), I don't > > > see a need for the original message to be included in the protocol > > > error answer message, but I may be missing something. > > [TOLGA]I have the impression that pending request queue is > mainly to deal > > with transport errors rather than with errors on Diameter level. RFC3588 > > speaks also of removing a request from the pending queue, when > an answer is > > received for it. It is not spelled clearly but my understanding > is that this > > removing of request happens regardless of the Result-Code value.( My > > understanding on this is based on 5.5.4) > > When the node remove the request from the queue when it receives an > answer, the node can extract the original message. So again I don't > see a need for the original message to be included in the protocol > error answer message. [TOLGA]I think this is quite related with implementation decisions and the "node" may be implemented according to a layered architecture where transport related procedures are not tightly coupled with Diameter related functionality. In any case, the way you suggested should work -maybe not as good for some implementations as for other ones-. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 16 18:00:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMMw-0004p8-Kt; Fri, 16 Jun 2006 18:00:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMMv-0004ot-09 for dime@ietf.org; Fri, 16 Jun 2006 18:00:45 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrMMt-0007mL-Nv for dime@ietf.org; Fri, 16 Jun 2006 18:00:44 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 16 Jun 2006 15:00:40 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,144,1149490800"; d="scan'208"; a="29721669:sNHT22407384" Received: from [10.86.242.75] (che-vpn-cluster-2-75.cisco.com [10.86.242.75]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5GM0dno005687; Fri, 16 Jun 2006 18:00:40 -0400 (EDT) Message-ID: <44932A06.3080205@cisco.com> Date: Fri, 16 Jun 2006 18:00:38 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] RFC3588 7.2 Misleading ABNF References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Some other things that I believe is wrong with the error ABNF: f) It should say *[Proxy-Info], not [Proxy-Info]. g) Should explicitly allow *[Redirect-Host], [Redirect-Host-Usage], [Redirect-Host-Cache-Time] AVPs. h) Should include [Error-Message]. i) Should include *[Failed-AVP] since presumably a 3009 (DIAMETER_INVALID_AVP_BITS) error should include the offending AVP (although unlike similar error cases this is not mentioned explicitly for this error code). Some comments inline... Tolga Asveren wrote: > RFC3588 7.2 defines the ABNF to be used for answer messages with a protocol > error return result. It is quite confusing/misleading/not-optimal (or I got > it wrong what it should be). > > As the starting assumption, I believe Protocol Errors must be related only > with routing, i.e. erorrs which are interesting from intermediares point of > view. Currently there a few errors classiefed as protocl errors, which > aren't, and hopefully we can have some cleanup there. This makes some sense to me but I don't know if it can be fixed in a backwards compatible manner. It doesn't seem to be important enough to break compatibility for. > > > I think the idea in 7.2 is: > a)Protocol error answer message must include the original message, e.g. so > that a relay agent can route it to some other peer. I assume *[ AVP ] stands > for that. This was not my impression at all and I don't think there's any text in the base spec to back it up. Proxies/relays then have to be stateful in order to try another peer and that seems OK to me. Thanks, Anders > > b)Protocol error answer message must include Result-Code, so that an > intermediary can decide what to do with that answer. This is why we have { > Result Code }. > > So far so good.... > > c) { Origin-Host } { Origin-Realm } > I assume those are *not* the Origin-Host Origin-Realm AVP of the original > message -7.4 Error-Reporting hints that they aren't-. Why do we need them? > If for troubleshooting, I would opt for Error-Reporting-Host AVP. When a > relay agent receives a protocol error answer, how does it know which > Origin-Host/Origin-Realm AVP to remove -there is also a pair for the > original message, which should be kept intact-. > > d) [ Error-Reporting-Host ] > It is a good idea to have an AVP for troubleshooting purposes -as specified > in 7.4-. IMHO, it is better to have this as optional rather than a MUST. I > think, it is a better idea not ise Origin-Host/Origin-Realm for debugging > and rely on this specific AVP. > > e) [ Origin-state-Id ] [ Proxy-Info ] > Why are they explicitly mentioned? > > > Overall, IMO, 7.2 should have said that protocol error answers must include > the original message, Result-Code AVP and may include Error-Reporting-Host > AVP. > > Thanks, > Tolga > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 16 18:13:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMYp-0007XI-5C; Fri, 16 Jun 2006 18:13:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMYo-0007XA-4p for dime@ietf.org; Fri, 16 Jun 2006 18:13:02 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrMYm-00018r-TN for dime@ietf.org; Fri, 16 Jun 2006 18:13:02 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2006 18:13:00 -0400 X-IronPort-AV: i="4.06,144,1149480000"; d="scan'208"; a="90260139:sNHT29875840" Received: from [10.86.242.75] (che-vpn-cluster-2-75.cisco.com [10.86.242.75]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5GMD0no007792; Fri, 16 Jun 2006 18:13:00 -0400 (EDT) Message-ID: <44932CEA.7020708@cisco.com> Date: Fri, 16 Jun 2006 18:12:58 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [Dime] 3588-bis References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Backwards compatibility is obviously a valid concern but in my view it's not a goal to not allow or even to limit the number of new features as long as they can be added in way that preserves backwards compatibility. I think we have to consider whatever ideas people have on a case by case basis. Anders john.loughney@nokia.com wrote: > Hi all, > > We've discussed both a 3588-bis (Diameter Base) & a 4005-bis (NASREQ). > Before starting to produce such > documents, I would like to get some feedback on some ground-rules. > > IANA considerations in 3588 explain the mechanisms to extend Diameter. > As there are existing deployments of Diameter, I think we should not add > new features to 3588-bis, just focusing on either removing features that > are not used and correcting mistakes. > > I'd like discussion to be very focused, having proposed text changes. > General statements like "wouldn't it be nice if feature x could do > this?" aren't very helpful. > > I think that we should spend time in Montreal talking about this - I > think we should prepare a list of issues with 3588. There are a number > of issues in the issue tracker, I suggest we start from that. > > comments? > John > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jun 17 08:45:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FraB4-0003qH-Jr; Sat, 17 Jun 2006 08:45:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FraB3-0003qC-TJ for dime@ietf.org; Sat, 17 Jun 2006 08:45:25 -0400 Received: from smtp1.int-evry.fr ([157.159.10.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FraB2-0003St-LG for dime@ietf.org; Sat, 17 Jun 2006 08:45:25 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp1.int-evry.fr (Postfix) with ESMTP id 1F70F18D004 for ; Sat, 17 Jun 2006 14:52:24 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1Fra9H-0007Vi-VQ for dime@ietf.org; Sat, 17 Jun 2006 14:43:35 +0200 Date: Sat, 17 Jun 2006 14:43:35 +0200 From: Julien Bournelle To: dime@ietf.org Message-ID: <20060617124335.GB28859@ipv6-3.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Dime] AVPs/Accounting and App-Id X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, I have a quick question: If a "service" (e.g. Mobile IPv6) needs specific AVPs for Accounting (ACR/ACA), do you think it would require a new Application-ID ? Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jun 17 12:54:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fre4M-0007xW-JS; Sat, 17 Jun 2006 12:54:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fre4M-0007xR-66 for dime@ietf.org; Sat, 17 Jun 2006 12:54:46 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fre4K-0002rD-On for dime@ietf.org; Sat, 17 Jun 2006 12:54:46 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5HGsgSe021937; Sat, 17 Jun 2006 19:54:42 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Jun 2006 19:54:42 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Jun 2006 19:54:41 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588-bis Date: Sat, 17 Jun 2006 19:54:41 +0300 Message-ID: In-Reply-To: <44932CEA.7020708@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3588-bis Thread-Index: AcaRkg03gVoxPCZ2Rra/8r5UJj99xgAnHQ5w From: To: X-OriginalArrivalTime: 17 Jun 2006 16:54:41.0522 (UTC) FILETIME=[BA1C8520:01C6922E] X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Andres, >Backwards compatibility is obviously a valid concern but in my=20 >view it's not a goal to not allow or even to limit the number=20 >of new features as long as they can be added in way that=20 >preserves backwards compatibility.=20 >I think we have to consider whatever ideas people have on a=20 >case by case basis. By no means do I imply that we cannot have new features. I'd prefer to see new features as extensions, using the basic extensibility options - I just wanting to be cautious about adding new features to the base spec document. I'm more comfortable if they are in separate documents, but then again, this is a consensus based process, so if there is consensus, then we should run with it. John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jun 18 01:56:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrqGx-0003bD-NR; Sun, 18 Jun 2006 01:56:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrqGw-0003b8-Oq for dime@ietf.org; Sun, 18 Jun 2006 01:56:34 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrqGv-0007gj-Dd for dime@ietf.org; Sun, 18 Jun 2006 01:56:34 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 17 Jun 2006 22:56:32 -0700 X-IronPort-AV: i="4.06,146,1149490800"; d="scan'208"; a="1827722877:sNHT30402596" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5I5uWBG005436; Sat, 17 Jun 2006 22:56:32 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5I5uWCU021241; Sat, 17 Jun 2006 22:56:32 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 17 Jun 2006 22:56:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 17 Jun 2006 22:56:29 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250230FBCD@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slot to talk about DCCA & Base MIBs Thread-Index: AcaSm/GXWkWa2Rx4Q1yP5OrsX8BPDA== From: "Glen Zorn \(gwz\)" To: , "Hannes Tschofenig" X-OriginalArrivalTime: 18 Jun 2006 05:56:31.0983 (UTC) FILETIME=[F2ECCFF0:01C6929B] DKIM-Signature: a=rsa-sha1; q=dns; l=440; t=1150610192; x=1151474192; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:Slot=20to=20talk=20about=20DCCA=20&=20Base=20MIBs; X=v=3Dcisco.com=3B=20h=3DKiUWtZPmcH7Y0JgrCdTVpt9W+4M=3D; b=YYjMN+tiscjOKbhJHmVudo3Y+3B338XLp+h1qzM7b4T/+ooxCLoz2dGdJCsE9taJ/tETKxUj fhOHCipCW8D5sKAoN4t6nl+HNnzpumXe0O1nCLNxjDZjhnz4l+uyzi0d; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: dime@ietf.org, "Glen Zorn \(gwz\)" Subject: [Dime] Slot to talk about DCCA & Base MIBs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, guys. I would like to request a 15-20 minute slot in Montreal to talk about the MIBs. Thanks! ~gwz Treat the Earth well.=20 It was not given to you by your parents. It was loaned to you by your children. -- Kenyan Proverb Humankind has not woven the web of life. We are but one thread within it. Whatever we do to the web, we do to ourselves. All things are bound together. All things connect. -- Chief Seattle _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 19 08:07:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIWy-0000ux-T7; Mon, 19 Jun 2006 08:07:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIWx-0000ur-Ei for dime@ietf.org; Mon, 19 Jun 2006 08:06:59 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsIWv-0000QY-Od for dime@ietf.org; Mon, 19 Jun 2006 08:06:59 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k5JC6uwg004640 for ; Mon, 19 Jun 2006 14:06:56 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k5JC6uNC009037 for ; Mon, 19 Jun 2006 14:06:56 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 14:06:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jun 2006 14:06:43 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter QoS Strawman Proposal Thread-Index: AcaTmNRLIB7sXABKQcSruXX8lrOzxg== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 19 Jun 2006 12:06:56.0347 (UTC) FILETIME=[DC1762B0:01C69398] X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: [Dime] Diameter QoS Strawman Proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1175974166==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1175974166== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69398.DBF029A3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69398.DBF029A3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 based on the thoughts by Avi about the Diameter QoS work, we (Mayutan Arumaithurai, Alan McNamee and myself) have produced a strawman proposal. I would like to particularly thank Mayutan since he had todo most of the work. Please find the draft at: http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/diamete r-qos-strawman-00.txt This strawman proposal takes a lot of text from the previous draft version (draft-tschofenig-dime-diameter-qos-00.txt) and allows the QoS mechanisms to work with NASREQ, EAP and DCC.=20 This document is meant to be input for discussion. Hence, there is no plan to submit it. Ciao Hannes ------_=_NextPart_001_01C69398.DBF029A3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Diameter QoS Strawman Proposal

Hi all,

based on the thoughts by Avi about the = Diameter QoS work, we (Mayutan Arumaithurai, Alan McNamee and myself) = have produced a strawman proposal. I would like to particularly thank = Mayutan since he had todo most of the work. Please find the draft = at:

http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diamet= er-qos/diameter-qos-strawman-00.txt

This strawman proposal takes a lot of = text from the previous draft version (draft-tschofenig-dime-diameter-qos-00.txt) and = allows the QoS mechanisms to work with NASREQ, EAP and = DCC.

This document is = meant to be input for discussion. Hence, there is no plan to submit = it.

Ciao
Hannes

------_=_NextPart_001_01C69398.DBF029A3-- --===============1175974166== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1175974166==-- From dime-bounces@ietf.org Mon Jun 19 08:15:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIf1-00049E-Hh; Mon, 19 Jun 2006 08:15:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIez-000498-Jc for dime@ietf.org; Mon, 19 Jun 2006 08:15:17 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsIey-0000qQ-0i for dime@ietf.org; Mon, 19 Jun 2006 08:15:17 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k5JCFEHi016174 for ; Mon, 19 Jun 2006 14:15:14 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k5JCFEQx007486 for ; Mon, 19 Jun 2006 14:15:14 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 14:15:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jun 2006 14:14:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter QoS Dinner Thread-Index: AcaTmfAYG5wnsZsPQfeCortcaXGmEQ== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 19 Jun 2006 12:15:14.0462 (UTC) FILETIME=[04FDB3E0:01C6939A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Subject: [Dime] Diameter QoS Dinner X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1740847429==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1740847429== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6939A.04C657FB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6939A.04C657FB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 it would be good to meet Diameter QoS interested folks at the next IETF for a discussion about possible next steps before the DIME session.=20 The DIME WG session will be on MONDAY, July 10, 2006=20 1740-1840 Afternoon Session III=20 Room 519B APP widex Widget Description Exchange Service WG =09 Room 520ABC INT softwire Softwires WG =09 Room 519A IRTF NMRG Network Management Research Group Charter =09 Room 513C-F OPS dime Diameter Maintenance and Extensions WG =09 Room 520DEF RAI rtpsec Securing the Real-time Transport Protocol BOF =09 Room 513B SEC sasl Simple Authentication and Security Layer WG =09 Room 518AB TSV tsvwg Transport Area Working Group WG =09 https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=3D= 66 Hence, there is only time after the Welcome Reception on Sunday. My proposal would be to meet at the registration desk at 19:30. =20 Please send me a mail if you are interested.=20 Ciao Hannes ------_=_NextPart_001_01C6939A.04C657FB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Diameter QoS Dinner

Hi all,

it would be good to meet Diameter QoS = interested folks at the next IETF for a discussion about possible next = steps before the DIME session.

The DIME WG session will be = on MONDAY, July 10, 2006
1740-1840 = Afternoon Session III =
Room = 519B       APP     = widex   Widget Description Exchange Service = WG 
Room 520ABC     INT     = softwire        Softwires WG   
Room 519A       IRTF    = NMRG    Network Management Research Group Charter =      
Room = 513C-F     OPS     = dime    Diameter Maintenance and Extensions WG 
Room = 520DEF     RAI     rtpsec  = Securing the Real-time Transport Protocol BOF  
Room 513B       = SEC     sasl    = Simple Authentication and Security Layer = WG    
Room 518AB      TSV     = tsvwg   Transport Area Working Group WG =        
https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meetin= g_num=3D66
Hence, there is = only time after the Welcome Reception on Sunday. My proposal would be to = meet  at the registration desk at 19:30. 

Please send me a = mail if you are interested.

Ciao
Hannes

------_=_NextPart_001_01C6939A.04C657FB-- --===============1740847429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1740847429==-- From dime-bounces@ietf.org Mon Jun 19 23:18:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsWki-0005SA-1F; Mon, 19 Jun 2006 23:18:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsWkg-0005S5-My for dime@ietf.org; Mon, 19 Jun 2006 23:18:06 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsWkf-0004wS-9h for dime@ietf.org; Mon, 19 Jun 2006 23:18:06 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5K3HxVE014282; Tue, 20 Jun 2006 06:18:02 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 06:17:37 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 06:17:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jun 2006 06:17:36 +0300 Message-ID: In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB26250230FBCD@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slot to talk about DCCA & Base MIBs Thread-Index: AcaSm/GXWkWa2Rx4Q1yP5OrsX8BPDABfBpRg From: To: , X-OriginalArrivalTime: 20 Jun 2006 03:17:37.0645 (UTC) FILETIME=[14D7C9D0:01C69418] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: dime@ietf.org Subject: [Dime] RE: Slot to talk about DCCA & Base MIBs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Without a doubt, that would be a good thing. thanks, John=20 >-----Original Message----- >From: ext Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 >Sent: 18 June, 2006 08:56 >To: Loughney John (Nokia-NRC/Helsinki); Hannes Tschofenig >Cc: dime@ietf.org; Glen Zorn (gwz) >Subject: Slot to talk about DCCA & Base MIBs > >Hi, guys. I would like to request a 15-20 minute slot in=20 >Montreal to talk about the MIBs. Thanks! > >~gwz > >Treat the Earth well.=20 >It was not given to you by your parents. >It was loaned to you by your children. > -- Kenyan Proverb > >Humankind has not woven the web of life. >We are but one thread within it. >Whatever we do to the web, we do to ourselves. >All things are bound together. >All things connect. > -- Chief Seattle > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 20 15:50:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmEn-0001V7-So; Tue, 20 Jun 2006 15:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmEc-0001Rd-VR; Tue, 20 Jun 2006 15:50:02 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsmEc-0003Tf-Ai; Tue, 20 Jun 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5KJo2Rx015712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsmEc-0003bF-0L; Tue, 20 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Jun 2006 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-mip6-integrated-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter MIPv6 Bootstrapping for the Integrated Scenario Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-integrated-00.txt Pages : 26 Date : 2006-6-20 A Mobile IPv6 node requires a home agent address, a home address, and IPsec security association with its home agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these parameters are statically configured. Ongoing Mobile IPv6 bootstrapping work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the usage of Diameter to facilitate Mobile IPv6 bootstrapping for the integrated scenario. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-mip6-integrated-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-mip6-integrated-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-20113607.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-integrated-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-integrated-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-20113607.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Tue Jun 20 16:37:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmyC-00070O-07; Tue, 20 Jun 2006 16:37:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmyA-0006wM-5w; Tue, 20 Jun 2006 16:37:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsmin-0007zs-V3; Tue, 20 Jun 2006 16:21:13 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsmWF-0004YR-VE; Tue, 20 Jun 2006 16:08:17 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5KJo2mU024851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsmEb-0003bC-Vy; Tue, 20 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-mip6-split-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Mobile IPv6 Bootstrapping using Diameter in the Split Scenario Author(s) : J. Bournelle, et al. Filename : draft-ietf-dime-mip6-split-00.txt Pages : 13 Date : 2006-6-20 In Mobile IPv6 deployment a need for an interaction between the Home Agent, the AAA infrastructure of the Mobile Service Provider (MSP) and the Mobility Service Authorizer (MSA) has been identified. This document describes how Diameter can be used to perform AAA functionalities for the Mobile IPv6 service in the "split" scenario. For this, it describes two possible approaches. It also explains how Diameter meet the goals outlined in the MIPv6 AAA goals document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-mip6-split-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-mip6-split-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-20113338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-split-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-split-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-20113338.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Wed Jun 21 06:11:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FszgB-0000TZ-En; Wed, 21 Jun 2006 06:11:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fszg9-0000TU-Lz for dime@ietf.org; Wed, 21 Jun 2006 06:11:21 -0400 Received: from mailout-1.omnitel.it ([194.20.77.121] helo=fmis437.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fszg7-0002E4-UA for dime@ietf.org; Wed, 21 Jun 2006 06:11:21 -0400 Received: from omini96.omnitel.it (omini96.omnitel.it [10.21.18.148]) by fmis437.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k5LABHps003840 for ; Wed, 21 Jun 2006 12:11:17 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.11]) by ominc74.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Jun 2006 12:11:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RE: Diameter base protocol messages used by DCCA Date: Wed, 21 Jun 2006 12:10:55 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC207713369@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter base protocol messages used by DCCA Thread-Index: AcaQvHRLCzEvKzDHRWSkW/O26V/ALwAWLJYwABK/jSAA6/upUA== From: "STURA, Marco, VF-IT" To: "Glen Zorn \(gwz\)" , "Tolga Asveren" , "Anders Kristensen" X-OriginalArrivalTime: 21 Jun 2006 10:11:11.0518 (UTC) FILETIME=[057A13E0:01C6951B] X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: aaa-wg@merit.edu, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Glen, Sorry for the late answer I was in business trip with no access to my emails. >So, in other words, in order to implement a e.g., [NASREQ], [DIAMMIP] peer >intended for general distribution, one must include CCA client >functionality. Not necessarily. One could provide communication means to enable a CCA functionality module to add relevant AVPs to the initial AA request and process relevant AVPs from AA answer. >Or, that there were no intermediate interrogations; also, what about the >case of a one-time event (balance check, etc.)? Although this kind of >activity doesn't seem to be included in any of the examples in RFC 4006, >neither does it appear to be prohibited. If a balance check or other type >of one-time event was included in the AAR it seems that there would be no >client-side counter incremented. One time events always use CCR/CCA messages. In section 6 of RFC4006 it is stated in first paragraph "The use of a one-time event implies that the user has been authenticated and authorized beforehand." Examples of one time event usage are given in Flow III, IV and V within the appendix. One time event uses Request-type of EVENT. >I hadn't planned to, no. However, if it is necessary to use this data to >infer the existence of an initial interrogation from its absence (does >anybody else see something odd about this?), I suppose I will have to do >so. I'm afraid DCCA MIB should be able at least to differentiate between EVENT, INITIAL, UPDATE and TERMINATION requests. If you want to go further and also count what type of event the request was sent for then you would need to consider the Requested-Action. However, all these are unfortunately DCCA specific AVP based information. Regards Marco _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 21 10:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3e7-0003gr-7I; Wed, 21 Jun 2006 10:25:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3e5-0003gm-OR for dime@ietf.org; Wed, 21 Jun 2006 10:25:29 -0400 Received: from ionians.ncr.disa.mil ([164.117.82.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3e3-0007x8-DC for dime@ietf.org; Wed, 21 Jun 2006 10:25:29 -0400 Received: from vanualevu.disanet.disa-u.mil ([164.117.144.226]) by ionians.ncr.disa.mil with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 10:25:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Diameter QoS Strawman Proposal (UNCLASSIFIED) Date: Wed, 21 Jun 2006 10:25:23 -0400 Message-ID: <9B4320CC9BC1D847AFFA97F25A422A59114B41@vanualevu.disanet.disa-u.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter QoS Strawman Proposal Thread-Index: AcaTmOCUGjLqPVdnRIG1B2MqHMqdEABnmB4A From: "Nguyen, An P CIV NCS NC2" To: "Tschofenig, Hannes" X-OriginalArrivalTime: 21 Jun 2006 14:25:23.0982 (UTC) FILETIME=[88A762E0:01C6953E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0693492033==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0693492033== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6953E.8870EBB0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6953E.8870EBB0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Classification: UNCLASSIFIED=20 Caveats: NONE =20 Hannes, =20 Just a question: RFC 4412 defines SIP header fields for communications resource priority. This RFC deals with different namespaces (e.g., ets.x, wps.x, etc.). How does your Diameter QoS draft take these namespaces into account when it comes to authentication and authorization?=20 =20 The reason I am interested in this draft is that the Cx and Dx interfaces of the IMS architecture specifies DIAMETER. =20 Thanks, =20 An -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] Sent: Monday, June 19, 2006 8:07 AM To: dime@ietf.org Subject: [Dime] Diameter QoS Strawman Proposal Hi all,=20 based on the thoughts by Avi about the Diameter QoS work, we (Mayutan Arumaithurai, Alan McNamee and myself) have produced a strawman proposal. I would like to particularly thank Mayutan since he had todo most of the work. Please find the draft at: =20 http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/diamete r-qos-strawman-00.txt=20 This strawman proposal takes a lot of text from the previous draft version (draft-tschofenig-dime-diameter-qos-00.txt) and allows the QoS mechanisms to work with NASREQ, EAP and DCC.=20 This document is meant to be input for discussion. Hence, there is no plan to submit it.=20 Ciao=20 Hannes=20 =20 Classification: UNCLASSIFIED=20 Caveats: NONE ------_=_NextPart_001_01C6953E.8870EBB0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Diameter QoS Strawman Proposal

Classification: UNCLASSIFIED =

Caveats: NONE

Hannes,
 
Just a=20 question: RFC 4412 = defines  SIP header fields = for=20 communications resource priority. This RFC deals with different = namespaces=20 (e.g., ets.x, wps.x, etc.). How does your Diameter QoS draft take = these=20 namespaces into account when it comes to authentication and = authorization?=20
 
The reason I am interested in this draft is = that the Cx and=20 Dx interfaces of the IMS architecture specifies=20 DIAMETER.
 
Thanks,
 
An
-----Original Message-----
From: Tschofenig, Hannes = [mailto:hannes.tschofenig@siemens.com]
Sent: Monday, June = 19, 2006=20 8:07 AM
To: dime@ietf.org
Subject: [Dime] Diameter = QoS=20 Strawman Proposal

Hi all,

based on the thoughts by Avi about the = Diameter QoS=20 work, we (Mayutan Arumaithurai, Alan McNamee and myself) have produced = a=20 strawman proposal. I would like to particularly thank Mayutan since he = had=20 todo most of the work. Please find the draft at:

http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos= /diameter-qos-strawman-00.txt=20

This strawman proposal takes a lot of = text from the=20 previous draft version (draft-tschofenig-dime-diameter-qos-00.txt) = and allows=20 the QoS mechanisms to work with NASREQ, EAP and = DCC.

This document is = meant to be input=20 for discussion. Hence, there is no plan to submit it. =

Ciao =
Hannes=20

Classification: UNCLASSIFIED

Caveats: NONE

------_=_NextPart_001_01C6953E.8870EBB0-- --===============0693492033== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0693492033==-- From dime-bounces@ietf.org Wed Jun 21 11:06:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4Hq-0005OS-4i; Wed, 21 Jun 2006 11:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4Ho-0005OI-3J for dime@ietf.org; Wed, 21 Jun 2006 11:06:32 -0400 Received: from ionians.ncr.disa.mil ([164.117.82.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4Hm-0006rM-Nj for dime@ietf.org; Wed, 21 Jun 2006 11:06:32 -0400 Received: from vanualevu.disanet.disa-u.mil ([164.117.144.226]) by ionians.ncr.disa.mil with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 11:06:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Diameter QoS Strawman Proposal (UNCLASSIFIED) Date: Wed, 21 Jun 2006 11:06:30 -0400 Message-ID: <9B4320CC9BC1D847AFFA97F25A422A59114B44@vanualevu.disanet.disa-u.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter QoS Strawman Proposal Thread-Index: AcaTmOCUGjLqPVdnRIG1B2MqHMqdEABnmB4AAAM07nA= From: "Nguyen, An P CIV NCS NC2" To: "Tschofenig, Hannes" X-OriginalArrivalTime: 21 Jun 2006 15:06:30.0278 (UTC) FILETIME=[46AE4A60:01C69544] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1606560767==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1606560767== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69544.46B854DC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69544.46B854DC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Classification: UNCLASSIFIED=20 Caveats: NONE =20 Sorry I meant IMS-based NGN architecture that has Cx and Dx interfaces. =20 An -----Original Message----- From: Nguyen, An P CIV NCS NC2=20 Sent: Wednesday, June 21, 2006 10:25 AM To: 'Tschofenig, Hannes' Cc: dime@ietf.org Subject: RE: [Dime] Diameter QoS Strawman Proposal (UNCLASSIFIED) Classification: UNCLASSIFIED=20 Caveats: NONE Hannes, =20 Just a question: RFC 4412 defines SIP header fields for communications resource priority. This RFC deals with different namespaces (e.g., ets.x, wps.x, etc.). How does your Diameter QoS draft take these namespaces into account when it comes to authentication and authorization?=20 =20 The reason I am interested in this draft is that the Cx and Dx interfaces of the IMS architecture specifies DIAMETER. =20 Thanks, =20 An -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] Sent: Monday, June 19, 2006 8:07 AM To: dime@ietf.org Subject: [Dime] Diameter QoS Strawman Proposal Hi all,=20 based on the thoughts by Avi about the Diameter QoS work, we (Mayutan Arumaithurai, Alan McNamee and myself) have produced a strawman proposal. I would like to particularly thank Mayutan since he had todo most of the work. Please find the draft at: =20 http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/diamete r-qos-strawman-00.txt=20 This strawman proposal takes a lot of text from the previous draft version (draft-tschofenig-dime-diameter-qos-00.txt) and allows the QoS mechanisms to work with NASREQ, EAP and DCC.=20 This document is meant to be input for discussion. Hence, there is no plan to submit it.=20 Ciao=20 Hannes=20 Classification: UNCLASSIFIED=20 Caveats: NONE =20 Classification: UNCLASSIFIED=20 Caveats: NONE ------_=_NextPart_001_01C69544.46B854DC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Diameter QoS Strawman Proposal

Classification: UNCLASSIFIED =

Caveats: NONE

Sorry=20 I meant IMS-based NGN architecture that has Cx and Dx=20 interfaces.
 
An
-----Original Message-----
From: Nguyen, An P CIV = NCS NC2=20
Sent: Wednesday, June 21, 2006 10:25 AM
To: = 'Tschofenig,=20 Hannes'
Cc: dime@ietf.org
Subject: RE: [Dime] = Diameter QoS=20 Strawman Proposal (UNCLASSIFIED)

Classification: UNCLASSIFIED =

Caveats: NONE

Hannes,
 
Just=20 a question: RFC 4412 = defines  SIP header = fields for=20 communications resource priority. This RFC deals with different = namespaces=20 (e.g., ets.x, wps.x, etc.). How does your Diameter QoS draft take = these=20 namespaces into account when it comes to authentication and = authorization?=20
 
The reason I am interested in = this draft is=20 that the Cx and Dx interfaces of the IMS architecture specifies=20 DIAMETER.
 
Thanks,
 
An
-----Original Message-----
From: Tschofenig, = Hannes=20 [mailto:hannes.tschofenig@siemens.com]
Sent: Monday, June = 19, 2006=20 8:07 AM
To: dime@ietf.org
Subject: [Dime] = Diameter QoS=20 Strawman Proposal

Hi all,

based on the thoughts by Avi about = the Diameter=20 QoS work, we (Mayutan Arumaithurai, Alan McNamee and myself) have = produced a=20 strawman proposal. I would like to particularly thank Mayutan since = he had=20 todo most of the work. Please find the draft at:

http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos= /diameter-qos-strawman-00.txt=20

This strawman proposal takes a lot of = text from=20 the previous draft version (draft-tschofenig-dime-diameter-qos-00.txt) = and allows=20 the QoS mechanisms to work with NASREQ, EAP and = DCC.

This document is = meant to be=20 input for discussion. Hence, there is no plan to submit = it.=20

Ciao =
Hannes =

Classification: UNCLASSIFIED

Caveats: NONE

Classification: UNCLASSIFIED

Caveats: NONE

------_=_NextPart_001_01C69544.46B854DC-- --===============1606560767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1606560767==-- From dime-bounces@ietf.org Wed Jun 21 11:38:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4mH-0002ls-Hs; Wed, 21 Jun 2006 11:38:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4mG-0002lj-VP for dime@ietf.org; Wed, 21 Jun 2006 11:38:00 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4mF-0000L3-Fh for dime@ietf.org; Wed, 21 Jun 2006 11:38:00 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k5LFbuPP003720; Wed, 21 Jun 2006 17:37:56 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k5LFbtge010528; Wed, 21 Jun 2006 17:37:55 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 17:37:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jun 2006 17:32:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: RE: Conclusions on the draft "Resource Management Extensions" Thread-Index: AcaVRs1ljFlPl29LSB+fntasVgkaCAAAIs9g From: "Tschofenig, Hannes" To: "Bernard Aboba" , "Pat Calhoun \(pacalhou\)" X-OriginalArrivalTime: 21 Jun 2006 15:37:55.0371 (UTC) FILETIME=[AA48A7B0:01C69548] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: aaa-wg@merit.edu, dime@ietf.org Subject: [Dime] AW: [AAA-WG]: RE: Conclusions on the draft "Resource Management Extensions" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all,=20 may I raise your attention to the following draft submitted for this = meeting. Requirement for the addition of Auditing Functionality to Diameter http://psg.com/~avri/dime/draft-bodin-dime-auditing-reqs-00.txt Unfortunately, it did not yet show up.=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]=20 > Im Auftrag von Bernard Aboba > Gesendet: Mittwoch, 21. Juni 2006 16:24 > An: Pat Calhoun (pacalhou) > Cc: MORAND Lionel RD-CORE-ISS; aaa-wg@merit.edu > Betreff: [AAA-WG]: RE: Conclusions on the draft "Resource=20 > Management Extensions" >=20 > As Pat said, the major priority of the AAA WG was completing=20 > work on the=20 > Diameter Base protocol and applications. I actually don't=20 > recall whether=20 > the WG made a judgement on the Resource Management draft; it=20 > just wasn't=20 > one of the top priorities.=20 >=20 > I will say that the Diameter architecture provides a much more sound=20 > base for resource management than RADIUS does. Most of the resource=20 > management implementations I have seen on RADIUS need to=20 > incorporate other=20 > information sources for validation, in order to deal with=20 > potential losses=20 > of RADIUS Accounting packets. Since Diameter runs over reliable=20 > transport, it should not have to do this.=20 >=20 > On Wed, 21 Jun 2006, Pat Calhoun (pacalhou) wrote: >=20 > > I'll let Bernard speak for the WG, but at the time the WG=20 > had many other > > priorities, and resource management was not one of them. However, I > > haven't had the opportunity to participate in the AAA WG=20 > for some time, > > so I'm not sure if this could be an opportune time to=20 > re-introduce it. > > =20 > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > >=20 > > =20 > >=20 > >=20 > > ________________________________ > >=20 > > From: MORAND Lionel RD-CORE-ISS > > [mailto:lionel.morand@orange-ft.com]=20 > > Sent: Wednesday, June 21, 2006 7:07 AM > > To: Bernard Aboba; Pat Calhoun (pacalhou) > > Subject: Conclusions on the draft "Resource Management > > Extensions" > > =09 > > =09 > >=20 > > Hi,=20 > > I would like to know what were the conclusions on the following > > draft initiated by Pat: draft-calhoun-diameter-res-mgmt-08.txt. > >=20 > (http://quimby.gnus.org/internet-drafts/draft-calhoun-diameter > -res-mgmt- > > 08.txt > >=20 > -res-mgmt- > > 08.txt> ) > >=20 > > Some folks from TISPAN are initiating a document based on this > > draft to perform resource management after failover, proposing to > > enhance the Diameter base protocol with dedicated commands.=20 > I'm pretty > > sure that the previous comments/concerns about such enhancements are > > still valid. > >=20 > > BR,=20 > > Lionel=20 > >=20 > >=20 > >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 21 11:38:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4mH-0002lo-EE; Wed, 21 Jun 2006 11:38:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4mG-0002ld-6W for dime@ietf.org; Wed, 21 Jun 2006 11:38:00 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4mE-0000Kz-Js for dime@ietf.org; Wed, 21 Jun 2006 11:38:00 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k5LFbtPZ030704; Wed, 21 Jun 2006 17:37:55 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k5LFbtgc010528; Wed, 21 Jun 2006 17:37:55 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 17:37:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jun 2006 17:37:44 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requirement for the addition of Auditing Functionality to Diameter Thread-Index: AcaVSKOxcPone4ZCSX2SqKwytskaNw== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 21 Jun 2006 15:37:55.0043 (UTC) FILETIME=[AA169B30:01C69548] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Ulf.Bodin@operax.com Subject: [Dime] Requirement for the addition of Auditing Functionality to Diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0643014693==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0643014693== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69548.A940162E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69548.A940162E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 Avri and Ulf submitted a draft about "Requirement for the addition of Auditing Functionality to Diameter".=20 Abstract=20 Diameter is being increasingly included in the work of other standards organizations and has become a key protocol in many architectures. One of the uses of Diameter includes setting and maintaining hard state. Often there is a need to query for information on active sessions for backup or synchronization purposes.=20 Please find the draft at before it will appear in the archive: http://psg.com/~avri/dime/draft-bodin-dime-auditing-reqs-00.txt Ciao Hannes ------_=_NextPart_001_01C69548.A940162E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Requirement for the addition of Auditing Functionality to = Diameter

Hi all,

Avri and Ulf submitted a draft about "Requirement = for the addition of Auditing Functionality to Diameter". =

Abstract =
Diameter is being = increasingly included in the work of other standards organizations and = has become a key protocol in many architectures. One of the uses of = Diameter includes setting and maintaining hard state. Often there is a = need to query for information on active sessions for backup or = synchronization purposes.

Please find the = draft at before it will appear in the archive:

= http://psg.com/~avri/dime/draft-bodin-dime-auditing-reqs-0= 0.txt


Ciao
Hannes

------_=_NextPart_001_01C69548.A940162E-- --===============0643014693== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0643014693==-- From dime-bounces@ietf.org Wed Jun 21 12:51:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5vG-00014C-Sz; Wed, 21 Jun 2006 12:51:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5uv-0000bt-BD for dime@ietf.org; Wed, 21 Jun 2006 12:51:01 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5gy-0006ef-9T for dime@ietf.org; Wed, 21 Jun 2006 12:36:37 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 99E34D2F3A; Wed, 21 Jun 2006 12:36:35 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5LGaYeL016433; Wed, 21 Jun 2006 12:36:34 -0400 (EDT) From: "Tolga Asveren" To: , Subject: RE: [Dime] AW: [AAA-WG]: RE: Conclusions on the draft "ResourceManagement Extensions" Date: Wed, 21 Jun 2006 12:13:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-reply-to: Importance: Normal X-STA-Metric: 0 (engine=021) X-STA-NotSpam: from:addr:ulticom.co message-id:@ulticom. subject:[ cc: diameter X-STA-Spam: calhoun identities, necessary? abort generic X-BTI-AntiSpam: sta:false/0/021, dcc:off, rbl:off, spf:pass, wlbl:trust/4, trusted:yes, pwl:no Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org A few quick questions/comments about this interesting draft: 1) 2.1 If there is no synchronization on client side, wouldn't using Origin-State-Id AVP (RFC3588 8.16)solve the problem described in this section? After failure/restart/takeover client can populate Origin-state-Id AVP with a value bigger than the one used before the failure and server should clean up previous sessions. 2) 2.1.1 SCTP multi-homing does not provide host redundancy -unless one has a distributed SCTP implementation, which probably is not realistic or something I would recomend to anybody- 3) 2.1.1 Is mentioning about IP address takeover really necessary? IMO, Diameter entities are addressed by Diameter Identities, hence what is important is that a backup assuming the identity of a failed active instance -which doesn't require IP takeover-. 4) As a generic comment, I always thought this type of functionality is to be addressed by specific applications themselves, e.g. DCCA, if there is such a need. Let's consider DCCA: When there is an open session, client will send from time to time CCR(Update) or CCR(Terminate), which would be replied with "DIAMETER UNKNOWN SESSION ID", if server failed/restarted etc... and corresponding state did not survive. Upon receipt of such an error answer, client can clean up its own state for this session. Similarly server can send RAR to client, if CCR(Update) is not received in a timely manner. If state did not survive on client side after a failure, client would reply with "DIAMETER UNKNOWN SESSION ID" and server can clean up session state (Alternatively server may choose not to send RAR and may abort the session) AFAICS, for the above example, all cases are covered. The question is, whose responsibility is that type of fucntionality, base protocol or applications. Thanks, Tolga > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Wednesday, June 21, 2006 11:33 AM > To: Bernard Aboba; Pat Calhoun (pacalhou) > Cc: aaa-wg@merit.edu; dime@ietf.org > Subject: [Dime] AW: [AAA-WG]: RE: Conclusions on the draft > "ResourceManagement Extensions" > > > Hi all, > > may I raise your attention to the following draft submitted for > this meeting. > > Requirement for the addition of Auditing Functionality to Diameter > http://psg.com/~avri/dime/draft-bodin-dime-auditing-reqs-00.txt > > Unfortunately, it did not yet show up. > > Ciao > Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 21 23:11:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFbg-0000Ji-SW; Wed, 21 Jun 2006 23:11:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFbf-0000JP-Fz for dime@ietf.org; Wed, 21 Jun 2006 23:11:47 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtFbd-0006L2-0c for dime@ietf.org; Wed, 21 Jun 2006 23:11:47 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5M3Bfn5022452; Thu, 22 Jun 2006 06:11:41 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 06:11:40 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 06:11:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jun 2006 06:11:40 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: RE: Conclusions on the draft "Resource Management Extensions" Thread-Index: AcaVR7cqZap4AUoPTLWUB+OuD//ieQAYbjyg From: To: , X-OriginalArrivalTime: 22 Jun 2006 03:11:40.0571 (UTC) FILETIME=[94D61EB0:01C695A9] X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: aaa-wg@merit.edu, dime@ietf.org Subject: [Dime] RE: [AAA-WG]: RE: Conclusions on the draft "Resource Management Extensions" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, I think that if there is interest, why not recycle the draft, and we can discuss it on the DiME mailing list. If you are able to rev it before Monday, it can be discussed in Montreal. John =20 >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]=20 >On Behalf Of ext Bernard Aboba >Sent: 21 June, 2006 17:24 >To: Pat Calhoun (pacalhou) >Cc: MORAND Lionel RD-CORE-ISS; aaa-wg@merit.edu >Subject: [AAA-WG]: RE: Conclusions on the draft "Resource=20 >Management Extensions" > >As Pat said, the major priority of the AAA WG was completing=20 >work on the Diameter Base protocol and applications. I=20 >actually don't recall whether the WG made a judgement on the=20 >Resource Management draft; it just wasn't one of the top priorities.=20 > >I will say that the Diameter architecture provides a much more=20 >sound base for resource management than RADIUS does. Most of=20 >the resource management implementations I have seen on RADIUS=20 >need to incorporate other information sources for validation,=20 >in order to deal with potential losses of RADIUS Accounting=20 >packets. Since Diameter runs over reliable transport, it=20 >should not have to do this.=20 > >On Wed, 21 Jun 2006, Pat Calhoun (pacalhou) wrote: > >> I'll let Bernard speak for the WG, but at the time the WG had many=20 >> other priorities, and resource management was not one of them.=20 >> However, I haven't had the opportunity to participate in the AAA WG=20 >> for some time, so I'm not sure if this could be an opportune=20 >time to re-introduce it. >> =20 >>=20 >> Pat Calhoun >> CTO, Wireless Networking Business Unit Cisco Systems >>=20 >> =20 >>=20 >>=20 >> ________________________________ >>=20 >> From: MORAND Lionel RD-CORE-ISS >> [mailto:lionel.morand@orange-ft.com]=20 >> Sent: Wednesday, June 21, 2006 7:07 AM >> To: Bernard Aboba; Pat Calhoun (pacalhou) >> Subject: Conclusions on the draft "Resource Management=20 >Extensions" >> =09 >> =09 >>=20 >> Hi,=20 >> I would like to know what were the conclusions on the=20 >following draft=20 >> initiated by Pat: draft-calhoun-diameter-res-mgmt-08.txt. >>=20 >(http://quimby.gnus.org/internet-drafts/draft-calhoun-diameter-res-mgm >> t- >> 08.txt >>=20 >> t- >> 08.txt> ) >>=20 >> Some folks from TISPAN are initiating a document based=20 >on this draft=20 >> to perform resource management after failover, proposing to enhance=20 >> the Diameter base protocol with dedicated commands. I'm pretty sure=20 >> that the previous comments/concerns about such enhancements=20 >are still=20 >> valid. >>=20 >> BR,=20 >> Lionel >>=20 >>=20 >>=20 > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 21 23:23:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFmx-0000HW-DL; Wed, 21 Jun 2006 23:23:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFmw-0000HM-ID for dime@ietf.org; Wed, 21 Jun 2006 23:23:26 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtFmu-0000OM-W2 for dime@ietf.org; Wed, 21 Jun 2006 23:23:26 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5M3NNHs030509; Thu, 22 Jun 2006 06:23:24 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 06:23:23 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 06:23:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Requirement for the addition of Auditing Functionality toDiameter Date: Thu, 22 Jun 2006 06:23:22 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Requirement for the addition of Auditing Functionality toDiameter Thread-Index: AcaVSKOxcPone4ZCSX2SqKwytskaNwAYnzkA From: To: , X-OriginalArrivalTime: 22 Jun 2006 03:23:23.0468 (UTC) FILETIME=[37CBB0C0:01C695AB] X-Spam-Score: 0.2 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: Ulf.Bodin@operax.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0317642517==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0317642517== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C695AB.377F56DA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C695AB.377F56DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 Hopefully Ulf/Avri are on the list, but I wonder if there is any overlap to this expired draft: =20 http://quimby.gnus.org/internet-drafts/draft-calhoun-diameter-res-mgm t-08.txt thanks, John ________________________________ From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: 21 June, 2006 18:38 To: dime@ietf.org Cc: Ulf.Bodin@operax.com Subject: [Dime] Requirement for the addition of Auditing Functionality toDiameter =09 =09 Hi all,=20 Avri and Ulf submitted a draft about "Requirement for the addition of Auditing Functionality to Diameter".=20 Abstract=20 Diameter is being increasingly included in the work of other standards organizations and has become a key protocol in many architectures. One of the uses of Diameter includes setting and maintaining hard state. Often there is a need to query for information on active sessions for backup or synchronization purposes.=20 Please find the draft at before it will appear in the archive:=20 http://psg.com/~avri/dime/draft-bodin-dime-auditing-reqs-00.txt =20 Ciao=20 Hannes=20 ------_=_NextPart_001_01C695AB.377F56DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Requirement for the addition of Auditing = Functionality to Diameter
Hi all,
 
Hopefully Ulf/Avri are on the list, but I = wonder if there=20 is any overlap to this expired draft:
 

http://quimby.gnus.org/internet-drafts/draft-calhoun-diamet= er-res-mgmt-08.txt

thanks,
John


From: ext Tschofenig, Hannes=20 [mailto:hannes.tschofenig@siemens.com]
Sent: 21 June, 2006=20 18:38
To: dime@ietf.org
Cc:=20 Ulf.Bodin@operax.com
Subject: [Dime] Requirement for the = addition of=20 Auditing Functionality toDiameter

Hi all,

Avri and Ulf submitted a draft about "Requirement for = the=20 addition of Auditing Functionality to Diameter".

Abstract =
Diameter is being = increasingly included=20 in the work of other standards organizations and has become a key = protocol in=20 many architectures. One of the uses of Diameter includes setting and=20 maintaining hard state. Often there is a need to query for information = on=20 active sessions for backup or synchronization purposes. =

Please find the = draft at before it=20 will appear in the archive:

= http://psg.com/~avri/dime/draft-bodin-dime-auditing-reqs-00.txt<= /FONT>


Ciao =
Hannes=20

------_=_NextPart_001_01C695AB.377F56DA-- --===============0317642517== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0317642517==-- From dime-bounces@ietf.org Thu Jun 22 03:08:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtJIO-0001PG-Vx; Thu, 22 Jun 2006 03:08:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtJIO-0001PB-Gx for dime@ietf.org; Thu, 22 Jun 2006 03:08:08 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FtJIN-0000eH-37 for dime@ietf.org; Thu, 22 Jun 2006 03:08:08 -0400 Received: (qmail invoked by alias); 22 Jun 2006 07:08:05 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp040) with SMTP; 22 Jun 2006 09:08:05 +0200 X-Authenticated: #29516787 Message-ID: <449A41D2.1030105@gmx.net> Date: Thu, 22 Jun 2006 09:08:02 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [Dime] Requirement for the addition of Auditing Functionality toDiameter References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Ulf.Bodin@operax.com, dime@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi John, yes, there certainly is an overlap. The previous draft expired a long time ago and Avri wanted to initiate the discussions in DIME again because of recent work done in other organizations. I encouraged here to submit something. Ciao Hannes john.loughney@nokia.com wrote: > Hi all, > > Hopefully Ulf/Avri are on the list, but I wonder if there is any overlap > to this expired draft: > > > __ > _http://quimby.gnus.org/internet-drafts/draft-calhoun-diameter-res-mgm > _t-08.txt > > thanks, > John > > > ------------------------------------------------------------------------ > *From:* ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > *Sent:* 21 June, 2006 18:38 > *To:* dime@ietf.org > *Cc:* Ulf.Bodin@operax.com > *Subject:* [Dime] Requirement for the addition of Auditing > Functionality toDiameter > > Hi all, > > Avri and Ulf submitted a draft about "Requirement for the addition > of Auditing Functionality to Diameter". > > Abstract > Diameter is being increasingly included in the work of other > standards organizations and has become a key protocol in many > architectures. One of the uses of Diameter includes setting and > maintaining hard state. Often there is a need to query for > information on active sessions for backup or synchronization purposes. > > Please find the draft at before it will appear in the archive: > > _http://psg.com/~avri/dime/draft-bodin-dime-auditing-reqs-00.txt_ > > > Ciao > Hannes > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 22 05:11:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtLDW-0003K4-0L; Thu, 22 Jun 2006 05:11:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtLDV-0003Jz-Ga for dime@ietf.org; Thu, 22 Jun 2006 05:11:13 -0400 Received: from web38212.mail.mud.yahoo.com ([209.191.124.155]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FtLDU-00075e-1V for dime@ietf.org; Thu, 22 Jun 2006 05:11:13 -0400 Received: (qmail 31199 invoked by uid 60001); 22 Jun 2006 09:11:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=P+4boO2Uc/H5CxxCU3GA0fy47HRUYKL6VfB+RIi5gpcChdb7hLW4dEF54wIq2bd2cjaAd46jPAOB6bQBB9d+khja6TJZOHDm7qGVeZ8nNo9lRqxpNu4B0hpCrt2E372EPzgVdeqH3RhFk5G+WAgaaI8BShOlD1Lpzb9YmLdeiKo= ; Message-ID: <20060622091111.31197.qmail@web38212.mail.mud.yahoo.com> Received: from [193.49.124.107] by web38212.mail.mud.yahoo.com via HTTP; Thu, 22 Jun 2006 11:11:11 CEST Date: Thu, 22 Jun 2006 11:11:11 +0200 (CEST) From: "#:-\) seb" To: dime@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Dime] ICID X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hello, I would like to know where can I find the ICID Identifer . Is it generated automatiquely bye a diameter node or is it hold by sip request ??? Is the ICID identifer is unique for a group or for a single user of a service ???? thank you ___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 22 07:59:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNqj-0008RA-4F; Thu, 22 Jun 2006 07:59:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNqi-0008Qx-3n for dime@ietf.org; Thu, 22 Jun 2006 07:59:52 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtNqg-00076I-1t for dime@ietf.org; Thu, 22 Jun 2006 07:59:52 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k5MBxlH0029830; Thu, 22 Jun 2006 13:59:47 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k5MBxkGH032278; Thu, 22 Jun 2006 13:59:46 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 13:59:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [Dime] Diameter QoS Strawman Proposal (UNCLASSIFIED) Date: Thu, 22 Jun 2006 13:59:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS Strawman Proposal (UNCLASSIFIED) Thread-Index: AcaTmOCUGjLqPVdnRIG1B2MqHMqdEABnmB4AAC5XQ/A= From: "Tschofenig, Hannes" To: "Nguyen, An P CIV NCS NC2" X-OriginalArrivalTime: 22 Jun 2006 11:59:46.0503 (UTC) FILETIME=[5B1FA570:01C695F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi An,=20 =20 the work on the Diameter QoS environment is still very much in progress. Currently, the following procedure is specified and I try to describe it in an abstract way without going into the detail of encoding.=20 =20 The client receives a request with a specific resource priority value (e.g., using RSVP or NSIS). Both RSVP and NSIS define the respective mechanisms.=20 For example, the QSPEC template draft (see http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt) can carry different values inside the QoS Desired when carried with the QoS NSLP.=20 =20 In RSVP the priority parameters might be signaled as defined in RFC 3181 or the more recent work in http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency-rsvp-01.t xt =20 A particular RSVP or NSIS router would not be able todo a lot with the received parameters. In fact, an end host could just state everything and the router would have no means to verify some of these parameters. If someone is able to give them a meaning then the AAA server.=20 Hence, QoS reservation request (along with the priority parameters) is forwarded to the AAA server and processed there. A response is generated that is sent back to the AAA client that performs processing according to the result indicated in the response.=20 What do you think? Does this make sense to you?=20 =20 Ciao Hannes =20 ________________________________ Von: Nguyen, An P CIV NCS NC2 [mailto:an.p.nguyen@dhs.gov]=20 Gesendet: Mittwoch, 21. Juni 2006 16:25 An: Tschofenig, Hannes Cc: dime@ietf.org Betreff: RE: [Dime] Diameter QoS Strawman Proposal (UNCLASSIFIED) =09 =09 Classification: UNCLASSIFIED=20 Caveats: NONE Hannes, =20 Just a question: RFC 4412 defines SIP header fields for communications resource priority. This RFC deals with different namespaces (e.g., ets.x, wps.x, etc.). How does your Diameter QoS draft take these namespaces into account when it comes to authentication and authorization?=20 =20 The reason I am interested in this draft is that the Cx and Dx interfaces of the IMS architecture specifies DIAMETER. =20 Thanks, =20 An -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] Sent: Monday, June 19, 2006 8:07 AM To: dime@ietf.org Subject: [Dime] Diameter QoS Strawman Proposal =09 =09 Hi all,=20 based on the thoughts by Avi about the Diameter QoS work, we (Mayutan Arumaithurai, Alan McNamee and myself) have produced a strawman proposal. I would like to particularly thank Mayutan since he had todo most of the work. Please find the draft at: =09 http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/diamete r-qos-strawman-00.txt =20 This strawman proposal takes a lot of text from the previous draft version (draft-tschofenig-dime-diameter-qos-00.txt) and allows the QoS mechanisms to work with NASREQ, EAP and DCC.=20 This document is meant to be input for discussion. Hence, there is no plan to submit it.=20 Ciao=20 Hannes=20 Classification: UNCLASSIFIED=20 Caveats: NONE _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 22 14:49:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUFC-0000by-EY; Thu, 22 Jun 2006 14:49:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUFB-0000bt-Jt for dime@ietf.org; Thu, 22 Jun 2006 14:49:33 -0400 Received: from [194.71.127.149] (helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUF9-0000Ox-3S for dime@ietf.org; Thu, 22 Jun 2006 14:49:33 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id k5MHr5tT020284; Thu, 22 Jun 2006 19:53:06 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Message-Id: <9595B978-06C5-4115-8BF8-FC084FDD83FF@acm.org> From: Avri Doria Subject: Re: [Dime] Requirement for the addition of Auditing Functionality toDiameter Date: Thu, 22 Jun 2006 14:49:19 -0400 To: "" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Ulf.Bodin@operax.com, dime@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0704051307==" Errors-To: dime-bounces@ietf.org --===============0704051307== Content-Type: multipart/alternative; boundary=Apple-Mail-20-896267294 --Apple-Mail-20-896267294 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On 21 jun 2006, at 23.23, wrote: > Hi all, > > Hopefully Ulf/Avri are on the list, but I wonder if there is any > overlap to this expired draft: > > http://quimby.gnus.org/internet-drafts/draft-calhoun-diameter-res- > mgmt-08.txt yes, we definitely aware of the expired draft (and i am on the list not sure about Ulf). we are proposing that the requirements in the draft be reviewed and then if the group agrees that the requirements warrant it and when they are complete, that the older draft be reviewed, revived and reworked if appropriate. btw, the official id notice: http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg10758.html a. --Apple-Mail-20-896267294 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

On 21 jun = 2006, at 23.23, <john.loughney@nokia.com> = <john.loughney@nokia.com> = wrote:

Hi all,
=A0
Hopefully Ulf/Avri are on the list, but I = wonder if there is any overlap to this expired = draft:
=A0

yes, we=A0definitely aware of = the expired draft (and i am on the list not sure about = Ulf).

we are = proposing that the requirements in the draft be reviewed and then if the = group agrees that the requirements warrant it and when they are = complete, that the older draft be reviewed, revived and reworked if = appropriate.

btw, the official id = notice:


a.

= --Apple-Mail-20-896267294-- --===============0704051307== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0704051307==-- From dime-bounces@ietf.org Fri Jun 23 23:16:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftyd2-0007Ev-SY; Fri, 23 Jun 2006 23:16:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftyd1-0007Dw-Lc for dime@ietf.org; Fri, 23 Jun 2006 23:16:11 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftycz-00031H-1Q for dime@ietf.org; Fri, 23 Jun 2006 23:16:11 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1C004VSHSDV1@szxga02-in.huawei.com> for dime@ietf.org; Sat, 24 Jun 2006 11:31:26 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1C006I8HSDEJ@szxga02-in.huawei.com> for dime@ietf.org; Sat, 24 Jun 2006 11:31:25 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1C00HFYH4DN9@szxml03-in.huawei.com> for dime@ietf.org; Sat, 24 Jun 2006 11:17:02 +0800 (CST) Date: Sat, 24 Jun 2006 11:15:19 +0800 From: Tony Zhang Subject: Re: [Dime] AW: [AAA-WG]: RE: Conclusions on the draft"ResourceManagement Extensions" To: Tolga Asveren , dime@ietf.org, aaa-wg@merit.edu Message-id: <000b01c6973c$6c912000$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org HI All: some querys: 1)if Failover,both nodes share same Host name or not.if use different Host name,how to route the message. if share both Host name,maybe establish connects connect two node is ok. 2)after audit,should restore the session state or not,In the case of failover without replication if want restore the sesssion,how long will be permit. a few minustes or hours. 3)should server or client,save some transparent data on each other. 4)session state synchronization maybe is mandatory,but only check the session active or not maybe is simply,if want restore session state then it will complex. Thanks Tony some comments see inline: ----- Original Message ----- From: "Tolga Asveren" To: ; Sent: Thursday, June 22, 2006 12:13 AM Subject: RE: [Dime] AW: [AAA-WG]: RE: Conclusions on the draft"ResourceManagement Extensions" > A few quick questions/comments about this interesting draft: > > 1) 2.1 > If there is no synchronization on client side, wouldn't using > Origin-State-Id AVP (RFC3588 8.16)solve the problem described in this > section? After failure/restart/takeover client can populate Origin-state-Id > AVP with a value bigger than the one used before the failure and server > should clean up previous sessions. [Tony]Origina-State-Id AVP maybe only use for check the session state synchronization or not. cannot use for state recovery > > 2) 2.1.1 > SCTP multi-homing does not provide host redundancy -unless one has a > distributed SCTP implementation, which probably is not realistic or > something I would recomend to anybody- > > 3) 2.1.1 > Is mentioning about IP address takeover really necessary? IMO, Diameter > entities are addressed by Diameter Identities, hence what is important is > that a backup assuming the identity of a failed active instance -which > doesn't require IP takeover-. > > 4) As a generic comment, I always thought this type of functionality is to > be addressed by specific applications themselves, e.g. DCCA, if there is > such a need. > Let's consider DCCA: > When there is an open session, client will send from time to time > CCR(Update) or CCR(Terminate), which would be replied with "DIAMETER UNKNOWN > SESSION ID", if server failed/restarted etc... and corresponding state did > not survive. Upon receipt of such an error answer, client can clean up its > own state for this session. > Similarly server can send RAR to client, if CCR(Update) is not received in a > timely manner. If state did not survive on client side after a failure, > client would reply with "DIAMETER UNKNOWN SESSION ID" and server can clean > up session state (Alternatively server may choose not to send RAR and may > abort the session) > > AFAICS, for the above example, all cases are covered. > > The question is, whose responsibility is that type of fucntionality, base > protocol or applications. > > Thanks, > Tolga > > > -----Original Message----- > > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: Wednesday, June 21, 2006 11:33 AM > > To: Bernard Aboba; Pat Calhoun (pacalhou) > > Cc: aaa-wg@merit.edu; dime@ietf.org > > Subject: [Dime] AW: [AAA-WG]: RE: Conclusions on the draft > > "ResourceManagement Extensions" > > > > > > Hi all, > > > > may I raise your attention to the following draft submitted for > > this meeting. > > > > Requirement for the addition of Auditing Functionality to Diameter > > http://psg.com/~avri/dime/draft-bodin-dime-auditing-reqs-00.txt > > > > Unfortunately, it did not yet show up. > > > > Ciao > > Hannes > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jun 25 21:35:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fug0U-0005lm-Nm; Sun, 25 Jun 2006 21:35:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fug0T-0005lh-HI for dime@ietf.org; Sun, 25 Jun 2006 21:35:17 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fug0S-00016S-7k for dime@ietf.org; Sun, 25 Jun 2006 21:35:17 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 25 Jun 2006 18:35:16 -0700 X-IronPort-AV: i="4.06,173,1149490800"; d="scan'208"; a="1832360476:sNHT36108862" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5Q1ZFuX001141; Sun, 25 Jun 2006 18:35:15 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5Q1ZFCU011372; Sun, 25 Jun 2006 18:35:15 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Jun 2006 18:35:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RE: Diameter base protocol messages used by DCCA Date: Sun, 25 Jun 2006 18:35:13 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502376D69@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter base protocol messages used by DCCA Thread-Index: AcaQvHRLCzEvKzDHRWSkW/O26V/ALwAWLJYwABK/jSAA6/upUADsDA4g From: "Glen Zorn \(gwz\)" To: "STURA, Marco, VF-IT" , "Tolga Asveren" , "Anders Kristensen" X-OriginalArrivalTime: 26 Jun 2006 01:35:15.0266 (UTC) FILETIME=[C62DA220:01C698C0] DKIM-Signature: a=rsa-sha1; q=dns; l=747; t=1151285715; x=1152149715; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Dime]=20RE=3A=20Diameter=20base=20protocol=20messages=20used=20 by=20DCCA; X=v=3Dcisco.com=3B=20h=3DHwsi7c48XQRfyiH8lUrRpE1X9Jg=3D; b=MzJZZkn2pwt0gmIkOPH5DCEuB/Q08EakB4Y2SIw28H32OA1NWhAbjjw1+Dbe7OfS99r2m7S8 MkWjgiMDScJew+E/j/PYKuupMS1WkglyUhz/uCgpdGX7zc4LQwdbXUXQ; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: aaa-wg@merit.edu, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org STURA, Marco, VF-IT supposedly = scribbled: ... >> So, in other words, in order to implement a e.g., [NASREQ], [DIAMMIP] > peer >intended for general distribution, one must include CCA client >> functionality. >=20 > Not necessarily. One could provide communication means to enable a > CCA functionality module to add relevant AVPs to the initial AA > request and process relevant AVPs from AA answer. =20 Maybe it's just me but that distinction seems to be, at best, = razor-thin. What you are saying is that every peer must make = concessions to CCA. =20 ... ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jun 25 22:51:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuhCL-0007GC-1t; Sun, 25 Jun 2006 22:51:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuhCK-0007Fv-3X for dime@ietf.org; Sun, 25 Jun 2006 22:51:36 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuhCG-0006Vr-Fg for dime@ietf.org; Sun, 25 Jun 2006 22:51:36 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5Q2pJAZ009813; Mon, 26 Jun 2006 05:51:26 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 05:51:24 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 05:51:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Requirement for the addition of Auditing Functionality toDiameter Date: Mon, 26 Jun 2006 05:51:23 +0300 Message-ID: In-Reply-To: <9595B978-06C5-4115-8BF8-FC084FDD83FF@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Requirement for the addition of Auditing Functionality toDiameter Thread-Index: AcaWLLls36cy8mR/SCKvWv4W2xgffwCnpVGA From: To: X-OriginalArrivalTime: 26 Jun 2006 02:51:24.0007 (UTC) FILETIME=[695C2F70:01C698CB] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: Ulf.Bodin@operax.com, dime@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0905582879==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0905582879== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C698CB.6924D519" This is a multi-part message in MIME format. ------_=_NextPart_001_01C698CB.6924D519 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the quick reply. This sounds like a reasonable start - it would be good to get people to read the draft and comment on the general problem. =20 thanks, John ________________________________ From: ext Avri Doria [mailto:avri@acm.org]=20 Sent: 22 June, 2006 21:49 To: Loughney John (Nokia-NRC/Helsinki) Cc: hannes.tschofenig@siemens.com; dime@ietf.org; Ulf.Bodin@operax.com Subject: Re: [Dime] Requirement for the addition of Auditing Functionality toDiameter =09 =09 Hi,=20 On 21 jun 2006, at 23.23, wrote: Hi all, =20 Hopefully Ulf/Avri are on the list, but I wonder if there is any overlap to this expired draft: =20 =09 http://quimby.gnus.org/internet-drafts/draft-calhoun-diameter-res-mgm t-08.txt yes, we definitely aware of the expired draft (and i am on the list not sure about Ulf). we are proposing that the requirements in the draft be reviewed and then if the group agrees that the requirements warrant it and when they are complete, that the older draft be reviewed, revived and reworked if appropriate. btw, the official id notice: =09 http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg10758.html a.=20 =09 ------_=_NextPart_001_01C698CB.6924D519 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks for the quick reply.  This sounds = like a=20 reasonable start - it would be good to get people to read the draft and = comment=20 on the general problem.
 
thanks,
John

From: ext Avri Doria = [mailto:avri@acm.org]=20
Sent: 22 June, 2006 21:49
To: Loughney John=20 (Nokia-NRC/Helsinki)
Cc: hannes.tschofenig@siemens.com;=20 dime@ietf.org; Ulf.Bodin@operax.com
Subject: Re: [Dime] = Requirement=20 for the addition of Auditing Functionality = toDiameter

Hi,

On 21 jun 2006, at 23.23, <john.loughney@nokia.com> = <john.loughney@nokia.com>=20 wrote:

Hi all,
 
Hopefully Ulf/Avri are on the list, but I = wonder if=20 there is any overlap to this expired draft:
 

http://quimby.gnus.org/internet-drafts/draft-calhoun-diamet= er-res-mgmt-08.txt


yes, we definitely = aware of=20 the expired draft (and i am on the list not sure about Ulf).

we are proposing that the requirements in the draft be reviewed = and then=20 if the group agrees that the requirements warrant it and when they are = complete, that the older draft be reviewed, revived and reworked if=20 appropriate.

btw, the official id notice:
http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg10= 758.html


a.

------_=_NextPart_001_01C698CB.6924D519-- --===============0905582879== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0905582879==-- From dime-bounces@ietf.org Sun Jun 25 23:33:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuhr6-0000jG-Ms; Sun, 25 Jun 2006 23:33:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuhr5-0000jB-Bj for dime@ietf.org; Sun, 25 Jun 2006 23:33:43 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuhqZ-00010L-92 for dime@ietf.org; Sun, 25 Jun 2006 23:33:43 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1G00DQA7LE3L@szxga03-in.huawei.com> for dime@ietf.org; Mon, 26 Jun 2006 11:41:38 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1G004FQ7LE3A@szxga03-in.huawei.com> for dime@ietf.org; Mon, 26 Jun 2006 11:41:38 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1G00HHX78R08@szxml03-in.huawei.com> for dime@ietf.org; Mon, 26 Jun 2006 11:34:04 +0800 (CST) Date: Mon, 26 Jun 2006 11:32:17 +0800 From: Tony Zhang To: dime@ietf.org Message-id: <003f01c698d1$1f9da610$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Subject: [Dime] one doubt about sip application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2047150965==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2047150965== Content-type: multipart/alternative; boundary="Boundary_(ID_tA95biTpfTdwf+nBYZYnWg)" This is a multi-part message in MIME format. --Boundary_(ID_tA95biTpfTdwf+nBYZYnWg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi All: In Sip Application SIP-Accounting_Information is like below: SIP-Accounting-Information ::= < AVP Header: xx01 > * [ SIP-Accounting-Server-URI ] * [ SIP-Credit-Control-Server-URI ] * [ AVP] Actual in Rfc3588 accounting request define is like below: ::= < Diameter Header: 271, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Accounting-Record-Type } { Accounting-Record-Number } [ Acct-Application-Id ] [ Vendor-Specific-Application-Id ] [ User-Name ] [ Accounting-Sub-Session-Id ] [ Acct-Session-Id ] [ Acct-Multi-Session-Id ] [ Acct-Interim-Interval ] [ Accounting-Realtime-Required ] [ Origin-State-Id ] [ Event-Timestamp ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ] this is means,Account Request recommend use Realm not Host. so if define SIP-Accounting_Information like below is better or not? SIP-Accounting-Information ::= < AVP Header: xx01 > [ SIP-Accounting-Server-Realm ] [ SIP-Credit-Control-Server-Ream ] * [ AVP] we send account request to account server,then we can Fill SIP-Accounting-Server-Realm Into Destination-Realm of Account Request. if not like this,we should fill SIP-Accounting-Server-URI into Destination-Host,the other question is how to contruct Destination-Realm(this avp is mandatory)? Thanks! Tony Zhang --Boundary_(ID_tA95biTpfTdwf+nBYZYnWg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi All:
   In Sip Application SIP-Accounting_Information is like below:
         SIP-Accounting-Information ::= < AVP Header: xx01 >
                                   * [ SIP-Accounting-Server-URI ]
                                   * [ SIP-Credit-Control-Server-URI ]
                                   * [ AVP]
 
   Actual in Rfc3588 accounting request define is like below:
      <ACR> ::= < Diameter Header: 271, REQ, PXY >
                < Session-Id >
                { Origin-Host }
                { Origin-Realm }
                { Destination-Realm }
                { Accounting-Record-Type }
                { Accounting-Record-Number }
                [ Acct-Application-Id ]
                [ Vendor-Specific-Application-Id ]
                [ User-Name ]
                [ Accounting-Sub-Session-Id ]
                [ Acct-Session-Id ]
                [ Acct-Multi-Session-Id ]
                [ Acct-Interim-Interval ]
                [ Accounting-Realtime-Required ]
                [ Origin-State-Id ]
                [ Event-Timestamp ]
              * [ Proxy-Info ]
              * [ Route-Record ]
              * [ AVP ]
 
this is means,Account Request recommend use Realm not Host.
 
so if define SIP-Accounting_Information  like below is better or not?
         SIP-Accounting-Information ::= < AVP Header: xx01 >
                                    [ SIP-Accounting-Server-Realm ]
                                    [ SIP-Credit-Control-Server-Ream ]
                                   * [ AVP]
we send account request to account server,then we can Fill SIP-Accounting-Server-Realm  Into Destination-Realm of Account Request.
 
if not like this,we should fill SIP-Accounting-Server-URI into Destination-Host,the other question is how to contruct Destination-Realm(this avp is mandatory)?
 
Thanks!
Tony Zhang
--Boundary_(ID_tA95biTpfTdwf+nBYZYnWg)-- --===============2047150965== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============2047150965==-- From dime-bounces@ietf.org Mon Jun 26 03:16:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FulKJ-0005rf-2d; Mon, 26 Jun 2006 03:16:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FulKH-0005pW-L3 for dime@ietf.org; Mon, 26 Jun 2006 03:16:05 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FulKG-0003wg-6v for dime@ietf.org; Mon, 26 Jun 2006 03:16:05 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5Q7Fwxf020000 for ; Mon, 26 Jun 2006 10:16:03 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 10:16:01 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 10:16:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Jun 2006 10:16:01 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DiME Meeting in Montreal, agenda requests Thread-Index: AcaY8GC0pYd5rX/jT6qF078m495hYg== From: To: X-OriginalArrivalTime: 26 Jun 2006 07:16:01.0366 (UTC) FILETIME=[6100E760:01C698F0] X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Dime] DiME Meeting in Montreal, agenda requests X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, If you are interested in having a slot at the DiME meeting in the IETF, please send the following information: Draft name Presenter's name Time slot needed. thanks, John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 26 04:33:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumXA-0001y2-UC; Mon, 26 Jun 2006 04:33:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumX9-0001xo-G2 for dime@ietf.org; Mon, 26 Jun 2006 04:33:27 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FukfP-0001eS-W7 for dime@ietf.org; Mon, 26 Jun 2006 02:33:52 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FukWU-0008Fh-M7 for dime@ietf.org; Mon, 26 Jun 2006 02:24:40 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5Q6OObt002952; Mon, 26 Jun 2006 09:24:31 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 09:24:31 +0300 Received: from [127.0.0.1] ([172.21.39.124]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Jun 2006 09:24:31 +0300 Message-ID: <449F7D9E.9040706@nokia.com> Date: Mon, 26 Jun 2006 09:24:30 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Tony Zhang Subject: Re: [Dime] one doubt about sip application References: <003f01c698d1$1f9da610$3791460a@china.huawei.com> In-Reply-To: <003f01c698d1$1f9da610$3791460a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2006 06:24:31.0038 (UTC) FILETIME=[2F0645E0:01C698E9] X-Spam-Score: -2.3 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tony: The intention of the SIP-Accounting-Information is to outsource Diameter accounting to a different server, not to a different realm. So, from that point of view, the idea is to keep the realm constant, but not the server. I am not sure of any use case where you need to switch realms within the same application (SIP services), but different hosts (authorization/authentication vs. accounting). Additionally, if the Diameter client gets only the realm where to provide accounting, as you propose, then you need to have a mechanism to guarantee that you can discover the host out of the realm. So, if this mechanism is not in place, or the Realm Routing Table is not properly provisioned, you run into trouble. Thus, I wouldn't recommend to provide realms for the accounting part of the Diameter SIP application. BR, Miguel Tony Zhang wrote: > Hi All: > In Sip Application SIP-Accounting_Information is like below: > SIP-Accounting-Information ::= < AVP Header: xx01 > > * [ SIP-Accounting-Server-URI ] > * [ SIP-Credit-Control-Server-URI ] > * [ AVP] > > Actual in Rfc3588 accounting request define is like below: > ::= < Diameter Header: 271, REQ, PXY > > < Session-Id > > { Origin-Host } > { Origin-Realm } > { Destination-Realm } > { Accounting-Record-Type } > { Accounting-Record-Number } > [ Acct-Application-Id ] > [ Vendor-Specific-Application-Id ] > [ User-Name ] > [ Accounting-Sub-Session-Id ] > [ Acct-Session-Id ] > [ Acct-Multi-Session-Id ] > [ Acct-Interim-Interval ] > [ Accounting-Realtime-Required ] > [ Origin-State-Id ] > [ Event-Timestamp ] > * [ Proxy-Info ] > * [ Route-Record ] > * [ AVP ] > > this is means,Account Request recommend use Realm not Host. > > so if define SIP-Accounting_Information like below is better or not? > SIP-Accounting-Information ::= < AVP Header: xx01 > > [ SIP-Accounting-Server-Realm ] > [ SIP-Credit-Control-Server-Ream ] > * [ AVP] > we send account request to account server,then we can Fill > SIP-Accounting-Server-Realm Into Destination-Realm of Account Request. > > if not like this,we should fill SIP-Accounting-Server-URI into > Destination-Host,the other question is how to contruct > Destination-Realm(this avp is mandatory)? > > Thanks! > Tony Zhang > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 26 04:34:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumY9-0002mq-6t; Mon, 26 Jun 2006 04:34:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumY8-0002mi-Ct for dime@ietf.org; Mon, 26 Jun 2006 04:34:28 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FumY6-00018Q-S7 for dime@ietf.org; Mon, 26 Jun 2006 04:34:28 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1G005R8LRP6N@szxga02-in.huawei.com> for dime@ietf.org; Mon, 26 Jun 2006 16:47:50 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1G002U9LRP7D@szxga02-in.huawei.com> for dime@ietf.org; Mon, 26 Jun 2006 16:47:49 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1G00LMTL3PWZ@szxml03-in.huawei.com> for dime@ietf.org; Mon, 26 Jun 2006 16:33:26 +0800 (CST) Date: Mon, 26 Jun 2006 16:31:40 +0800 From: Tony Zhang Subject: Re: [Dime] one doubt about sip application To: Miguel Garcia Message-id: <000f01c698fa$f2786420$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <003f01c698d1$1f9da610$3791460a@china.huawei.com> <449F7D9E.9040706@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Miguel: Thanks your reply. In my understanding,the Realm have another meaning,like one group of nodes,then it can realize device level reliablity.maybe it will like this all accounting server maybe will use one realm.for example:account.base.com,for call server maybe will use:call.base.com.so i am not assure the sip server will use same realm name with account server.because realm name based on longest-match-from-the-right on the realm rather than requiring an exact match,so maybe both just belong to big realm,but big realm still have some samll realm. because almost accounting is very important,so almost have two accounting server,so we should return all server name to sip server,if just return realm,the realm will mangement all accounting server .no need each user data should return two accounting server name,also if server name changed,maybe should update all user data.but use realm,maybe maybe no need update. when return realm how to process it,i think return accounting server,also should have some process.base protocol also give some comments how to process the message. Regars! Tony ----- Original Message ----- From: "Miguel Garcia" To: "Tony Zhang" Cc: Sent: Monday, June 26, 2006 2:24 PM Subject: Re: [Dime] one doubt about sip application > Tony: > > The intention of the SIP-Accounting-Information is to outsource Diameter > accounting to a different server, not to a different realm. So, from > that point of view, the idea is to keep the realm constant, but not the > server. I am not sure of any use case where you need to switch realms > within the same application (SIP services), but different hosts > (authorization/authentication vs. accounting). > > Additionally, if the Diameter client gets only the realm where to > provide accounting, as you propose, then you need to have a mechanism to > guarantee that you can discover the host out of the realm. So, if this > mechanism is not in place, or the Realm Routing Table is not properly > provisioned, you run into trouble. > > Thus, I wouldn't recommend to provide realms for the accounting part of > the Diameter SIP application. > > BR, > > Miguel > > > Tony Zhang wrote: > > Hi All: > > In Sip Application SIP-Accounting_Information is like below: > > SIP-Accounting-Information ::= < AVP Header: xx01 > > > * [ SIP-Accounting-Server-URI ] > > * [ SIP-Credit-Control-Server-URI ] > > * [ AVP] > > > > Actual in Rfc3588 accounting request define is like below: > > ::= < Diameter Header: 271, REQ, PXY > > > < Session-Id > > > { Origin-Host } > > { Origin-Realm } > > { Destination-Realm } > > { Accounting-Record-Type } > > { Accounting-Record-Number } > > [ Acct-Application-Id ] > > [ Vendor-Specific-Application-Id ] > > [ User-Name ] > > [ Accounting-Sub-Session-Id ] > > [ Acct-Session-Id ] > > [ Acct-Multi-Session-Id ] > > [ Acct-Interim-Interval ] > > [ Accounting-Realtime-Required ] > > [ Origin-State-Id ] > > [ Event-Timestamp ] > > * [ Proxy-Info ] > > * [ Route-Record ] > > * [ AVP ] > > > > this is means,Account Request recommend use Realm not Host. > > > > so if define SIP-Accounting_Information like below is better or not? > > SIP-Accounting-Information ::= < AVP Header: xx01 > > > [ SIP-Accounting-Server-Realm ] > > [ SIP-Credit-Control-Server-Ream ] > > * [ AVP] > > we send account request to account server,then we can Fill > > SIP-Accounting-Server-Realm Into Destination-Realm of Account Request. > > > > if not like this,we should fill SIP-Accounting-Server-URI into > > Destination-Host,the other question is how to contruct > > Destination-Realm(this avp is mandatory)? > > > > Thanks! > > Tony Zhang > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 26 05:49:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Funiq-00040G-EU; Mon, 26 Jun 2006 05:49:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Funip-0003u8-5A for dime@ietf.org; Mon, 26 Jun 2006 05:49:35 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Funio-0006y7-Ip for dime@ietf.org; Mon, 26 Jun 2006 05:49:35 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5Q9nNIi001122; Mon, 26 Jun 2006 12:49:28 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 12:49:23 +0300 Received: from [127.0.0.1] ([172.30.72.98]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 26 Jun 2006 12:49:23 +0300 Message-ID: <449FADA5.8030000@nokia.com> Date: Mon, 26 Jun 2006 12:49:25 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Tony Zhang Subject: Re: [Dime] one doubt about sip application References: <003f01c698d1$1f9da610$3791460a@china.huawei.com> <449F7D9E.9040706@nokia.com> <000f01c698fa$f2786420$3791460a@china.huawei.com> In-Reply-To: <000f01c698fa$f2786420$3791460a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2006 09:49:23.0682 (UTC) FILETIME=[CE02E420:01C69905] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tony: I am sorry, but I still don't get the reasons why someone would like to do the realm split... you seem to mention something like "device level reliability", which I don't really understand. What puzzles me is that the Diameter SIP application has been hanging around four about 4 years, and we had a requirement from day one to be able to supply the accounting server, but we never had a requirement to supply a separate accounting realm. It can be done, it is a simple extension, but we should understand the requirements and use cases before starting extending the protocol just because it is possible to do it. Regards, Miguel Tony Zhang wrote: > Miguel: > Thanks your reply. > In my understanding,the Realm have another meaning,like one group of nodes,then it can realize device level reliablity.maybe it will like this all accounting server maybe will use one realm.for example:account.base.com,for call server maybe will use:call.base.com.so i am not assure the sip server will use same realm name with account server.because realm name based on longest-match-from-the-right on the realm rather than requiring an exact match,so maybe both just belong to big realm,but big realm still have some samll realm. > because almost accounting is very important,so almost have two accounting server,so we should return all server name to sip server,if just return realm,the realm will mangement all accounting server .no need each user data should return two accounting server name,also if server name changed,maybe should update all user data.but use realm,maybe maybe no need update. > when return realm how to process it,i think return accounting server,also should have some process.base protocol also give some comments how to process the message. > Regars! > Tony > > ----- Original Message ----- > From: "Miguel Garcia" > To: "Tony Zhang" > Cc: > Sent: Monday, June 26, 2006 2:24 PM > Subject: Re: [Dime] one doubt about sip application > > >> Tony: >> >> The intention of the SIP-Accounting-Information is to outsource Diameter >> accounting to a different server, not to a different realm. So, from >> that point of view, the idea is to keep the realm constant, but not the >> server. I am not sure of any use case where you need to switch realms >> within the same application (SIP services), but different hosts >> (authorization/authentication vs. accounting). >> >> Additionally, if the Diameter client gets only the realm where to >> provide accounting, as you propose, then you need to have a mechanism to >> guarantee that you can discover the host out of the realm. So, if this >> mechanism is not in place, or the Realm Routing Table is not properly >> provisioned, you run into trouble. >> >> Thus, I wouldn't recommend to provide realms for the accounting part of >> the Diameter SIP application. >> >> BR, >> >> Miguel >> >> >> Tony Zhang wrote: >>> Hi All: >>> In Sip Application SIP-Accounting_Information is like below: >>> SIP-Accounting-Information ::= < AVP Header: xx01 > >>> * [ SIP-Accounting-Server-URI ] >>> * [ SIP-Credit-Control-Server-URI ] >>> * [ AVP] >>> >>> Actual in Rfc3588 accounting request define is like below: >>> ::= < Diameter Header: 271, REQ, PXY > >>> < Session-Id > >>> { Origin-Host } >>> { Origin-Realm } >>> { Destination-Realm } >>> { Accounting-Record-Type } >>> { Accounting-Record-Number } >>> [ Acct-Application-Id ] >>> [ Vendor-Specific-Application-Id ] >>> [ User-Name ] >>> [ Accounting-Sub-Session-Id ] >>> [ Acct-Session-Id ] >>> [ Acct-Multi-Session-Id ] >>> [ Acct-Interim-Interval ] >>> [ Accounting-Realtime-Required ] >>> [ Origin-State-Id ] >>> [ Event-Timestamp ] >>> * [ Proxy-Info ] >>> * [ Route-Record ] >>> * [ AVP ] >>> >>> this is means,Account Request recommend use Realm not Host. >>> >>> so if define SIP-Accounting_Information like below is better or not? >>> SIP-Accounting-Information ::= < AVP Header: xx01 > >>> [ SIP-Accounting-Server-Realm ] >>> [ SIP-Credit-Control-Server-Ream ] >>> * [ AVP] >>> we send account request to account server,then we can Fill >>> SIP-Accounting-Server-Realm Into Destination-Realm of Account Request. >>> >>> if not like this,we should fill SIP-Accounting-Server-URI into >>> Destination-Host,the other question is how to contruct >>> Destination-Realm(this avp is mandatory)? >>> >>> Thanks! >>> Tony Zhang >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >> -- >> Miguel A. Garcia tel:+358-50-4804586 >> sip:miguel.an.garcia@openlaboratory.net >> Nokia Research Center Helsinki, Finland >> >> -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 26 14:41:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuw1Z-0005Yu-Bp; Mon, 26 Jun 2006 14:41:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuw1X-0005Yp-HA for dime@ietf.org; Mon, 26 Jun 2006 14:41:27 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuw1U-0000jZ-W1 for dime@ietf.org; Mon, 26 Jun 2006 14:41:27 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 26 Jun 2006 11:41:24 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,177,1149490800"; d="scan'208"; a="30504523:sNHT23422984" Received: from [161.44.55.106] (dhcp-161-44-55-106.cisco.com [161.44.55.106]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5QIfOYL009928; Mon, 26 Jun 2006 14:41:24 -0400 (EDT) Message-ID: <44A02A54.1050809@cisco.com> Date: Mon, 26 Jun 2006 14:41:24 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [Dime] Requirement for the addition of Auditing Functionality toDiameter References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This draft does seem like it could be very useful. Some comments... The starting point of the draft is that of a rebooted device not knowing its state. I wonder if the scope could be expanded to cover failover scenarios, e.g. allow a backup node, typically a node belonging to the same realm as the failed element, to audit sessions belonging to the failed node and take them over (which would amount to the peer associating the session with the backup node). This probably raises all sorts of issues, some security issues for a start, but could be very useful. I imagine that for some implementations the validity of a returned Query-Index would be time limited -- if the initial query resulted in some state being created on the server it will be treated as soft state. Does the draft need to talk about that, e.g. have the server indicate in the answer how long the Query-Index will be valid or mandate a minimum time? Should the querying party have a say in how much state is returned in one answer? The peer returns generic (common across apps) and appliation specific per-session state. I'm thinking the generic state listed should include Class AVPs (cookies) that the peer has stored on behalf of the client and also time until the session expires. There are probably other things. Thanks, Anders john.loughney@nokia.com wrote: > Thanks for the quick reply. This sounds like a reasonable start - it > would be good to get people to read the draft and comment on the general > problem. > > thanks, > John > > ------------------------------------------------------------------------ > *From:* ext Avri Doria [mailto:avri@acm.org] > *Sent:* 22 June, 2006 21:49 > *To:* Loughney John (Nokia-NRC/Helsinki) > *Cc:* hannes.tschofenig@siemens.com; dime@ietf.org; Ulf.Bodin@operax.com > *Subject:* Re: [Dime] Requirement for the addition of Auditing > Functionality toDiameter > > Hi, > > On 21 jun 2006, at 23.23, > > wrote: > >> Hi all, >> >> Hopefully Ulf/Avri are on the list, but I wonder if there is any >> overlap to this expired draft: >> >> >> __ >> _http://quimby.gnus.org/internet-drafts/draft-calhoun-diameter-res-mgm >> _ >> >> t-08.txt >> > > yes, we definitely aware of the expired draft (and i am on the list > not sure about Ulf). > > we are proposing that the requirements in the draft be reviewed and > then if the group agrees that the requirements warrant it and when > they are complete, that the older draft be reviewed, revived and > reworked if appropriate. > > btw, the official id notice: > http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg10758.html > > > a. > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 26 15:15:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwYi-0006gF-1B; Mon, 26 Jun 2006 15:15:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwYg-0006fE-Rp for dime@ietf.org; Mon, 26 Jun 2006 15:15:42 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuwYe-0004Jf-Bz for dime@ietf.org; Mon, 26 Jun 2006 15:15:42 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 698E5094E7 for ; Mon, 26 Jun 2006 15:15:39 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5QJFca0008628 for ; Mon, 26 Jun 2006 15:15:39 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] AW: [AAA-WG]: RE: Conclusions on the draft "ResourceManagement Extensions" Date: Mon, 26 Jun 2006 14:52:35 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org One more question about this draft: AFAICS, there are actually two different issues (they are related but not the same): a)Preventing session leaking Making sure that after a node fails, other nodes do not continue keeping state for the lost sessions. b)Retrieving state information After a node reboots, it retrieves its state data from another node. When I first read draft-bodin-dime-auditing-reqs-00, I had the impression that the main concern is a), based on the example scenarios described. OTOH, draft-calhoun-diameter-res-mgmt-08 seem to deal with b). So, what is the main issue a) or b)? If both, what are their priorities. Thanks, Tolga > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Wednesday, June 21, 2006 11:33 AM > To: Bernard Aboba; Pat Calhoun (pacalhou) > Cc: aaa-wg@merit.edu; dime@ietf.org > Subject: [Dime] AW: [AAA-WG]: RE: Conclusions on the draft > "ResourceManagement Extensions" > > > Hi all, > > may I raise your attention to the following draft submitted for > this meeting. > > Requirement for the addition of Auditing Functionality to Diameter > http://psg.com/~avri/dime/draft-bodin-dime-auditing-reqs-00.txt > > Unfortunately, it did not yet show up. > > Ciao > Hannes > > > -----Ursprüngliche Nachricht----- > > Von: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] > > Im Auftrag von Bernard Aboba > > Gesendet: Mittwoch, 21. Juni 2006 16:24 > > An: Pat Calhoun (pacalhou) > > Cc: MORAND Lionel RD-CORE-ISS; aaa-wg@merit.edu > > Betreff: [AAA-WG]: RE: Conclusions on the draft "Resource > > Management Extensions" > > > > As Pat said, the major priority of the AAA WG was completing > > work on the > > Diameter Base protocol and applications. I actually don't > > recall whether > > the WG made a judgement on the Resource Management draft; it > > just wasn't > > one of the top priorities. > > > > I will say that the Diameter architecture provides a much more sound > > base for resource management than RADIUS does. Most of the resource > > management implementations I have seen on RADIUS need to > > incorporate other > > information sources for validation, in order to deal with > > potential losses > > of RADIUS Accounting packets. Since Diameter runs over reliable > > transport, it should not have to do this. > > > > On Wed, 21 Jun 2006, Pat Calhoun (pacalhou) wrote: > > > > > I'll let Bernard speak for the WG, but at the time the WG > > had many other > > > priorities, and resource management was not one of them. However, I > > > haven't had the opportunity to participate in the AAA WG > > for some time, > > > so I'm not sure if this could be an opportune time to > > re-introduce it. > > > > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit > > > Cisco Systems > > > > > > > > > > > > > > > ________________________________ > > > > > > From: MORAND Lionel RD-CORE-ISS > > > [mailto:lionel.morand@orange-ft.com] > > > Sent: Wednesday, June 21, 2006 7:07 AM > > > To: Bernard Aboba; Pat Calhoun (pacalhou) > > > Subject: Conclusions on the draft "Resource Management > > > Extensions" > > > > > > > > > > > > Hi, > > > I would like to know what were the conclusions on the following > > > draft initiated by Pat: draft-calhoun-diameter-res-mgmt-08.txt. > > > > > (http://quimby.gnus.org/internet-drafts/draft-calhoun-diameter > > -res-mgmt- > > > 08.txt > > > > > > -res-mgmt- > > > 08.txt> ) > > > > > > Some folks from TISPAN are initiating a document based on this > > > draft to perform resource management after failover, proposing to > > > enhance the Diameter base protocol with dedicated commands. > > I'm pretty > > > sure that the previous comments/concerns about such enhancements are > > > still valid. > > > > > > BR, > > > Lionel > > > > > > > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 26 16:12:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxRz-0000Fs-0E; Mon, 26 Jun 2006 16:12:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxRy-0000Fi-AA for dime@ietf.org; Mon, 26 Jun 2006 16:12:50 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuxRx-0002Md-1A for dime@ietf.org; Mon, 26 Jun 2006 16:12:50 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 1EE25B0DFB for ; Mon, 26 Jun 2006 16:12:48 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5QKClkD013791 for ; Mon, 26 Jun 2006 16:12:47 -0400 (EDT) From: "Tolga Asveren" To: Date: Mon, 26 Jun 2006 15:49:43 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Dime] Comments for draft-tsou-dime-base-routing-ext X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I have one comment/question regarding 1.1 in draft-tsou-dime-base-routing. The configuration described is as follows, AFAIU: WLAN 3GPP 3GPP AN --Wa-- AAA Proxy--Wd--Server I am not sure whether it is the correct view to consider 3GPP AAA Proxy as a proxy from Diameter base protocol point of view. It seems to me, it is more like a Diameter endpoint, which is acting as a proxy from 3GPP AAA service point of view, i.e. it would have two related sessions: one between WLAN AN and 3GPP AAA Proxy and the other one betweeen 3GPP Server and 3GPP AAA Proxy; it would provide interworking/bridging between those two session and probably would implement some local policy as well. AFAICS, this interpretation would solve the problem, the draft is trying to address in 1.1. Does this make sense or am I missing something completely? Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 26 21:45:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv2eK-0002MO-6e; Mon, 26 Jun 2006 21:45:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv2eI-0002MC-UW for dime@ietf.org; Mon, 26 Jun 2006 21:45:54 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv2eB-0001gT-Ca for dime@ietf.org; Mon, 26 Jun 2006 21:45:54 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1H00IFYXM43R@szxga02-in.huawei.com> for dime@ietf.org; Tue, 27 Jun 2006 10:01:16 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1H000G1XM3VL@szxga02-in.huawei.com> for dime@ietf.org; Tue, 27 Jun 2006 10:01:16 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1H005X7XD7R2@szxml04-in.huawei.com> for dime@ietf.org; Tue, 27 Jun 2006 09:55:56 +0800 (CST) Date: Tue, 27 Jun 2006 09:45:03 +0800 From: Tony Zhang Subject: Re: [Dime] one doubt about sip application To: Miguel Garcia Message-id: <003f01c6998b$4f8cf6e0$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <003f01c698d1$1f9da610$3791460a@china.huawei.com> <449F7D9E.9040706@nokia.com> <000f01c698fa$f2786420$3791460a@china.huawei.com> <449FADA5.8030000@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Miguel: actual i am not very good understand realm and host.so i regard a group server as realm,then when i read RFC3588 or 3GPP Accounting Application(Ro interface),both account request donot list Destination Host AVP.so i have doubt how to use the account server URL AVP.so i think it should fill to destinaiton Realm(Destination Host Avp missing in both specification or not?). so i just want all application can keep consistent.when have chance please correct it in RFC3588 or Ro interface. device level reliability,in my idea.any server an provide service in the realm,so it have more high reliability. Regards, Tony ----- Original Message ----- From: "Miguel Garcia" To: "Tony Zhang" Cc: Sent: Monday, June 26, 2006 5:49 PM Subject: Re: [Dime] one doubt about sip application > Hi Tony: > > I am sorry, but I still don't get the reasons why someone would like to > do the realm split... you seem to mention something like "device level > reliability", which I don't really understand. > > What puzzles me is that the Diameter SIP application has been hanging > around four about 4 years, and we had a requirement from day one to be > able to supply the accounting server, but we never had a requirement to > supply a separate accounting realm. It can be done, it is a simple > extension, but we should understand the requirements and use cases > before starting extending the protocol just because it is possible to do it. > > Regards, > > Miguel > > Tony Zhang wrote: > > Miguel: > > Thanks your reply. > > In my understanding,the Realm have another meaning,like one group of nodes,then it can realize device level reliablity.maybe it will like this all accounting server maybe will use one realm.for example:account.base.com,for call server maybe will use:call.base.com.so i am not assure the sip server will use same realm name with account server.because realm name based on longest-match-from-the-right on the realm rather than requiring an exact match,so maybe both just belong to big realm,but big realm still have some samll realm. > > because almost accounting is very important,so almost have two accounting server,so we should return all server name to sip server,if just return realm,the realm will mangement all accounting server .no need each user data should return two accounting server name,also if server name changed,maybe should update all user data.but use realm,maybe maybe no need update. > > when return realm how to process it,i think return accounting server,also should have some process.base protocol also give some comments how to process the message. > > Regars! > > Tony > > > > ----- Original Message ----- > > From: "Miguel Garcia" > > To: "Tony Zhang" > > Cc: > > Sent: Monday, June 26, 2006 2:24 PM > > Subject: Re: [Dime] one doubt about sip application > > > > > >> Tony: > >> > >> The intention of the SIP-Accounting-Information is to outsource Diameter > >> accounting to a different server, not to a different realm. So, from > >> that point of view, the idea is to keep the realm constant, but not the > >> server. I am not sure of any use case where you need to switch realms > >> within the same application (SIP services), but different hosts > >> (authorization/authentication vs. accounting). > >> > >> Additionally, if the Diameter client gets only the realm where to > >> provide accounting, as you propose, then you need to have a mechanism to > >> guarantee that you can discover the host out of the realm. So, if this > >> mechanism is not in place, or the Realm Routing Table is not properly > >> provisioned, you run into trouble. > >> > >> Thus, I wouldn't recommend to provide realms for the accounting part of > >> the Diameter SIP application. > >> > >> BR, > >> > >> Miguel > >> > >> > >> Tony Zhang wrote: > >>> Hi All: > >>> In Sip Application SIP-Accounting_Information is like below: > >>> SIP-Accounting-Information ::= < AVP Header: xx01 > > >>> * [ SIP-Accounting-Server-URI ] > >>> * [ SIP-Credit-Control-Server-URI ] > >>> * [ AVP] > >>> > >>> Actual in Rfc3588 accounting request define is like below: > >>> ::= < Diameter Header: 271, REQ, PXY > > >>> < Session-Id > > >>> { Origin-Host } > >>> { Origin-Realm } > >>> { Destination-Realm } > >>> { Accounting-Record-Type } > >>> { Accounting-Record-Number } > >>> [ Acct-Application-Id ] > >>> [ Vendor-Specific-Application-Id ] > >>> [ User-Name ] > >>> [ Accounting-Sub-Session-Id ] > >>> [ Acct-Session-Id ] > >>> [ Acct-Multi-Session-Id ] > >>> [ Acct-Interim-Interval ] > >>> [ Accounting-Realtime-Required ] > >>> [ Origin-State-Id ] > >>> [ Event-Timestamp ] > >>> * [ Proxy-Info ] > >>> * [ Route-Record ] > >>> * [ AVP ] > >>> > >>> this is means,Account Request recommend use Realm not Host. > >>> > >>> so if define SIP-Accounting_Information like below is better or not? > >>> SIP-Accounting-Information ::= < AVP Header: xx01 > > >>> [ SIP-Accounting-Server-Realm ] > >>> [ SIP-Credit-Control-Server-Ream ] > >>> * [ AVP] > >>> we send account request to account server,then we can Fill > >>> SIP-Accounting-Server-Realm Into Destination-Realm of Account Request. > >>> > >>> if not like this,we should fill SIP-Accounting-Server-URI into > >>> Destination-Host,the other question is how to contruct > >>> Destination-Realm(this avp is mandatory)? > >>> > >>> Thanks! > >>> Tony Zhang > >>> > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/dime > >> -- > >> Miguel A. Garcia tel:+358-50-4804586 > >> sip:miguel.an.garcia@openlaboratory.net > >> Nokia Research Center Helsinki, Finland > >> > >> > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 26 21:53:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv2m1-00014e-Qz; Mon, 26 Jun 2006 21:53:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv2m0-00014Z-Mv for dime@ietf.org; Mon, 26 Jun 2006 21:53:52 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv2lw-0002vw-ST for dime@ietf.org; Mon, 26 Jun 2006 21:53:52 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1H00IWVXZB3R@szxga02-in.huawei.com> for dime@ietf.org; Tue, 27 Jun 2006 10:09:12 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1H0000OXZBVL@szxga02-in.huawei.com> for dime@ietf.org; Tue, 27 Jun 2006 10:09:11 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1H005FKXQGR2@szxml04-in.huawei.com> for dime@ietf.org; Tue, 27 Jun 2006 10:03:52 +0800 (CST) Date: Tue, 27 Jun 2006 09:53:00 +0800 From: Tony Zhang Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext To: Tolga Asveren , dime@ietf.org Message-id: <004501c6998c$6b7d6910$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga: In my understand, AAA Proxy in visited network,AAA server in home network.so both nodes belong to different realm. when AN Send message, the destination Realm should address to AAA server not AAA Proxy.so AAA proxy should do routing, AAA Proxy and AAA Server is belong to same session. Regards! Tony ----- Original Message ----- From: "Tolga Asveren" To: Sent: Tuesday, June 27, 2006 3:49 AM Subject: [Dime] Comments for draft-tsou-dime-base-routing-ext > I have one comment/question regarding 1.1 in draft-tsou-dime-base-routing. > The configuration described is as follows, AFAIU: > > WLAN 3GPP 3GPP > AN --Wa-- AAA Proxy--Wd--Server > > I am not sure whether it is the correct view to consider 3GPP AAA Proxy as a > proxy from Diameter base protocol point of view. It seems to me, it is more > like a Diameter endpoint, which is acting as a proxy from 3GPP AAA service > point of view, i.e. it would have two related sessions: one between WLAN AN > and 3GPP AAA Proxy and the other one betweeen 3GPP Server and 3GPP AAA > Proxy; it would provide interworking/bridging between those two session and > probably would implement some local policy as well. AFAICS, this > interpretation would solve the problem, the draft is trying to address in > 1.1. Does this make sense or am I missing something completely? > > Thanks, > Tolga > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 27 01:58:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv6ap-0007q8-3v; Tue, 27 Jun 2006 01:58:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv6an-0007pz-C2 for dime@ietf.org; Tue, 27 Jun 2006 01:58:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv6an-0005YB-8s for dime@ietf.org; Tue, 27 Jun 2006 01:58:33 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fv6ag-0006ye-Tf for dime@ietf.org; Tue, 27 Jun 2006 01:58:33 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 26 Jun 2006 22:58:26 -0700 X-IronPort-AV: i="4.06,178,1149490800"; d="scan'208"; a="1833158218:sNHT35357250" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5R5wPF9006613; Mon, 26 Jun 2006 22:58:25 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5R5wPCU002627; Mon, 26 Jun 2006 22:58:25 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 22:58:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] one doubt about sip application Date: Mon, 26 Jun 2006 22:58:23 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625023771A6@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] one doubt about sip application Thread-Index: AcaY+zYrJ4FcCSIHQ4mtY8RG/Uuf3AAsztsQ From: "Glen Zorn \(gwz\)" To: "Miguel Garcia" , "Tony Zhang" X-OriginalArrivalTime: 27 Jun 2006 05:58:25.0566 (UTC) FILETIME=[B457F3E0:01C699AE] DKIM-Signature: a=rsa-sha1; q=dns; l=3582; t=1151387905; x=1152251905; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Dime]=20one=20doubt=20about=20sip=20application; X=v=3Dcisco.com=3B=20h=3D2ytVEwPGA53+4nAQXZxtjuHSlRo=3D; b=WnEea/2Q3GDtOC0zBocN8X9Yv9fhlA3OpOY/xvOrpb+6Q+F/+xUhqSz18XRqO5RYIhfYS4WY t4MstW78d47+c/SnCVnFR5mel7bntL1MQzRfz8737qfxHrJq2OzZ4rg5; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Miguel Garcia supposedly scribbled: > Tony: >=20 > The intention of the SIP-Accounting-Information is to outsource > Diameter accounting to a different server, not to a different realm. > So, from that point of view, the idea is to keep the realm constant, > but not the server. I am not sure of any use case where you need to > switch realms within the same application (SIP services), but > different hosts (authorization/authentication vs. accounting). =20 >=20 > Additionally, if the Diameter client gets only the realm where to > provide accounting, as you propose, then you need to have a mechanism > to guarantee that you can discover the host out of the realm. So, if > this mechanism is not in place, or the Realm Routing Table is not > properly provisioned, you run into trouble. =20 What happens if the provided host crashes? Do you just throw away the = accounting message? >=20 > Thus, I wouldn't recommend to provide realms for the accounting part > of the Diameter SIP application.=20 >=20 > BR, >=20 > Miguel >=20 >=20 > Tony Zhang wrote: >> Hi All: >> In Sip Application SIP-Accounting_Information is like below: >> SIP-Accounting-Information ::=3D < AVP Header: xx01 > >> * [ SIP-Accounting-Server-URI ] >> * [ SIP-Credit-Control-Server-URI >> ]=20 >> * [ AVP] >>=20 >> Actual in Rfc3588 accounting request define is like below: >> ::=3D < Diameter Header: 271, REQ, PXY > >> < Session-Id > >> { Origin-Host } >> { Origin-Realm } >> { Destination-Realm } >> { Accounting-Record-Type } >> { Accounting-Record-Number } >> [ Acct-Application-Id ] >> [ Vendor-Specific-Application-Id ] >> [ User-Name ] >> [ Accounting-Sub-Session-Id ] >> [ Acct-Session-Id ] >> [ Acct-Multi-Session-Id ] >> [ Acct-Interim-Interval ] >> [ Accounting-Realtime-Required ] >> [ Origin-State-Id ] >> [ Event-Timestamp ] >> * [ Proxy-Info ] >> * [ Route-Record ] >> * [ AVP ] >>=20 >> this is means,Account Request recommend use Realm not Host. >>=20 >> so if define SIP-Accounting_Information like below is better or not? >> SIP-Accounting-Information ::=3D < AVP Header: xx01 > >> [ SIP-Accounting-Server-Realm ] >> [ SIP-Credit-Control-Server-Ream >> ] * [ AVP] we send account >> request to=20 >> account server,then we can Fill SIP-Accounting-Server-Realm Into >> Destination-Realm of Account Request. >>=20 >> if not like this,we should fill SIP-Accounting-Server-URI into >> Destination-Host,the other question is how to contruct >> Destination-Realm(this avp is mandatory)? >>=20 >> Thanks! >> Tony Zhang >>=20 >>=20 >> = ---------------------------------------------------------------------- >> --=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 27 02:15:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv6rT-0002rl-6w; Tue, 27 Jun 2006 02:15:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv6rS-0002rg-PP for dime@ietf.org; Tue, 27 Jun 2006 02:15:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv6rS-0006rz-Md for dime@ietf.org; Tue, 27 Jun 2006 02:15:46 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fv6rR-0007AU-Kr for dime@ietf.org; Tue, 27 Jun 2006 02:15:46 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5R6Fc5g018579; Tue, 27 Jun 2006 09:15:39 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 09:15:01 +0300 Received: from [127.0.0.1] ([172.21.35.92]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 27 Jun 2006 09:15:02 +0300 Message-ID: <44A0CCE5.7030208@nokia.com> Date: Tue, 27 Jun 2006 09:15:01 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Glen Zorn (gwz)" Subject: Re: [Dime] one doubt about sip application References: <4C0FAAC489C8B74F96BEAD85EAEB2625023771A6@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625023771A6@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2006 06:15:02.0669 (UTC) FILETIME=[06A9CBD0:01C699B1] X-Spam-Score: -2.4 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Glen Zorn (gwz) wrote: > Miguel Garcia supposedly scribbled: > >> Tony: >> >> The intention of the SIP-Accounting-Information is to outsource >> Diameter accounting to a different server, not to a different realm. >> So, from that point of view, the idea is to keep the realm constant, >> but not the server. I am not sure of any use case where you need to >> switch realms within the same application (SIP services), but >> different hosts (authorization/authentication vs. accounting). >> >> Additionally, if the Diameter client gets only the realm where to >> provide accounting, as you propose, then you need to have a mechanism >> to guarantee that you can discover the host out of the realm. So, if >> this mechanism is not in place, or the Realm Routing Table is not >> properly provisioned, you run into trouble. > > What happens if the provided host crashes? Do you just throw awa the accounting message? No, you are supposed to install several servers for redundancy purposes, so there is a backup accounting server. The SIP-Accounting-Information AVP allows for repetition of the URI of each server, so you can provide as many as you want: SIP-Accounting-Information ::= < AVP Header: xx01 > * [ SIP-Accounting-Server-URI ] * [ SIP-Credit-Control-Server-URI ] * [ AVP] Additionally, you can also get redundancy through round robin DNS, although I favor the repetition of the URI AVPs. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 27 06:24:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvAkW-0003wz-Qa; Tue, 27 Jun 2006 06:24:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvAkW-0003wu-7N for dime@ietf.org; Tue, 27 Jun 2006 06:24:52 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvAkU-0007sW-Of for dime@ietf.org; Tue, 27 Jun 2006 06:24:52 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5RAOmCe026554; Tue, 27 Jun 2006 13:24:49 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 13:24:45 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 13:24:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jun 2006 13:24:44 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I have some question for Diameter Base Protocol(RFC3588) Thread-Index: AcaZjMwR66XSBtpzTYybEnVnOoZwiwARv/YQ From: To: X-OriginalArrivalTime: 27 Jun 2006 10:24:45.0194 (UTC) FILETIME=[E8F1AEA0:01C699D3] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: csmacdnet@gmail.com Subject: [Dime] FW: I have some question for Diameter Base Protocol(RFC3588) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Lee, I am forwarding this to the Diameter Extentions & Maintanence mailing = list, for discussion there. John=20 ________________________________ From: ext Mark Lee [mailto:csmacdnet@gmail.com]=20 Sent: 27 June, 2006 04:55 To: pcalhoun@airespace.com; Loughney John (Nokia-NRC/Helsinki); = Jari.Arkko@ericsson.com; erik.guttman@sun.com Subject: I have some question for Diameter Base Protocol(RFC3588) =09 =09 Hello! =20 I am LEE.. live in Korea.. =20 I have some question for Diameter Base Protocol. =20 I'm university and studying Diameter Base protocol. =20 I want to know this... =20 Tell me some information plz.. =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 6.11. Vendor-Specific-Application-Id AVP =20 AVP Format =09 ::=3D < AVP Header: 260 > 1* [ Vendor-Id ] 0*1{ Auth-Application-Id }=20 0*1{ Acct-Application-Id } = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 I can't understand that AVP Format of Vendor-Specific-Application-Id = AVP. =20 this is grammar of grouped avp =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 grouped-avp-def =3D name "::=3D" avp =20 name-fmt =3D ALPHA *(ALPHA / DIGIT / "-") =20 name =3D name-fmt ; The name has to be the name of an AVP, ; defined in the base or extended Diameter=20 ; specifications. =20 avp =3D header [ *fixed] [ *required] [ *optional] = [ *fixed] = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 See that " header [ *fixed] [ *required] [ *optional] [ *fixed] " =20 But.. =20 Vendor-Specific-Application-Id is=20 =20 ::=3D < AVP Header: 260 > 1* [ Vendor-Id ] = <-- this is optional.. (front of fixed!!)=20 0*1{ Auth-Application-Id } = <-- this is required 0*1{ Acct-Application-Id } =09 I think that it is violation of rule that "avp =3D header [ *fixed] [ = *required] [ *optional] [ *fixed]" =20 Is it right?? =20 and I want to know... =20 1* [ Vendor-Id ] -> [] is optional.. why have to more than 1???=20 0*1{ Auth-Application-Id } - {} is required .... why can be 0 ?? =20 I am sorry I am not good at speak in English. =20 Have nice day.! --=20 Best regards! =09 Hyo-Sung Lee(=EC=B0=FC=FB=E0=F8/Mark Lee) =09 KRSF Certified Inline Skate Instructor Fitness Inline Skate Trainer Mogul&Freeride Skier IDOne ski rider GranTurismo International A Licence=20 =09 +82-11-257-4758 / nayalee@korea.com; csmacdnet@hotmail.com(MSN) csmacdnet@gmail.com; csmacdnet@paran.com(KT-Iman)=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 27 10:43:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEmv-0000Ki-Ro; Tue, 27 Jun 2006 10:43:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEmu-0000Ka-2v for dime@ietf.org; Tue, 27 Jun 2006 10:43:36 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvEms-0002qC-NY for dime@ietf.org; Tue, 27 Jun 2006 10:43:36 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k5REh0B3084306; Tue, 27 Jun 2006 10:43:02 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44A143F5.1060705@tari.toshiba.com> Date: Tue, 27 Jun 2006 10:43:01 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext References: <004501c6998c$6b7d6910$3791460a@china.huawei.com> In-Reply-To: <004501c6998c$6b7d6910$3791460a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, Thanks for your review. > Hi Tolga: > In my understand, AAA Proxy in visited network,AAA server in home network.so both nodes belong to different realm. > when AN Send message, the destination Realm should address to AAA server not AAA Proxy.so AAA proxy should do routing, > AAA Proxy and AAA Server is belong to same session. > I hope I'm describing this accurately but a further example maybe in terms of accounting exchanges where the visited domain (which may have its own AAA proxy) uses a clearing house (which in turn has its own AAA proxy in a different domain) prior to reaching the home domain. It's probably a more generic scenario which may help clarify the problem statement better than the 3gpp example. In some sense, the mechanism is similar to SIP Record-Route. hope this helps, victor > Regards! > Tony > > ----- Original Message ----- > From: "Tolga Asveren" > To: > Sent: Tuesday, June 27, 2006 3:49 AM > Subject: [Dime] Comments for draft-tsou-dime-base-routing-ext > > > >> I have one comment/question regarding 1.1 in draft-tsou-dime-base-routing. >> The configuration described is as follows, AFAIU: >> >> WLAN 3GPP 3GPP >> AN --Wa-- AAA Proxy--Wd--Server >> >> I am not sure whether it is the correct view to consider 3GPP AAA Proxy as a >> proxy from Diameter base protocol point of view. It seems to me, it is more >> like a Diameter endpoint, which is acting as a proxy from 3GPP AAA service >> point of view, i.e. it would have two related sessions: one between WLAN AN >> and 3GPP AAA Proxy and the other one betweeen 3GPP Server and 3GPP AAA >> Proxy; it would provide interworking/bridging between those two session and >> probably would implement some local policy as well. AFAICS, this >> interpretation would solve the problem, the draft is trying to address in >> 1.1. Does this make sense or am I missing something completely? >> >> Thanks, >> Tolga >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 28 14:03:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FveO6-0000iK-K0; Wed, 28 Jun 2006 14:03:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FveO5-0000V4-61 for dime@ietf.org; Wed, 28 Jun 2006 14:03:41 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FveO4-0002RK-Ns for dime@ietf.org; Wed, 28 Jun 2006 14:03:41 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 2C4EAC3E97; Wed, 28 Jun 2006 14:03:40 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5SI3c6W013028; Wed, 28 Jun 2006 14:03:38 -0400 (EDT) From: "Tolga Asveren" To: "Victor Fajardo" Subject: RE: [Dime] Comments for draft-tsou-dime-base-routing-ext Date: Wed, 28 Jun 2006 13:40:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A143F5.1060705@tari.toshiba.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, Tony, The issue of routing where proxies are involved is an interesting one. I don't know how it is supposed to work but I will try to explain my opinion -which is more a collection of questions- about this topic. If we consider the example provided by Victor, I can think of two different ways of doing it(similar thing applies to the example presented in the draft): a)Clearinghouse proxy provides message routing and executes local policy but does not terminate the session. It will be seen as proxy1.clearinghouse.com from client point of view. b)Clearinghouse proxy terminates the session and actually proxies the service provided. It will be seen as AAAserver1.providerB.com from client point of view. The way application support is advertised hints slightly and implicitly to b). Proxies do not advertise supported application/realm pairs in CER/CEA but just the applications. The realm is implicitly identified by the DiameterIdentity of the proxy. For example in the above example, there is no way to tell for the clearinghouse proxy that it can't handle anymore requests for b.com, if it is handling multiple realms and if a) is used. With b), it can drop the connection from its AAAserver1.providerB.com identity to clients. This won't effect that it is handling requests for other realms, because clearinghouse proxy would assume different identities for them and would have separate connections to clients. OTOH, b) would require that clearinghouse proxy assumes identity for each realm, it is providing service for. I wouldn't think this would be a huge problem but it probably is not desirable either. The definition of proxies in RFC3588 2.8.2 doesn't mention about application level proxying. >From architectural point of view, I like the idea that Diameter base message routing is not affected by the specific needs of applications, i.e. if there is a need to traverse specific nodes, which have semantical application processing, this should be handled by proxying the service, where each such proxy decides for the next hop based on application logic (kind of like an overlay application specific network if I may say so). IMO, the analogy is that IP routing is not effected by the needs of application level necessities, e.g. it is the application entity which populates the correct IP address, if there is a need to traverse a specific set of application nodes. To me, Diameter base protocol (RFC3588 - Authentication/Authorization application defined in RFC3588) is a network layer protocol. Relay agents are similar to routers in IP networks but IMHO any type of proxying is better handled on application layer. I don't know, which one of those models is the one, Diameter authors had in mind for such scenarios, just I hope by considering all pros/contras we can clarify -and if necessary fix- this thing. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Tuesday, June 27, 2006 10:43 AM > To: Tolga Asveren > Cc: Tony Zhang; dime@ietf.org > Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext > > > Hi Tolga, > > Thanks for your review. > > Hi Tolga: > > In my understand, AAA Proxy in visited network,AAA server > in home network.so both nodes belong to different realm. > > when AN Send message, the destination Realm should address to > AAA server not AAA Proxy.so AAA proxy should do routing, > > AAA Proxy and AAA Server is belong to same session. > > > > I hope I'm describing this accurately but a further example maybe in > terms of accounting exchanges where the visited domain (which may have > its own AAA proxy) uses a clearing house (which in turn has its own AAA > proxy in a different domain) prior to reaching the home domain. It's > probably a more generic scenario which may help clarify the problem > statement better than the 3gpp example. In some sense, the mechanism is > similar to SIP Record-Route. > > hope this helps, > victor > > > Regards! > > Tony > > > > ----- Original Message ----- > > From: "Tolga Asveren" > > To: > > Sent: Tuesday, June 27, 2006 3:49 AM > > Subject: [Dime] Comments for draft-tsou-dime-base-routing-ext > > > > > > > >> I have one comment/question regarding 1.1 in > draft-tsou-dime-base-routing. > >> The configuration described is as follows, AFAIU: > >> > >> WLAN 3GPP 3GPP > >> AN --Wa-- AAA Proxy--Wd--Server > >> > >> I am not sure whether it is the correct view to consider 3GPP > AAA Proxy as a > >> proxy from Diameter base protocol point of view. It seems to > me, it is more > >> like a Diameter endpoint, which is acting as a proxy from 3GPP > AAA service > >> point of view, i.e. it would have two related sessions: one > between WLAN AN > >> and 3GPP AAA Proxy and the other one betweeen 3GPP Server and 3GPP AAA > >> Proxy; it would provide interworking/bridging between those > two session and > >> probably would implement some local policy as well. AFAICS, this > >> interpretation would solve the problem, the draft is trying to > address in > >> 1.1. Does this make sense or am I missing something completely? > >> > >> Thanks, > >> Tolga > >> > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> > >> > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 29 10:18:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxLT-0004vb-JX; Thu, 29 Jun 2006 10:18:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxLS-0004vV-Ub for dime@ietf.org; Thu, 29 Jun 2006 10:18:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvxLS-0001pG-SL for dime@ietf.org; Thu, 29 Jun 2006 10:18:14 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvxK1-0005MJ-VN for dime@ietf.org; Thu, 29 Jun 2006 10:16:48 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k5TEGT19092963; Thu, 29 Jun 2006 10:16:30 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44A3E0BF.2070102@tari.toshiba.com> Date: Thu, 29 Jun 2006 10:16:31 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, Comments inline: > Hi Victor, Tony, > > The issue of routing where proxies are involved is an interesting one. I > don't know how it is supposed to work but I will try to explain my > opinion -which is more a collection of questions- about this topic. > > If we consider the example provided by Victor, I can think of two different > ways of doing it(similar thing applies to the example presented in the > draft): > a)Clearinghouse proxy provides message routing and executes local policy but > does not terminate the session. It will be seen as proxy1.clearinghouse.com > from client point of view. > > b)Clearinghouse proxy terminates the session and actually proxies the > service provided. It will be seen as AAAserver1.providerB.com from client > point of view. > > The way application support is advertised hints slightly and implicitly to > b). Proxies do not advertise supported application/realm pairs in CER/CEA > but just the applications. The realm is implicitly identified by the > DiameterIdentity of the proxy. For example in the above example, there is no > way to tell for the clearinghouse proxy that it can't handle anymore > requests for b.com, if it is handling multiple realms and if a) is used. > With b), it can drop the connection from its AAAserver1.providerB.com > identity to clients. This won't effect that it is handling requests for > other realms, because clearinghouse proxy would assume different identities > for them and would have separate connections to clients. > > OTOH, b) would require that clearinghouse proxy assumes identity for each > realm, it is providing service for. I wouldn't think this would be a huge > problem but it probably is not desirable either. > > The definition of proxies in RFC3588 2.8.2 doesn't mention about application > level proxying. > In general, the above scenarios you describe will work. However, I'm guessing that it assumes that there is only one single AAA proxy in the clearing house which will manage all sessions for all visited domains. In normal deployments, there will most likely be more than one of these proxies for scalability purposes and flexibility in the topology. So I think the draft attempts to solve a slightly different issue. As an example, if we do have multiple proxies in the clearing house and there is a relay in between the proxies and visited domains which routes messages based on some scaling policy but independent of the sessions then the problem statement in the draft holds true. > >From architectural point of view, I like the idea that Diameter base message > routing is not affected by the specific needs of applications, i.e. if there > is a need to traverse specific nodes, which have semantical application > processing, this should be handled by proxying the service, where each such > proxy decides for the next hop based on application logic (kind of like an > overlay application specific network if I may say so). I agree with you and the draft does not mandate changes to the base protocol routing that affects any and all proxies. I think this is why the routing scheme in the draft is bounded to an application's sessions. In such a case, the routing scheme is will be based on the requirements of the application and the proxy services that supports them as you have mentioned. It would then be the responsibility of the applications to manage destination-host/destination-realm and the draft simply proposes a generic method for applications to accomplish this. > IMO, the analogy is > that IP routing is not effected by the needs of application level > necessities, e.g. it is the application entity which populates the correct > IP address, if there is a need to traverse a specific set of application > nodes. To me, Diameter base protocol (RFC3588 - Authentication/Authorization > application defined in RFC3588) is a network layer protocol. Relay agents > are similar to routers in IP networks but IMHO any type of proxying is > better handled on application layer. > To extend your IP analogy, the proposed scheme would be similar to IP strict source routing. many thanks, victor > I don't know, which one of those models is the one, Diameter authors had in > mind for such scenarios, just I hope by considering all pros/contras we can > clarify -and if necessary fix- this thing. > > Thanks, > Tolga > > > >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: Tuesday, June 27, 2006 10:43 AM >> To: Tolga Asveren >> Cc: Tony Zhang; dime@ietf.org >> Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext >> >> >> Hi Tolga, >> >> Thanks for your review. >> >>> Hi Tolga: >>> In my understand, AAA Proxy in visited network,AAA server >>> >> in home network.so both nodes belong to different realm. >> >>> when AN Send message, the destination Realm should address to >>> >> AAA server not AAA Proxy.so AAA proxy should do routing, >> >>> AAA Proxy and AAA Server is belong to same session. >>> >>> >> I hope I'm describing this accurately but a further example maybe in >> terms of accounting exchanges where the visited domain (which may have >> its own AAA proxy) uses a clearing house (which in turn has its own AAA >> proxy in a different domain) prior to reaching the home domain. It's >> probably a more generic scenario which may help clarify the problem >> statement better than the 3gpp example. In some sense, the mechanism is >> similar to SIP Record-Route. >> >> hope this helps, >> victor >> >> >>> Regards! >>> Tony >>> >>> ----- Original Message ----- >>> From: "Tolga Asveren" >>> To: >>> Sent: Tuesday, June 27, 2006 3:49 AM >>> Subject: [Dime] Comments for draft-tsou-dime-base-routing-ext >>> >>> >>> >>> >>>> I have one comment/question regarding 1.1 in >>>> >> draft-tsou-dime-base-routing. >> >>>> The configuration described is as follows, AFAIU: >>>> >>>> WLAN 3GPP 3GPP >>>> AN --Wa-- AAA Proxy--Wd--Server >>>> >>>> I am not sure whether it is the correct view to consider 3GPP >>>> >> AAA Proxy as a >> >>>> proxy from Diameter base protocol point of view. It seems to >>>> >> me, it is more >> >>>> like a Diameter endpoint, which is acting as a proxy from 3GPP >>>> >> AAA service >> >>>> point of view, i.e. it would have two related sessions: one >>>> >> between WLAN AN >> >>>> and 3GPP AAA Proxy and the other one betweeen 3GPP Server and 3GPP AAA >>>> Proxy; it would provide interworking/bridging between those >>>> >> two session and >> >>>> probably would implement some local policy as well. AFAICS, this >>>> interpretation would solve the problem, the draft is trying to >>>> >> address in >> >>>> 1.1. Does this make sense or am I missing something completely? >>>> >>>> Thanks, >>>> Tolga >>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> >>> >>> > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 29 10:59:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvxz0-0006V6-5P; Thu, 29 Jun 2006 10:59:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvxyz-0006RS-Fj for dime@ietf.org; Thu, 29 Jun 2006 10:59:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvx4A-0001Fk-4d for dime@ietf.org; Thu, 29 Jun 2006 10:00:22 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvwZu-0004CQ-8G for dime@ietf.org; Thu, 29 Jun 2006 09:29:07 -0400 Received: by nf-out-0910.google.com with SMTP id b2so58062nfe for ; Thu, 29 Jun 2006 06:29:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=in7pHv9i3ck5ZB5haVkV9X6USCWndpS2UkoHdtaQoVS3zgZqjPqK+ue1VY1n6X9Vmni79i7Nrl5TsSd5zdF8Fqe1NWKLaavyL7Nly14RioipKhQYGoZhVlPOPpCcinugrxjnyoPK42Gcmgxm2yEzqR4EdrpKlXSdimaqo4AgWLc= Received: by 10.49.72.6 with SMTP id z6mr1632076nfk; Thu, 29 Jun 2006 06:29:02 -0700 (PDT) Received: by 10.49.40.17 with HTTP; Thu, 29 Jun 2006 06:29:02 -0700 (PDT) Message-ID: Date: Thu, 29 Jun 2006 14:29:02 +0100 From: "Gerardo Giaretta" To: dime@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.5 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Dime] New version of draft-ietf-mip6-aaa-ha-goals-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, this is the new version of the AAA-HA Goals draft from MIP6 WG. The document is interesting for DIME WG since it lists the AAA requirements for MIP6. Our intention is to start asap a WGLC in MIP6 WG so that DIME WG can work on the solution. Please provide your comments before the meeting (if possibile to the mip6 mailing list) so that we can use the meeting time to solve the open issues. Regards, --Gerardo > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobility for IPv6 Working Group of the IETF. > > Title : Goals for AAA-HA interface > Author(s) : G. Giaretta, et al. > Filename : draft-ietf-mip6-aaa-ha-goals-02.txt > Pages : 12 > Date : 2006-6-28 > > In commercial deployments Mobile IPv6 can be a service offered by a > Mobility Services Provider (MSP). In this case all protocol > operations may need to be explicitly authorized and traced, requiring > the interaction between Mobile IPv6 and the AAA infrastructure. > Integrating the AAA infrastructure offers also a solution component > for Mobile IPv6 bootstrapping in integrated and split scenarios. > > This document describes various scenarios where a AAA interface for > Mobile IPv6 is actually required. Additionally, it lists design > goals and requirements for such an interface. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-02.txt > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 29 17:38:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4DR-0000mO-6v; Thu, 29 Jun 2006 17:38:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4DQ-0000mJ-EP for dime@ietf.org; Thu, 29 Jun 2006 17:38:24 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw4DP-0006cd-SZ for dime@ietf.org; Thu, 29 Jun 2006 17:38:24 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k5TLbhBL094922; Thu, 29 Jun 2006 17:37:43 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44A44827.4070206@tari.toshiba.com> Date: Thu, 29 Jun 2006 17:37:43 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, >>> >> In general, the above scenarios you describe will work. However, I'm >> guessing that it assumes that there is only one single AAA proxy in the >> clearing house which will manage all sessions for all visited domains. >> In normal deployments, there will most likely be more than one of these >> proxies for scalability purposes and flexibility in the topology. So I >> think the draft attempts to solve a slightly different issue. As an >> example, if we do have multiple proxies in the clearing house and there >> is a relay in between the proxies and visited domains which routes >> messages based on some scaling policy but independent of the sessions >> then the problem statement in the draft holds true. >> > [TOLGA]I agree with that. Initally I thought why do we need such a > mechanism, if proxies involved are already stateful. The answer is existence > of stateles intermediares, i.e. relay agents. IMO there are two different > situations: > a)All intermediares on the path are stateful > b)At least one intermediary in the path is stateless. > > For a), I believe there is a relatively easy solution, which does not > require protocol involvement: All nodes send messages belonging to the saem > session to the same peer. I know this is not mandated in RFC3588 -at least I > don't recall it being mandated somewhere-. OTOH, I believe it is common > sense to do so and is useful. It would help to prevent some probbaly quite > unlikely but still possible missequencing of messages. I think, you may want > to mention about a) and how it could provide a solution to cover all cases. > Actually maybe that type of message routing is something, which can be > included in a possible Diameter-bis document: "All Diameter nodes, which are > keeping session state SHOULD send requests belonging to the same session to > the same next hop unless htere is a failure." > Sounds good to me. best regards, victor > >>> >From architectural point of view, I like the idea that >>> >> Diameter base message >> >>> routing is not affected by the specific needs of applications, >>> >> i.e. if there >> >>> is a need to traverse specific nodes, which have semantical application >>> processing, this should be handled by proxying the service, >>> >> where each such >> >>> proxy decides for the next hop based on application logic (kind >>> >> of like an >> >>> overlay application specific network if I may say so). >>> >> I agree with you and the draft does not mandate changes to the base >> protocol routing that affects any and all proxies. I think this is why >> the routing scheme in the draft is bounded to an application's sessions. >> In such a case, the routing scheme is will be based on the requirements >> of the application and the proxy services that supports them as you have >> mentioned. It would then be the responsibility of the applications to >> manage destination-host/destination-realm and the draft simply proposes >> a generic method for applications to accomplish this. >> >> >>> IMO, the analogy is >>> that IP routing is not effected by the needs of application level >>> necessities, e.g. it is the application entity which populates >>> >> the correct >> >>> IP address, if there is a need to traverse a specific set of application >>> nodes. To me, Diameter base protocol (RFC3588 - >>> >> Authentication/Authorization >> >>> application defined in RFC3588) is a network layer protocol. >>> >> Relay agents >> >>> are similar to routers in IP networks but IMHO any type of proxying is >>> better handled on application layer. >>> >>> >> To extend your IP analogy, the proposed scheme would be similar to IP >> strict source routing. >> >> many thanks, >> victor >> >> >>> I don't know, which one of those models is the one, Diameter >>> >> authors had in >> >>> mind for such scenarios, just I hope by considering all >>> >> pros/contras we can >> >>> clarify -and if necessary fix- this thing. >>> >>> Thanks, >>> Tolga >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >>>> Sent: Tuesday, June 27, 2006 10:43 AM >>>> To: Tolga Asveren >>>> Cc: Tony Zhang; dime@ietf.org >>>> Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext >>>> >>>> >>>> Hi Tolga, >>>> >>>> Thanks for your review. >>>> >>>> >>>>> Hi Tolga: >>>>> In my understand, AAA Proxy in visited network,AAA server >>>>> >>>>> >>>> in home network.so both nodes belong to different realm. >>>> >>>> >>>>> when AN Send message, the destination Realm should address to >>>>> >>>>> >>>> AAA server not AAA Proxy.so AAA proxy should do routing, >>>> >>>> >>>>> AAA Proxy and AAA Server is belong to same session. >>>>> >>>>> >>>>> >>>> I hope I'm describing this accurately but a further example maybe in >>>> terms of accounting exchanges where the visited domain (which may have >>>> its own AAA proxy) uses a clearing house (which in turn has its own AAA >>>> proxy in a different domain) prior to reaching the home domain. It's >>>> probably a more generic scenario which may help clarify the problem >>>> statement better than the 3gpp example. In some sense, the mechanism is >>>> similar to SIP Record-Route. >>>> >>>> hope this helps, >>>> victor >>>> >>>> >>>> >>>>> Regards! >>>>> Tony >>>>> >>>>> ----- Original Message ----- >>>>> From: "Tolga Asveren" >>>>> To: >>>>> Sent: Tuesday, June 27, 2006 3:49 AM >>>>> Subject: [Dime] Comments for draft-tsou-dime-base-routing-ext >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> I have one comment/question regarding 1.1 in >>>>>> >>>>>> >>>> draft-tsou-dime-base-routing. >>>> >>>> >>>>>> The configuration described is as follows, AFAIU: >>>>>> >>>>>> WLAN 3GPP 3GPP >>>>>> AN --Wa-- AAA Proxy--Wd--Server >>>>>> >>>>>> I am not sure whether it is the correct view to consider 3GPP >>>>>> >>>>>> >>>> AAA Proxy as a >>>> >>>> >>>>>> proxy from Diameter base protocol point of view. It seems to >>>>>> >>>>>> >>>> me, it is more >>>> >>>> >>>>>> like a Diameter endpoint, which is acting as a proxy from 3GPP >>>>>> >>>>>> >>>> AAA service >>>> >>>> >>>>>> point of view, i.e. it would have two related sessions: one >>>>>> >>>>>> >>>> between WLAN AN >>>> >>>> >>>>>> and 3GPP AAA Proxy and the other one betweeen 3GPP Server >>>>>> >> and 3GPP AAA >> >>>>>> Proxy; it would provide interworking/bridging between those >>>>>> >>>>>> >>>> two session and >>>> >>>> >>>>>> probably would implement some local policy as well. AFAICS, this >>>>>> interpretation would solve the problem, the draft is trying to >>>>>> >>>>>> >>>> address in >>>> >>>> >>>>>> 1.1. Does this make sense or am I missing something completely? >>>>>> >>>>>> Thanks, >>>>>> Tolga >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 29 18:08:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4gh-0008Kq-Ki; Thu, 29 Jun 2006 18:08:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4gb-0008Bn-If for dime@ietf.org; Thu, 29 Jun 2006 18:08:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw3VL-0003TF-0S for dime@ietf.org; Thu, 29 Jun 2006 16:52:51 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fw3KN-0006Ud-Nz for dime@ietf.org; Thu, 29 Jun 2006 16:41:34 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 9BDC796BF5; Thu, 29 Jun 2006 16:41:24 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5TKfM6W004773; Thu, 29 Jun 2006 16:41:23 -0400 (EDT) From: "Tolga Asveren" To: "Victor Fajardo" Subject: RE: [Dime] Comments for draft-tsou-dime-base-routing-ext Date: Thu, 29 Jun 2006 16:17:57 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A3E0BF.2070102@tari.toshiba.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: -2.3 (--) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Thursday, June 29, 2006 10:17 AM > To: Tolga Asveren > Cc: Tony Zhang; dime@ietf.org > Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext > > > Hi Tolga, > > Comments inline: > > Hi Victor, Tony, > > > > The issue of routing where proxies are involved is an interesting one. I > > don't know how it is supposed to work but I will try to explain my > > opinion -which is more a collection of questions- about this topic. > > > > If we consider the example provided by Victor, I can think of > two different > > ways of doing it(similar thing applies to the example presented in the > > draft): > > a)Clearinghouse proxy provides message routing and executes > local policy but > > does not terminate the session. It will be seen as > proxy1.clearinghouse.com > > from client point of view. > > > > b)Clearinghouse proxy terminates the session and actually proxies the > > service provided. It will be seen as AAAserver1.providerB.com > from client > > point of view. > > > > The way application support is advertised hints slightly and > implicitly to > > b). Proxies do not advertise supported application/realm pairs > in CER/CEA > > but just the applications. The realm is implicitly identified by the > > DiameterIdentity of the proxy. For example in the above > example, there is no > > way to tell for the clearinghouse proxy that it can't handle anymore > > requests for b.com, if it is handling multiple realms and if a) is used. > > With b), it can drop the connection from its AAAserver1.providerB.com > > identity to clients. This won't effect that it is handling requests for > > other realms, because clearinghouse proxy would assume > different identities > > for them and would have separate connections to clients. > > > > OTOH, b) would require that clearinghouse proxy assumes > identity for each > > realm, it is providing service for. I wouldn't think this would > be a huge > > problem but it probably is not desirable either. > > > > The definition of proxies in RFC3588 2.8.2 doesn't mention > about application > > level proxying. > > > In general, the above scenarios you describe will work. However, I'm > guessing that it assumes that there is only one single AAA proxy in the > clearing house which will manage all sessions for all visited domains. > In normal deployments, there will most likely be more than one of these > proxies for scalability purposes and flexibility in the topology. So I > think the draft attempts to solve a slightly different issue. As an > example, if we do have multiple proxies in the clearing house and there > is a relay in between the proxies and visited domains which routes > messages based on some scaling policy but independent of the sessions > then the problem statement in the draft holds true. [TOLGA]I agree with that. Initally I thought why do we need such a mechanism, if proxies involved are already stateful. The answer is existence of stateles intermediares, i.e. relay agents. IMO there are two different situations: a)All intermediares on the path are stateful b)At least one intermediary in the path is stateless. For a), I believe there is a relatively easy solution, which does not require protocol involvement: All nodes send messages belonging to the saem session to the same peer. I know this is not mandated in RFC3588 -at least I don't recall it being mandated somewhere-. OTOH, I believe it is common sense to do so and is useful. It would help to prevent some probbaly quite unlikely but still possible missequencing of messages. I think, you may want to mention about a) and how it could provide a solution to cover all cases. Actually maybe that type of message routing is something, which can be included in a possible Diameter-bis document: "All Diameter nodes, which are keeping session state SHOULD send requests belonging to the same session to the same next hop unless htere is a failure." > > > >From architectural point of view, I like the idea that > Diameter base message > > routing is not affected by the specific needs of applications, > i.e. if there > > is a need to traverse specific nodes, which have semantical application > > processing, this should be handled by proxying the service, > where each such > > proxy decides for the next hop based on application logic (kind > of like an > > overlay application specific network if I may say so). > I agree with you and the draft does not mandate changes to the base > protocol routing that affects any and all proxies. I think this is why > the routing scheme in the draft is bounded to an application's sessions. > In such a case, the routing scheme is will be based on the requirements > of the application and the proxy services that supports them as you have > mentioned. It would then be the responsibility of the applications to > manage destination-host/destination-realm and the draft simply proposes > a generic method for applications to accomplish this. > > > IMO, the analogy is > > that IP routing is not effected by the needs of application level > > necessities, e.g. it is the application entity which populates > the correct > > IP address, if there is a need to traverse a specific set of application > > nodes. To me, Diameter base protocol (RFC3588 - > Authentication/Authorization > > application defined in RFC3588) is a network layer protocol. > Relay agents > > are similar to routers in IP networks but IMHO any type of proxying is > > better handled on application layer. > > > To extend your IP analogy, the proposed scheme would be similar to IP > strict source routing. > > many thanks, > victor > > > I don't know, which one of those models is the one, Diameter > authors had in > > mind for such scenarios, just I hope by considering all > pros/contras we can > > clarify -and if necessary fix- this thing. > > > > Thanks, > > Tolga > > > > > > > >> -----Original Message----- > >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > >> Sent: Tuesday, June 27, 2006 10:43 AM > >> To: Tolga Asveren > >> Cc: Tony Zhang; dime@ietf.org > >> Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext > >> > >> > >> Hi Tolga, > >> > >> Thanks for your review. > >> > >>> Hi Tolga: > >>> In my understand, AAA Proxy in visited network,AAA server > >>> > >> in home network.so both nodes belong to different realm. > >> > >>> when AN Send message, the destination Realm should address to > >>> > >> AAA server not AAA Proxy.so AAA proxy should do routing, > >> > >>> AAA Proxy and AAA Server is belong to same session. > >>> > >>> > >> I hope I'm describing this accurately but a further example maybe in > >> terms of accounting exchanges where the visited domain (which may have > >> its own AAA proxy) uses a clearing house (which in turn has its own AAA > >> proxy in a different domain) prior to reaching the home domain. It's > >> probably a more generic scenario which may help clarify the problem > >> statement better than the 3gpp example. In some sense, the mechanism is > >> similar to SIP Record-Route. > >> > >> hope this helps, > >> victor > >> > >> > >>> Regards! > >>> Tony > >>> > >>> ----- Original Message ----- > >>> From: "Tolga Asveren" > >>> To: > >>> Sent: Tuesday, June 27, 2006 3:49 AM > >>> Subject: [Dime] Comments for draft-tsou-dime-base-routing-ext > >>> > >>> > >>> > >>> > >>>> I have one comment/question regarding 1.1 in > >>>> > >> draft-tsou-dime-base-routing. > >> > >>>> The configuration described is as follows, AFAIU: > >>>> > >>>> WLAN 3GPP 3GPP > >>>> AN --Wa-- AAA Proxy--Wd--Server > >>>> > >>>> I am not sure whether it is the correct view to consider 3GPP > >>>> > >> AAA Proxy as a > >> > >>>> proxy from Diameter base protocol point of view. It seems to > >>>> > >> me, it is more > >> > >>>> like a Diameter endpoint, which is acting as a proxy from 3GPP > >>>> > >> AAA service > >> > >>>> point of view, i.e. it would have two related sessions: one > >>>> > >> between WLAN AN > >> > >>>> and 3GPP AAA Proxy and the other one betweeen 3GPP Server > and 3GPP AAA > >>>> Proxy; it would provide interworking/bridging between those > >>>> > >> two session and > >> > >>>> probably would implement some local policy as well. AFAICS, this > >>>> interpretation would solve the problem, the draft is trying to > >>>> > >> address in > >> > >>>> 1.1. Does this make sense or am I missing something completely? > >>>> > >>>> Thanks, > >>>> Tolga > >>>> > >>>> > >>>> _______________________________________________ > >>>> DiME mailing list > >>>> DiME@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/dime > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/dime > >>> > >>> > >>> > >>> > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 29 22:33:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw8pH-00007v-Dm; Thu, 29 Jun 2006 22:33:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw8pG-00007q-Jw for dime@ietf.org; Thu, 29 Jun 2006 22:33:46 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw8pE-0001Le-Vi for dime@ietf.org; Thu, 29 Jun 2006 22:33:46 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1N00012J5VNS@szxga01-in.huawei.com> for dime@ietf.org; Fri, 30 Jun 2006 10:34:43 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1N000C9J5TGW@szxga01-in.huawei.com> for dime@ietf.org; Fri, 30 Jun 2006 10:34:43 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1N00AFTJ5WZ9@szxml03-in.huawei.com> for dime@ietf.org; Fri, 30 Jun 2006 10:34:44 +0800 (CST) Date: Fri, 30 Jun 2006 10:32:49 +0800 From: Tony Zhang Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext To: Tolga Asveren , Victor Fajardo Message-id: <006701c69bed$7af85f90$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga: > [TOLGA]I agree with that. Initally I thought why do we need such a > mechanism, if proxies involved are already stateful. The answer is existence > of stateles intermediares, i.e. relay agents. IMO there are two different > situations: > a)All intermediares on the path are stateful > b)At least one intermediary in the path is stateless. > > For a), I believe there is a relatively easy solution, which does not > require protocol involvement: All nodes send messages belonging to the saem > session to the same peer. I know this is not mandated in RFC3588 -at least I > > don't recall it being mandated somewhere-. OTOH, I believe it is common > sense to do so and is useful. It would help to prevent some probbaly quite > unlikely but still possible missequencing of messages. I think, you may want > to mention about a) and how it could provide a solution to cover all cases. > Actually maybe that type of message routing is something, which can be > included in a possible Diameter-bis document: "All Diameter nodes, which are > keeping session state SHOULD send requests belonging to the same session to > the same next hop unless htere is a failure." maybe should change the other part also,because RFC Diameter,the request route process should change. last time is base on Destination Host and Destination Realm.now should base on next hop. because one node cannot assure which all node in session path been stateful or not. so should only give one solution cover both situations. i also agree with you,this solution is application independent. Regards Tony ----- Original Message ----- From: "Tolga Asveren" To: "Victor Fajardo" Cc: "Tony Zhang" ; Sent: Friday, June 30, 2006 4:17 AM Subject: RE: [Dime] Comments for draft-tsou-dime-base-routing-ext > Hi Victor, > > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: Thursday, June 29, 2006 10:17 AM > > To: Tolga Asveren > > Cc: Tony Zhang; dime@ietf.org > > Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext > > > > > > Hi Tolga, > > > > Comments inline: > > > Hi Victor, Tony, > > > > > > The issue of routing where proxies are involved is an interesting one. I > > > don't know how it is supposed to work but I will try to explain my > > > opinion -which is more a collection of questions- about this topic. > > > > > > If we consider the example provided by Victor, I can think of > > two different > > > ways of doing it(similar thing applies to the example presented in the > > > draft): > > > a)Clearinghouse proxy provides message routing and executes > > local policy but > > > does not terminate the session. It will be seen as > > proxy1.clearinghouse.com > > > from client point of view. > > > > > > b)Clearinghouse proxy terminates the session and actually proxies the > > > service provided. It will be seen as AAAserver1.providerB.com > > from client > > > point of view. > > > > > > The way application support is advertised hints slightly and > > implicitly to > > > b). Proxies do not advertise supported application/realm pairs > > in CER/CEA > > > but just the applications. The realm is implicitly identified by the > > > DiameterIdentity of the proxy. For example in the above > > example, there is no > > > way to tell for the clearinghouse proxy that it can't handle anymore > > > requests for b.com, if it is handling multiple realms and if a) is used. > > > With b), it can drop the connection from its AAAserver1.providerB.com > > > identity to clients. This won't effect that it is handling requests for > > > other realms, because clearinghouse proxy would assume > > different identities > > > for them and would have separate connections to clients. > > > > > > OTOH, b) would require that clearinghouse proxy assumes > > identity for each > > > realm, it is providing service for. I wouldn't think this would > > be a huge > > > problem but it probably is not desirable either. > > > > > > The definition of proxies in RFC3588 2.8.2 doesn't mention > > about application > > > level proxying. > > > > > In general, the above scenarios you describe will work. However, I'm > > guessing that it assumes that there is only one single AAA proxy in the > > clearing house which will manage all sessions for all visited domains. > > In normal deployments, there will most likely be more than one of these > > proxies for scalability purposes and flexibility in the topology. So I > > think the draft attempts to solve a slightly different issue. As an > > example, if we do have multiple proxies in the clearing house and there > > is a relay in between the proxies and visited domains which routes > > messages based on some scaling policy but independent of the sessions > > then the problem statement in the draft holds true. > [TOLGA]I agree with that. Initally I thought why do we need such a > mechanism, if proxies involved are already stateful. The answer is existence > of stateles intermediares, i.e. relay agents. IMO there are two different > situations: > a)All intermediares on the path are stateful > b)At least one intermediary in the path is stateless. > > For a), I believe there is a relatively easy solution, which does not > require protocol involvement: All nodes send messages belonging to the saem > session to the same peer. I know this is not mandated in RFC3588 -at least I > > don't recall it being mandated somewhere-. OTOH, I believe it is common > sense to do so and is useful. It would help to prevent some probbaly quite > unlikely but still possible missequencing of messages. I think, you may want > to mention about a) and how it could provide a solution to cover all cases. > Actually maybe that type of message routing is something, which can be > included in a possible Diameter-bis document: "All Diameter nodes, which are > keeping session state SHOULD send requests belonging to the same session to > the same next hop unless htere is a failure." > > > > > > >From architectural point of view, I like the idea that > > Diameter base message > > > routing is not affected by the specific needs of applications, > > i.e. if there > > > is a need to traverse specific nodes, which have semantical application > > > processing, this should be handled by proxying the service, > > where each such > > > proxy decides for the next hop based on application logic (kind > > of like an > > > overlay application specific network if I may say so). > > I agree with you and the draft does not mandate changes to the base > > protocol routing that affects any and all proxies. I think this is why > > the routing scheme in the draft is bounded to an application's sessions. > > In such a case, the routing scheme is will be based on the requirements > > of the application and the proxy services that supports them as you have > > mentioned. It would then be the responsibility of the applications to > > manage destination-host/destination-realm and the draft simply proposes > > a generic method for applications to accomplish this. > > > > > IMO, the analogy is > > > that IP routing is not effected by the needs of application level > > > necessities, e.g. it is the application entity which populates > > the correct > > > IP address, if there is a need to traverse a specific set of application > > > nodes. To me, Diameter base protocol (RFC3588 - > > Authentication/Authorization > > > application defined in RFC3588) is a network layer protocol. > > Relay agents > > > are similar to routers in IP networks but IMHO any type of proxying is > > > better handled on application layer. > > > > > To extend your IP analogy, the proposed scheme would be similar to IP > > strict source routing. > > > > many thanks, > > victor > > > > > I don't know, which one of those models is the one, Diameter > > authors had in > > > mind for such scenarios, just I hope by considering all > > pros/contras we can > > > clarify -and if necessary fix- this thing. > > > > > > Thanks, > > > Tolga > > > > > > > > > > > >> -----Original Message----- > > >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > >> Sent: Tuesday, June 27, 2006 10:43 AM > > >> To: Tolga Asveren > > >> Cc: Tony Zhang; dime@ietf.org > > >> Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext > > >> > > >> > > >> Hi Tolga, > > >> > > >> Thanks for your review. > > >> > > >>> Hi Tolga: > > >>> In my understand, AAA Proxy in visited network,AAA server > > >>> > > >> in home network.so both nodes belong to different realm. > > >> > > >>> when AN Send message, the destination Realm should address to > > >>> > > >> AAA server not AAA Proxy.so AAA proxy should do routing, > > >> > > >>> AAA Proxy and AAA Server is belong to same session. > > >>> > > >>> > > >> I hope I'm describing this accurately but a further example maybe in > > >> terms of accounting exchanges where the visited domain (which may have > > >> its own AAA proxy) uses a clearing house (which in turn has its own AAA > > >> proxy in a different domain) prior to reaching the home domain. It's > > >> probably a more generic scenario which may help clarify the problem > > >> statement better than the 3gpp example. In some sense, the mechanism is > > >> similar to SIP Record-Route. > > >> > > >> hope this helps, > > >> victor > > >> > > >> > > >>> Regards! > > >>> Tony > > >>> > > >>> ----- Original Message ----- > > >>> From: "Tolga Asveren" > > >>> To: > > >>> Sent: Tuesday, June 27, 2006 3:49 AM > > >>> Subject: [Dime] Comments for draft-tsou-dime-base-routing-ext > > >>> > > >>> > > >>> > > >>> > > >>>> I have one comment/question regarding 1.1 in > > >>>> > > >> draft-tsou-dime-base-routing. > > >> > > >>>> The configuration described is as follows, AFAIU: > > >>>> > > >>>> WLAN 3GPP 3GPP > > >>>> AN --Wa-- AAA Proxy--Wd--Server > > >>>> > > >>>> I am not sure whether it is the correct view to consider 3GPP > > >>>> > > >> AAA Proxy as a > > >> > > >>>> proxy from Diameter base protocol point of view. It seems to > > >>>> > > >> me, it is more > > >> > > >>>> like a Diameter endpoint, which is acting as a proxy from 3GPP > > >>>> > > >> AAA service > > >> > > >>>> point of view, i.e. it would have two related sessions: one > > >>>> > > >> between WLAN AN > > >> > > >>>> and 3GPP AAA Proxy and the other one betweeen 3GPP Server > > and 3GPP AAA > > >>>> Proxy; it would provide interworking/bridging between those > > >>>> > > >> two session and > > >> > > >>>> probably would implement some local policy as well. AFAICS, this > > >>>> interpretation would solve the problem, the draft is trying to > > >>>> > > >> address in > > >> > > >>>> 1.1. Does this make sense or am I missing something completely? > > >>>> > > >>>> Thanks, > > >>>> Tolga > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> DiME mailing list > > >>>> DiME@ietf.org > > >>>> https://www1.ietf.org/mailman/listinfo/dime > > >>>> > > >>>> > > >>>> > > >>> _______________________________________________ > > >>> DiME mailing list > > >>> DiME@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/dime > > >>> > > >>> > > >>> > > >>> > > > > > > > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 30 07:39:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwHLi-0006ah-PZ; Fri, 30 Jun 2006 07:39:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwHLh-0006ac-Sk for dime@ietf.org; Fri, 30 Jun 2006 07:39:49 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwHLg-0005oB-DA for dime@ietf.org; Fri, 30 Jun 2006 07:39:49 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5UBdkge010968 for ; Fri, 30 Jun 2006 14:39:47 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 14:39:43 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 14:39:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Jun 2006 14:39:43 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DiME Agenda at IETF 66 Thread-Index: AcacOeCcjcZDBVNGTdaOcFi9cpAI1g== From: To: X-OriginalArrivalTime: 30 Jun 2006 11:39:43.0522 (UTC) FILETIME=[E1655020:01C69C39] X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Dime] DiME Agenda at IETF 66 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is what I have so far. John DiME Working=20 IETF 66 Agenda Version 1 MONDAY, July 10, 2006 1740-1840 Afternoon Session III Room 515 OPS dime Diameter Maintenance and Extensions WG 1) Agenda Bashing - 5 minutes 2) Diameter Base issues - 30 minutes Open Issues TBA 15 minutes http://www.ietf.org/internet-drafts/draft-garcia-dime-aaa-uri-00.txt Miguel Garcia 10 m. 3) Diameter Mobie IPv6 application - 30 minutes draft-ietf-dime-mip6-integrated-00.txt draft-ietf-dime-mip6-split-00.txt 4) Diameter QoS work - 15 minutes http://tools.ietf.org/wg/dime/draft-tschofenig-dime-diameter-qos-00.txt TBA 5) New work - 30 minutes DCCA & BASE MIBs =20 http://tools.ietf.org/wg/dime/draft-zorn-dime-diameter-cc-app-mib-00.txt =20 http://tools.ietf.org/wg/dime/draft-zorn-dime-diameter-base-protocol-mib -00.txt Glenn Zorn http://www.ietf.org/internet-drafts/draft-tsou-dime-base-routing-ext Victor Fajardo 10 mins _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 30 08:46:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwIOA-0007IB-Mk; Fri, 30 Jun 2006 08:46:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwIO9-0007GE-5B for dime@ietf.org; Fri, 30 Jun 2006 08:46:25 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwIO8-00028k-Dd for dime@ietf.org; Fri, 30 Jun 2006 08:46:25 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 6D894D94B0; Fri, 30 Jun 2006 08:46:24 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5UCkLNn028790; Fri, 30 Jun 2006 08:46:22 -0400 (EDT) From: "Tolga Asveren" To: "Tony Zhang" , "Victor Fajardo" Subject: RE: [Dime] Comments for draft-tsou-dime-base-routing-ext Date: Fri, 30 Jun 2006 08:22:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <006701c69bed$7af85f90$3791460a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tony, > -----Original Message----- > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] > Sent: Thursday, June 29, 2006 10:33 PM > To: Tolga Asveren; Victor Fajardo > Cc: dime@ietf.org > Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext > > > Hi Tolga: > > [TOLGA]I agree with that. Initally I thought why do we need such a > > mechanism, if proxies involved are already stateful. The answer > is existence > > of stateles intermediares, i.e. relay agents. IMO there are two > different > > situations: > > a)All intermediares on the path are stateful > > b)At least one intermediary in the path is stateless. > > > > For a), I believe there is a relatively easy solution, which does not > > require protocol involvement: All nodes send messages belonging > to the saem > > session to the same peer. I know this is not mandated in > RFC3588 -at least I > > > > don't recall it being mandated somewhere-. OTOH, I believe it is common > > sense to do so and is useful. It would help to prevent some > probbaly quite > > unlikely but still possible missequencing of messages. I think, > you may want > > to mention about a) and how it could provide a solution to > cover all cases. > > Actually maybe that type of message routing is something, which can be > > included in a possible Diameter-bis document: "All Diameter > nodes, which are > > keeping session state SHOULD send requests belonging to the > same session to > > the same next hop unless htere is a failure." > > maybe should change the other part also,because RFC Diameter,the > request route process should change. > last time is base on Destination Host and Destination Realm.now > should base on next hop. [TOLGA]Just to prevent a confusion, my suggestion is not about changing anyhting in RFC3588 per se. RFC3588 does not mandate, how the next hop is selected if next hop is not the node identified by Destination-Host AVP. My proposal is only mentioning about a common-sense approach, which could be useful for certain configurations. > > because one node cannot assure which all node in session path > been stateful or not. > so should only give one solution cover both situations. [TOLGA]That I disagree. Topology may be known in advance based on agreement between different parties. I personally don't see much difference between saying "Your nodes should support Diameter Strict Source Routing extension" and "All your nodes should keep session state." Depending on situation one or another may be the preferrable solution. IMO, let's provide the tools, and let the people choose which tool is more suitable for their specific need. > > i also agree with you,this solution is application independent. > > Regards > Tony > ----- Original Message ----- > From: "Tolga Asveren" > To: "Victor Fajardo" > Cc: "Tony Zhang" ; > Sent: Friday, June 30, 2006 4:17 AM > Subject: RE: [Dime] Comments for draft-tsou-dime-base-routing-ext > > > > Hi Victor, > > > > > -----Original Message----- > > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > > Sent: Thursday, June 29, 2006 10:17 AM > > > To: Tolga Asveren > > > Cc: Tony Zhang; dime@ietf.org > > > Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext > > > > > > > > > Hi Tolga, > > > > > > Comments inline: > > > > Hi Victor, Tony, > > > > > > > > The issue of routing where proxies are involved is an > interesting one. I > > > > don't know how it is supposed to work but I will try to explain my > > > > opinion -which is more a collection of questions- about this topic. > > > > > > > > If we consider the example provided by Victor, I can think of > > > two different > > > > ways of doing it(similar thing applies to the example > presented in the > > > > draft): > > > > a)Clearinghouse proxy provides message routing and executes > > > local policy but > > > > does not terminate the session. It will be seen as > > > proxy1.clearinghouse.com > > > > from client point of view. > > > > > > > > b)Clearinghouse proxy terminates the session and actually > proxies the > > > > service provided. It will be seen as AAAserver1.providerB.com > > > from client > > > > point of view. > > > > > > > > The way application support is advertised hints slightly and > > > implicitly to > > > > b). Proxies do not advertise supported application/realm pairs > > > in CER/CEA > > > > but just the applications. The realm is implicitly identified by the > > > > DiameterIdentity of the proxy. For example in the above > > > example, there is no > > > > way to tell for the clearinghouse proxy that it can't handle anymore > > > > requests for b.com, if it is handling multiple realms and > if a) is used. > > > > With b), it can drop the connection from its > AAAserver1.providerB.com > > > > identity to clients. This won't effect that it is handling > requests for > > > > other realms, because clearinghouse proxy would assume > > > different identities > > > > for them and would have separate connections to clients. > > > > > > > > OTOH, b) would require that clearinghouse proxy assumes > > > identity for each > > > > realm, it is providing service for. I wouldn't think this would > > > be a huge > > > > problem but it probably is not desirable either. > > > > > > > > The definition of proxies in RFC3588 2.8.2 doesn't mention > > > about application > > > > level proxying. > > > > > > > In general, the above scenarios you describe will work. However, I'm > > > guessing that it assumes that there is only one single AAA > proxy in the > > > clearing house which will manage all sessions for all visited domains. > > > In normal deployments, there will most likely be more than > one of these > > > proxies for scalability purposes and flexibility in the topology. So I > > > think the draft attempts to solve a slightly different issue. As an > > > example, if we do have multiple proxies in the clearing house > and there > > > is a relay in between the proxies and visited domains which routes > > > messages based on some scaling policy but independent of the sessions > > > then the problem statement in the draft holds true. > > [TOLGA]I agree with that. Initally I thought why do we need such a > > mechanism, if proxies involved are already stateful. The answer > is existence > > of stateles intermediares, i.e. relay agents. IMO there are two > different > > situations: > > a)All intermediares on the path are stateful > > b)At least one intermediary in the path is stateless. > > > > For a), I believe there is a relatively easy solution, which does not > > require protocol involvement: All nodes send messages belonging > to the saem > > session to the same peer. I know this is not mandated in > RFC3588 -at least I > > > > don't recall it being mandated somewhere-. OTOH, I believe it is common > > sense to do so and is useful. It would help to prevent some > probbaly quite > > unlikely but still possible missequencing of messages. I think, > you may want > > to mention about a) and how it could provide a solution to > cover all cases. > > Actually maybe that type of message routing is something, which can be > > included in a possible Diameter-bis document: "All Diameter > nodes, which are > > keeping session state SHOULD send requests belonging to the > same session to > > the same next hop unless htere is a failure." > > > > > > > > > > > >From architectural point of view, I like the idea that > > > Diameter base message > > > > routing is not affected by the specific needs of applications, > > > i.e. if there > > > > is a need to traverse specific nodes, which have semantical > application > > > > processing, this should be handled by proxying the service, > > > where each such > > > > proxy decides for the next hop based on application logic (kind > > > of like an > > > > overlay application specific network if I may say so). > > > I agree with you and the draft does not mandate changes to the base > > > protocol routing that affects any and all proxies. I think this is why > > > the routing scheme in the draft is bounded to an > application's sessions. > > > In such a case, the routing scheme is will be based on the > requirements > > > of the application and the proxy services that supports them > as you have > > > mentioned. It would then be the responsibility of the applications to > > > manage destination-host/destination-realm and the draft > simply proposes > > > a generic method for applications to accomplish this. > > > > > > > IMO, the analogy is > > > > that IP routing is not effected by the needs of application level > > > > necessities, e.g. it is the application entity which populates > > > the correct > > > > IP address, if there is a need to traverse a specific set > of application > > > > nodes. To me, Diameter base protocol (RFC3588 - > > > Authentication/Authorization > > > > application defined in RFC3588) is a network layer protocol. > > > Relay agents > > > > are similar to routers in IP networks but IMHO any type of > proxying is > > > > better handled on application layer. > > > > > > > To extend your IP analogy, the proposed scheme would be similar to IP > > > strict source routing. > > > > > > many thanks, > > > victor > > > > > > > I don't know, which one of those models is the one, Diameter > > > authors had in > > > > mind for such scenarios, just I hope by considering all > > > pros/contras we can > > > > clarify -and if necessary fix- this thing. > > > > > > > > Thanks, > > > > Tolga > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > > >> Sent: Tuesday, June 27, 2006 10:43 AM > > > >> To: Tolga Asveren > > > >> Cc: Tony Zhang; dime@ietf.org > > > >> Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext > > > >> > > > >> > > > >> Hi Tolga, > > > >> > > > >> Thanks for your review. > > > >> > > > >>> Hi Tolga: > > > >>> In my understand, AAA Proxy in visited network,AAA server > > > >>> > > > >> in home network.so both nodes belong to different realm. > > > >> > > > >>> when AN Send message, the destination Realm should address to > > > >>> > > > >> AAA server not AAA Proxy.so AAA proxy should do routing, > > > >> > > > >>> AAA Proxy and AAA Server is belong to same session. > > > >>> > > > >>> > > > >> I hope I'm describing this accurately but a further > example maybe in > > > >> terms of accounting exchanges where the visited domain > (which may have > > > >> its own AAA proxy) uses a clearing house (which in turn > has its own AAA > > > >> proxy in a different domain) prior to reaching the home > domain. It's > > > >> probably a more generic scenario which may help clarify the problem > > > >> statement better than the 3gpp example. In some sense, the > mechanism is > > > >> similar to SIP Record-Route. > > > >> > > > >> hope this helps, > > > >> victor > > > >> > > > >> > > > >>> Regards! > > > >>> Tony > > > >>> > > > >>> ----- Original Message ----- > > > >>> From: "Tolga Asveren" > > > >>> To: > > > >>> Sent: Tuesday, June 27, 2006 3:49 AM > > > >>> Subject: [Dime] Comments for draft-tsou-dime-base-routing-ext > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>> I have one comment/question regarding 1.1 in > > > >>>> > > > >> draft-tsou-dime-base-routing. > > > >> > > > >>>> The configuration described is as follows, AFAIU: > > > >>>> > > > >>>> WLAN 3GPP 3GPP > > > >>>> AN --Wa-- AAA Proxy--Wd--Server > > > >>>> > > > >>>> I am not sure whether it is the correct view to consider 3GPP > > > >>>> > > > >> AAA Proxy as a > > > >> > > > >>>> proxy from Diameter base protocol point of view. It seems to > > > >>>> > > > >> me, it is more > > > >> > > > >>>> like a Diameter endpoint, which is acting as a proxy from 3GPP > > > >>>> > > > >> AAA service > > > >> > > > >>>> point of view, i.e. it would have two related sessions: one > > > >>>> > > > >> between WLAN AN > > > >> > > > >>>> and 3GPP AAA Proxy and the other one betweeen 3GPP Server > > > and 3GPP AAA > > > >>>> Proxy; it would provide interworking/bridging between those > > > >>>> > > > >> two session and > > > >> > > > >>>> probably would implement some local policy as well. AFAICS, this > > > >>>> interpretation would solve the problem, the draft is trying to > > > >>>> > > > >> address in > > > >> > > > >>>> 1.1. Does this make sense or am I missing something completely? > > > >>>> > > > >>>> Thanks, > > > >>>> Tolga > > > >>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> DiME mailing list > > > >>>> DiME@ietf.org > > > >>>> https://www1.ietf.org/mailman/listinfo/dime > > > >>>> > > > >>>> > > > >>>> > > > >>> _______________________________________________ > > > >>> DiME mailing list > > > >>> DiME@ietf.org > > > >>> https://www1.ietf.org/mailman/listinfo/dime > > > >>> > > > >>> > > > >>> > > > >>> > > > > > > > > > > > > > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 30 10:33:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwK49-00066m-Oi; Fri, 30 Jun 2006 10:33:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwK48-00066F-VQ for dime@ietf.org; Fri, 30 Jun 2006 10:33:52 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FwK45-00024x-HY for dime@ietf.org; Fri, 30 Jun 2006 10:33:52 -0400 Received: (qmail invoked by alias); 30 Jun 2006 14:33:48 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp005) with SMTP; 30 Jun 2006 16:33:48 +0200 X-Authenticated: #29516787 Message-ID: <44A5364A.8050700@gmx.net> Date: Fri, 30 Jun 2006 16:33:46 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Dime] RFC 3588bis Issue Tracker X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, we got the impression that it would be good to create a separate issue tracker for RFC3588bis issues. You can find the issue tracker here: http://www.tschofenig.priv.at:8080/rfc3588bis We will also use it to collect text proposals. Some of the issues captured during the Diameter interop event (see http://www.tschofenig.priv.at:8080/diameter-interop ) will be moved to the new issue tracker. Ciao Hannes & John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 30 11:44:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLAZ-0005fo-64; Fri, 30 Jun 2006 11:44:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLAX-0005eZ-7Z for dime@ietf.org; Fri, 30 Jun 2006 11:44:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwJAl-0006VC-Uh for dime@ietf.org; Fri, 30 Jun 2006 09:36:40 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FwJ0y-0005lL-6R for dime@ietf.org; Fri, 30 Jun 2006 09:26:34 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k5UDQIOJ097248; Fri, 30 Jun 2006 09:26:18 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44A5267A.1050505@tari.toshiba.com> Date: Fri, 30 Jun 2006 09:26:18 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Scan-Signature: 9aa22b77adc37e7d33e29644e4dc0b33 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi guys, >> >> maybe should change the other part also,because RFC Diameter,the >> request route process should change. >> last time is base on Destination Host and Destination Realm.now >> should base on next hop. >> > [TOLGA]Just to prevent a confusion, my suggestion is not about changing > anyhting in RFC3588 per se. RFC3588 does not mandate, how the next hop is > selected if next hop is not the node identified by Destination-Host AVP. My > proposal is only mentioning about a common-sense approach, which could be > useful for certain configurations. > Yes. I do not think there is a need to change the base protocol routing to accomodate the proposed scheme. This is why the scheme is application dependent. Note that for a single diameter node, not all the applications in that node can/should support this scheme so it should be transparent to base protocol routing. >> because one node cannot assure which all node in session path >> been stateful or not. >> so should only give one solution cover both situations. >> > [TOLGA]That I disagree. Topology may be known in advance based on agreement > between different parties. I personally don't see much difference between > saying "Your nodes should support Diameter Strict Source Routing extension" > and "All your nodes should keep session state." Depending on situation one > or another may be the preferrable solution. IMO, let's provide the tools, > and let the people choose which tool is more suitable for their specific > need. > I agree. regards, victor >> i also agree with you,this solution is application independent. >> >> Regards >> Tony >> ----- Original Message ----- >> From: "Tolga Asveren" >> To: "Victor Fajardo" >> Cc: "Tony Zhang" ; >> Sent: Friday, June 30, 2006 4:17 AM >> Subject: RE: [Dime] Comments for draft-tsou-dime-base-routing-ext >> >> >> >>> Hi Victor, >>> >>> >>>> -----Original Message----- >>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >>>> Sent: Thursday, June 29, 2006 10:17 AM >>>> To: Tolga Asveren >>>> Cc: Tony Zhang; dime@ietf.org >>>> Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext >>>> >>>> >>>> Hi Tolga, >>>> >>>> Comments inline: >>>> >>>>> Hi Victor, Tony, >>>>> >>>>> The issue of routing where proxies are involved is an >>>>> >> interesting one. I >> >>>>> don't know how it is supposed to work but I will try to explain my >>>>> opinion -which is more a collection of questions- about this topic. >>>>> >>>>> If we consider the example provided by Victor, I can think of >>>>> >>>> two different >>>> >>>>> ways of doing it(similar thing applies to the example >>>>> >> presented in the >> >>>>> draft): >>>>> a)Clearinghouse proxy provides message routing and executes >>>>> >>>> local policy but >>>> >>>>> does not terminate the session. It will be seen as >>>>> >>>> proxy1.clearinghouse.com >>>> >>>>> from client point of view. >>>>> >>>>> b)Clearinghouse proxy terminates the session and actually >>>>> >> proxies the >> >>>>> service provided. It will be seen as AAAserver1.providerB.com >>>>> >>>> from client >>>> >>>>> point of view. >>>>> >>>>> The way application support is advertised hints slightly and >>>>> >>>> implicitly to >>>> >>>>> b). Proxies do not advertise supported application/realm pairs >>>>> >>>> in CER/CEA >>>> >>>>> but just the applications. The realm is implicitly identified by the >>>>> DiameterIdentity of the proxy. For example in the above >>>>> >>>> example, there is no >>>> >>>>> way to tell for the clearinghouse proxy that it can't handle anymore >>>>> requests for b.com, if it is handling multiple realms and >>>>> >> if a) is used. >> >>>>> With b), it can drop the connection from its >>>>> >> AAAserver1.providerB.com >> >>>>> identity to clients. This won't effect that it is handling >>>>> >> requests for >> >>>>> other realms, because clearinghouse proxy would assume >>>>> >>>> different identities >>>> >>>>> for them and would have separate connections to clients. >>>>> >>>>> OTOH, b) would require that clearinghouse proxy assumes >>>>> >>>> identity for each >>>> >>>>> realm, it is providing service for. I wouldn't think this would >>>>> >>>> be a huge >>>> >>>>> problem but it probably is not desirable either. >>>>> >>>>> The definition of proxies in RFC3588 2.8.2 doesn't mention >>>>> >>>> about application >>>> >>>>> level proxying. >>>>> >>>>> >>>> In general, the above scenarios you describe will work. However, I'm >>>> guessing that it assumes that there is only one single AAA >>>> >> proxy in the >> >>>> clearing house which will manage all sessions for all visited domains. >>>> In normal deployments, there will most likely be more than >>>> >> one of these >> >>>> proxies for scalability purposes and flexibility in the topology. So I >>>> think the draft attempts to solve a slightly different issue. As an >>>> example, if we do have multiple proxies in the clearing house >>>> >> and there >> >>>> is a relay in between the proxies and visited domains which routes >>>> messages based on some scaling policy but independent of the sessions >>>> then the problem statement in the draft holds true. >>>> >>> [TOLGA]I agree with that. Initally I thought why do we need such a >>> mechanism, if proxies involved are already stateful. The answer >>> >> is existence >> >>> of stateles intermediares, i.e. relay agents. IMO there are two >>> >> different >> >>> situations: >>> a)All intermediares on the path are stateful >>> b)At least one intermediary in the path is stateless. >>> >>> For a), I believe there is a relatively easy solution, which does not >>> require protocol involvement: All nodes send messages belonging >>> >> to the saem >> >>> session to the same peer. I know this is not mandated in >>> >> RFC3588 -at least I >> >>> don't recall it being mandated somewhere-. OTOH, I believe it is common >>> sense to do so and is useful. It would help to prevent some >>> >> probbaly quite >> >>> unlikely but still possible missequencing of messages. I think, >>> >> you may want >> >>> to mention about a) and how it could provide a solution to >>> >> cover all cases. >> >>> Actually maybe that type of message routing is something, which can be >>> included in a possible Diameter-bis document: "All Diameter >>> >> nodes, which are >> >>> keeping session state SHOULD send requests belonging to the >>> >> same session to >> >>> the same next hop unless htere is a failure." >>> >> >>>>> >From architectural point of view, I like the idea that >>>>> >>>> Diameter base message >>>> >>>>> routing is not affected by the specific needs of applications, >>>>> >>>> i.e. if there >>>> >>>>> is a need to traverse specific nodes, which have semantical >>>>> >> application >> >>>>> processing, this should be handled by proxying the service, >>>>> >>>> where each such >>>> >>>>> proxy decides for the next hop based on application logic (kind >>>>> >>>> of like an >>>> >>>>> overlay application specific network if I may say so). >>>>> >>>> I agree with you and the draft does not mandate changes to the base >>>> protocol routing that affects any and all proxies. I think this is why >>>> the routing scheme in the draft is bounded to an >>>> >> application's sessions. >> >>>> In such a case, the routing scheme is will be based on the >>>> >> requirements >> >>>> of the application and the proxy services that supports them >>>> >> as you have >> >>>> mentioned. It would then be the responsibility of the applications to >>>> manage destination-host/destination-realm and the draft >>>> >> simply proposes >> >>>> a generic method for applications to accomplish this. >>>> >>>> >>>>> IMO, the analogy is >>>>> that IP routing is not effected by the needs of application level >>>>> necessities, e.g. it is the application entity which populates >>>>> >>>> the correct >>>> >>>>> IP address, if there is a need to traverse a specific set >>>>> >> of application >> >>>>> nodes. To me, Diameter base protocol (RFC3588 - >>>>> >>>> Authentication/Authorization >>>> >>>>> application defined in RFC3588) is a network layer protocol. >>>>> >>>> Relay agents >>>> >>>>> are similar to routers in IP networks but IMHO any type of >>>>> >> proxying is >> >>>>> better handled on application layer. >>>>> >>>>> >>>> To extend your IP analogy, the proposed scheme would be similar to IP >>>> strict source routing. >>>> >>>> many thanks, >>>> victor >>>> >>>> >>>>> I don't know, which one of those models is the one, Diameter >>>>> >>>> authors had in >>>> >>>>> mind for such scenarios, just I hope by considering all >>>>> >>>> pros/contras we can >>>> >>>>> clarify -and if necessary fix- this thing. >>>>> >>>>> Thanks, >>>>> Tolga >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >>>>>> Sent: Tuesday, June 27, 2006 10:43 AM >>>>>> To: Tolga Asveren >>>>>> Cc: Tony Zhang; dime@ietf.org >>>>>> Subject: Re: [Dime] Comments for draft-tsou-dime-base-routing-ext >>>>>> >>>>>> >>>>>> Hi Tolga, >>>>>> >>>>>> Thanks for your review. >>>>>> >>>>>> >>>>>>> Hi Tolga: >>>>>>> In my understand, AAA Proxy in visited network,AAA server >>>>>>> >>>>>>> >>>>>> in home network.so both nodes belong to different realm. >>>>>> >>>>>> >>>>>>> when AN Send message, the destination Realm should address to >>>>>>> >>>>>>> >>>>>> AAA server not AAA Proxy.so AAA proxy should do routing, >>>>>> >>>>>> >>>>>>> AAA Proxy and AAA Server is belong to same session. >>>>>>> >>>>>>> >>>>>>> >>>>>> I hope I'm describing this accurately but a further >>>>>> >> example maybe in >> >>>>>> terms of accounting exchanges where the visited domain >>>>>> >> (which may have >> >>>>>> its own AAA proxy) uses a clearing house (which in turn >>>>>> >> has its own AAA >> >>>>>> proxy in a different domain) prior to reaching the home >>>>>> >> domain. It's >> >>>>>> probably a more generic scenario which may help clarify the problem >>>>>> statement better than the 3gpp example. In some sense, the >>>>>> >> mechanism is >> >>>>>> similar to SIP Record-Route. >>>>>> >>>>>> hope this helps, >>>>>> victor >>>>>> >>>>>> >>>>>> >>>>>>> Regards! >>>>>>> Tony >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Tolga Asveren" >>>>>>> To: >>>>>>> Sent: Tuesday, June 27, 2006 3:49 AM >>>>>>> Subject: [Dime] Comments for draft-tsou-dime-base-routing-ext >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I have one comment/question regarding 1.1 in >>>>>>>> >>>>>>>> >>>>>> draft-tsou-dime-base-routing. >>>>>> >>>>>> >>>>>>>> The configuration described is as follows, AFAIU: >>>>>>>> >>>>>>>> WLAN 3GPP 3GPP >>>>>>>> AN --Wa-- AAA Proxy--Wd--Server >>>>>>>> >>>>>>>> I am not sure whether it is the correct view to consider 3GPP >>>>>>>> >>>>>>>> >>>>>> AAA Proxy as a >>>>>> >>>>>> >>>>>>>> proxy from Diameter base protocol point of view. It seems to >>>>>>>> >>>>>>>> >>>>>> me, it is more >>>>>> >>>>>> >>>>>>>> like a Diameter endpoint, which is acting as a proxy from 3GPP >>>>>>>> >>>>>>>> >>>>>> AAA service >>>>>> >>>>>> >>>>>>>> point of view, i.e. it would have two related sessions: one >>>>>>>> >>>>>>>> >>>>>> between WLAN AN >>>>>> >>>>>> >>>>>>>> and 3GPP AAA Proxy and the other one betweeen 3GPP Server >>>>>>>> >>>> and 3GPP AAA >>>> >>>>>>>> Proxy; it would provide interworking/bridging between those >>>>>>>> >>>>>>>> >>>>>> two session and >>>>>> >>>>>> >>>>>>>> probably would implement some local policy as well. AFAICS, this >>>>>>>> interpretation would solve the problem, the draft is trying to >>>>>>>> >>>>>>>> >>>>>> address in >>>>>> >>>>>> >>>>>>>> 1.1. Does this make sense or am I missing something completely? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tolga >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> DiME mailing list >>>>>>>> DiME@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/dime >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 30 17:07:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwQD9-0004cE-FT; Fri, 30 Jun 2006 17:07:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwQD8-0004c9-9O for dime@ietf.org; Fri, 30 Jun 2006 17:07:34 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwQD4-0000T2-1s for dime@ietf.org; Fri, 30 Jun 2006 17:07:34 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 3663F7D02A for ; Fri, 30 Jun 2006 17:07:29 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5UL7Q9Y011403 for ; Fri, 30 Jun 2006 17:07:28 -0400 (EDT) From: "Tolga Asveren" To: Date: Fri, 30 Jun 2006 16:43:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A5267A.1050505@tari.toshiba.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Dime] Comments for draft-tsou-dime-base-routing-ext -2- X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Should SRR-Originators need to be initiators of the corresponding session? This makes it mandatory to know at the message originator, whether there is an intermediary which wants to stay in the message path. This may not always be practical. I can see that it is necessary that client is strict-routing-aware, but that is different than it being SRR-Originator. Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 30 17:31:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwQaY-0003PN-Ji; Fri, 30 Jun 2006 17:31:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwQaW-0003PH-NH for dime@ietf.org; Fri, 30 Jun 2006 17:31:44 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwQaV-0000tN-EV for dime@ietf.org; Fri, 30 Jun 2006 17:31:44 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 654228C16B for ; Fri, 30 Jun 2006 17:31:43 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k5ULVgMd012364 for ; Fri, 30 Jun 2006 17:31:42 -0400 (EDT) From: "Tolga Asveren" To: Date: Fri, 30 Jun 2006 17:08:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Dime] yet another way of achieving strict routing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org While studying the mechanics of achiveing strict routing in draft-tsou-dime-base-routing-ext, the following came to my mind: 1) Requests are sent by client regularly 2) Stateless intermediaries just relay the message 3) If an intermediary wants to stay in the path for a session, it does the following with the messages for that session: i- For the first answer, it saves the Origin-Host/Origin-Realm AVP values in the message and replaces them with its own Host/Realm values. ii- Subsequent requests received by this intermediary will have its Host/Realm value in Destination-Host/Destination-Realm AVPs of the request. They are replaced with the values stored in i-. Considering that proxies which want to stay on the path will be stateful, 3) shouldn't be a problem. This is very similar to what is explained in the draft, except the state is kept in proxies rather than in the message. Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime