Re: [Pana] Explicit error indication

I'm fine with using existing messages as well. In fact, that would 
probably be better.

Jari

Alper Yegin kirjoitti:
> 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: pana-bounces@ietf.org [mailto:pana-bounces@ietf.org] On Behalf Of
>> Jari Arkko
>> Sent: Monday, May 30, 2011 9:48 AM
>> To: Yoshihiro Ohba
>> Cc: Ralph Droms; pana@ietf.org
>> 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
>> Pana@ietf.org
>> https://www.ietf.org/mailman/listinfo/pana
>>     
>
>
>   