From jouni.nospam@gmail.com Thu Oct 6 03:10:25 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770A121F8C31 for ; Thu, 6 Oct 2011 03:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1FAfbuDSXZL for ; Thu, 6 Oct 2011 03:10:25 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A301C21F8C79 for ; Thu, 6 Oct 2011 03:10:24 -0700 (PDT) Received: by bkaq10 with SMTP id q10so3674202bka.31 for ; Thu, 06 Oct 2011 03:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=/cGz90/ZPSa0kM+YeQbRBjcuHDJH7LwTctFhaf+uGfQ=; b=elvO+GxMsI4jjcYkk0iud6pnwh+ir5JJfHGNdnJ4NVHzmA/VohDfi7SAQ3B3su1qXa XvjY0jSg2ToY3acXhQonTcPqoq3SpvAGpq0cj3FmZLrwPWwm4mdQKVtK+5s06+mgC7vN nfDi/M57E1w2M/JmpjRap2HJAT42zflSLdX3Y= Received: by 10.204.156.156 with SMTP id x28mr435348bkw.108.1317896011615; Thu, 06 Oct 2011 03:13:31 -0700 (PDT) Received: from a83-245-210-213.elisa-laajakaista.fi (a83-245-210-213.elisa-laajakaista.fi. [83.245.210.213]) by mx.google.com with ESMTPS id d17sm4874825bkq.11.2011.10.06.03.13.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 Oct 2011 03:13:30 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Oct 2011 13:13:27 +0300 Message-Id: <236C66F2-05B5-4C0E-AB0A-D419987EF79A@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Dime] Detecting loops when redirecting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 10:10:25 -0000 Folks, This came up recently with RFC3588 and RFC3588bis. Assume a network = topology where a Diameter node A sends a request to a Diameter node B. = The Diameter node B redirects A to a Diameter node C. And then again the = Diameter node C redirects A back to B. There are other topologies with = similar properties.. While this is a sad misconfiguration of the network & routing, we have = no protocol means to detect such loop. No Route-Record gets added to = requests in this case because B and C are not forwarding packets per se. = Should we have a "fix" for this or just let implementations deal with = it? At minimum text describing the issue could be put somewhere in some = relevant document. One possibility could be a "TTL" AVP that gets = decremented every time a request/reply gets sent somewhere, independent = of being redirected/relayed/proxied. However, that obviously has some = backward compatibility issues if added as a mandatory AVP to the base = protocol. Any views on this? - Jouni= From stefan.winter@restena.lu Thu Oct 6 07:20:32 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6C421F8D66 for ; Thu, 6 Oct 2011 07:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMZGFR5lV3t2 for ; Thu, 6 Oct 2011 07:20:31 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 35D6121F8D48 for ; Thu, 6 Oct 2011 07:20:31 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id F0F6D10A09 for ; Thu, 6 Oct 2011 16:23:40 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id C191F109FC for ; Thu, 6 Oct 2011 16:23:40 +0200 (CEST) Message-ID: <4E8DB9EC.2010703@restena.lu> Date: Thu, 06 Oct 2011 16:23:40 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: dime@ietf.org References: <236C66F2-05B5-4C0E-AB0A-D419987EF79A@gmail.com> In-Reply-To: <236C66F2-05B5-4C0E-AB0A-D419987EF79A@gmail.com> X-Enigmail-Version: 1.3.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig963A64D976200F15023ED073" X-Virus-Scanned: ClamAV Subject: Re: [Dime] Detecting loops when redirecting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 14:20:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig963A64D976200F15023ED073 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > This came up recently with RFC3588 and RFC3588bis. Assume a network top= ology where a Diameter node A sends a request to a Diameter node B. The D= iameter node B redirects A to a Diameter node C. And then again the Diame= ter node C redirects A back to B. There are other topologies with similar= properties.. > > While this is a sad misconfiguration of the network & routing, we have = no protocol means to detect such loop. No Route-Record gets added to requ= ests in this case because B and C are not forwarding packets per se. Shou= ld we have a "fix" for this or just let implementations deal with it? At = minimum text describing the issue could be put somewhere in some relevant= document. One possibility could be a "TTL" AVP that gets decremented eve= ry time a request/reply gets sent somewhere, independent of being redirec= ted/relayed/proxied. However, that obviously has some backward compatibil= ity issues if added as a mandatory AVP to the base protocol. Interestingly enough, we have been facing the exact same issue in good old RADIUS, when using multiple proxy hops. It is - as you write - a sad misconfiguration, but it happens more frequently than we'd like. We have been disucssing a TTL attribute quite a lot for our eduroam consortium. I've brought forward the idea to the IETF ages ago on my first appearance (uh, Chicago?) but wasn't able to generate much intertia towards IETF-wide creation of such an attribute. For a while we thought about a VSA, but then again, it wasn't quite important enough for us to bully RADIUS server implementations all over the place to include an eduroam VSA dictionary; so at some point we learned to live without it. If there is sufficient interest for Diameter folks to move this ahead, it would be nice to use one of the <256 attributes so that it could be defined in the same way in RADIUS... Greetings, Stefan Winter > > Any views on this? > > - Jouni > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig963A64D976200F15023ED073 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6NuewACgkQ+jm90f8eFWbzygCfTTqIdB5DA6HaCFXX9CAhigXE aPkAn2dcslq1be92aDAK8Hv3qbSFWeY+ =qiNh -----END PGP SIGNATURE----- --------------enig963A64D976200F15023ED073-- From mark@azu.ca Thu Oct 6 07:23:26 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07FB21F8B71 for ; Thu, 6 Oct 2011 07:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qr9MEipXj1kv for ; Thu, 6 Oct 2011 07:23:25 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9351121F8B68 for ; Thu, 6 Oct 2011 07:23:23 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so2816668vcb.31 for ; Thu, 06 Oct 2011 07:26:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.183.164 with SMTP id en4mr44826vdc.99.1317911192898; Thu, 06 Oct 2011 07:26:32 -0700 (PDT) Received: by 10.52.184.138 with HTTP; Thu, 6 Oct 2011 07:26:32 -0700 (PDT) In-Reply-To: <236C66F2-05B5-4C0E-AB0A-D419987EF79A@gmail.com> References: <236C66F2-05B5-4C0E-AB0A-D419987EF79A@gmail.com> Date: Thu, 6 Oct 2011 10:26:32 -0400 Message-ID: From: Mark Jones To: jouni korhonen Content-Type: multipart/alternative; boundary=bcaec548a16b7f8aed04aea21c7f Cc: dime@ietf.org Subject: Re: [Dime] Detecting loops when redirecting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 14:23:26 -0000 --bcaec548a16b7f8aed04aea21c7f Content-Type: text/plain; charset=ISO-8859-1 Hi Jouni, On Thu, Oct 6, 2011 at 6:13 AM, jouni korhonen wrote: > Folks, > > This came up recently with RFC3588 and RFC3588bis. Assume a network > topology where a Diameter node A sends a request to a Diameter node B. The > Diameter node B redirects A to a Diameter node C. And then again the > Diameter node C redirects A back to B. There are other topologies with > similar properties.. > > While this is a sad misconfiguration of the network & routing, we have no > protocol means to detect such loop. No Route-Record gets added to requests > in this case because B and C are not forwarding packets per se. Should we > have a "fix" for this or just let implementations deal with it? At minimum > text describing the issue could be put somewhere in some relevant document. I would support describing the problem in bis (your example is clear) and state that the client is responsible for detecting this type of misconfiguration. If the client is an agent, presumably it MUST answer with the Result-Code AVP set to DIAMETER_LOOP_DETECTED when such an event occurs. Anything else we need to say? > One possibility could be a "TTL" AVP that gets decremented every time a > request/reply gets sent somewhere, independent of being > redirected/relayed/proxied. However, that obviously has some backward > compatibility issues if added as a mandatory AVP to the base protocol. > > Nice idea....for Diameter v2. I would want to impact backwards compatibility for this. > Any views on this? > > - Jouni > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --bcaec548a16b7f8aed04aea21c7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jouni,

On Thu, Oct 6, 2011 at 6:13 AM,= jouni korhonen <jouni.nospam@gmail.com> wrote:
Folks,

This came up recently with RFC3588 and RFC3588bis. Assume a network topolog= y where a Diameter node A sends a request to a Diameter node B. The Diamete= r node B redirects A to a Diameter node C. And then again the Diameter node= C redirects A back to B. There are other topologies with similar propertie= s..

While this is a sad misconfiguration of the network & routing, we have = no protocol means to detect such loop. No Route-Record gets added to reques= ts in this case because B and C are not forwarding packets per se. Should w= e have a "fix" for this or just let implementations deal with it?= At minimum text describing the issue could be put somewhere in some releva= nt document.


I would support describing the problem i= n bis (your example is clear) and state that the client is responsible for = detecting this type of misconfiguration. If the client is an agent, presuma= bly it MUST answer=A0with the Result-Code AVP set to DIAMETER_LOOP_DETECTED= when such an event occurs. Anything else we need to say?

=A0
One possibilit= y could be a "TTL" AVP that gets decremented every time a request= /reply gets sent somewhere, independent of being redirected/relayed/proxied= . However, that obviously has some backward compatibility issues if added a= s a mandatory AVP to the base protocol.


Nice idea....for Diameter v2. I would = want to impact backwards compatibility for this.

= =A0
Any views on this?

- Jouni
_______________________________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime

--bcaec548a16b7f8aed04aea21c7f-- From mark@azu.ca Thu Oct 6 07:24:12 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9172D21F8D37 for ; Thu, 6 Oct 2011 07:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjwdnkKA8as0 for ; Thu, 6 Oct 2011 07:24:11 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4F721F8B71 for ; Thu, 6 Oct 2011 07:24:11 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so2817757vcb.31 for ; Thu, 06 Oct 2011 07:27:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.92.137 with SMTP id cm9mr699390vdb.501.1317911241968; Thu, 06 Oct 2011 07:27:21 -0700 (PDT) Received: by 10.52.184.138 with HTTP; Thu, 6 Oct 2011 07:27:21 -0700 (PDT) In-Reply-To: References: <236C66F2-05B5-4C0E-AB0A-D419987EF79A@gmail.com> Date: Thu, 6 Oct 2011 10:27:21 -0400 Message-ID: From: Mark Jones To: jouni korhonen Content-Type: multipart/alternative; boundary=20cf307f3b4a6c4c3604aea21f15 Cc: dime@ietf.org Subject: Re: [Dime] Detecting loops when redirecting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 14:24:12 -0000 --20cf307f3b4a6c4c3604aea21f15 Content-Type: text/plain; charset=ISO-8859-1 That should read "I would NOT want to impact backwards compatibility for this". /Mark On Thu, Oct 6, 2011 at 10:26 AM, Mark Jones wrote: > Hi Jouni, > > On Thu, Oct 6, 2011 at 6:13 AM, jouni korhonen wrote: > >> Folks, >> >> This came up recently with RFC3588 and RFC3588bis. Assume a network >> topology where a Diameter node A sends a request to a Diameter node B. The >> Diameter node B redirects A to a Diameter node C. And then again the >> Diameter node C redirects A back to B. There are other topologies with >> similar properties.. >> >> While this is a sad misconfiguration of the network & routing, we have no >> protocol means to detect such loop. No Route-Record gets added to requests >> in this case because B and C are not forwarding packets per se. Should we >> have a "fix" for this or just let implementations deal with it? At minimum >> text describing the issue could be put somewhere in some relevant document. > > > > I would support describing the problem in bis (your example is clear) and > state that the client is responsible for detecting this type of > misconfiguration. If the client is an agent, presumably it MUST answer with > the Result-Code AVP set to DIAMETER_LOOP_DETECTED when such an event occurs. > Anything else we need to say? > > > >> One possibility could be a "TTL" AVP that gets decremented every time a >> request/reply gets sent somewhere, independent of being >> redirected/relayed/proxied. However, that obviously has some backward >> compatibility issues if added as a mandatory AVP to the base protocol. >> >> > Nice idea....for Diameter v2. I would want to impact backwards > compatibility for this. > > > >> Any views on this? >> >> - Jouni >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > --20cf307f3b4a6c4c3604aea21f15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That should read "I would NOT want to impact backwards compatibility f= or this".

/Mark

O= n Thu, Oct 6, 2011 at 10:26 AM, Mark Jones <mark@azu.ca> wrote:
Hi Jouni,

On Thu, Oct 6, 2011 at 6:13 AM, jouni korhonen <jo= uni.nospam@gmail.com> wrote:
Folks,

This came up recently with RFC3588 and RFC3588bis. Assume a network topolog= y where a Diameter node A sends a request to a Diameter node B. The Diamete= r node B redirects A to a Diameter node C. And then again the Diameter node= C redirects A back to B. There are other topologies with similar propertie= s..

While this is a sad misconfiguration of the network & routing, we have = no protocol means to detect such loop. No Route-Record gets added to reques= ts in this case because B and C are not forwarding packets per se. Should w= e have a "fix" for this or just let implementations deal with it?= At minimum text describing the issue could be put somewhere in some releva= nt document.


I would support describing the pro= blem in bis (your example is clear) and state that the client is responsibl= e for detecting this type of misconfiguration. If the client is an agent, p= resumably it MUST answer=A0with the Result-Code AVP set to DIAMETER_LOOP_DE= TECTED when such an event occurs. Anything else we need to say?

=A0
One possibility= could be a "TTL" AVP that gets decremented every time a request/= reply gets sent somewhere, independent of being redirected/relayed/proxied.= However, that obviously has some backward compatibility issues if added as= a mandatory AVP to the base protocol.


Nice idea....for Diameter v2. I = would want to impact backwards compatibility for this.

=A0
Any views on this?

- Jouni
_______________________________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime


--20cf307f3b4a6c4c3604aea21f15-- From adam@nostrum.com Thu Oct 6 07:27:03 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A402721F8AEE for ; Thu, 6 Oct 2011 07:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.38 X-Spam-Level: X-Spam-Status: No, score=-102.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1-XRHY7ZVaP for ; Thu, 6 Oct 2011 07:27:03 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 053EA21F8AED for ; Thu, 6 Oct 2011 07:27:02 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p96EUAZx083365 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 6 Oct 2011 09:30:11 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4E8DBB72.6030705@nostrum.com> Date: Thu, 06 Oct 2011 09:30:10 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mark Jones References: <236C66F2-05B5-4C0E-AB0A-D419987EF79A@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010307060106050509070900" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] Detecting loops when redirecting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 14:27:03 -0000 This is a multi-part message in MIME format. --------------010307060106050509070900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/6/11 9:26 AM, Mark Jones wrote: > > One possibility could be a "TTL" AVP that gets decremented every > time a request/reply gets sent somewhere, independent of being > redirected/relayed/proxied. However, that obviously has some > backward compatibility issues if added as a mandatory AVP to the > base protocol. > > > Nice idea....for Diameter v2. I would want to impact backwards > compatibility for this. > I don't think you'd need to make it mandatory. If it were inserted and acted upon by nodes that understood it (and ignored by nodes that didn't) then loops would eventually be shut down as long as one of the nodes acting on the attribute was involved. /a --------------010307060106050509070900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/6/11 9:26 AM, Mark Jones wrote:

One possibility could be a "TTL" AVP that gets decremented every time a request/reply gets sent somewhere, independent of being redirected/relayed/proxied. However, that obviously has some backward compatibility issues if added as a mandatory AVP to the base protocol.


Nice idea....for Diameter v2. I would want to impact backwards compatibility for this.


I don't think you'd need to make it mandatory. If it were inserted and acted upon by nodes that understood it (and ignored by nodes that didn't) then loops would eventually be shut down as long as one of the nodes acting on the attribute was involved.

/a
--------------010307060106050509070900-- From victor.pascual.avila@gmail.com Thu Oct 6 08:09:26 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB9621F8DD2 for ; Thu, 6 Oct 2011 08:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9lHYhiia840 for ; Thu, 6 Oct 2011 08:09:25 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB1AD21F8DD6 for ; Thu, 6 Oct 2011 08:09:22 -0700 (PDT) Received: by iaby26 with SMTP id y26so3783809iab.31 for ; Thu, 06 Oct 2011 08:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VmqEre4y1Alld2U83B9jqpsK2fAXreP1jIPJ8oA0lYw=; b=udt+JIJhlm3Eb6kkrSl1IbNbdPUjLZouZH07L3HsdgA1KiSKY+lVebXm+0c/jtQsHN //6NKRcN8WxDrHSVDsJBVAlXcFuxiWcxYFIU9/UpBgv2e5OrMcgtx4LiJuI0hTK37UcS kIDKwjlR9Ls3IF+SWilSesvCQLB5q55BiiFdk= MIME-Version: 1.0 Received: by 10.231.20.168 with SMTP id f40mr1430638ibb.57.1317913953781; Thu, 06 Oct 2011 08:12:33 -0700 (PDT) Received: by 10.231.33.130 with HTTP; Thu, 6 Oct 2011 08:12:33 -0700 (PDT) In-Reply-To: <4E8DBB72.6030705@nostrum.com> References: <236C66F2-05B5-4C0E-AB0A-D419987EF79A@gmail.com> <4E8DBB72.6030705@nostrum.com> Date: Thu, 6 Oct 2011 17:12:33 +0200 Message-ID: From: Victor Pascual Avila To: Adam Roach Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] Detecting loops when redirecting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 15:09:26 -0000 On Thu, Oct 6, 2011 at 4:30 PM, Adam Roach wrote: > > On 10/6/11 9:26 AM, Mark Jones wrote: >> >> One possibility could be a "TTL" AVP that gets decremented every time a = request/reply gets sent somewhere, independent of being redirected/relayed/= proxied. However, that obviously has some backward compatibility issues if = added as a mandatory AVP to the base protocol. >> > > Nice idea....for Diameter v2. I would want to impact backwards compatibil= ity for this. > > I don't think you'd need to make it mandatory. If it were inserted and ac= ted upon by nodes that understood it (and ignored by nodes that didn't) the= n loops would eventually be shut down as long as one of the nodes acting on= the attribute was involved. +1 Cheers, -Victor From glenzorn@gmail.com Thu Oct 6 22:01:18 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2F821F8B5E for ; Thu, 6 Oct 2011 22:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxz3JknsZfeY for ; Thu, 6 Oct 2011 22:01:17 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7F2121F8B62 for ; Thu, 6 Oct 2011 22:01:17 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so3528922vcb.31 for ; Thu, 06 Oct 2011 22:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zSYSYxAhQJN35sfmN37UkoTAvsTsFbvi5O6wd/FBVDM=; b=VAdy0GPQA7LKAA5lyTwAoeECtgZtGWVVjzbTSEELbLgEMD0Bq8lBCVjfgNUA1RFxQJ daiDu9ocnErmFMbrC/bS4NC8qAXWTq187p8mGBTKCM3jmJA06JPnl2GyQK5Ass6I9SMq nvyT/UaS3DWP5Oos/QZl0zZG+FSeCrIrZ8UMw= Received: by 10.52.69.9 with SMTP id a9mr1050840vdu.17.1317963867632; Thu, 06 Oct 2011 22:04:27 -0700 (PDT) Received: from [192.168.1.98] (ppp-110-169-223-127.revip5.asianet.co.th. [110.169.223.127]) by mx.google.com with ESMTPS id bu10sm6586580vdb.3.2011.10.06.22.04.21 (version=SSLv3 cipher=OTHER); Thu, 06 Oct 2011 22:04:23 -0700 (PDT) Message-ID: <4E8E8851.9030003@gmail.com> Date: Fri, 07 Oct 2011 12:04:17 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mark Jones References: <236C66F2-05B5-4C0E-AB0A-D419987EF79A@gmail.com> <4E8DBB72.6030705@nostrum.com> In-Reply-To: <4E8DBB72.6030705@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Detecting loops when redirecting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 05:01:18 -0000 On 10/6/2011 9:30 PM, Adam Roach wrote: > On 10/6/11 9:26 AM, Mark Jones wrote: >> >> One possibility could be a "TTL" AVP that gets decremented every >> time a request/reply gets sent somewhere, independent of being >> redirected/relayed/proxied. However, that obviously has some >> backward compatibility issues if added as a mandatory AVP to the >> base protocol. >> >> >> Nice idea....for Diameter v2. I would want to impact backwards >> compatibility for this. Actually, I don't think that this that great of an idea: it could be used to put an absolute limit upon hops traversed, but that doesn't seem especially useful. Why not just change Section 6.1.8 to allow redirect agents to check for loops & a Route-Record AVP to be added to the redirected message? I think that, if phrased carefully, this would not harm backward compatibility while still providing a way to solve the problem. In the same vein, bullet 4 under the heading "Local Action" says 4. REDIRECT - Diameter messages that fall within this category MUST have the identity of the home Diameter server(s) appended, and returned to the sender of the message. See Section 6.1.8 for redirect guidelines. Why is the identity of the home Diameter server appended & how does an arbitrary redirect agent know what it is? ... From jouni.nospam@gmail.com Fri Oct 7 00:21:15 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D06E21F8B0B for ; Fri, 7 Oct 2011 00:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xcArHDv9dci for ; Fri, 7 Oct 2011 00:21:14 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AE8A421F8B0C for ; Fri, 7 Oct 2011 00:21:08 -0700 (PDT) Received: by bkaq10 with SMTP id q10so5024720bka.31 for ; Fri, 07 Oct 2011 00:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=StmGdmaEhkn2Zdha3lOslH/LNcoRCmyWlDNJpGK/GC4=; b=VueXvCCHUnpaGolxLRqtcDzEI7BM2KrL4UqfYsan2xFZ7VGlPegHkxpF51gq+HVPh5 MJkP/2WCVr2AdjB5HK1DDBozJmCcO7/wB3eHc0JOKiuCoFi/JszYr0BVT++Re9uhm1Ry q7DBDWbb/HDo0Wps+KLS8fiijdW0CD8tuGjCs= Received: by 10.204.131.198 with SMTP id y6mr1079808bks.330.1317972260759; Fri, 07 Oct 2011 00:24:20 -0700 (PDT) Received: from a88-114-174-221.elisa-laajakaista.fi (a88-114-174-221.elisa-laajakaista.fi. [88.114.174.221]) by mx.google.com with ESMTPS id e14sm7976627bka.0.2011.10.07.00.24.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Oct 2011 00:24:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4E8E8851.9030003@gmail.com> Date: Fri, 7 Oct 2011 10:24:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <236C66F2-05B5-4C0E-AB0A-D419987EF79A@gmail.com> <4E8DBB72.6030705@nostrum.com> <4E8E8851.9030003@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] Detecting loops when redirecting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 07:21:15 -0000 On Oct 7, 2011, at 8:04 AM, Glen Zorn wrote: > On 10/6/2011 9:30 PM, Adam Roach wrote: >> On 10/6/11 9:26 AM, Mark Jones wrote: >>>=20 >>> One possibility could be a "TTL" AVP that gets decremented every >>> time a request/reply gets sent somewhere, independent of being >>> redirected/relayed/proxied. However, that obviously has some >>> backward compatibility issues if added as a mandatory AVP to the >>> base protocol. >>>=20 >>>=20 >>> Nice idea....for Diameter v2. I would want to impact backwards >>> compatibility for this. >=20 > Actually, I don't think that this that great of an idea: it could be > used to put an absolute limit upon hops traversed, but that doesn't = seem > especially useful. Why not just change Section 6.1.8 to allow = redirect > agents to check for loops & a Route-Record AVP to be added to the > redirected message? I think that, if phrased carefully, this would = not That would also be rather big change. Currently redirect agents do cause = Route-Record to be added into requests, thus checking for Route-Record = has really no effect. > harm backward compatibility while still providing a way to solve the > problem. In the same vein, bullet 4 under the heading "Local Action" = says >=20 > 4. REDIRECT - Diameter messages that fall within this category > MUST have the identity of the home Diameter server(s) > appended, and returned to the sender of the message. See > Section 6.1.8 for redirect guidelines. >=20 > Why is the identity of the home Diameter server appended & how does an > arbitrary redirect agent know what it is? Our interpretation has been that the sentence implies one cannot place = Redirect Agents anywhere else than in front of the "home server". That = would mean topologies having Redirect Agents doing redirections to = relays/proxies/redirects are wrong. "Identity of the home Diameter = server(s) appended" means adding Redirect-Host AVPs according to our = interpretation. - Jouni >=20 > ... > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From kishore.kumar-jv@hp.com Mon Oct 10 02:15:33 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3C721F84A7 for ; Mon, 10 Oct 2011 02:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.11 X-Spam-Level: X-Spam-Status: No, score=-105.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ubSZcyl8-m1 for ; Mon, 10 Oct 2011 02:15:32 -0700 (PDT) Received: from g6t0185.atlanta.hp.com (g6t0185.atlanta.hp.com [15.193.32.62]) by ietfa.amsl.com (Postfix) with ESMTP id AC6CC21F84A5 for ; Mon, 10 Oct 2011 02:15:32 -0700 (PDT) Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0185.atlanta.hp.com (Postfix) with ESMTPS id 017F6242E0 for ; Mon, 10 Oct 2011 09:15:31 +0000 (UTC) Received: from G9W0364.americas.hpqcorp.net (16.216.193.45) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 10 Oct 2011 09:14:44 +0000 Received: from G9W0766.americas.hpqcorp.net ([169.254.4.60]) by G9W0364.americas.hpqcorp.net ([16.216.193.45]) with mapi id 14.01.0289.001; Mon, 10 Oct 2011 09:14:44 +0000 From: "J V, Kishore Kumar (Communication & Media Solutions)" To: "dime@ietf.org" Thread-Topic: DWR & REOPEN Peer State Thread-Index: AcyHLQtcpQEdrOHUSvWl7ZCzmsnY3Q== Date: Mon, 10 Oct 2011 09:14:42 +0000 Message-ID: <956FF5FB16AD1C44BED82EF060676E5501D716@G9W0766.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.216.12.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 10 Oct 2011 02:52:50 -0700 Subject: [Dime] DWR & REOPEN Peer State X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 09:18:28 -0000 Description of issue:=20 When peer is REOPEN state, any non-DWA message (including DWR) are "thrown = away". This may cause the peer who sent the DWR to failover and when this i= ssue occurs, this peer can never be in OPEN state. Submitter name: Kishore Submitter email address: Kishore.Kumar-JV@hp.com Date first submitted: October/10/2011=20 Document: AAATRANS Comment type: T Priority: S Section: Appendix A - Detailed Watchdog Algorithm Rationale/Explanation of issue:=20 Peer-1 and Peer-2 have established diameter connection and they are in OPEN= state. For some reason, Peer-2 loses connection to Peer-1. This causes Pee= r-2 to move Peer-1 to "DOWN" state. When Peer-1 connects again to Peer-2, then Peer-2 moves the state of Peer-1= to "REOPEN" state. Then it sends a DWR immediately. If Tw period of Peer-2= happens to be larger than Tw period of Peer-1 ( Eg., Tw(Peer-2) > 3 * Tw(P= eer-1)), then it is possible that a DWR might be received from Peer-1 befor= e second/third DWR are sent from Peer-2. Since Peer-1 is in "REOPEN" state = in Peer-2, the DWR would Be "thrown away". This causes Peer-1 to initiate f= ailback. When Peer-1 establishes the connection again, the above set of eve= nts are repeated and hence the state can never change to [R/I]-OPEN. From kishore.kumar-jv@hp.com Tue Oct 11 22:35:27 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0007A21F8A62 for ; Tue, 11 Oct 2011 22:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.263 X-Spam-Level: X-Spam-Status: No, score=-106.263 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn6prIJ-4RAg for ; Tue, 11 Oct 2011 22:35:26 -0700 (PDT) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by ietfa.amsl.com (Postfix) with ESMTP id 863D121F88A0 for ; Tue, 11 Oct 2011 22:35:26 -0700 (PDT) Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g5t0006.atlanta.hp.com (Postfix) with ESMTPS id 28327C0F9 for ; Wed, 12 Oct 2011 05:35:26 +0000 (UTC) Received: from G9W0705G.americas.hpqcorp.net (16.216.198.36) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 12 Oct 2011 05:34:04 +0000 Received: from G9W0766.americas.hpqcorp.net ([169.254.4.60]) by G9W0705G.americas.hpqcorp.net ([16.216.198.36]) with mapi id 14.01.0289.001; Wed, 12 Oct 2011 05:34:04 +0000 From: "J V, Kishore Kumar (Communication & Media Solutions)" To: "dime@ietf.org" Thread-Topic: DWR & REOPEN Peer State [ReSending] Thread-Index: AcyHLQtcpQEdrOHUSvWl7ZCzmsnY3QBc1cyg Date: Wed, 12 Oct 2011 05:34:00 +0000 Message-ID: <956FF5FB16AD1C44BED82EF060676E5501E162@G9W0766.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.216.12.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Dime] DWR & REOPEN Peer State [ReSending] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 05:35:27 -0000 Description of issue:=20 When peer is REOPEN state, any non-DWA message (including DWR) are "thrown = away". This may cause the peer who sent the DWR to failover and when this i= ssue occurs, this peer can never be in OPEN state. Submitter name: Kishore Submitter email address: Kishore.Kumar-JV@hp.com Date first submitted: October/10/2011=20 Document: AAATRANS Comment type: T Priority: S Section: Appendix A - Detailed Watchdog Algorithm Rationale/Explanation of issue:=20 Peer-1 and Peer-2 have established diameter connection and they are in OPEN= state. For some reason, Peer-2 loses connection to Peer-1. This causes Pee= r-2 to move Peer-1 to "DOWN" state. When Peer-1 connects again to Peer-2, then Peer-2 moves the state of Peer-1= to "REOPEN" state. Then it sends a DWR immediately. If Tw period of Peer-2= happens to be larger than Tw period of Peer-1 ( Eg., Tw(Peer-2) > 3 * Tw(P= eer-1)), then it is possible that a DWR might be received from Peer-1 befor= e second/third DWR are sent from Peer-2. Since Peer-1 is in "REOPEN" state = in Peer-2, the DWR would Be "thrown away". This causes Peer-1 to initiate f= ailback. When Peer-1 establishes the connection again, the above set of eve= nts are repeated and hence the state can never change to [R/I]-OPEN. From jouni.nospam@gmail.com Thu Oct 13 14:34:32 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECD021F8A7D for ; Thu, 13 Oct 2011 14:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABE+FvJC4HPG for ; Thu, 13 Oct 2011 14:34:31 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1556521F8564 for ; Thu, 13 Oct 2011 14:34:30 -0700 (PDT) Received: by bkbzv3 with SMTP id zv3so2226397bkb.31 for ; Thu, 13 Oct 2011 14:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=1j3eqBeWPZOWINRWnDdOCKLpdfdZDXTwMMoSZwzolmU=; b=eEwvv3gapdM2qFFOp5S/0kS4SqooPpjXl6R/hRzJ+8yrkCyLEPqd3Uz/c4C44eorGd KHs3OvRi7MYwP/4UQU1fo7h38Z4lSAFIyr7q+biPFMFlAgLadVUdAuCdzCGcjt8ENS6I o+KOV0BJsnRh/qjmyanzCM5oEC4u9EikCwGDI= Received: by 10.204.135.197 with SMTP id o5mr4370950bkt.37.1318541670193; Thu, 13 Oct 2011 14:34:30 -0700 (PDT) Received: from jounis-imac.lan ([188.117.15.106]) by mx.google.com with ESMTPS id d17sm5494565bkq.11.2011.10.13.14.34.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Oct 2011 14:34:29 -0700 (PDT) From: Jouni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Oct 2011 00:34:27 +0300 Message-Id: <82B68D9E-04FA-4444-8888-FF628CB085B9@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [Dime] Dime session and presentations in Taipei X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 21:34:32 -0000 Folks, We have a 2 hours WG session slot in Taipei. If you want to present = something, just send an abstract + needed time to co-chairs. - Jouni & Lionel.= From naveen.sarma@gmail.com Wed Oct 19 03:54:03 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8700321F8B5E for ; Wed, 19 Oct 2011 03:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KKtZlpi8Kc8 for ; Wed, 19 Oct 2011 03:54:03 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6F7D21F8997 for ; Wed, 19 Oct 2011 03:54:02 -0700 (PDT) Received: by gyh20 with SMTP id 20so1886492gyh.31 for ; Wed, 19 Oct 2011 03:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+Bqb0fjbf545I0PIONQl5SK+K7yDL0kViAIGJrI7yR0=; b=xHORRdTnFCbFPiEFOAjFZPJK+++NiZ/u9JpkKMxJqlU/1GXDG2PkYYN6Zsiu4yUbaO bS8lADLFfy8WP+8mAMxkOseQPmZAnhZ5gef7m6fPqXUaF9lwmg1WXl0uYuDVCDftWVUM ijcgmJ6o47/n0oRBbVlImFY5RUrF0zewRaEaE= Received: by 10.223.76.11 with SMTP id a11mr10534877fak.1.1319021642091; Wed, 19 Oct 2011 03:54:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.134.72 with HTTP; Wed, 19 Oct 2011 03:53:42 -0700 (PDT) In-Reply-To: <956FF5FB16AD1C44BED82EF060676E5501E162@G9W0766.americas.hpqcorp.net> References: <956FF5FB16AD1C44BED82EF060676E5501E162@G9W0766.americas.hpqcorp.net> From: Naveen Kottapalli Date: Wed, 19 Oct 2011 16:23:42 +0530 Message-ID: To: "J V, Kishore Kumar (Communication & Media Solutions)" Content-Type: multipart/alternative; boundary=00151747b9b86d8c8704afa4a85a Cc: "dime@ietf.org" Subject: Re: [Dime] DWR & REOPEN Peer State [ReSending] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 10:54:03 -0000 --00151747b9b86d8c8704afa4a85a Content-Type: text/plain; charset=ISO-8859-1 Due to this problem, some of the implementations took violation of RFC and send DWA for received DWR in REOPEN state. Yours, Naveen. On 12 October 2011 11:04, J V, Kishore Kumar (Communication & Media Solutions) wrote: > Description of issue: > > When peer is REOPEN state, any non-DWA message (including DWR) are "thrown > away". This may cause the peer who sent the DWR to failover and when this > issue occurs, this peer can never be in OPEN state. > > Submitter name: Kishore > Submitter email address: Kishore.Kumar-JV@hp.com > > Date first submitted: October/10/2011 > Document: AAATRANS > > Comment type: T > > Priority: S > > Section: Appendix A - Detailed Watchdog Algorithm > > Rationale/Explanation of issue: > Peer-1 and Peer-2 have established diameter connection and they are in OPEN > state. For some reason, Peer-2 loses connection to Peer-1. This causes > Peer-2 to move Peer-1 to "DOWN" state. > When Peer-1 connects again to Peer-2, then Peer-2 moves the state of Peer-1 > to "REOPEN" state. Then it sends a DWR immediately. If Tw period of Peer-2 > happens to be larger than Tw period of Peer-1 ( Eg., Tw(Peer-2) > 3 * > Tw(Peer-1)), then it is possible that a DWR might be received from Peer-1 > before second/third DWR are sent from Peer-2. Since Peer-1 is in "REOPEN" > state in Peer-2, the DWR would Be "thrown away". This causes Peer-1 to > initiate failback. When Peer-1 establishes the connection again, the above > set of events are repeated and hence the state can never change to > [R/I]-OPEN. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --00151747b9b86d8c8704afa4a85a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Due to this problem, some of the implementations took violation of RFC and = send DWA for received DWR in REOPEN state.

Yours,
N= aveen.


On 12 October 2011 11:04, J V, Kishore K= umar (Communication & Media Solutions) <kishore.kumar-jv@hp.com> wro= te:
Description of is= sue:

When peer is REOPEN state, any non-DWA message (including DWR) are "th= rown away". This may cause the peer who sent the DWR to failover and w= hen this issue occurs, this peer can never be in OPEN state.

Submitter name: Kishore
Submitter email address: Kishore= .Kumar-JV@hp.com

Date first submitted: October/10/2011
Document: AAATRANS

Comment type: T

Priority: S

Section: Appendix A - Detailed Watchdog Algorithm

Rationale/Explanation of issue:
Peer-1 and Peer-2 have established diameter connection and they are in OPEN= state. For some reason, Peer-2 loses connection to Peer-1. This causes Pee= r-2 to move Peer-1 to "DOWN" state.
When Peer-1 connects again to Peer-2, then Peer-2 moves the state of Peer-1= to "REOPEN" state. Then it sends a DWR immediately. If Tw period= of Peer-2 happens to be larger than Tw period of Peer-1 ( Eg., Tw(Peer-2) = > 3 * Tw(Peer-1)), then it is possible that a DWR might be received from= Peer-1 before second/third DWR are sent from Peer-2. Since Peer-1 is in &q= uot;REOPEN" state in Peer-2, the DWR would Be "thrown away".= This causes Peer-1 to initiate failback. When Peer-1 establishes the conne= ction again, the above set of events are repeated and hence the state can n= ever change to [R/I]-OPEN.

_______________________________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime

--00151747b9b86d8c8704afa4a85a-- From alisajjad_mushtaq@yahoo.com Thu Oct 20 07:19:25 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5015221F8B5D for ; Thu, 20 Oct 2011 07:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.886 X-Spam-Level: X-Spam-Status: No, score=0.886 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjdVGHHN7CdP for ; Thu, 20 Oct 2011 07:19:24 -0700 (PDT) Received: from nm5.bullet.mail.bf1.yahoo.com (nm5.bullet.mail.bf1.yahoo.com [98.139.212.164]) by ietfa.amsl.com (Postfix) with SMTP id E0ACF21F8B45 for ; Thu, 20 Oct 2011 07:19:23 -0700 (PDT) Received: from [98.139.212.146] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 20 Oct 2011 14:19:20 -0000 Received: from [98.139.212.194] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 20 Oct 2011 14:19:20 -0000 Received: from [127.0.0.1] by omp1003.mail.bf1.yahoo.com with NNFMP; 20 Oct 2011 14:19:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 164946.39142.bm@omp1003.mail.bf1.yahoo.com Received: (qmail 13144 invoked by uid 60001); 20 Oct 2011 14:19:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1319120360; bh=MoEk2ppUwJlvyNCxf8TX50g4heg/j84LumnBtdiuMAA=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ngJ9sKhu0biIWWPARU5ubyUgN+arNRfs4K3aog4f9FsH4H52+AsGNaEtknQYkdVYMkmCcycgT2yx58AmTwLNmc1dA3JJOsgIE9WQm09yhGZpm2ISAhnetT33eHhksAMsgYH59+Qh51LHTi1i0WCAfQjnxxvNpt90IpWmZLYKBf0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=DBqrrWrfiHXzfcS/eyh86EbzxRCoigFHlMtwZNjBbthSynM6BsWO1zIjNQIVqpw2KyNMrtHFxfLzq/PuXvuR3b/xLp2Up89w32C5bNrvJ8DIkisRGziBVAGXsCk/++LJUsUWaou5a2T/JxiyZAQ5+/hQ8zcMUwK3oNRdC9/fOjg=; X-YMail-OSG: gQi.7zUVM1krO0Ffmrzus0Th80PjP5x3sS0MArbgMsZcxtY HGJ1RGg3SM1NtqPn9tlJeDaOoZSqtxi543hjcFT3oQQ0lyI0Z.FCB3uLiEQ7 8x._2Qdfjb09KDVh2WO2jaR3zI9SX7Exmdn6.rV390YMiC5g3k0KrHnl9q_j MIGOWi_L6jo7JcKXJDhQ8_lSv7LykZEabUleVHi9ZWBAo7T8BTCn2MJZt0_X 0ISx52nVRPA8nwA3jmbp9udnI91CivXcRg1GM5o2lD3kWX8.eRavzVf7OZhD sKiS8W9byWy76qtmOv0qWbYdb2KK43QHht6.v0J.7o6NyCAZ1dsY3yjqAhbi pFZCHYYTS_xHA1P63H6AZ1St3go0fGGD2t..Fr.OoPT0drymo5ZtFdNrsuqu jkxRQqXgyRsZb4oaYmj.TZsjyvudbGHBjXWhxeRAT_mIbMI9Mhh1PDoKIk6b DSnXSpLlfPxOLaSbSSrXe2pTwocHJvdyPYaEwbrYE2_BqzMNOljCJ9a1KIIK ugjLTHJMS.5IWZeA5BRxc9g8m8VDih.02UbSbthhcaIvEq8IeqvMVzXbjM.. O46zVHwp2Gb3zY7L.FTRf.pxQ1GAafBUJr3M2mX8m5m_b2EV2p3hcD48j7o3 O.f8qD6_cCKFTgtvfWTvPTYQWcSAwgiQz8KYbW8AmGMqF Received: from [192.108.117.66] by web160313.mail.bf1.yahoo.com via HTTP; Thu, 20 Oct 2011 07:19:19 PDT X-Mailer: YahooMailWebService/0.8.114.317681 References: <1319111758.11785.YahooMailNeo@web161302.mail.bf1.yahoo.com> Message-ID: <1319120359.55090.YahooMailNeo@web160313.mail.bf1.yahoo.com> Date: Thu, 20 Oct 2011 07:19:19 -0700 (PDT) From: Sajjad Ali Mushtaq To: "dime@ietf.org" In-Reply-To: <1319111758.11785.YahooMailNeo@web161302.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="2025718379-196607314-1319120359=:55090" Subject: [Dime] Fw: Call for Papers: (ICC2012) SaCoNeT-III X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sajjad Ali Mushtaq List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:19:25 -0000 --2025718379-196607314-1319120359=:55090 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=A0=0A=A0=0APlease accept our apologies in advance, if you receive th= is CFP multiple times.=0A=0A=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D =0APlease Spread the word!=0A=0ACall for Papers=0A=0A3rd IEEE Internati= onal Workshop on SmArt COmmunications in NEtwork Technologies (SaCoNeT-III)= =0A=0Ahttp://www.lissi.fr/saconet2012/doku.php=0A=0Ato be held in conjuncti= on with IEEE ICC 2012 Conference=0Athat will be held in Ottawa, Canada, Jun= e 11, 2012.=0A=0AFor paper submission, please follow the following link.=0A= =0Ahttp://edas.info/N11473=0A=0A=0APaper submission deadline November 30, 2= 011=0A=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0AAs continuity of t= he first and the second edition of SaCoNeT =0Aworkshop, the scope of SaCoNe= T-III is to deal with the growing overlap =0Abetween both autonomous system= s and the future generation of network =0Atechnologies embedded in Internet= and cloud computing for a wide variety of applications (underwater, vehicu= lar, medical, robotic, etc.). =0ASaCoNet focused on how smart communication= s has affect some aspects =0A(protocols, design, equipment, algorithms, par= adigm, power, etc.) for a =0Alarge family of applications (Healthcare, Medi= cal, Underwater, =0AVehicular, Robotic, etc.) using network technologies (S= ensor Networks, =0AMaNet, VANET, etc.). Indeed, autonomous applications emb= edded in complex configurations and dynamic environments have rapidly expan= ded from =0Aclassical applications where different modular devices, actuato= rs and =0Asensors interact closely. This has impacted considerably the cont= rol of a given system in a centralized manner. Current trends are to propos= e new autonomic architecture schemes that manage and control =0Afuture emer= ging networks: sky of clouds, Internet of things, etc. =0AHealthcare and we= llness applications such as helping elderly people, =0Aassisting dependent = persons, habitat monitoring in a smart environment =0Aconstitute some of th= e potential scenarios of convergence between =0Aautonomous systems and smar= t network technologies. These applications, =0A(which are based on high-lev= el commands) accomplish some specific tasks, reveal new challenges regardin= g mechanic design, portability, =0Aacceptability, power support and efficie= ncy, control theory, etc. In =0Aaddition to portability and low-power syste= ms, which are vital =0Achallenges that limit substantially the efficiency o= f any autonomous =0Asystem based application; network paradigms should also= take into =0Aaccount issues related to cost, scalability and security. Thi= s workshop =0Awill highlight the overlapping of these two domains of autono= mous =0Asystems and the smart network technologies devoted for different ap= plications for a =0Alarge variety of domains: Healthcare, Medical, Underwat= er, Vehicular, =0ARobotic, etc. Issues related to concepts, new technologie= s, testbeds and trials, and protocols will elicit particular attention.=0A= =0AThe workshop solicits papers addressing the following topics:=0A=0A=A0= =A0=A0 Smart Communications for Cloud Computing and Internet of things=0A= =A0=A0=A0 Architecture and protocol for wireless based sensor networks=0A= =A0=A0=A0 Vehicular applications of autonomous behavior=0A=A0=A0=A0 Underwa= ter applications=0A=A0=A0=A0 Rural applications=0A=A0=A0=A0 Autonomous mani= pulation using service robots=0A=A0=A0=A0 Virtual networks and distributed = Agent Platform=0A=A0=A0=A0 Pervasive communication in autonomous applicatio= n fields=0A=A0=A0=A0 Rehabilitation robotics, exoskeletons, smart textile c= lothes and=0A wearable robots applications=0A=A0=A0=A0 Context-awareness an= d ubiquitous robotics=0A=A0=A0=A0 Secure, scalable and low cost network par= adigms applications=0A=A0=A0=A0 Techniques of sensing, actuation and recogn= ition=0A=A0=A0=A0 Vehicular applications of autonomous behavior=0A=A0=A0=A0= Underwater applications=0A=A0=A0=A0 Rural applications=0A=A0=A0=A0 Design = modeling and control of autonomous robotic systems=0A=A0=A0=A0 Assistive ro= botic technology=0A=A0=A0=A0 Energy optimization of autonomous systems=0A= =A0=A0=A0 Monitoring and security of autonomous systems in intelligent envi= ronment=0A=A0=A0=A0 Context awareness using sensor networks=0A=A0=A0=A0 Net= work based transmission architecture for controlling autonomous systems=0A= =A0=A0=A0 Real-time network based structure using sensors, actuators and tr= ansducers=0A=0AAll=0A=0A submitted papers will be rigorously reviewed and w= e will select papers =0Abased on their originality, timeliness, significanc= e, and relevance to =0Athe workshop. All accepted papers must be presented = and at least on =0Aauthor needs to register for the paper to be included in= the workshop =0Aproceedings. Submitted papers should not be under consider= ation for =0Apublication anywhere else.=0A=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=0A=0A=0ABest regards,=0A=0A=0A_____________________________= ___=0ANadeem Javaid, Ph.D. Wireless Networks (University of Paris-Est, Fran= ce),=0AAssistant Professor, Dept. of Electrical Engineering,=0ACOMSATS Inst= itute of IT, Park Road, Chak-Shahzad, 44000, Islamabad, Pakistan.=0Anadeemj= avaid@comsats.edu.pk/@ieee.org/@yahoo.com,=0AOffice#: +92 (0)51 9049207,Mob= ile#: +92 (0)300 5792728.=0Ahttp://ww3.comsats.edu.pk/faculty/FacultyDetail= s.aspx?Uid=3D1211 --2025718379-196607314-1319120359=:55090 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

 
<= div style=3D"color:#000;background-color:#fff;font-family:arial, helvetica,= sans-serif;font-size:10pt;">
 
Please accept our apolog= ies in advance, if you receive this CFP multiple times.
=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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A
=0A
Please Spread the word!

Cal= l for Papers
=0A

3rd IEEE International W= orkshop on SmArt COmmunications in NEtwork Technologies (SaCoNeT-III)

=0A=0A=0A=0A

to be held in conjunction wit= h IEEE ICC 2012 Conference
that will be held in Ottawa, Canada, June 11= , 2012.
=0A
=0AFor paper submission, please follow th= e following link.
=0A
=0A http://edas.info/N11473
=0A

Paper submission deadline November 30, 2011
=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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=0A=0A
As conti= nuity of the first and the second edition of SaCoNeT =0Aworkshop, the scope= of SaCoNeT-III is to deal with the growing overlap =0Abetween both autonom= ous systems and the future generation of network =0Atechnologies embedded i= n Internet and cloud computing for a wide variety=0A of applications (under= water, vehicular, medical, robotic, etc.). =0ASaCoNet focused on how smart = communications has affect some aspects =0A(protocols, design, equipment, al= gorithms, paradigm, power, etc.) for a =0Alarge family of applications (Hea= lthcare, Medical, Underwater, =0AVehicular, Robotic, etc.) using network te= chnologies (Sensor Networks, =0AMaNet, VANET, etc.). Indeed, autonomous app= lications embedded in complex=0A configurations and dynamic environments ha= ve rapidly expanded from =0Aclassical applications where different modular = devices, actuators and =0Asensors interact closely. This has impacted consi= derably the control of a=0A given system in a centralized manner. Current t= rends are to=0A propose new autonomic architecture schemes that manage and = control =0Afuture emerging networks: sky of clouds, Internet of things, etc= . =0AHealthcare and wellness applications such as helping elderly people, = =0Aassisting dependent persons, habitat monitoring in a smart environment = =0Aconstitute some of the potential scenarios of convergence between =0Aaut= onomous systems and smart network technologies. These applications, =0A(whi= ch are based on high-level commands) accomplish some specific tasks,=0A rev= eal new challenges regarding mechanic design, portability, =0Aacceptability= , power support and efficiency, control theory, etc. In =0Aaddition to port= ability and low-power systems, which are vital =0Achallenges that limit sub= stantially the efficiency of any autonomous =0Asystem based application; ne= twork paradigms should also take into =0Aaccount issues related to cost, sc= alability and security. This workshop =0Awill highlight the overlapping of = these two domains of autonomous =0Asystems and the=0A smart network technol= ogies devoted for different applications for a =0Alarge variety of domains:= Healthcare, Medical, Underwater, Vehicular, =0ARobotic, etc. Issues relate= d to concepts, new technologies, testbeds and=0A trials, and protocols will= elicit particular attention.

The workshop solicits papers addressin= g the following topics:

    Smart Communications for = Cloud Computing and Internet of things
    Architecture a= nd protocol for wireless based sensor networks
    Vehicu= lar applications of autonomous behavior
    Underwater ap= plications
    Rural applications
    A= utonomous manipulation using service robots
    Virtual n= etworks and distributed Agent Platform
    Pervasive comm= unication in autonomous application fields
    Rehabilita= tion robotics, exoskeletons, smart textile clothes and=0A wearable robots a= pplications
    Context-awareness and ubiquitous robotics=
    Secure, scalable and low cost network paradigms appl= ications
    Techniques of sensing, actuation and recogni= tion
    Vehicular applications of autonomous behavior    Underwater applications
    Rural app= lications
    Design modeling and control of autonomous r= obotic systems
    Assistive robotic technology
 =    Energy optimization of autonomous systems
   = ; Monitoring and security of autonomous systems in intelligent environment<= br>    Context awareness using sensor networks
 &nbs= p;  Network based transmission architecture for controlling autonomous= systems
    Real-time network based structure using sens= ors, actuators and transducers

All=0A=0A submitted papers will be ri= gorously reviewed and we will select papers =0Abased on their originality, = timeliness, significance, and relevance to =0Athe workshop. All accepted pa= pers must be presented and at least on =0Aauthor needs to register for the = paper to be included in the workshop =0Aproceedings. Submitted papers shoul= d not be under consideration for =0Apublication anywhere else.
=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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Best regards,
<= font style=3D"font-family:bookman old style, new york, times, serif;color:r= gb(33, 33, 67);" class=3D"yiv5100862Apple-style-span" color=3D"#00007f" siz= e=3D"2">Nadeem Javaid, Ph.D. Wireless Networks (University of Paris-Est, Fr= ance),
Assistant Prof= essor, Dept. of Electrical Engineering,
COMSATS = Institute of IT, Park Road, Chak-= Shahzad, 44000, Islamabad, Pakistan.
nadeemjavaid@comsats.edu.pk/@ieee.org/@yahoo.com,
Office#: +92 (0)51 9049207, Mobile#: +92 (0)300 5792728.
http://ww3.comsats.edu.pk/faculty/FacultyDetails.aspx?Uid=3D1211
=


--2025718379-196607314-1319120359=:55090-- From internet-drafts@ietf.org Tue Oct 25 08:17:40 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA36221F8B8D; Tue, 25 Oct 2011 08:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbx1c9X796zH; Tue, 25 Oct 2011 08:17:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A6F21F8B19; Tue, 25 Oct 2011 08:17:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111025151740.15705.6508.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 08:17:40 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-nat-control-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 15:17:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Network Address and Port Translation Control Ap= plication Author(s) : Frank Brockners Shwetha Bhandari Vaneeta Singh Victor Fajardo Filename : draft-ietf-dime-nat-control-12.txt Pages : 59 Date : 2011-10-25 This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4-address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device - expanding the existing Diameter-based AAA and policy control capabilities with a Network Address Translators and Network Address and Port Translators control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA- servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server, and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-nat-control-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-nat-control-12.txt From Internet-Drafts@ietf.org Mon Oct 31 08:45:02 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA12321F8CF2; Mon, 31 Oct 2011 08:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d8tgCsBdyRL; Mon, 31 Oct 2011 08:45:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274EF21F8D58; Mon, 31 Oct 2011 08:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031154502.30139.4348.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 08:45:02 -0700 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-priority-avps-05.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 15:45:03 -0000 --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 Priority Attribute Value Pairs Author(s) : K. Carlberg, et al Filename : draft-ietf-dime-priority-avps-05.txt Pages : 8 Date : 2011-10-31 This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the AAA framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-priority-avps-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dime-priority-avps-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-10-31084418.I-D@ietf.org> --NextPart--