[Pana] Explicit error indication
Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp> Mon, 30 May 2011 04:07 UTC
Return-Path: <yoshihiro.ohba@toshiba.co.jp>
X-Original-To: pana@ietfa.amsl.com
Delivered-To: pana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AFAE068C for <pana@ietfa.amsl.com>; Sun, 29 May 2011 21:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.86
X-Spam-Level:
X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBmDf0pMS5PM for <pana@ietfa.amsl.com>; Sun, 29 May 2011 21:07:49 -0700 (PDT)
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFE6E0680 for <pana@ietf.org>; Sun, 29 May 2011 21:07:48 -0700 (PDT)
Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id p4U47hMC005607; Mon, 30 May 2011 13:07:43 +0900 (JST)
Received: (from root@localhost) by arc11.toshiba.co.jp id p4U47hWs008161; Mon, 30 May 2011 13:07:43 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id PAA08158; Mon, 30 May 2011 13:07:42 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id p4U47g67010341; Mon, 30 May 2011 13:07:42 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p4U47fpM018080; Mon, 30 May 2011 13:07:41 +0900 (JST)
Received: from [133.196.17.90] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LLZ0027PQ4T6SA0@mail.po.toshiba.co.jp>; Mon, 30 May 2011 13:07:41 +0900 (JST)
Date: Mon, 30 May 2011 13:07:37 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <4DDDDE0B.4070601@piuha.net>
To: Jari Arkko <jari.arkko@piuha.net>
Message-id: <4DE31809.1040100@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-2022-JP"
Content-transfer-encoding: 7bit
References: <4D5AA4A7.3050104@toshiba.co.jp> <4DDCE436.2010507@piuha.net> <4DDDA869.204@toshiba.co.jp> <4DDDDE0B.4070601@piuha.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
Cc: Ralph Droms <rdroms@cisco.com>, pana@ietf.org
Subject: [Pana] Explicit error indication
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pana>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 May 2011 04:07:50 -0000
Let me start a new thread on this subject. I remember a ZigBee member asked if explicit error indication can be sent by a PRE when a PANA message cannot be relayed for some reasons (buffer shortage, no route to PAA, etc.). I think it would be useful to add such a feature if there is little impact to RFC 5191 to support the feature, as it could reduce unnecessarily retransmissions of PCIs from PaCs. Reduce unnecessarily retransmissions may be good for resource constrained networks such as ZigBee. Explicit error indication can be by means of a new PANA message or a new Result-Code. Processing explicit error indication is like handling exceptions/interruptions. So considerations would be necessarily not to interfere with the PANA sequence number processing rule. Especially this would be the case where an error indication is protected by a PANA SA. I would expect that we don't need to support protected error indication as it would require a complex sequence number processing rule such as a separate sequence number space dedicated to error indications. IMHO, a new PANA message (e.g., PANA-Error-Indication) carrying sequence number of zero (0) may be simple, something like this: PaC PRE ---> PCI <--- PEI[Error-Code="Relay-failed"] // seqno=0 PEI message is unprotected and it can be used only as a hint. Regards, Yoshihiro Ohba (2011/05/26 13:58), Jari Arkko wrote: > Yoshihiro, > >> Let me give some time to analyze the impact of this recommendation. >> > > Ok. I' not claiming that my solution is necessarily the way forward, but > I am worried about the issue. > > Jari > >
- Re: [Pana] Explicit error indication Alper Yegin
- [Pana] PANA relay implementation status Yoshihiro Ohba
- Re: [Pana] PANA relay implementation status Hannes Tschofenig
- Re: [Pana] PANA relay implementation status Basavaraj.Patil
- Re: [Pana] PANA relay implementation status Jari Arkko
- Re: [Pana] PANA relay implementation status Yoshihiro Ohba
- Re: [Pana] PANA relay implementation status Jari Arkko
- [Pana] Explicit error indication Yoshihiro Ohba
- Re: [Pana] Explicit error indication Jari Arkko
- Re: [Pana] Explicit error indication Jari Arkko
- Re: [Pana] Explicit error indication Yoshihiro Ohba
- Re: [Pana] Explicit error indication Alper Yegin
- Re: [Pana] Explicit error indication Yoshihiro Ohba