Subject: [Pana] PANA-Error-Request

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 26 Oct 2006 00:56:18 -0400

"
7.14.  PANA-Error-Request (PER)

   The PANA-Error-Request (PER) message is sent either by the PaC or the
   PAA to report an error with the last received PANA message.

   PANA-Error-Request ::= < PANA-Header: 8, REQ >
                        < Session-Id >
                        < Result-Code >
                     *  [ Failed-AVP ]
                        [ Notification ]
                     *  [ AVP ]
                    0*1 < AUTH >
"

It is possible that a sender can send two different messages back to
back.  An example is that the PaC may send a PANA-Auth-Answer 
without piggybacking EAP-Payload AVP and then send PANA-Auth-Request
with an EAP-Payload AVP (see Figure 3).

If the first message is received and contains an error, but the second
message gets lost, then a PER will be generated for the first message
in which case the receiver of the PER will confuse about which message
the PER was sent.

To avoid this situation, it is better to add a new AVP that carries
header information of the message that caused the error.

Proposal:

[1] Change the PANA-Error-Request format to (Session-Id is now moved to
PANA header):

"
   PANA-Error-Request ::= < PANA-Header: 8, REQ >
                        < Result-Code >
                        < Failed-Message >
                     *  [ Failed-AVP ]
                        [ Notification ]
                     *  [ AVP ]
                    0*1 < AUTH >
"

[2] Add the following section.

"
8.X.  Failed-Message AVP

   The Algorithm AVP (AVP Code X) is of type Unsigned64 containing
   Flags, Message Type and Sequence Number fields of the header of the
   message that caused the error.  The AVP Data field is encoded as 
   follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Flags              |         Message Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sequence Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"

Yoshihiro Ohba

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 27 Oct 2006 13:44:05 +0300

>    message that caused the error.  The AVP Data field is encoded as

Actually, why not simply carry the sequence number only. This is sufficient
to identify a unique message within a PANA session.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 27 Oct 2006 10:02:59 -0400

Alper,

Since sequence numbers used for requests generated by PaC and
generated by PAA are independent, it is possible that the sequence
numbers contained in two consecutive messages sent by the same entity
can be the same.  

For example, if the PaC sends a PAN (without EAP-Payload) in response
to a PAR generated by the PAA and then sends a PAR (with EAP-Payload),
then the PAN contains the sequence number assigned by the PAA and
contained in a PAA-generated PAR while the PaC-generated PAR contains
the sequence number assigned by the PaC, the two sequence numbers can
happen to be the same (perhaps with a very low probability).  As a
result, when a PER for one of those messages are generated by the PAA,
the PaC will not able to determine which message caused an error.

So I think Sequence Number is not sufficient to determine the message
that caused the error.

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 27 Oct 2006 20:47:06 +0300

I see.

Than my second thought was, why not carry the whole PANA header? Why is the
bits carried is limited to what you stated?

Alper

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Friday, October 27, 2006 5:03 PM
> To: Alper Yegin
> Cc: 'Yoshihiro Ohba'; [email-masked]
> Subject: Re: [Pana] PANA-Error-Request
> 
> Alper,
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 27 Oct 2006 14:10:56 -0400

> bits carried is limited to what you stated?

This is is because I thought only 'R' bit of Flags, Message Type and
Sequence Number fields are sufficit for message identification.
Version and Message Length fields would not be part of message
identification information.  Session Identifier is not needed because
Session Identifier is the same as that is contained in PER.

However, if the usage of the Failed-Message AVP is more than message
identification, it would make sense to carry the whole PANA header.

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 29 Oct 2006 00:20:30 +0300

I guess I'd have preferred including the whole PANA header and naming the
AVP accordingly. But maybe this is just a "protocol design style" thing, so
I'd not insist.

Alper

> Sent: Friday, October 27, 2006 9:11 PM
> To: Alper Yegin
> > > > >    |            Flags              |         Message Type
> |
> > > > >    |                      Sequence Number
> |

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 29 Oct 2006 09:59:24 -0500

Then how about including the whole PANA header in "Failed-Message-Header" AVP?

It is easier to understand and it is harmless to include more than
message identification information.

Yoshihiro Ohba