Subject: [AAA-WG]: Accounting-Multi-Session-Id AVP (draft-mobileip-08)

From: "Bob Kopacz" <[email-masked]>
Date: Sun, 24 Feb 2002 22:18:32 -0500

Hi Tony,

Here's some feedback regarding draft-mobileip-08's treatment of the
Accounting-Multi-Session-Id AVP.

The following lines prefixed with "*" are extracted from
draft-mobileip-08.  The extracted lines includes ALL places where the
Accounting-Multi-Session-Id AVP is mentioned.  I numbered the lines to
make them referencable.

Here goes...

 *01 1.2  Inter-Realm Mobile IP
 *02
 *03 [...]
 *04
 *05 For new sessions, the AAAH MUST create an accounting session
 *06 identifier, which is added to the Accounting-Multi-Session-Id AVP in
 *07 the HAR message sent to the home agent.
 *08
 *09 During the creation of the HAR, the AAAH MUST use a different session
 *10 identifier than the one used in the AMR/AMA (see figure 2). Of
 *11 course, an AAAH MUST use the same session identifier for all HARs
 *12 initiated on behalf of a given mobile node's session. [...]
 *13

(1) According to the Introduction, an AAAH may be session-stateless. I
don't think a session-stateless AAAH can differentiate a new session
from a handoff of an existing session.  Therefore a session-stateless
AAAH couldn't send the same session-id for handoffs, as stated in 
line *11.

So lines *05-*12 should be replaced by:

"During the creation of the HAR, the AAAH MUST use a different session
identifier than the one used in the AMR/AMA.  

"If the AAAH is session-stateful, it should send the same session
identifier for all HARs initiated on behalf of a given mobile node's
session.  

"If the AAAH is not session-stateful, it will manufacture a unique
session-id for every HAR.  (Note--This will not cause a problem for
the HA, who must be able to recognize a handoff even if the AAAH
thinks the session is new; an AAAH may incorrectly view a session as
new when the handoff AMR goes to a different AAAH than the previous
AMR).

"Similarly, a session-stateful AAAH should send the same
Accounting-Multi-Session-Id identifier for all HARs initiated on
behalf of a given mobile node's session, while a session-stateless
AAAH will manufacture a unique Accounting-Multi-Session-Id in every
HAR."

(In a later section, I will propose eliminating the last paragraph
which begins "Similarly...")

 *14 [...]
 *15
 *16 Upon receipt of the HAR, the Home Agent first processes the Diameter
 *17 message. [...]  The Accounting-Multi-Session-Id AVP in
 *18 the HAR MUST be included in the HAA, which is then forwarded to the
 *19 AAAH.
 *20

(2) The last sentence is not quite right.  While the HA does send an
Accounting-Multi-Session-Id AVP in the HAA, it may be a different one
than was received in the HAR. (see lines *44-*46).

 *21 Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer
 *22 (AMA) message, includes the Accounting-Multi-Session-Id that was
 *23 present in the HAA, and the MIP-Home-Agent-Address, [...]
 *24
 *25 1.3  Support for Mobile IP Handoffs
 *26
 *27 [...]
 *28
 *29 Since the new AAAH in the home network MAY not have access to the
 *30 session identifier that was used by the old AAAH, it is necessary for
 *31 the resulting HAR received by the HA to be identified as a
 *32 continuation of an existing session. If the HA receives an HAR for a
 *33 mobile node, with a new session identifier, and the HA can guarantee
 *34 that this request is to extend service for an existing service, then
 *35 the HA MUST be able to modify its internal session state information
 *36 to reflect the new AAAH and session identifier.  The HA MUST also
 *37 issue an STR message with the old session identifier to the AAAH it
 *38 was communicating with when using the old session identifier.
 *39
 *40 It is necessary for accounting records to have some commonality
 *41 across handoffs in order for correlation to occur. Therefore, in the
 *42 event that a home agent receives an HAR with a different Accounting-
 *43 Multi-Session-id AVP (and obviously a different Session-Id AVP), the
 *44 home agent MUST send an HAA with the Accounting-Multi-Session-Id AVP
 *45 that was received by the AAAH in the first HAR for the mobile's
 *46 session. This modified Accounting-Multi-Session-Id AVP will be
 *47 returned to the foreign agent by the AAAH in the AMA. Both the
 *48 foreign and home agents MUST include the Accounting-Multi-Session-Id
 *49 in the accounting messages.
 *50

(3) Since the AAAH must be prepared to have the AAAH-generated
Accounting-Multi-Session-Id overridden by the HA, why don't we just
have the HA always specify the Accounting-Multi-Session-Id?  

The thinking is that the HA is constant over the MN's session, while the
AAAHs and AAAFs and FAs change.  So the HA is in a position to specify a
constant Accounting-Multi-Session-Id, eliminating the extra
complications of a switcheroo.

The proposal here is that the AAAH MUST NOT send a
Accounting-Multi-Session-Id in the HAR.  The HA MUST send a
Accounting-Multi-Session-Id in the HAA.  All of the messages for a
MN's session will have the same value for the
Accounting-Multi-Session-Id AVP.

(4) Since the AAAH may be session-stateless, the HA would send the STR
to the AAAH, as indicated in lines *36-*38, if and only if the AAAH
has changed.

(5) So then lines *29-*50 are replaced by:

"Since the new AAAH in the home network MAY not have access to the
session identifier that was used by the old AAAH, or since the AAAH
may be session-stateless, it is necessary for the resulting HAR
received by the HA to be identified as a continuation of an existing
session. 

"If the HA receives an HAR for a mobile node, with a new session
identifier, and the HA can guarantee that this request is to extend
service for an existing service, then the HA MUST be able to modify
its internal session state information to reflect the (possibly) new
AAAH and new session identifier.  

"If the AAAH is new, the HA MUST also issue an STR message with the old
session identifier to the AAAH it was communicating with when using
the old session identifier.

"It is necessary for accounting records to have some commonality across
handoffs in order for correlation to occur.  Therefore, the home agent
MUST send the same Accounting-Multi-Session-Id AVP value in all HAAs for
the mobile's session.  That is, the HA generates a unique
Accounting-Multi-Session-Id when receiving an HAR for a new session, and
returns this same value in every HAA for the session.

"This Accounting-Multi-Session-Id AVP will be returned to the foreign
agent by the AAAH in the AMA. Both the foreign and home agents MUST
include the Accounting-Multi-Session-Id in the accounting messages."

(6) And if you agree that the HA should generate the
Accounting-Multi-Session-Id, then Section 1.5 "Co-located Mobile Node",
should add the sentence:

"The HA includes the Accounting-Multi-Session-Id AVP in the AMR sent to
the AAAH, as the AAAH may find this a useful tidbit of session-state or
log entry information."

 *51 2.2  AA-Mobile-Node-Answer
 *52
 *53 [...]
 *54
 *55    <AA-Mobile-Node-Answer> ::= < Diameter Header: 260, PXY >
 *56                                [...]
 *57                                [ Accounting-Multi-Session-Id ]
 *58                                [...]
 *59
 *60
 *61 2.3  Home-Agent-MIP-Request
 *62
 *63 [...]
 *64
 *65    <Home-Agent-MIP-Request> ::= < Diameter Header: 262, REQ, PXY >
 *66                                 [...]
 *67                                 { Accounting-Multi-Session-Id }
 *68                                 [...]
 *69
 *70 2.4  Home-Agent-MIP-Answer
 *71
 *72 [...]
 *73
 *74    <Home-Agent-MIP-Answer> ::= < Diameter Header: 262, PXY >
 *75                                [...]
 *76                                [ Accounting-Multi-Session-Id ]
 *77                                [...]
 *78

 *79 8.1  Mobile IP Command AVP Table
 *80
 *81 The table in this section is limited to the Command Codes defined in
 *82 this specification.

(7) The AMR/AMA/HAR/HAA occurrence table doesn't include the
Accounting-Multi-Session-Id AVP.  It needs an entry like:

Attribute Name                | AMR | AMA | HAR | HAA |
------------------------------|-----+-----+-----+-----+
Accounting-Multi-Session-Id   | 0-1 | 1   | 0   | 1   |

 *83
 *84 8.2  Accounting AVP Table
 *85

(8) The Accounting occurrence table doesn't mention the
Accounting-Multi-Session-Id AVP, but it should because the Base protocol
defines the Accounting-Multi-Session-Id AVP, and makes the general
statement that the Accounting-Multi-Session-Id AVP can occur in the ACR
and ACA messages "0-1" times.  But the applications have their own
specific requirements.  The Mobile IPv4 application requires the
following:

Attribute Name                | ACR | ACA |
------------------------------|-----+-----+
Accounting-Multi-Session-Id   | 1   | 0-1 |

(9) The above Accounting occurrence table should indicate any other
application-specific ACR/ACA requirements that are different from the
Base protocol's more general Accounting occurrence table.

Bob K.

---

From: Tony Johansson <[email-masked]>
Date: Tue, 26 Feb 2002 19:19:16 -0800

I tend to agree with you. However, can you please submit this as an issue with
the proposed change so we get this right according to our work process..

Regards,

/Tony