[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
> 
>