Re: [Pana] Explicit error indication

[Yoshihiro Ohba <[e-mail]>]

Hi Alper,

In the first part of your email, PRE-to-PRE error indication is
mentioned.  I only considered PRE-to-PaC error indication in my
previous email, but I think we can support PRE-to-PRE error indication
as well.  I think both PRY with an error indication AVP and a new
error indication message can be workable here, but
a Result-Code AVP may not be appropriate for temporal errors (see
below) because the use of a Result-Code AVP is to indicate whether EAP
authentication was completed successfully.

For PRE-to-PaC error indication, I thought that using a
Result-Code for that purpose has an impact on existing RFC 5191
implementations that do not expect to receive a Result-Code in the
first PAR with the 'S' bit set, because in the current use of a
Result-Code is for the last PAR message with the 'C' bit set, but RFC
5191 explicitly prohibits to set both the 'S' bit and 'C' bit at the
same time.  So I thought defining a new message (just as we define
PRY) has less impact on RFC 5191 as an implementation that does not
support the new message will simply discard the message and the
initial PAR-PAN exchange part is kept intact.  Maybe I am missing
something.  If a Result-Code in the initial PAR works without
impacting on RFC 5191, then I am also ok with it.

Regarding types of error, some error can be temporary.  For example,
temporal buffer shortage or temporal routing fluctuations (e.g., even
if the PRE has the  PAA information there may be no next hop towards
the PAA), both can be recoverable (so a PaC may retry PANA
authentication later on).  I think it would be good we can
support both non-temporal and temporal errors as long as the impact on
RFC 5191 is low.

Regarding which session identifier should be used for a new message
for error indication, I think the session id contained in the message
that caused the error should be used.  When the error indication
message is sent in response to PCI or PRY, then session id is zero,
otherwise non-zero.

Regards,
Yoshihiro Ohba



(2011/05/30 17:52), Alper Yegin wrote:
> 
> 
> For relaying already relayed messages... The Result-Code AVP (something like
> MULTIPLE-RELAYING-DISALLOWED) would be included in the PRY message sent from
> one PRE to the other.
> In response to a PRY that was received from the latter one.
> 
> How seq no and PANA SA are used for PRY is already defined. There'd not be
> any special considerations here.
> 
> Right?
> 
> 
> The other Result-Code would be something like RELAY-REJECTED-NO-PAA-INFO.
> This can be carried in a PAR in response to the PCI received from the PaC.
> (Defining it in response to any other message is less justified [why would
> PER lose the PAA info in the middle of a session relaying?], and also less
> trivial [what would the session id be set to??]
> 
> I'm trying to see if we can achieve this with the minimum impact.
> 
> I don't think we need a new message. We just need new Result-Codes.
> 
> 
> We shouldn't have to touch RFC 5191.
> 
> Alper
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Jari Arkko
>> Sent: Monday, May 30, 2011 9:48 AM
>> To: Yoshihiro Ohba
>> Cc: Ralph Droms; [e-mail]
>> Subject: Re: [Pana] Explicit error indication
>>
>> That would work for me.
>>
>> Jari
>>
>> Yoshihiro Ohba kirjoitti:
>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Pana mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pana
> 
>