Subject: [AAA-WG]: Issue 79: Error Handling Editorial Changes

From: Pat Calhoun <[email-masked]>
Date: Thu, 21 Jun 2001 17:01:41 -0700

All,

during the call today, we agreed with Issue 79, that it wasn't necessary for
a new command code (Message-Reject-Answer) to be used when a protocol error
occurs. However, some folks wanted a simpler way to identify that a relay
needs to process the message other than parsing through it looking for the
Result-Code AVP. So, we decided that introducing the 'E' (error) bit in the
header was a very fast and easy way for relays to identify that local processing
of a message is necessary.

Here is a portion of my proposed text (most of the changes is to replace the
term Message-Reject-Answer with something that states that an answer is returned
with the 'E' bit set).

Comments appreciated,

PatC
----

3.0  Diameter Header

   A summary of the Diameter header format is shown below. The fields
   are transmitted in network byte order.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Ver      |                 Message Length                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R P E r r r r r|                  Command-Code                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Vendor-ID                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Hop-by-Hop Identifier                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      End-to-End Identifier                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  AVPs ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

[...]
   Command Flags
      The Command Flags field is eight bits.  The following bits are
      assigned:

         R(equest)   - If set, the message is a request. If cleared, the
                       message is an answer.
         P(roxiable) - If set, the message MAY be proxied. If cleared,
                       the message MUST be locally processed.
         E(rror)     - If set, the message contains a protocol error,
                       and the message will not conform to the ABNF
                       described for this command.  This bit MUST NOT be
                       set in request messages. See section x.x.
         r(eserved)  - this flag bit is reserved for future use, and
                       MUST be set to zero.

[...]
3.2  Command Code ABNF specification

[...]
      header           = "< Diameter-Header:" command-id [r-bit]
                           [p-bit] [e-bit] ">"
[...]
      e-bit            = ", ERR"
                          ; If present, the 'E' bit in the Command
                          ; Flags is set, indication that the answer
                          ; message contains a Result-Code AVP in
                          ; the "protocol error" class.
[...]

9.2  Error Bit

   The 'E' (Error Bit) in the Diameter header is set when the request
   caused a protocol-related error (see section 9.1.3).  When set, the
   answer message will not conform to the ABNF specification for the
   command, and will instead conform to the following ABNF:

   Message Format

      <answer-message> ::= < Diameter Header: code, ERR >
                           < Session-Id >
                           { Origin-Host }
                           { Origin-Realm }
                           { Result-Code }
                           { Destination-Host }
                           [ Origin-State-Id ]
                           [ Error-Reporting-Host ]
                         * [ AVP ]

   Note that the code used in the header is the same that the one found
   in the request message, but with the 'R' bit cleared and the 'E' bit
   set.

Thanks,

PatC

---

From: Jacques Caron <[email-masked]>
Date: Fri, 22 Jun 2001 11:23:07 +0200

Hi,

I still think this is redundant with the 'P' bit. A message with 'R' clear 
and 'P' clear is a non-proxiable answer, and thus something for local 
processing. Then the combination of Command-Code and Result-Code will tell 
the proxy/relay whether it's a CEA or a protocol error.

Also, I think it would be wise to specify which combinations of the flag 
bits are allowed, and what to do if an unallowed combination is received.

As an aside, I would like just for the record [I'm afraid many might feel 
it's too late to make such radical changes :-(] to state that my favorite 
option would be to separate a lot more explicitly the "protocol" part from 
the "application" part (a bit like HTTP vs HTML or SMTP vs RFC822 e-mail, 
etc). I think we are still way too close to the Radius model where we just 
exchange messages on a link, and some happen to be local protocol things 
and others are end-to-end application things. This is not really good for 
the robustness and clarity of the protocol.

This would apply to command-codes (e.g. CER, CEA, DWR, DWA vs AAA, AAR, 
etc.), error-codes, and AVPs (some AVPs are used for routing purposes, such 
as Destination-Host, Destination-Realm, Route-Record..., and are comparable 
to HTTP headers, while others are purely applicative, such as 
Framed-IP-Address, User-Name or EAP-Message, and closer to HTML tags).

This would probably simplify a lot the ABNF, as all "Application" commands 
would not be encumbered with all the "protocol" AVPs, too.

Note that though the changes are radical, it might not require to change 
that much text, so it could still be done pretty quickly. Let me know if 
anyone wants to pursue this [for some reason I doubt it :-(].

Jacques.

>    are transmitted in network byte order.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 22 Jun 2001 11:35:48 -0700

> the proxy/relay whether it's a CEA or a protocol error.

'P' and 'E' are different. A message with the 'E' bit set is still
proxiable, but the 'E' bit is an alert to agents that they should attempt
to take local action. However, if they cannot, they must proxy the 
answer.

> bits are allowed, and what to do if an unallowed combination is received.

The text already does state this. The only rule is that the 'R' and the 'E'
bits cannot be set at the same time. See the text in 'E'.

So, if I understand your second comment, a new result code needs to be created
that states that conflicting bits are set in the header?

> the robustness and clarity of the protocol.

hmmmm.... why does it feel like we are flip-flopping :(

your comment has been noted.... moving on...

> would not be encumbered with all the "protocol" AVPs, too.

it certainly is possible to create new avps that do exactly the same thing
as those defined in the base, but I fail to see the logic in duplicate
functionality.

> anyone wants to pursue this [for some reason I doubt it :-(].

i doubt it, and would need additional clarifying information, like what exactly
are we talking about here.

PatC

---

From: Jacques Caron <[email-masked]>
Date: Sat, 23 Jun 2001 12:01:58 +0200

>to take local action. However, if they cannot, they must proxy the

I think in both cases the messages calls for local action. In some cases, 
the local action might be to forward it further downstream...

>bits cannot be set at the same time. See the text in 'E'.

What about P with the other ones?

>that states that conflicting bits are set in the header?

Yep.

>as those defined in the base, but I fail to see the logic in duplicate

No, the idea is to separate them. I.e, no need to put all the 
"Route-Record", "Destination-Host", "Destination-Realm", "Proxy-State" and 
any other routing-related stuff in the ANBF for AAA/AAR. So you can change 
more easily all the routing part without having to touch all possible 
application commands.

It makes it easier also for proxies/relays that have to understand some 
AVPs (e.g. Session-Timeout) to know which ones they're supposed to know how 
to handle or not.

>are we talking about here.

Well, it's a matter of separating the Diameter protocol in two layers: one 
which takes care of communication over a local link, and one which is 
end-to-end communication.

On a local link, one could exchange the following messages:
- Capabilities-Advertisement
- Device-Watchdog
- Termination-Request
- Protocol-Error
- Application-C2S-Request
- Application-S2C-Request
- Aplication-Answer

[C2S and S2C mean Client-to-Server and Server-to-client, respectively].

Each of those messages would contain AVPs related to their function, in a 
local context. The two Application-*-Requests would contain 
Destination-Realm/Host and Route-Record AVPs, and an "Application-Data" 
grouped AVP that would contain the actual end-to-end command and AVPs. 
Application-Answer could contain just that AVP.

To make extension simpler, the local link command types should have a bit 
structure that makes it easy for an agent to understand what type of 
command is which. Note that for requests, I would also include the type of 
request (auth, accounting...), as proxies that maintain session state need 
to be able to interpret them.

I'm trying to put all that into some clear text, I'll send it as soon as I can.

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 25 Jun 2001 06:40:54 -0700

> the local action might be to forward it further downstream...

Then let's call it additional local action. relaying, or proxying is always
the case. This is a special message that the agent must treat with care. In certain
cases, it may require that the request be forwarded to an alternate agent.

When neither bits are set, normal fast path routing is done.

> What about P with the other ones?

that isn't a problem.

> >that states that conflicting bits are set in the header?

ok.

> I'm trying to put all that into some clear text, I'll send it as soon as I can.

That a whole lotta changes so late in the game....

PatC