Subject: [Dime] Redundancy support AVPs

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 21 Nov 2006 10:02:16 -0500

Hi All,

During the interoperability testing there were some ideas about having more
support in Diameter to facilitate redundant implementations. I guess also
during some threads in DIME WG similar opinions were expressed. During the
last IETF DIME WG meeting, I had the chance to briefly mention about this
issue as well and said that I will provide some text for review/to get
opinions.

The initial version of the text is below. I also entered it to the issue
tracker (#25). Does this look good to others? Shall/can we include this in
the bis?

   Thanks,
   Tolga

============================================================================
=
Some generic support to preserve opaque session data in messages and to
communicate server support for session level failover could be very useful
to facilitate development of redundant systems.

The following changes are proposed:

================================================================
8.22
Session-Info AVP is used by application sessions to store session related
opaque data in the messages. This AVP carries state information that are
communicated between Diameter application end-points only. It provides
applications with a generic method to store opaque data in messages for high
availability, redundancy or other purposes that may not be defined in the
Diameter application itself.

                                            AVP Flag Rules
                  AVP   Data                     SHLD  MUST  MAY
Attribute Name    Code  Type         MUST  MAY   NOT   NOT  Encr
Session-Info       XYZ  Grouped        M    P           V     Y
Origin-Host        264  DiamIdent      M    P           V     Y
Session-Data       XYZ  OctetString    M    P           V     Y

Session-Info AVP
The Session-Info AVP (AVP code xyz) is of type Grouped and is used by
Diameter entities serving as application endpoints to send and receive
session related opaque data. An application originating a request or answer
message MAY include the Session-Info AVP in the message. The receiver of the
message that includes a Session-Info AVP inserted by the remote peer MUST
include the same Session-Info AVP in the subsequent request or answer
messages. Diameter endpoints MAY update the opaque data carried in
Session-info AVP. Diameter endpoints MUST use the last received Session-Info
AVP in the subsequent request and answers they generate.

     Session-Info ::= < AVP Header: XYZ >
			{ Origin-Host }
			{ Session-Data }

Origin-Host AVP
The Origin-Host AVP contains the identity of the host that added the
Session-Info AVP.

Session-Data AVP
The Session-Data AVP (AVP code xyz) is of type OctetString and contains
opaque session related data. The maximum length of Session-Data AVP is 4096
octets. An endpoint receiving a Session-Data AVP more than 4096 octets in
size MUST terminate the session.

Addition to 10.1
                          Command Code
Attribute Name   CER CEA DPR DPA DWR DWA RAR RAA ASR ASA STR STA
Session-Info      0   0   0   0   0   0   0+  0+  0+  0+  0+  0+

Addition to 10.2
                           Command Code
Attribute Name    ACR ACA
Session-Info       0+  0+

=================================================
8.23
Application-Failover-Info AVP is used by applications that can support
failover at the application level. It can be used by any applications for
communicating information regarding backup or alternate nodes which can
takeover traffic for an ongoing session in case of failover. This allows a
sessions to retransmit messages to the alternate node if present. Note that
the application level failover is independent of the base protocol failover
but both can be used concurrently.

                                                          AVP Flag Rules
                                AVP   Data                     SHLD  MUST
MAY
Attribute Name                  Code  Type         MUST  MAY   NOT   NOT
Encr
Application-Failover-Info       XYZ  Grouped        M    P           V     Y
Application-Failover-Host       XYZ  DiamIdent      M    P           V     Y
Application-Failover-Priority   XYZ  Unsigned32     M    P           V     Y

Application-Failover-Info AVP
The Application-Failover-Info AVP (AVP code xyz) is of type Grouped and is
used by a Diameter endpoint to communicate information about its backup
peers, which can takeover traffic for ongoing sessions, in case this
Diameter endpoint fails. There may be multiple Application-Failover-Info
AVPs present in a message.

     Application-Failover-Info ::= < AVP Header: XYZ >
				   { Application-Failover-Host }
				   { Application-Failvoer-Priority }

Application-Failover-Host
The Application-Failover-Host AVP (AVP code xyz) is of type DiameterIdentity
and contains the identity of a backup host, which is able to takeover
traffic for ongoing sessions active on the host, which originated the
message containing this AVP.

Application-Failover-Priority
The Application-Failover-Priority AVP (AVP code xyz) is of type Unsigned32.
It contains the priority associated with a backup host. When messages need
to be retransmitted on application level for an ongoing session, the backup
host with the highest Application-Failover-Priority value SHOULD be tried
first. A bigger Application-Failover-Priority AVP value indicates that the
corresponding backup server is preferred. It is up to the implementations to
choose between two backup hosts with the same Application-Failover-Priority
value.

Addition to 10.1
                                               Command Code
Attribute Name                 CER CEA DPR DPA DWR DWA RAR RAA ASR ASA STR
STA
Application-Failover-Info      0   0   0   0   0   0   0+  0+   0   0   0
0

Addition to 10.2
                               Command Code
Attribute Name                  ACR ACA
Application-Failover-Info       0+  0+

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

---

From: <[email-masked]>
Date: Wed, 22 Nov 2006 15:57:26 +0530

Hi Tolga,
	According to me, the AVPs you suggested are very much required
and needs to be added in bis, but it will be useful if you clarify the
following two small points.

1) Is there any specific reason for length constraint(4096) on
Session-Data AVP?

2) Does it more helpful if we add some text saying that these AVPs MAY
included in any 'service specific requests/responses' (not just in
RAR,ASR,STR ..etc).

Thanks
Prasad.

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Tuesday, November 21, 2006 8:32 PM
To: [email-masked]
Subject: [Dime] Redundancy support AVPs

Hi All,

During the interoperability testing there were some ideas about having
more
support in Diameter to facilitate redundant implementations. I guess
also
during some threads in DIME WG similar opinions were expressed. During
the
last IETF DIME WG meeting, I had the chance to briefly mention about
this
issue as well and said that I will provide some text for review/to get
opinions.

The initial version of the text is below. I also entered it to the issue
tracker (#25). Does this look good to others? Shall/can we include this
in
the bis?

   Thanks,
   Tolga

========================================================================
====
=
Some generic support to preserve opaque session data in messages and to
communicate server support for session level failover could be very
useful
to facilitate development of redundant systems.

================================================================
8.22
Session-Info AVP is used by application sessions to store session
related
opaque data in the messages. This AVP carries state information that are
communicated between Diameter application end-points only. It provides
applications with a generic method to store opaque data in messages for
high
availability, redundancy or other purposes that may not be defined in
the
Diameter application itself.

                                            AVP Flag Rules
                  AVP   Data                     SHLD  MUST  MAY

Session-Info AVP
The Session-Info AVP (AVP code xyz) is of type Grouped and is used by
Diameter entities serving as application endpoints to send and receive
session related opaque data. An application originating a request or
answer
message MAY include the Session-Info AVP in the message. The receiver of
the
message that includes a Session-Info AVP inserted by the remote peer
MUST
include the same Session-Info AVP in the subsequent request or answer
messages. Diameter endpoints MAY update the opaque data carried in
Session-info AVP. Diameter endpoints MUST use the last received
Session-Info
AVP in the subsequent request and answers they generate.

Origin-Host AVP

Session-Data AVP
The Session-Data AVP (AVP code xyz) is of type OctetString and contains
opaque session related data. The maximum length of Session-Data AVP is
4096
octets. An endpoint receiving a Session-Data AVP more than 4096 octets
in
size MUST terminate the session.

Addition to 10.1
                          Command Code

Addition to 10.2
                           Command Code
Attribute Name    ACR ACA
Session-Info       0+  0+

=================================================
8.23
Application-Failover-Info AVP is used by applications that can support
failover at the application level. It can be used by any applications
for
communicating information regarding backup or alternate nodes which can
takeover traffic for an ongoing session in case of failover. This allows
a
sessions to retransmit messages to the alternate node if present. Note
that
the application level failover is independent of the base protocol
failover
but both can be used concurrently.

                                                          AVP Flag Rules
                                AVP   Data                     SHLD
MUST
MAY
Attribute Name                  Code  Type         MUST  MAY   NOT   NOT
Encr
Application-Failover-Info       XYZ  Grouped        M    P           V
Y
Application-Failover-Host       XYZ  DiamIdent      M    P           V
Y
Application-Failover-Priority   XYZ  Unsigned32     M    P           V
Y

The Application-Failover-Info AVP (AVP code xyz) is of type Grouped and
is

The Application-Failover-Host AVP (AVP code xyz) is of type
DiameterIdentity

Application-Failover-Priority
The Application-Failover-Priority AVP (AVP code xyz) is of type
Unsigned32.
It contains the priority associated with a backup host. When messages
need
to be retransmitted on application level for an ongoing session, the
backup
host with the highest Application-Failover-Priority value SHOULD be
tried
first. A bigger Application-Failover-Priority AVP value indicates that
the
corresponding backup server is preferred. It is up to the
implementations to
choose between two backup hosts with the same
Application-Failover-Priority
value.

Addition to 10.1
                                               Command Code
Attribute Name                 CER CEA DPR DPA DWR DWA RAR RAA ASR ASA
STR
STA
Application-Failover-Info      0   0   0   0   0   0   0+  0+   0   0
0
0

Addition to 10.2
                               Command Code
Attribute Name                  ACR ACA

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.8/539 - Release Date:
11/19/2006

---

From: Preeti Shandilya <[email-masked]>
Date: Wed, 22 Nov 2006 09:56:39 +0530

Hi Tolga !

I have few suggestion in this regard.

1. Send  Application failover AVP in CER/CEA only. Inform peer node about 
the redundant node during capability exchange
2. Enhance  Application failover AVP to include Auth-Application-Id AVP 
and Acct-Application-Id AVP as well to indicate for what kind of 
application redundancy support is available.

In this method, node will have to process this AVP only during capability 
exchange and nodes will update its' database for redundant nodes.
I have captured this in following figure

Node1 shall send Application-Failover-Priority as 1(high) and Node2 shall 
send Application-Failover-Priority as 2(low). Peer node will always send 
messages to Node1 only as it is on high priority. Incase of Node1 fails, 
peer node shall start sending data to Node2.

Let me know if this approach has any problem.

Regards
Preeti

"Tolga Asveren" <[email-masked]> 
11/21/2006 08:32 PM

To
<[email-masked]>
cc

Subject
[Dime] Redundancy support AVPs

Hi All,

   Thanks,
   Tolga

                                            AVP Flag Rules
                  AVP   Data                     SHLD  MUST  MAY

Session-Info AVP

Origin-Host AVP

Session-Data AVP

Addition to 10.1
                          Command Code

Addition to 10.2
                           Command Code
Attribute Name    ACR ACA
Session-Info       0+  0+

                                                          AVP Flag Rules
                                AVP   Data                     SHLD  MUST
MAY

     Application-Failover-Info ::= < AVP Header: XYZ >
                                                                    { 
Application-Failover-Host }
                                                                    { 
Application-Failvoer-Priority }

corresponding backup server is preferred. It is up to the implementations 
to

Addition to 10.1
                                               Command Code

Addition to 10.2
                               Command Code
Attribute Name                  ACR ACA

***********************  Aricent-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Aricent  and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 22 Nov 2006 11:33:38 -0500

Hi,

> 1) Is there any specific reason for length constraint(4096) on

I think the idea was to mimic the constraints set by Class AVP but we 
can remove this restriction since Session-Data is opaque.

> included in any 'service specific requests/responses' (not just in

The AVPs are not limited to base protocol messages only. They are for 
general end-to-end use and can be optionally attached to service 
specific messages. We can add text to clarify this if needed.

regards,
victor

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 22 Nov 2006 11:34:57 -0500

Hi Preeti,

I think there are a few issues related with using CER/CEA for that purpose:

a) It could be the case that a node supports more than one application,
where failover support characteristics are different (this could be
addressed with an Application-Id AVP)
b) This infomration exchange has to happen end-to-end between applications,
they are not neighbors necessarily.

    Thanks,
    Tolga
-----Original Message-----
From: Preeti Shandilya [mailto:[email-masked]]
Sent: Tuesday, November 21, 2006 11:27 PM
To: Tolga Asveren
Cc: [email-masked]
Subject: Re: [Dime] Redundancy support AVPs

Hi Tolga !

1. Send  Application failover AVP in CER/CEA only. Inform peer node about
the redundant node during capability exchange
2. Enhance  Application failover AVP to include Auth-Application-Id AVP and
Acct-Application-Id AVP as well to indicate for what kind of application
redundancy support is available.

Regards
Preeti

"Tolga Asveren" <[email-masked]>
11/21/2006 08:32 PM
To<[email-masked]>
cc
Subject[Dime] Redundancy support AVPs

Hi All,

  Thanks,
  Tolga

                                           AVP Flag Rules
                 AVP   Data                     SHLD  MUST  MAY

Session-Info AVP

Origin-Host AVP

Session-Data AVP

Addition to 10.1
                         Command Code

Addition to 10.2
                          Command Code
Attribute Name    ACR ACA
Session-Info       0+  0+

                                                         AVP Flag Rules
                               AVP   Data                     SHLD  MUST
MAY

Addition to 10.1
                                              Command Code

Addition to 10.2
                              Command Code
Attribute Name                  ACR ACA

***********************  Aricent-Unclassified   ***********************
"DISCLAIMER: This message is proprietary to Aricent  and is intended solely
for the use of
the individual to whom it is addressed. It may contain privileged or
confidential information and should not be
circulated or used for any purpose other than for what it is intended. If
you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this
message. Aricent accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 22 Nov 2006 12:16:49 -0500

Hi Tolga,
> addressed with an Application-Id AVP)
We may need to add clarifying text which says that when this AVP is 
present in a message, redundancy support applies to the application 
specified by the message (app-id in the header or app-id avps etc).

regards,
victor