From allcommunity@0451.com Tue Jul 11 12:32:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0LAL-0004ZV-7C for aaa-archive@lists.ietf.org; Tue, 11 Jul 2006 12:32:53 -0400 Received: from host186-73.pool8291.interbusiness.it ([82.91.73.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0LAJ-00059Z-Qo for aaa-archive@lists.ietf.org; Tue, 11 Jul 2006 12:32:53 -0400 Date: Tue, 11 Jul 2006 16:32:50 -0060 From: "Sherrie Baxter" X-Mailer: The Bat! (v3.0.1 RC4) Home Reply-To: "Sherrie Baxter" X-Priority: 3 (Normal) Message-ID: <219560274.20060711163250@0451.com> To: aaa-archive@lists.ietf.org Subject: 0D6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 and they still don't catch on. I stabbed the ashtray with my cigarette butt. quietly with them all, exhorting them never to stop their learning and "Do you remember the story of Hansel and Gretel? Studied it in school? "Oh, Fletch, you don't love that! You don't love hatred and evil, of From 2Cacn4qe1q@mail.ru Wed Jul 12 04:04:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ZiJ-0000z0-0E for aaa-archive@lists.ietf.org; Wed, 12 Jul 2006 04:04:55 -0400 Received: from aib6.internetdsl.tpnet.pl ([83.16.209.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0ZiF-0006Vx-JB for aaa-archive@lists.ietf.org; Wed, 12 Jul 2006 04:04:54 -0400 Date: Wed, 12 Jul 2006 08:03:59 -0060 From: "Annabelle Weaver" X-Mailer: The Bat! (v3.01 RC8) Professional Reply-To: "Annabelle Weaver" X-Priority: 3 (Normal) Message-ID: <8598714850.20060712080359@mail.ru> To: aaa-archive@lists.ietf.org Subject: CF2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 whatever I reach first. I'll apologize now. For example, Mr. Tender, if I that? What does it feel like? How far can you go?" last nut onto the asphalt. his truth in the face of the Flock. And the more Jonathan practiced his From owner-aaa-wg@merit.edu Wed Jul 12 13:22:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iPQ-00070U-Tk for aaa-archive@lists.ietf.org; Wed, 12 Jul 2006 13:22:00 -0400 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0iPP-0007j0-Iw for aaa-archive@lists.ietf.org; Wed, 12 Jul 2006 13:22:00 -0400 Received: by trapdoor.merit.edu (Postfix) id 3FF6C91235; Wed, 12 Jul 2006 13:21:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B86C912BC; Wed, 12 Jul 2006 13:21:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D32B191235 for ; Wed, 12 Jul 2006 13:21:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C29725828D; Wed, 12 Jul 2006 13:21:48 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from fiji.merit.edu (fiji.merit.edu [198.108.1.12]) by segue.merit.edu (Postfix) with ESMTP id 83AA458288 for ; Wed, 12 Jul 2006 13:21:48 -0400 (EDT) Received: by fiji.merit.edu (Postfix) id 689BC186F; Wed, 12 Jul 2006 13:21:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fiji.merit.edu ([127.0.0.1]) by localhost (fiji.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18857-06 for ; Wed, 12 Jul 2006 13:21:48 -0400 (EDT) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by fiji.merit.edu (Postfix) with ESMTP id 08C86186C for ; Wed, 12 Jul 2006 13:21:47 -0400 (EDT) Received: from c-24-16-73-85.hsd1.wa.comcast.net ([24.16.73.85] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1G0iPC-000Efk-V3 for aaa-wg@merit.edu; Wed, 12 Jul 2006 13:21:47 -0400 Received: by internaut.com (Postfix, from userid 1000) id 1014B6FE38; Wed, 12 Jul 2006 10:21:46 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.73.85 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 12 Jul 2006 10:21:45 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: RFC 4590 on RADIUS Extension for Digest Authentication (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at merit.edu Sender: owner-aaa-wg@merit.edu Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 A new Request for Comments is now available in online RFC libraries. RFC 4590 Title: RADIUS Extension for Digest Authentication Author: B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck Status: Standards Track Date: July 2006 Mailbox: baruch@kayote.com, dscreat@dscreat.com, david@kayote.com, dwilli@cisco.com, beckw@t-systems.com Pages: 32 Characters: 67181 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-radext-digest-auth-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4590.txt This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [STANDARDS TRACK] This document is a product of the RADIUS EXTensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute From owner-aaa-wg@merit.edu Thu Jul 20 05:12:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3UaJ-0005WL-HX for aaa-archive@lists.ietf.org; Thu, 20 Jul 2006 05:12:43 -0400 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3UUr-0002Iy-9s for aaa-archive@lists.ietf.org; Thu, 20 Jul 2006 05:07:07 -0400 Received: by trapdoor.merit.edu (Postfix) id E32F491209; Thu, 20 Jul 2006 05:06:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AEC709120E; Thu, 20 Jul 2006 05:06:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F27D091209 for ; Thu, 20 Jul 2006 05:06:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DDCAF58293; Thu, 20 Jul 2006 05:06:53 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from fiji.merit.edu (fiji.merit.edu [198.108.1.12]) by segue.merit.edu (Postfix) with ESMTP id CA26358280 for ; Thu, 20 Jul 2006 05:06:53 -0400 (EDT) Received: by fiji.merit.edu (Postfix) id AD99B17A2; Thu, 20 Jul 2006 05:06:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fiji.merit.edu ([127.0.0.1]) by localhost (fiji.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14583-09 for ; Thu, 20 Jul 2006 05:06:53 -0400 (EDT) X-Greylist: delayed 428 seconds by postgrey-1.21 at fiji.merit.edu; Thu, 20 Jul 2006 05:06:51 EDT Received: from inoavrex07.ptin.corpPT.com (mail2.ptinovacao.pt [194.65.138.21]) by fiji.merit.edu (Postfix) with ESMTP id C5E7A58C for ; Thu, 20 Jul 2006 05:06:51 -0400 (EDT) Received: from INOAVREX05.ptin.corpPT.com ([10.112.15.68]) by inoavrex07.ptin.corpPT.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 09:58:07 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6ABDA.D372E7A0" Subject: [AAA-WG]: Diameter redirect X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 20 Jul 2006 09:59:35 +0100 Message-ID: <75D349FBF7C131408F5061B7168072C30332A1BA@INOAVREX06.ptin.corpPT.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter redirect Thread-Index: Acar2tMLs7EqoM5IRJqZlhX6BMOOBw== From: "Paulo Rolo" To: X-OriginalArrivalTime: 20 Jul 2006 08:58:07.0078 (UTC) FILETIME=[9E206060:01C6ABDA] X-Virus-Scanned: amavisd-new at merit.edu Sender: owner-aaa-wg@merit.edu Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6ABDA.D372E7A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 We are currently developing a set of Diameter interfaces and some doubts = have arise, concerning SLF usage. =20 On ETSI TS 123 228 (IP Multimedia Subsystem (IMS)) at section 5.8.1 = (User identity to HSS resolution) it is suggested that a Public User = Identity should be selected and used as input to SLF_QUERY, in order to = resolve to the correct HSS name.=20 =20 Also at section 6.1.2 (S-CSCF registration/deregistration notification) = of TS 129 228 (IP Multimedia (IM) Subsystem Cx and Dx Interfaces), it is = suggested that if Routing Information is not available for SAR (S-CSCF = registration/deregistration), it should be routed to next diameter node, = for example SLF. =20 =20 The issue is that on TS 129 229 (Cx and Dx interfaces based on the = Diameter protocol) at section 6.1.3 (Server-Assignment-Request (SAR) = Command) the Public-Identity is presented as an optional attribute. If = it is not present how should be SLF_QUERY performed? All the other = messages (UAR, LIR, MAR) have Public-Identity as mandatory. =20 =20 Thanks in advance, Paulo Rolo =20 Network and Protocols Unit Intelligent Networks Department Portugal Telecom Inova=E7=E3o, S.A =20 ------_=_NextPart_001_01C6ABDA.D372E7A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

We are currently = developing a set of Diameter interfaces and some doubts have arise, concerning SLF = usage.

 

On ETSI TS 123 228 = (IP Multimedia Subsystem (IMS)) at section 5.8.1 (User identity to HSS = resolution) it is suggested that a Public User Identity should be selected and used = as input to SLF_QUERY, in order to resolve to the correct HSS name. =

 

Also at section = 6.1.2 (S-CSCF registration/deregistration notification) of TS 129 228 (IP = Multimedia (IM) Subsystem Cx and Dx Interfaces), it is suggested that if Routing Information is not available for SAR (S-CSCF = registration/deregistration), it should be routed to next diameter node, for example SLF.=A0 =

 

The issue is that = on TS 129 229 (Cx and Dx interfaces based on the Diameter protocol) at section = 6.1.3 (Server-Assignment-Request (SAR) Command) the Public-Identity is = presented as an optional attribute. If it is not present how should be SLF_QUERY = performed? All the other messages (UAR, LIR, MAR) have Public-Identity as = mandatory.

 

 

Thanks in = advance,

Paulo = Rolo

 

Network and = Protocols Unit

Intelligent = Networks Department

Portugal Telecom Inova=E7=E3o, S.A

 

------_=_NextPart_001_01C6ABDA.D372E7A0-- From owner-aaa-wg@merit.edu Thu Jul 20 08:10:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3XMc-0000cH-Tj for aaa-archive@lists.ietf.org; Thu, 20 Jul 2006 08:10: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 1G3UwH-0004is-Rz for aaa-archive@lists.ietf.org; Thu, 20 Jul 2006 05:35:25 -0400 Received: from trapdoor.merit.edu ([198.108.1.26]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3Uqb-0006qn-1E for aaa-archive@lists.ietf.org; Thu, 20 Jul 2006 05:29:34 -0400 Received: by trapdoor.merit.edu (Postfix) id E802F9120E; Thu, 20 Jul 2006 05:29:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3A2891223; Thu, 20 Jul 2006 05:29:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 462EA9120E for ; Thu, 20 Jul 2006 05:29:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 358A258293; Thu, 20 Jul 2006 05:29:21 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from fiji.merit.edu (fiji.merit.edu [198.108.1.12]) by segue.merit.edu (Postfix) with ESMTP id D609B58280 for ; Thu, 20 Jul 2006 05:29:20 -0400 (EDT) Received: by fiji.merit.edu (Postfix) id B974417A2; Thu, 20 Jul 2006 05:29:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fiji.merit.edu ([127.0.0.1]) by localhost (fiji.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14996-07 for ; Thu, 20 Jul 2006 05:29:20 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by fiji.merit.edu (Postfix) with ESMTP id 1933ACF0 for ; Thu, 20 Jul 2006 05:29:19 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id m3so711565ugc for ; Thu, 20 Jul 2006 02:29:17 -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=WhU1sGG43kQ4/t8k98MfZE+qKMvG5/QtfUaAvBuR0kf2GeHns5CFWpDME4vye1M+B6kU0XBl4PYfGz45M6XZvepbplB45GOd1ksYcuiIgeR8QwYT2ZtFNaei+9JEyT1erdTF0CA5cej9an1Smmckt9mHknH6BnvkiuTGR4ydOD8= Received: by 10.67.101.10 with SMTP id d10mr1703747ugm; Thu, 20 Jul 2006 02:29:17 -0700 (PDT) Received: by 10.66.249.18 with HTTP; Thu, 20 Jul 2006 02:29:17 -0700 (PDT) Message-ID: <5be720c40607200229j461057bfxe256b89dfdeced0@mail.gmail.com> Date: Thu, 20 Jul 2006 14:59:17 +0530 From: "Monal Sengar" To: aaa-wg@merit.edu Subject: [AAA-WG]: Realm table updation in Diameter MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_109181_2255856.1153387757219" X-Virus-Scanned: amavisd-new at merit.edu Sender: owner-aaa-wg@merit.edu Precedence: bulk X-Spam-Score: -2.4 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 ------=_Part_109181_2255856.1153387757219 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, When we recieve exchange CER and CEA with statically configured peer , do we need to update the realm routing table. In our realm routing table we are maintaining the mapping of application id and supported host ids for particular realm entry.e.g [example.net] 0x01 = server.example.net 0x02 = server.example.net This means that in realm example.net we have host id server.example.netwhich supports applicaiton id 0x01 and 0x02 Now , suppose due to some reason the Peer server.example.net doesnot wish to advertise both the applicaiton Ids and it sends only applicaiton Id 0x01 in CEA. So do we need to update the realm table every time we exchange CER and CEA with statically configured peers? Thanks and Regards Monal ------=_Part_109181_2255856.1153387757219 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,

When we recieve exchange CER and CEA with statically configured peer , do we need to update the realm routing table.
In our realm routing table we are maintaining the mapping of application id and supported host ids for particular realm entry.e.g

[example.net]
0x01 = server.example.net
0x02 = server.example.net
This means that in realm example.net we have host id server.example.net which supports applicaiton id 0x01 and 0x02

Now , suppose due to some reason the Peer server.example.net doesnot wish to advertise both the applicaiton Ids and it sends only applicaiton Id 0x01 in CEA. So do we need to update the realm table every time we exchange CER and CEA with statically configured peers?

Thanks and Regards
Monal

------=_Part_109181_2255856.1153387757219-- From owner-aaa-wg@merit.edu Thu Jul 20 10:00:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Z4x-0001Z4-BR for aaa-archive@lists.ietf.org; Thu, 20 Jul 2006 10:00:39 -0400 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Z4w-0001yj-3P for aaa-archive@lists.ietf.org; Thu, 20 Jul 2006 10:00:39 -0400 Received: by trapdoor.merit.edu (Postfix) id 90E4A9122B; Thu, 20 Jul 2006 10:00:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5249291260; Thu, 20 Jul 2006 10:00:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 090DE9122B for ; Thu, 20 Jul 2006 10:00:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 61D7258293; Thu, 20 Jul 2006 10:00:11 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from fiji.merit.edu (fiji.merit.edu [198.108.1.12]) by segue.merit.edu (Postfix) with ESMTP id 4036758280 for ; Thu, 20 Jul 2006 10:00:11 -0400 (EDT) Received: by fiji.merit.edu (Postfix) id 239E517A2; Thu, 20 Jul 2006 10:00:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fiji.merit.edu ([127.0.0.1]) by localhost (fiji.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19031-01 for ; Thu, 20 Jul 2006 10:00:10 -0400 (EDT) X-Greylist: delayed 433 seconds by postgrey-1.21 at fiji.merit.edu; Thu, 20 Jul 2006 10:00:10 EDT Received: from hu-out-0102.google.com (hu-out-0102.google.com [72.14.214.203]) by fiji.merit.edu (Postfix) with ESMTP id 63459CF0 for ; Thu, 20 Jul 2006 10:00:10 -0400 (EDT) Received: by hu-out-0102.google.com with SMTP id 34so252059hui for ; Thu, 20 Jul 2006 07:00:09 -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=sdistJ6nMW33nx9dRTFxvnsYNhM71QScQHKxxGKObkbcpfm1+sRbaTeaA6nLWSFC7iKkXnOaF1e3hqrXp/p9diopprFNo3PbpvkvnZUU3zNnQ3wA1lRyXNe/zizGDGytOLySRt3U56y9zY3rAqJEDWSdfvm87UElUnvZ5IH780o= Received: by 10.67.29.12 with SMTP id g12mr1941361ugj; Thu, 20 Jul 2006 06:52:56 -0700 (PDT) Received: by 10.66.249.18 with HTTP; Thu, 20 Jul 2006 06:52:56 -0700 (PDT) Message-ID: <5be720c40607200652y7f413615m14e675e75a47a1c4@mail.gmail.com> Date: Thu, 20 Jul 2006 19:22:56 +0530 From: "Monal Sengar" To: aaa-wg@merit.edu Subject: [AAA-WG]: Request Forwarding MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_113688_17087881.1153403576145" X-Virus-Scanned: amavisd-new at merit.edu Sender: owner-aaa-wg@merit.edu Precedence: bulk X-Spam-Score: 2.0 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ------=_Part_113688_17087881.1153403576145 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, Is Request Forwarding (Ref sec 6.1.5 RFC 3588) a relay functionality? If we are supporting only peer to peer diameter and not the intermediate nodes (agents) then do we need to implement request forwarding. Thanks and Regards Monal ------=_Part_113688_17087881.1153403576145 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,

Is Request Forwarding (Ref sec 6.1.5 RFC 3588) a relay functionality?
If we are supporting only peer to peer diameter and not the intermediate nodes (agents) then do we need to implement request forwarding.

Thanks and Regards
Monal
------=_Part_113688_17087881.1153403576145-- From owner-aaa-wg@merit.edu Thu Jul 20 10:57:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ZyR-0006Re-H7 for aaa-archive@lists.ietf.org; Thu, 20 Jul 2006 10:57:59 -0400 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ZyF-0006oL-Gb for aaa-archive@lists.ietf.org; Thu, 20 Jul 2006 10:57:48 -0400 Received: by trapdoor.merit.edu (Postfix) id 05FC59121F; Thu, 20 Jul 2006 10:57:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9C7B91256; Thu, 20 Jul 2006 10:57:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 37BA49121F for ; Thu, 20 Jul 2006 10:57:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1BA5558296; Thu, 20 Jul 2006 10:57:37 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from fiji.merit.edu (fiji.merit.edu [198.108.1.12]) by segue.merit.edu (Postfix) with ESMTP id C9DDB58280 for ; Thu, 20 Jul 2006 10:57:36 -0400 (EDT) Received: by fiji.merit.edu (Postfix) id A666017A7; Thu, 20 Jul 2006 10:57:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fiji.merit.edu ([127.0.0.1]) by localhost (fiji.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20193-04; Thu, 20 Jul 2006 10:57:36 -0400 (EDT) X-Greylist: delayed 439 seconds by postgrey-1.21 at fiji.merit.edu; Thu, 20 Jul 2006 10:57:36 EDT Received: from mail47.messagelabs.com (mail47.messagelabs.com [216.82.240.163]) by fiji.merit.edu (Postfix) with SMTP id 20782CF0; Thu, 20 Jul 2006 10:57:36 -0400 (EDT) X-VirusChecked: Checked X-Env-Sender: Srinivas.Mylavarapu@lntinfotech.com X-Msg-Ref: server-22.tower-47.messagelabs.com!1153407013!31932377!1 X-StarScan-Version: 5.5.10.7; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 2861 invoked from network); 20 Jul 2006 14:50:14 -0000 Received: from bangaloresmtp.lntinfotech.com (HELO Bangaloresmtp.lntinfotech.com) (203.101.96.4) by server-22.tower-47.messagelabs.com with SMTP; 20 Jul 2006 14:50:14 -0000 Received: from Bangalore.lntinfotech.com ([172.28.0.3]) by Bangaloresmtp.lntinfotech.com (Lotus Domino Release 6.5.4) with ESMTP id 2006072020201290-20716 ; Thu, 20 Jul 2006 20:20:12 +0530 In-Reply-To: <5be720c40607200652y7f413615m14e675e75a47a1c4@mail.gmail.com> Subject: Re: [AAA-WG]: Request Forwarding To: "Monal Sengar" Cc: aaa-wg@merit.edu, owner-aaa-wg@merit.edu X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: Srinivas Mylavarapu Date: Thu, 20 Jul 2006 20:20:11 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 6.5.5|November 30, 2005) at 07/20/2006 08:20:10 PM, Itemize by SMTP Server on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 07/20/2006 08:20:12 PM, Serialize by Router on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 07/20/2006 08:20:16 PM, Serialize complete at 07/20/2006 08:20:16 PM Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: amavisd-new at merit.edu Sender: owner-aaa-wg@merit.edu Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Monal, 'Request Forwarding' is nothing but relay functionality. If your node need not support 'Relay functionality' there is no need to implement it. Warm Regards Srini "Monal Sengar" To Sent by: aaa-wg@merit.edu owner-aaa-wg@meri cc t.edu Subject [AAA-WG]: Request Forwarding 07/20/2006 07:22 PM Hello, Is Request Forwarding (Ref sec 6.1.5 RFC 3588) a relay functionality? If we are supporting only peer to peer diameter and not the intermediate nodes (agents) then do we need to implement request forwarding. Thanks and Regards Monal ______________________________________________________________________ ______________________________________________________________________ From owner-aaa-wg@merit.edu Thu Jul 20 10:58:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Zyh-0006dp-N2 for aaa-archive@lists.ietf.org; Thu, 20 Jul 2006 10:58:15 -0400 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Zsj-00064K-E0 for aaa-archive@lists.ietf.org; Thu, 20 Jul 2006 10:52:06 -0400 Received: by trapdoor.merit.edu (Postfix) id D17AB91218; Thu, 20 Jul 2006 10:51:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D0919121F; Thu, 20 Jul 2006 10:51:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 02F7991218 for ; Thu, 20 Jul 2006 10:51:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D9B7858297; Thu, 20 Jul 2006 10:51:54 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from fiji.merit.edu (fiji.merit.edu [198.108.1.12]) by segue.merit.edu (Postfix) with ESMTP id B6A3958294 for ; Thu, 20 Jul 2006 10:51:54 -0400 (EDT) Received: by fiji.merit.edu (Postfix) id 8F65517A2; Thu, 20 Jul 2006 10:51:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fiji.merit.edu ([127.0.0.1]) by localhost (fiji.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19935-05; Thu, 20 Jul 2006 10:51:54 -0400 (EDT) X-Greylist: delayed 440 seconds by postgrey-1.21 at fiji.merit.edu; Thu, 20 Jul 2006 10:51:53 EDT Received: from mail45.messagelabs.com (mail45.messagelabs.com [216.82.249.195]) by fiji.merit.edu (Postfix) with SMTP id EE483CF0; Thu, 20 Jul 2006 10:51:53 -0400 (EDT) X-VirusChecked: Checked X-Env-Sender: Srinivas.Mylavarapu@lntinfotech.com X-Msg-Ref: server-10.tower-45.messagelabs.com!1153406669!23605408!1 X-StarScan-Version: 5.5.10.7; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 5167 invoked from network); 20 Jul 2006 14:44:30 -0000 Received: from bangaloresmtp.lntinfotech.com (HELO Bangaloresmtp.lntinfotech.com) (203.101.96.4) by server-10.tower-45.messagelabs.com with SMTP; 20 Jul 2006 14:44:30 -0000 Received: from Bangalore.lntinfotech.com ([172.28.0.3]) by Bangaloresmtp.lntinfotech.com (Lotus Domino Release 6.5.4) with ESMTP id 2006072020142920-20710 ; Thu, 20 Jul 2006 20:14:29 +0530 In-Reply-To: <000a01c6abe0$bbed8f90$a905120a@china.huawei.com> Subject: RE: [AAA-WG]: Realm table updation in Diameter To: rajithr@huawei.com Cc: aaa-wg@merit.edu, 'Monal Sengar' , owner-aaa-wg@merit.edu X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: Srinivas Mylavarapu Date: Thu, 20 Jul 2006 20:14:27 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 6.5.5|November 30, 2005) at 07/20/2006 08:14:26 PM, Itemize by SMTP Server on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 07/20/2006 08:14:29 PM, Serialize by Router on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 07/20/2006 08:14:32 PM, Serialize complete at 07/20/2006 08:14:32 PM Content-transfer-encoding: base64 Content-type: text/plain; charset=UTF-8 X-Virus-Scanned: amavisd-new at merit.edu Sender: owner-aaa-wg@merit.edu Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 SGksCgogICAgICAgIFdoZXRoZXIgaXQgaXMgc3RhdGljYWxseSBjb25maWd1cmVkIHRvIGR5bmFt aWNhbGx5IGNvbmZpZ3VyZWQsIHlvdQphbHdheXMgbmVlZCB0byBtYWludGFpbiB0aGUgc3VwcG9y dGVkIGFwcC1pZHMgYXQgZWFjaCBwZWVyIGJhc2VkIG9uIHRoZQpDRVIvQ0VBIGV4Y2hhbmdlLgoK V2FybSBSZWdhcmRzClNyaW5pCgoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICBSYWpp dGggUiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgPHJhaml0aHJAaHVhd2VpLmMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgIG9tPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVG8gCiAgICAgICAgICAgICBTZW50 IGJ5OiAgICAgICAgICAgICAgICAgICdNb25hbCBTZW5nYXInICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgb3duZXItYWFhLXdnQG1lcmkgICAgICAgICA8bW9uYWwuc2VuZ2FyQGdt YWlsLmNvbT4sICAgICAgICAgICAKICAgICAgICAgICAgIHQuZWR1ICAgICAgICAgICAgICAgICAg ICAgYWFhLXdnQG1lcml0LmVkdSAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNj IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgIDA3LzIwLzIwMDYgMDM6MTEgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN1YmplY3QgCiAgICAgICAgICAgICBQTSAg ICAgICAgICAgICAgICAgICAgICAgIFJFOiBbQUFBLVdHXTogUmVhbG0gdGFibGUgdXBkYXRpb24g IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbiBEaWFtZXRlciAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICBQbGVh c2UgcmVzcG9uZCB0byAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgcmFqaXRockBodWF3ZWkuY28gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgbSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKCgoKCkhpCiAgICAgICAgICAgIEFwcGxpY2F0aW9uIHN1cHBv cnQgYXQgYSBEaWFtZXRlciBub2RlIG1heSBiZSBjb25maWd1cmFibGUsCmkuZS4gYXBwbGljYXRp b25zIG1heSBjb21lICYgZ28uIEF0IHRoZSBsb2NhbCBub2RlLCBhdCBiZXN0IHlvdSBjYW4gYXNz dW1lCndoaWxlIGNvbmZpZ3VyaW5nIChpbml0aWFsIGNvbmZpZ3VyYXRpb24pIHlvdXIgcmVhbG0g cm91dGluZyB0YWJsZSB0aGF0IGEKRGlhbWV0ZXIgbm9kZSwgc2F5IHNlcnZlci5leGFtcGxlLm5l dCBzdXBwb3J0cyBhcHAgSWQgMSAmIDIuCiAgICAgICAgICAgIFRoZSBhcHAgc3VwcG9ydCBpcyAo cmUpYWZmaXJtZWQgKHJ1biB0aW1lKSBieSB0aGUgZXhjaGFuZ2Ugb2YKc3VwcG9ydGVkIGFwcCBp ZHMgaW4gQ0VSL0NFQS4KICAgICAgICAgICAgU28gaXQgaXMgZGVzaXJhYmxlIHRvIHVwZGF0ZSB0 aGUgcmVhbG0gdGFibGUgd2l0aCB0aGUgYXBwIElkCmluZm9ybWF0aW9uIGluIENFUi9DRUEuCiAg ICAgICAgICAgIEVsc2UgeW91IG1heSByZWNlaXZlIGEg4oCcRElBTUVURVJfQVBQTElDQVRJT05f VU5TVVBQT1JURUTigJ0gYW5kCnlvdXIgcmVhbG0gdGFibGUgd2lsbCBoYXZlIHRvIGJlIGRpYWdu b3N0aWNhbGx5IHJlY29uZmlndXJlZC4gVGhpcyB3b3VsZCBiZQphIGNvc3RsaWVyIG9wdGlvbiB3 aGVuIGNvbXBhcmVkIHRvIHRoZSBmaXJzdCBvbmUuCgpSYWppdGgKCioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKgpUaGlzIGUtbWFpbCBhbmQgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRp YWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksCndoaWNoIGlzIGludGVuZGVkIG9ubHkgZm9yIHRo ZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkCmFib3ZlLiBBbnkgdXNl IG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGlu ZywKYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsIGRpc2Nsb3N1cmUsIHJlcHJv ZHVjdGlvbiwgb3IKZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRl bmRlZCByZWNpcGllbnQncykgaXMKcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcgpieSBwaG9uZSBvciBlbWFpbCBp bW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQoKRnJvbTogb3duZXItYWFhLXdnQG1lcml0LmVkdSBb bWFpbHRvOm93bmVyLWFhYS13Z0BtZXJpdC5lZHVdIE9uIEJlaGFsZiBPZgpNb25hbCBTZW5nYXIK U2VudDogVGh1cnNkYXksIEp1bHkgMjAsIDIwMDYgMjo1OSBQTQpUbzogYWFhLXdnQG1lcml0LmVk dQpTdWJqZWN0OiBbQUFBLVdHXTogUmVhbG0gdGFibGUgdXBkYXRpb24gaW4gRGlhbWV0ZXIKCkhl bGxvLAoKV2hlbiB3ZSByZWNpZXZlIGV4Y2hhbmdlIENFUiBhbmQgQ0VBIHdpdGggc3RhdGljYWxs eSBjb25maWd1cmVkIHBlZXIgLCBkbwp3ZSBuZWVkIHRvIHVwZGF0ZSB0aGUgcmVhbG0gcm91dGlu ZyB0YWJsZS4KSW4gb3VyIHJlYWxtIHJvdXRpbmcgdGFibGUgd2UgYXJlIG1haW50YWluaW5nIHRo ZSBtYXBwaW5nIG9mIGFwcGxpY2F0aW9uIGlkCmFuZCBzdXBwb3J0ZWQgaG9zdCBpZHMgZm9yIHBh cnRpY3VsYXIgcmVhbG0gZW50cnkuZS5nCgpbZXhhbXBsZS5uZXRdCjB4MDEgPSBzZXJ2ZXIuZXhh bXBsZS5uZXQKMHgwMiA9IHNlcnZlci5leGFtcGxlLm5ldApUaGlzIG1lYW5zIHRoYXQgaW4gcmVh bG0gZXhhbXBsZS5uZXQgd2UgaGF2ZSBob3N0IGlkIHNlcnZlci5leGFtcGxlLm5ldAp3aGljaCBz dXBwb3J0cyBhcHBsaWNhaXRvbiBpZCAweDAxIGFuZCAweDAyCgpOb3cgLCBzdXBwb3NlIGR1ZSB0 byBzb21lIHJlYXNvbiB0aGUgUGVlciBzZXJ2ZXIuZXhhbXBsZS5uZXQgZG9lc25vdCB3aXNoCnRv IGFkdmVydGlzZSBib3RoIHRoZSBhcHBsaWNhaXRvbiBJZHMgYW5kIGl0IHNlbmRzIG9ubHkgYXBw bGljYWl0b24gSWQgMHgwMQppbiBDRUEuIFNvIGRvIHdlIG5lZWQgdG8gdXBkYXRlIHRoZSByZWFs bSB0YWJsZSBldmVyeSB0aW1lIHdlIGV4Y2hhbmdlIENFUgphbmQgQ0VBIHdpdGggc3RhdGljYWxs eSBjb25maWd1cmVkIHBlZXJzPwoKVGhhbmtzIGFuZCBSZWdhcmRzCk1vbmFsCgoKCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCg== From owner-aaa-wg@merit.edu Thu Jul 20 14:12:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3d0S-0005Kt-MS for aaa-archive@lists.ietf.org; Thu, 20 Jul 2006 14:12:16 -0400 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3cn7-0005gZ-PA for aaa-archive@lists.ietf.org; Thu, 20 Jul 2006 13:58:31 -0400 Received: by trapdoor.merit.edu (Postfix) id 1C60B91260; Thu, 20 Jul 2006 13:58:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DBF239123E; Thu, 20 Jul 2006 13:58:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0109C91260 for ; Thu, 20 Jul 2006 13:58:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D011958298; Thu, 20 Jul 2006 13:58:18 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from fiji.merit.edu (fiji.merit.edu [198.108.1.12]) by segue.merit.edu (Postfix) with ESMTP id 9E62458296 for ; Thu, 20 Jul 2006 13:58:18 -0400 (EDT) Received: by fiji.merit.edu (Postfix) id 788DE17A7; Thu, 20 Jul 2006 13:58:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fiji.merit.edu ([127.0.0.1]) by localhost (fiji.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23113-07; Thu, 20 Jul 2006 13:58:18 -0400 (EDT) Received: from mail45.messagelabs.com (mail45.messagelabs.com [216.82.249.195]) by fiji.merit.edu (Postfix) with SMTP id D1DE5179D; Thu, 20 Jul 2006 13:58:17 -0400 (EDT) X-VirusChecked: Checked X-Env-Sender: Srinivas.Mylavarapu@lntinfotech.com X-Msg-Ref: server-22.tower-45.messagelabs.com!1153418294!21535563!1 X-StarScan-Version: 5.5.10.7; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 22069 invoked from network); 20 Jul 2006 17:58:15 -0000 Received: from bangaloresmtp.lntinfotech.com (HELO Bangaloresmtp.lntinfotech.com) (203.101.96.4) by server-22.tower-45.messagelabs.com with SMTP; 20 Jul 2006 17:58:15 -0000 Received: from Bangalore.lntinfotech.com ([172.28.0.3]) by Bangaloresmtp.lntinfotech.com (Lotus Domino Release 6.5.4) with ESMTP id 2006072023281573-20815 ; Thu, 20 Jul 2006 23:28:15 +0530 In-Reply-To: <75D349FBF7C131408F5061B7168072C30332A1BA@INOAVREX06.ptin.corpPT.com> Subject: Re: [AAA-WG]: Diameter redirect To: "Paulo Rolo" Cc: aaa-wg@merit.edu, owner-aaa-wg@merit.edu X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: Srinivas Mylavarapu Date: Thu, 20 Jul 2006 23:28:14 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 6.5.5|November 30, 2005) at 07/20/2006 11:28:13 PM, Itemize by SMTP Server on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 07/20/2006 11:28:15 PM, Serialize by Router on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 07/20/2006 11:28:17 PM, Serialize complete at 07/20/2006 11:28:17 PM Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: amavisd-new at merit.edu Sender: owner-aaa-wg@merit.edu Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Hi, =20=20=20=20=20=20SAR=20message=20has=20got=20two=20AVPs=20through=20which= =20user=20identity=20can=20be=20sent, "User-Name"=20=20and=20=20"Public-Identity".=2029.229=20says=20that=20both= =20are=20optional=20but one=20of=20=20them=20should=20be=20present=20to=20make=20the=20message=20m= eaningful=20to=20the receiver,=20ie=20receiving=20entity=20should=20be=20able=20to=20make=20out= =20for=20which subscriber=20this=20registration=20request=20is=20meant=20for.=20Hence=20a= ssumption=20is=20that SAR=20message=20need=20to=20contain=20either=20=20"User-Name"=20=20or=20=20= "Public-Identity". Now=20SLF=20can=20use=20one=20of=20those=20AVPs=20to=20find=20out=20in=20w= hich=20HSS=20respective profile=20is=20being=20maintained. Warm=20Regards Srini =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20"Paulo=20Rolo"=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20To=20 =20=20=20=20=20=20=20=20=20=20=20=20=20Sent=20by:=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20owner-aaa-wg@meri=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20cc=20 =20=20=20=20=20=20=20=20=20=20=20=20=20t.edu=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Subject=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20[AAA-WG]:=20Diameter=20redirect=20= =20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=2007/20/2006=2002:29=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20PM=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Hello, We=20are=20currently=20developing=20a=20set=20of=20Diameter=20interfaces=20= and=20some=20doubts have=20arise,=20concerning=20SLF=20usage. On=20ETSI=20TS=20123=20228=20(IP=20Multimedia=20Subsystem=20(IMS))=20at=20= section=205.8.1=20(User identity=20to=20HSS=20resolution)=20it=20is=20suggested=20that=20a=20Publi= c=20User=20Identity should=20be=20selected=20and=20used=20as=20input=20to=20SLF_QUERY,=20in=20= order=20to=20resolve=20to the=20correct=20HSS=20name. Also=20at=20section=206.1.2=20(S-CSCF=20registration/deregistration=20noti= fication)=20of TS=20129=20228=20(IP=20Multimedia=20(IM)=20Subsystem=20Cx=20and=20Dx=20Int= erfaces),=20it=20is suggested=20that=20if=20Routing=20Information=20is=20not=20available=20for= =20SAR=20(S-CSCF registration/deregistration),=20it=20should=20be=20routed=20to=20next=20di= ameter=20node, for=20example=20SLF. The=20issue=20is=20that=20on=20TS=20129=20229=20(Cx=20and=20Dx=20interface= s=20based=20on=20the=20Diameter protocol)=20at=20section=206.1.3=20(Server-Assignment-Request=20(SAR)=20Co= mmand)=20the Public-Identity=20is=20presented=20as=20an=20optional=20attribute.=20If=20= it=20is=20not=20present how=20should=20be=20SLF_QUERY=20performed?=20All=20the=20other=20messages=20= (UAR,=20LIR,=20MAR) have=20Public-Identity=20as=20mandatory. Thanks=20in=20advance, Paulo=20Rolo Network=20and=20Protocols=20Unit Intelligent=20Networks=20Department Portugal=20Telecom=20Inova=E7=E3o,=20S.A ______________________________________________________________________ ______________________________________________________________________ From owner-aaa-wg@merit.edu Thu Jul 20 19:59:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3iKu-0008Ub-Aq for aaa-archive@lists.ietf.org; Thu, 20 Jul 2006 19:53:44 -0400 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3i79-00049B-I8 for aaa-archive@lists.ietf.org; Thu, 20 Jul 2006 19:39:33 -0400 Received: by trapdoor.merit.edu (Postfix) id B3A469123E; Thu, 20 Jul 2006 19:39:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7931791262; Thu, 20 Jul 2006 19:39:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9A4629123E for ; Thu, 20 Jul 2006 19:39:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 886FC58294; Thu, 20 Jul 2006 19:39:20 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from fiji.merit.edu (fiji.merit.edu [198.108.1.12]) by segue.merit.edu (Postfix) with ESMTP id 735EA58292 for ; Thu, 20 Jul 2006 19:39:20 -0400 (EDT) Received: by fiji.merit.edu (Postfix) id 557FF17D2; Thu, 20 Jul 2006 19:39:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fiji.merit.edu ([127.0.0.1]) by localhost (fiji.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27758-07 for ; Thu, 20 Jul 2006 19:39:19 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by fiji.merit.edu (Postfix) with ESMTP id 642B817A3 for ; Thu, 20 Jul 2006 19:39:19 -0400 (EDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 01:39:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AC55.AD4FEAB4" Subject: RE: [AAA-WG]: Diameter redirect Date: Fri, 21 Jul 2006 01:38:59 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02603A9E4CC@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: Diameter redirect Thread-Index: Acar2tMLs7EqoM5IRJqZlhX6BMOOBwABfcSwAB00TUA= From: "MORAND Lionel RD-CORE-ISS" To: "Paulo Rolo" , X-OriginalArrivalTime: 20 Jul 2006 23:39:02.0157 (UTC) FILETIME=[AE3563D0:01C6AC55] X-Virus-Scanned: amavisd-new at merit.edu Sender: owner-aaa-wg@merit.edu Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AC55.AD4FEAB4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ********************RESEND*********************************** ________________________________ De : MORAND Lionel RD-CORE-ISS=20 Envoy=E9 : jeudi 20 juillet 2006 11:55 =C0 : 'Paulo Rolo'; aaa-wg@merit.edu Objet : RE: [AAA-WG]: Diameter redirect Hi Paulo, =20 Over the 3GPP Cx interface, the Public-Identity AVP is optional for SAR = because there are specific cases for which the presence of the User-Name = AVP is enough (please refer to the 3GPP spec for further details). So, it was decided not to mandate the presence of the Public-Identity = AVP in the SAR with the following limitation: at least one of the = identity types shall be present in the SAR i.e. either a Public-Identity = AVP or a User-Name AVP (of course, both AVPs may be present in the = command). =20 If at least one identity is present in the command, it is always = possible to perform a user identity to HSS resolution, as either = Public-Identity or User-Name can be used as SLF key entry to retrieve = the correct HSS name. =20 Hope this helps! =20 Lionel ________________________________ De : owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] De la part = de Paulo Rolo Envoy=E9 : jeudi 20 juillet 2006 11:00 =C0 : aaa-wg@merit.edu Objet : [AAA-WG]: Diameter redirect Hello, =20 We are currently developing a set of Diameter interfaces and some doubts = have arise, concerning SLF usage. =20 On ETSI TS 123 228 (IP Multimedia Subsystem (IMS)) at section 5.8.1 = (User identity to HSS resolution) it is suggested that a Public User = Identity should be selected and used as input to SLF_QUERY, in order to = resolve to the correct HSS name.=20 =20 Also at section 6.1.2 (S-CSCF registration/deregistration notification) = of TS 129 228 (IP Multimedia (IM) Subsystem Cx and Dx Interfaces), it is = suggested that if Routing Information is not available for SAR (S-CSCF = registration/deregistration), it should be routed to next diameter node, = for example SLF. =20 =20 The issue is that on TS 129 229 (Cx and Dx interfaces based on the = Diameter protocol) at section 6.1.3 (Server-Assignment-Request (SAR) = Command) the Public-Identity is presented as an optional attribute. If = it is not present how should be SLF_QUERY performed? All the other = messages (UAR, LIR, MAR) have Public-Identity as mandatory. =20 =20 Thanks in advance, Paulo Rolo =20 Network and Protocols Unit Intelligent Networks Department Portugal Telecom Inova=E7=E3o, S.A =20 ------_=_NextPart_001_01C6AC55.AD4FEAB4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
********************RESEND********************= ***************

De : MORAND Lionel RD-CORE-ISS=20
Envoy=E9 : jeudi 20 juillet 2006 = 11:55
=C0 : 'Paulo=20 Rolo'; aaa-wg@merit.edu
Objet : RE: [AAA-WG]: Diameter=20 redirect

Hi Paulo,
 
Over the 3GPP Cx interface, the Public-Identity = AVP is=20 optional for SAR because there are specific cases for which the = presence of=20 the User-Name AVP is enough (please refer to the 3GPP spec for further=20 details).
So, it was decided not to mandate the presence = of the=20 Public-Identity AVP in the SAR with the following limitation: at least = one of=20 the identity types shall be present in the SAR i.e. either a = Public-Identity AVP=20 or a User-Name AVP (of course, both AVPs may be present in the=20 command).
 
If at least one identity is present in the = command, it is=20 always possible to perform a user identity to HSS resolution, as either=20 Public-Identity or User-Name can be used as SLF key entry to retrieve = the=20 correct HSS name.
 
Hope this helps!
 
Lionel
De :=20 owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] De la part = de=20 Paulo Rolo
Envoy=E9 : jeudi 20 juillet 2006=20 11:00
=C0 : aaa-wg@merit.edu
Objet : = [AAA-WG]:=20 Diameter redirect

Hello,

 

We are currently = developing=20 a set of Diameter interfaces and some doubts have arise, concerning SLF=20 usage.

 

On ETSI TS 123 228 = (IP=20 Multimedia Subsystem (IMS)) at section 5.8.1 (User identity to HSS = resolution)=20 it is suggested that a Public User Identity should be selected and used = as input=20 to SLF_QUERY, in order to resolve to the correct HSS name.=20

 

Also at section = 6.1.2=20 (S-CSCF registration/deregistration notification) of TS 129 228 (IP = Multimedia=20 (IM) Subsystem Cx and Dx Interfaces), it is suggested that if Routing=20 Information is not available for SAR (S-CSCF = registration/deregistration), it=20 should be routed to next diameter node, for example SLF. =20

 

The issue is that = on TS 129=20 229 (Cx and Dx interfaces based on the Diameter protocol) at section = 6.1.3=20 (Server-Assignment-Request (SAR) Command) the Public-Identity is = presented as an=20 optional attribute. If it is not present how should be SLF_QUERY = performed? All=20 the other messages (UAR, LIR, MAR) have Public-Identity as=20 mandatory.

 

 

Thanks in=20 advance,

Paulo=20 Rolo

 

Network and = Protocols=20 Unit

Intelligent = Networks=20 Department

Portugal Telecom = Inova=E7=E3o,=20 S.A

 

------_=_NextPart_001_01C6AC55.AD4FEAB4-- From owner-aaa-wg@merit.edu Mon Jul 24 06:04:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4xIl-00012z-F5 for aaa-archive@lists.ietf.org; Mon, 24 Jul 2006 06:04:39 -0400 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4xIk-0004sB-3o for aaa-archive@lists.ietf.org; Mon, 24 Jul 2006 06:04:39 -0400 Received: by trapdoor.merit.edu (Postfix) id 2250291210; Mon, 24 Jul 2006 06:04:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC41091217; Mon, 24 Jul 2006 06:04:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7CB5891210 for ; Mon, 24 Jul 2006 06:04:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 681EC58291; Mon, 24 Jul 2006 06:04:30 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from fiji.merit.edu (fiji.merit.edu [198.108.1.12]) by segue.merit.edu (Postfix) with ESMTP id 5572658283 for ; Mon, 24 Jul 2006 06:04:30 -0400 (EDT) Received: by fiji.merit.edu (Postfix) id 3916111B5; Mon, 24 Jul 2006 06:04:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fiji.merit.edu ([127.0.0.1]) by localhost (fiji.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00076-01 for ; Mon, 24 Jul 2006 06:04:29 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by fiji.merit.edu (Postfix) with ESMTP id AB98955F for ; Mon, 24 Jul 2006 06:04:29 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x66so2180264pye for ; Mon, 24 Jul 2006 03:04:29 -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=TbDQBnspTAeKpfrjAzkyL9l4BbYlXmk739B9wskTz7kkcfISvbSvsH1asayODsoivTS6NTrNdbQsTZn+wWpgAaZXZaET7dFcBBkxSvACg5sH+H5cjZ/fiiHB+rr9movRvLlktomY+ThObWyamqOLgSCTHc62SawPBJea95JLmUQ= Received: by 10.35.78.9 with SMTP id f9mr7293029pyl; Mon, 24 Jul 2006 03:04:28 -0700 (PDT) Received: by 10.35.82.12 with HTTP; Mon, 24 Jul 2006 03:04:28 -0700 (PDT) Message-ID: Date: Mon, 24 Jul 2006 15:34:28 +0530 From: "naveen sarma" To: aaa-wg@merit.edu Subject: [AAA-WG]: Realm expiration timer MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_62244_33088602.1153735468513" X-Virus-Scanned: amavisd-new at merit.edu Sender: owner-aaa-wg@merit.edu Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d ------=_Part_62244_33088602.1153735468513 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, As per RFC 3588 section 5.2 "A dynamically discovered peer causes an entry in the Peer Table (see Section 2.6) to be created. Note that entries created via DNS MUST expire (or be refreshed) within the DNS TTL. If a peer is discovered outside of the local realm, a routing table entry (see Section 2.7) for the peer's realm is created. The routing table entry's expiration MUST match the peer's expiration value." So we will make an entry into the peer table and realm table (if required) when ever a new peer is discovered, connected and CER, CEA are exchanged. As per our understanding, if the peer expiration timeout happens and if the peer's state is closed we will try to re-connect to the peer. If the peer's state is Open we are doing nothing. Is this correct? What do we need to do when the the realm expiration timeout happens? -- Yours Naveen. ------=_Part_62244_33088602.1153735468513 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,
    As per RFC 3588 section 5.2

"A dynamically discovered peer causes an entry in the Peer Table (see Section 2.6) to be created. Note that entries created via DNS MUST expire (or be refreshed) within the DNS TTL. If a peer is discovered outside of the local realm, a routing table entry (see Section 2.7) for the peer's realm is created. The routing table entry's expiration MUST match the peer's expiration value."

So we will make an entry into the peer table and realm table (if required) when ever a new peer is discovered, connected and CER, CEA are exchanged.

As per our understanding, if the peer expiration timeout happens and if the peer's state is closed we will try to re-connect to the peer.  If the peer's state is Open we are doing nothing.  Is this correct?

What do we need to do when the the realm expiration timeout happens?

--
Yours
Naveen. ------=_Part_62244_33088602.1153735468513-- From owner-aaa-wg@merit.edu Mon Jul 24 06:07:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4xLU-0001Ho-Jp for aaa-archive@lists.ietf.org; Mon, 24 Jul 2006 06:07:28 -0400 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4xLT-0005hA-9E for aaa-archive@lists.ietf.org; Mon, 24 Jul 2006 06:07:28 -0400 Received: by trapdoor.merit.edu (Postfix) id 68E9091217; Mon, 24 Jul 2006 06:07:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 327949124D; Mon, 24 Jul 2006 06:07:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BD38B91217 for ; Mon, 24 Jul 2006 06:07:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A84E858291; Mon, 24 Jul 2006 06:07:17 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from fiji.merit.edu (fiji.merit.edu [198.108.1.12]) by segue.merit.edu (Postfix) with ESMTP id 6897B58283 for ; Mon, 24 Jul 2006 06:07:17 -0400 (EDT) Received: by fiji.merit.edu (Postfix) id 4908F11B5; Mon, 24 Jul 2006 06:07:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fiji.merit.edu ([127.0.0.1]) by localhost (fiji.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00301-02 for ; Mon, 24 Jul 2006 06:07:16 -0400 (EDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by fiji.merit.edu (Postfix) with ESMTP id 82D1055F for ; Mon, 24 Jul 2006 06:07:16 -0400 (EDT) Received: by ug-out-1314.google.com with SMTP id m3so2132204ugc for ; Mon, 24 Jul 2006 03:07:15 -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=YocnAcrjp/jZQAxX53ZjGzJbGN/YAQmG7tSF15+CzMMpmx34d4oIpe+gilLAIp+Q9KDdRgFxOWDXvSg91QLDaecZNGdZSZIXsKVeYTt59VOi1J6wdmprsLuujDwZTxw1YftjsmCMM2en6VOmsimEzhEDUZ0lOjD/ihmYw4+PFDo= Received: by 10.67.101.10 with SMTP id d10mr3377937ugm; Mon, 24 Jul 2006 03:01:07 -0700 (PDT) Received: by 10.66.249.18 with HTTP; Mon, 24 Jul 2006 03:01:07 -0700 (PDT) Message-ID: <5be720c40607240301s40646076i3c879042e9044768@mail.gmail.com> Date: Mon, 24 Jul 2006 15:31:07 +0530 From: "Monal Sengar" To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter - Failover Implementation MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_157495_32123958.1153735267101" X-Virus-Scanned: amavisd-new at merit.edu Sender: owner-aaa-wg@merit.edu Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 ------=_Part_157495_32123958.1153735267101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, In case of implementing Failover in Diameter base protocol, do we need to send the requests in pending message queue on per peer basis or do we need to distribute the requests based on the application Id. In case, we implement the first option then we will have a mapping of Primary peer to alternate peer.When primary peer is down , all the requests in pending message queue will be routed to alternate peer.But in this case , alternate peer must support all the applicaiton Ids which primary peer is supporting. But in case of second option, we can retireve the pending message from the pending message queue and based on the applicaiton Id , we can retireve the proper alternate peer (from realm table and peer table) for this request which will be supproting the application id present in the pending message and route the request to the same.So for different pending requests we can have different alternate peers.In such case there will not be any fixed alternate peer but based on the application Id, we will find the proper alternate peer from realm table and peer table. Which option seems to be better? Thanks in advance Monal ------=_Part_157495_32123958.1153735267101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,

In case of implementing Failover in Diameter base protocol, do we need to send the requests in pending message queue on per peer basis or do we need to distribute the requests based on the application Id.

In case, we implement the first option then we will have a mapping of Primary peer to alternate peer.When primary peer is down , all the requests in pending message queue will be routed to alternate peer.But in this case , alternate peer must support all the applicaiton Ids which primary peer is supporting.

But in case of second option, we can retireve the pending message from the pending message queue and based on the applicaiton Id , we can retireve the proper alternate peer (from realm table and peer table) for this request which will be supproting the application id present in the pending message and route the request to the same.So for different pending requests we can have different alternate peers.In such case there will not be any fixed alternate peer but based on the application Id, we will find the proper alternate peer from realm table and peer table.

Which option seems to be better?

Thanks in advance
Monal
------=_Part_157495_32123958.1153735267101-- From owner-aaa-wg@merit.edu Wed Jul 26 03:16:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5dd9-0003ke-JP for aaa-archive@lists.ietf.org; Wed, 26 Jul 2006 03:16:31 -0400 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5dd8-0002zR-88 for aaa-archive@lists.ietf.org; Wed, 26 Jul 2006 03:16:31 -0400 Received: by trapdoor.merit.edu (Postfix) id 6FACF912AB; Wed, 26 Jul 2006 03:15:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3A5B91266; Wed, 26 Jul 2006 03:15:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4EE29912AB for ; Wed, 26 Jul 2006 03:15:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 35FAA58283; Wed, 26 Jul 2006 03:15:54 -0400 (EDT) Delivered-To: aaa-wg@segue.merit.edu Received: from fiji.merit.edu (fiji.merit.edu [198.108.1.12]) by segue.merit.edu (Postfix) with ESMTP id D96AD58281 for ; Wed, 26 Jul 2006 03:15:53 -0400 (EDT) Received: by fiji.merit.edu (Postfix) id B785A17A4; Wed, 26 Jul 2006 03:15:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fiji.merit.edu ([127.0.0.1]) by localhost (fiji.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12967-02 for ; Wed, 26 Jul 2006 03:15:53 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by fiji.merit.edu (Postfix) with ESMTP id 4545A11AF for ; Wed, 26 Jul 2006 03:15:53 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id x66so2999046pye for ; Wed, 26 Jul 2006 00:15:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=RVLA6CYZgfsqmGwNh/8+QkL0drwlWEpzZJh9P53RRQDRgjxAOhso1L9X9mfkgaUp9bVeBeUpXpcuiug9ZIsgNIYXq1Orvek65lySCa8M/v5dJXuk/XY1h3z/rWQvLeperrGafjau/vqOZEqjnMN0hmu+hFrF25PCIpvolfFzyjw= Received: by 10.35.132.13 with SMTP id j13mr10856128pyn; Wed, 26 Jul 2006 00:15:52 -0700 (PDT) Received: by 10.35.82.12 with HTTP; Wed, 26 Jul 2006 00:15:52 -0700 (PDT) Message-ID: Date: Wed, 26 Jul 2006 12:45:52 +0530 From: "naveen sarma" To: aaa-wg@merit.edu Subject: [AAA-WG]: Fwd: Failover processing In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_110057_10710197.1153898152674" References: X-Virus-Scanned: amavisd-new at merit.edu Sender: owner-aaa-wg@merit.edu Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab ------=_Part_110057_10710197.1153898152674 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline ---------- Forwarded message ---------- From: naveen sarma Date: Jul 26, 2006 12:35 PM Subject: Failover processing To: dime-request@ietf.org Hi, In the case of failover processing, do we need to change the destination host before forwarding to the new alternate peer? Suppose consider the following scenario: P0 is the originating host, to which P1 and P2 are peers (direct connection). P0 is supporting applications 1, 2, 3 P1 is supporting applications 1, 2 P2 is supporting applications 2, 3 After some time if P1 is down. Cosider that in the pending message queue of P1, there is a message M1 with application id 2 and the destination host as P1. As part of the failover, we will send the request message M1 to P2. In this case do we need to change the destination host inside the request message to P2, which was actually having the destination host as P1? Can anyone explain the responsibility when the diameter node is acting as an intermidate also? -- Yours Naveen. -- Yours Naveen. ------=_Part_110057_10710197.1153898152674 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

---------- Forwarded message ----------
From: naveen sarma <naveen.sarma@gmail.com>
Date: Jul 26, 2006 12:35 PM
Subject: Failover processing
To: dime-request@ietf.org

Hi,

In the case of failover processing, do we need to change the destination host before forwarding to the new alternate peer?

Suppose consider the following scenario:

P0 is the originating host, to which P1 and P2 are peers (direct connection).

P0 is supporting applications 1, 2, 3
P1 is supporting applications 1, 2
P2 is supporting applications 2, 3

After some time if P1 is down.  Cosider that in the pending message queue of P1, there is a message M1 with application id 2 and the destination host as P1.  As part of the failover, we will send the request message M1 to P2.

In this case do we need to change the destination host inside the request message to P2, which was actually having the destination host as P1?

Can anyone explain the responsibility when the diameter node is acting as an intermidate also?

--
Yours
Naveen.


--
Yours
Naveen. ------=_Part_110057_10710197.1153898152674--