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-boun...@ietf.org [mailto:pana-boun...@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 _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana
