Subject: [Dime] DOIC Endpoint behavior -- Capability Exchange

From: Steve Donovan <[email-masked]>
Date: Mon, 03 Feb 2014 17:55:14 -0600

All,

I believe that the current DOIC Endpoint behavior definition is not
sufficiently defined, especially for agents.

There was also a change introduced in the -01 version of the draft that
implies that there can be a DOIC association that goes through a DOIC
enabled agent.  This was not  how I understood endpoints.  The original
diagrams showed a DOIC agent as terminating an endpoint that came to
it.    I suspect there were different assumptions that lead to clearly
different interpretations. 

I propose that we return to the original diagrams and add the wording
below on how DOC agents behave.  One way to look at this is that DOC
agents act as back-to-back DOC endpoints.  I intentionally don't say
back-to-back Diameter endpoints because this does not impact anything
except the handling of DOIC related AVPs.

Note that I don't believe this requires any changes to Diameter clients
or servers.  I also don't believe this requires any changes to the
contents of the DOIC related AVPs but there is an open question as to
whether there is a need to indicate when a OC-Supported-Features AVP is
generated or modified by an agent.

I propose to add the following section to the section on capabilities
announcement.  I'll send a separate email proposing text to section 5.5
on how DOC agents are to behave.

Regards,

Steve

-----

5.3.1 DOC Agent handling of DOIC capability exchange.

A DOC agent is defined as a Diameter agent that supports the DOIC extension.

A DOC node is defined as a Diameter client, Diameter server or Diameter
agent that supports the DOIC extension.

An downstream DOIC Association is defined as the association between the
DOIC supporting Diameter entity that sends a Diameter request message to
a DOC agent and the DOC agent.

A upstream DOIC Association is defined as the association between a DOC
agent and the Diameter entity to which the DOC agent sends the Diameter
request message.  The following illustrated the upstream and downstream
concepts.

  DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC
association--> DOC  node
  Direction of request message for a transaction ----->
  Direction of answer message for a transaction <-----

Four scenarios must be supported:

  - Scenario 1 - There is both an upstream and downstream DOIC association.
  - Scenario 2 - There is no upstream DOIC association
  - Scenario 3 - There is no downstream DOIC association
  - Scenario 4 - No DOIC association in either direction

Scenario 1 - Both upstream and downstream DOIC associations

Request message handling:

A DOC agent that receives a request that contains the
OC-Supported-Features AVP must act as an endpoint for the downstream
DOIC association.

If the DOC agent relays or proxies the request message then the agent
must include an OC-Supported-Features AVP in the relayed message.  The
contents of the OC-Supported-Features AVP must include, at a minimum,
all of the content included in the received OC-Supported-Features AVP. 
If the agent does not support any additional features then the sent
OC-Supported-Features AVP will remain the same as the received
OC-Supported-Features AVP.

If the agent supports DOIC features that are not indicated in the
received OC-Supported-Features AVP then the agent must modify the
OC-Supported-Features AVP to indicate support for those features.  The
modified OC-Supported-Features AVP must be included in the relayed
request message.

  Note: any DOIC extension must define the changes needed to the
OC-Feature-Vector AVP and any additional AVPs that need to be added to
the OC-Supported-Features AVP as part of the capabilities advertisement
for that feature.

Question: Should there be an indication that the contents of the
OC-Supported-Features AVP was changed?

Question: Will this work when end-to-end security is introduced?  Would
adding a separate OC-Supported-Features AVP be better, especially when
end-to-end security is considered?

Answer message handling:

When an agent receives the  answer message that corresponds to the above
request message, the agent must act as the DOIC endpoint for the
upstream DOIC association. 

If the DOC agent relays or proxies the answer message then the agent
must include an OC-Supported-Features AVP in the relayed message.  The
contents of the OC-Supported-Features AVP must include, at a minimum,
all of the content included in the received OC-Supported-Features AVP. 
If the agent does not support any additional features then the sent
OC-Supported-Features AVP will remain the same as the received
OC-Supported-Features AVP.

If the agent supports DOIC features that are not indicated in the
received OC-Supported-Features AVP then the agent should modify the
OC-Supported-Features AVP to indicate support for those features.  The
modified OC-Supported Features AVP must be included in the relayed
answer message.

Scenario 2 - No downstream DOIC association with an upstream association

In this case a request is received that does not contain an
OC-Supported-Features AVP.

Request message handling:

If a DOC agent receives a request that does NOT contain an
OC-Supported-Features AVP then the agent must generate an
OC-Supported-Features AVP reflecting the DOIC features supported by the
DOC agent.  The new OC-Supported-Features AVP must be included in the
relayed/proxied request message.

The agent will then become the reacting DOIC endpoint for the upstream
DOIC association that results from the transaction. 

Note: Section x.x.x defines agent behavior when it is the reacting node
for a DOIC association.

Answer message handling

In this case the answer message will contain an OC-Supported-Features
AVP.  The DOC agent must store the advertised capabilities for use when
the DOC agent reacts to an overload report from the upstream Diameter node.

The DOC agent should remove the OC-Supported-Features AVP from the
answer message before relaying/proxying the answer message. 

Scenario 3 - Downstream DOC association with no upstream DOIC association

In this case a OC-Supported-Features AVP is received in the request from
the downstream Diameter entity but no OC-Supported-Features AVP is
received in the answer message received from the upstream Diameter
entity.  In this case the agent must act as the reporting DOIC endpoint
for the downstream DOIC association.

Request message handling:

Request message handling is the same as for scenario 1.

Answer message handling:

If a DOC agent receives an answer message that does not contain an
OC-Supported-Features AVP for a transaction that includes an upstream
DOC association then the agent must generate an OC-Supported-Features
AVP reflecting the DOIC features supported by the DOC agent.  The
generation of this OC-Supported-Features AVP must also follow the rules
specified in section 5.3.2.  The new OC-Supported-Features AVP must be
included in the relayed/proxied the answer message.

Scenario 4 - No upstream association and no downstream association

Request message handling:

The request message handling in this case is the same as scenario 2.

Answer message handling:

If the DOC agent receives an answer message that does not contain an
OC-Supported-Features AVP for a transaction that does not include a
downstream DOC association then the agent must NOT generate an
OC-Supported-Features AVP.  The DOC Agent must relay/proxy the answer
message with no DOIC related change.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 4 Feb 2014 13:43:37 +0000

Steve,

please find comments inline.

Regards
Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, February 04, 2014 12:55 AM
To: [email-masked]
Subject: [Dime] DOIC Endpoint behavior -- Capability Exchange

All,

I believe that the current DOIC Endpoint behavior definition is not sufficiently defined, especially for agents.
<Ulrich> I agree. </Ulrich>

There was also a change introduced in the -01 version of the draft that implies that there can be a DOIC association that goes through a DOIC enabled agent.  This was not  how I understood endpoints.
<Ulrich> same with me </Ulrich>  The original diagrams showed a DOIC agent as terminating an endpoint that came to it.    I suspect there were different assumptions that lead to clearly different interpretations.  

I propose that we return to the original diagrams and add the wording below on how DOC agents behave.  One way to look at this is that DOC agents act as back-to-back DOC endpoints.  I intentionally don't say back-to-back Diameter endpoints because this does not impact anything except the handling of DOIC related AVPs.

Note that I don't believe this requires any changes to Diameter clients or servers.  I also don't believe this requires any changes to the contents of the DOIC related AVPs but there is an open question as to whether there is a need to indicate when a OC-Supported-Features AVP is generated or modified by an agent.

I propose to add the following section to the section on capabilities announcement.  I'll send a separate email proposing text to section 5.5 on how DOC agents are to behave. 

Regards,

Steve

-----

A DOC agent is defined as a Diameter agent that supports the DOIC extension.
<Ulrich> A Diameter agent that supports the DOIC extension is not necessarily taking the role of a reacting DOIC endpoint.
It only takes the role of a reacting DOIC endpoint when receiving a request that does not contain an OC-Supported-Features AVP.
Similarily a Diameter agent that supports the DOIC extensions is not necessarily taking the role of a reporting DOIC endpoint.
It only takes the role of a reporting DOIC endpoint when receiving a realm type request (not containing a destination host) that contains an OC-Supported-Features AVP while it is configured to act as a reporting DOIC endpoint for that realm. </Ulrich>

A DOC node is defined as a Diameter client, Diameter server or Diameter agent that supports the DOIC extension
<Ulrich> and decided to take the role of a reacting DOIC endpoint and/or reporting DOIC endpoint </Ulrich>.

An downstream DOIC Association is defined as the association between the DOIC supporting Diameter entity that sends a Diameter request message to a DOC agent and the DOC agent.

A upstream DOIC Association is defined as the association between a DOC agent and the Diameter entity to which the DOC agent sends the Diameter request message.  The following illustrated the upstream and downstream concepts.

  DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC association--> DOC  node
  Direction of request message for a transaction ----->
  Direction of answer message for a transaction <-----
<Ulrich> this depends on the point of view: one node's downstream DOIC association is another node's upstream DOIC association. </Ulrich>
<Ulrich> The general case is:

+---------+      +---------+     +--------+     +--------+                          +--------+                +--------+
| client  |      | A1      |     | A2     |     | A3     |                          | A4     |                | server |
| no DOIC |      | no DOIC |     | DOIC   |     | DOIC   |                          | DOIC   |                | DOIC   |
| support |      | support |     | support|     | support|                          | support|                | support| 
+---------+      +---------+     +--------+     +--------+                          +--------+                +--------+
    |                 |              |              |                                 |                             |
    |                 |              |<---DOIC association 1------------------------->|<-------DOIC association 2-->|
    |                 |              |              |                                 |                             |
    |                 |              |<-----------------DOIC association 3----------------------------------------->|
    |                 |              |              |                                 |                             |
    |                 |              |              |                                 |                             |
    |----1.xxR------->|---2.xxR----->|              |                                 |                             |
    |                 |              |---3.xxR----->|----4.xxR----------------------->|                             |
    |                 |              |              |                                 |--------5.xxR--------------->| 
    |                 |              |              |                                 |<-------6.xxA----------------|
    |                 |              |<--8.xxA------|<---7.xxA------------------------|                             |
    |<---10.xxA-------|<--9.xxA------|              |                                 |                             |
    |                 |              |              |                                 |                             |
    |                 |              |              |                                 |                             |
    |                 |              |              |                                 |                             |
    |                 |              |              |                                 |                             |
    |----11.xxR------>|---12.xxR---->|              |                                 |                             |
    |                 |              |---13.xxR---->|-----14.xxR--------------------->|-------15.xxR--------------->|
    |                 |              |              |                                 |                             |
    |                 |              |<---18.xxA----|<----17.xxA----------------------|<-----16.xxA-----------------|
    |<---20.xxA-------|<---19.xxA----|              |                                 |                             |
    |                 |              |              |                                 |                             |
DOIC association 1 is for realm type requests; 
DOIC association 2 is for request for which A4 selects the server
DOIC association 3 is for host type requests

1. the client that does not support DOIC sends 1.xxR (realm type request not containing destination host) to the next hop; 1.xxR does not contain an OC-Supported-Features AVP
2. the agent A1 that does not support DOIC forwards the request to the next hop; 2.xxR still dos not contain an OC-Supported-Feature AVP.
3. the agent A2 that supports DOIC decides to take the role of a reacting endpoint; it inserts an OC-Supported-Features AVP into 3.xxR indicating support of features 1 and 2 (in this example).
4. agent A3, although it supports DOIC, does not take the role of a reacting endpoint (because 3.xxR contains an OC-Supported-Features AVP); it also does not take the role of a reporting endpoint since it is not configured to act as reporting endpoint for the destination realm received in 3.xxR; 4.xxR (unmodified) is sent to the next hop.
5. agent A4 is configured to take the role of the reporting endpoint for the realm. It therefore removes the OC-Supported-Features AVP reveived in 4.xxR and inserts its own supported features (in this example features 1 and 3) in 5.xxR. A4 also selects the server to which 5.xxR is sent.
6. the server (that supports DOIC e.g. features 1 and 3) returns 6.xxA including an OLR1 (host type) requesting a feature 3 specific traffic reduction (e.g. window size 20). 
7. A4 calculates the overall realm overload level, removes the received OLR1 and adds its own calculated realm type OLR2 (e.g. a feature 1 specific traffic reduction of 50%-loss) to 7.xxA. A4 stores OLR1 for later use.
8. A3 not taking any DOIC role forwards the answer unmodified.
9. agent A2 may remove the reveived OLR2 when sending 9.xxA. A2 stores OLR2 for later use.
10. A1 not supporting DOIC is transparent.
11. client sends a new request 11.xxR (containing destination host as learnd from 10.xxA; no OC-Supported-Features AVP included.
12. A1 is transparent.
13. A2 decides to take the role of the reacting endpoint and includes again its supported features 1 and 2 in OC-Supported-Features AVO sent within 13.xxR.
14. A3 is transparent
15. A4 is transparent for host type requests that contain an OC-Supported-Features AVP.
16. server returns 16.xxA including a host type OLR3 requesting a feature 1 specific traffic reduction of e.g. 30%-loss.
17. A4 is transparent
18. A3 is transparent
19. A2 stores OLR3 for later use and may remove OLR3 when sending 19.xxA.
20. client receives 20.xxA.
</Ulrich>

  - Scenario 1 - There is both an upstream and downstream DOIC association.
<Ulrich> for example see A4 in the figure above </Ulrich>
  - Scenario 2 - There is no upstream DOIC association
<Ulrich> do you mean "There is a downstream DOIC association but no upstream DOIC association"? Not covered in the figure above. </Ulrich>
  - Scenario 3 - There is no downstream DOIC association
<Ulrich> do you mean "There is an upstream DOIC association but no downstream DOIC association"? for example see A2 in the figure above </Ulrich> 
  - Scenario 4 - No DOIC association in either direction
<Ulrich> for example see A3 in the figure above </Ulrich>

A DOC agent that receives a request that contains the OC-Supported-Features AVP must act as an endpoint for the downstream DOIC association.
<Ulrich> NO! see A3 receiving 3.xxR or 13.xxR (this may not be scenario 1, but how does the agent know which scenario applies?)</Ulrich>

If the DOC agent relays or proxies the request message then the agent must include an OC-Supported-Features AVP in the relayed message.  The contents of the OC-Supported-Features AVP must include, at a minimum, all of the content included in the received OC-Supported-Features AVP.  If the agent does not support any additional features then the sent OC-Supported-Features AVP will remain the same as the received OC-Supported-Features AVP.
<Ulrich>There cannot be more than one OC-Supported-Features AVPs in one request. An agent that inserts an OC-Supported-Features AVP must remove the received OC-Supported-Features AVP (see A4 when sending 5.xxR). The inserted OC-Supported Features AVP shall indicate the features the inserting node supports, not more, not less</Ulrich>

If the agent supports DOIC features that are not indicated in the received OC-Supported-Features AVP then the agent must modify the OC-Supported-Features AVP to indicate support for those features.  The modified OC-Supported-Features AVP must be included in the relayed request message.

  Note: any DOIC extension must define the changes needed to the OC-Feature-Vector AVP and any additional AVPs that need to be added to the OC-Supported-Features AVP as part of the capabilities advertisement for that feature.

Question: Should there be an indication that the contents of the OC-Supported-Features AVP was changed?
<Ulrich> no. for what reason? </Ulrich>

Question: Will this work when end-to-end security is introduced?  Would adding a separate OC-Supported-Features AVP be better, especially when end-to-end security is considered?
<Ulrich> what is the issue? </Ulrich>

Answer message handling:

When an agent receives the  answer message that corresponds to the above request message
<Ulrich> i.e. the request message into which the agent has inserted its OC-Supported-Features AVP </Ulrich>
, the agent must act as the DOIC endpoint for the upstream DOIC association.  

If the DOC agent relays or proxies the answer message then the agent must include an OC-Supported-Features AVP in the relayed message.
<Ulrich> OC-Supported-Features AVP in answer messages is an open issue </Ulrich>
  The contents of the OC-Supported-Features AVP must include, at a minimum, all of the content included in the received OC-Supported-Features AVP.  If the agent does not support any additional features then the sent OC-Supported-Features AVP will remain the same as the received OC-Supported-Features AVP.

If the agent supports DOIC features that are not indicated in the received OC-Supported-Features AVP then the agent should modify the OC-Supported-Features AVP to indicate support for those features.  The modified OC-Supported Features AVP must be included in the relayed answer message.

Scenario 2 - No downstream DOIC association with an upstream association
<Ulrich> wasn't that scenario 3? </Ulrich>

In this case a request is received that does not contain an OC-Supported-Features AVP.

If a DOC agent receives a request that does NOT contain an OC-Supported-Features AVP then the agent must generate an OC-Supported-Features AVP reflecting the DOIC features supported by the DOC agent.  The new OC-Supported-Features AVP must be included in the relayed/proxied request message.

The agent will then become the reacting DOIC endpoint for the upstream DOIC association that results from the transaction.  

Note: Section x.x.x defines agent behavior when it is the reacting node for a DOIC association.

Answer message handling

In this case the answer message will contain an OC-Supported-Features AVP.  The DOC agent must store the advertised capabilities for use when the DOC agent reacts to an overload report from the upstream Diameter node.

The DOC agent should remove the OC-Supported-Features AVP from the answer message before relaying/proxying the answer message.  

Scenario 3 - Downstream DOC association with no upstream DOIC association
<Ulrich> wasn't this scenario 2? </Ulrich>

In this case a OC-Supported-Features AVP is received in the request from the downstream Diameter entity but no OC-Supported-Features AVP is received in the answer message received from the upstream Diameter entity.  In this case the agent must act as the reporting DOIC endpoint for the downstream DOIC association.
<Ulrich> this is totally new to me. Where does this come from? If a server does not support DOIC it cannot request load reduction from a downstream agent. The downstream agent (even if it would detect the DOIC-non-support of the server) cannot request load reduction from further downstream nodes on behalf of the server </Ulrich>

Answer message handling:

If a DOC agent receives an answer message that does not contain an OC-Supported-Features AVP for a transaction that includes an upstream DOC association then the agent must generate an OC-Supported-Features AVP reflecting the DOIC features supported by the DOC agent.  The generation of this OC-Supported-Features AVP must also follow the rules specified in section 5.3.2.  The new OC-Supported-Features AVP must be included in the relayed/proxied the answer message.

Answer message handling:

If the DOC agent receives an answer message that does not contain an OC-Supported-Features AVP for a transaction that does not include a downstream DOC association then the agent must NOT generate an OC-Supported-Features AVP.  The DOC Agent must relay/proxy the answer message with no DOIC related change.

<Ulrich> the open issue seems to be: How can an agent determine which scenario is applicable? Let me try:
An agent that does not support DOIC is always in scenario 4 (no upstream DOIC association, no downstream DOIC association).
For an agent that supports DOIC:
When receiving a request that does not contain an OC-Supported-Features AVP the agent is in scenario 3 or 4 (no downstream DOIC association). Whether its 3 or 4 depends on whether or not an OLR is received in the corresponding answer.
When receiving a host type request (a request that contains a Destination-Host AVP) that contains an OC-Supported-Feature AVP the agent is in scenario 4 (no upstream DOIC association, no downstream DOIC association)
When receiving a realm type request (a request that does not contain a Destination-Host AVP) that contains an OC-Supported-Feature AVP and the agent is configured to act as reporting node for that realm, the agent is scenario 1 or 2 (there is a downstream DOIC association). Whether its 1 or 2 depends on whether or not an OLR is received in the corresponding answer.
When receiving a realm type request (a request that does not contain a Destination-Host AVP) that contains an OC-Supported-Feature AVP and the agent is configured not to act as reporting node for that realm, the agent is in scenario 4 (no upstream DOIC association, no downstream DOIC association). </Ulrich>

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 7 Feb 2014 10:38:07 +0200

Steve,

On Feb 4, 2014, at 1:55 AM, Steve Donovan <[email-masked]> wrote:

> There was also a change introduced in the -01 version of the draft that implies that there can be a DOIC association that goes through a DOIC enabled agent.  This was not  how I understood endpoints.  The original diagrams showed a DOIC agent as terminating an endpoint that came to it.    I suspect there were different assumptions that lead to clearly different interpretations.  

Yes.. one of the confusion points was how the endpoint is
actually identified, specifically in a case of agents. Is 
that done B2B fashion where the client thinks the agent is
actually the server or whether the client still talks directly
to the server endpoint (and the agent just keeps out of the
DOIC business or participates to it if configured to do so).
The modified figure attempt to cover both.. with little success
apparently; lack of explaining text I would say. 

It is definitive that more text and clarity is needed here.

- JOuni

> A DOC node is defined as a Diameter client, Diameter server or Diameter agent that supports the DOIC extension.
> 
> When an agent receives the  answer message that corresponds to the above request message, the agent must act as the DOIC endpoint for the upstream DOIC association.  
> 
> If the DOC agent relays or proxies the answer message then the agent must include an OC-Supported-Features AVP in the relayed message.  The contents of the OC-Supported-Features AVP must include, at a minimum, all of the content included in the received OC-Supported-Features AVP.  If the agent does not support any additional features then the sent OC-Supported-Features AVP will remain the same as the received OC-Supported-Features AVP.
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 7 Feb 2014 10:44:15 +0200

Gotta hate these mega long mails ;) See inline..

> <Ulrich> The general case is:

Thanks for the diagram. It is pretty thorough.

> <Ulrich> what is the issue? </Ulrich>

With e2e security, modified AVPs fail the integrity check and therefore
are subject to be rejected..

> <Ulrich> OC-Supported-Features AVP in answer messages is an open issue </Ulrich>

I don't think this is an open issue.. we already had supported features
in answers covered Section 5.3.

> When receiving a realm type request (a request that does not contain a Destination-Host AVP) that contains an OC-Supported-Feature AVP and the agent is configured not to act as reporting node for t…

I tend to agree most of <ulrich> assertions. However, I need to reread
this mail/proposal a couple of time since my attention span has difficulties
with very long mails :)

- Jouni

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 10 Feb 2014 10:55:10 +0000

Hello Ulrich et all,

As far as I can follow your comments on diagram, I tend to agree with your proposal, but I cannot fully follow this, since diagram is not properly received.
Is it possible to provide diagram in another format that is not modified by each one email configuration? I think this is very important for discussion and agreement
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: martes, 04 de febrero de 2014 14:44
To: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] DOIC Endpoint behavior -- Capability Exchange

Steve,

Regards
Ulrich

All,

Regards,

Steve

-----

A DOC node is defined as a Diameter client, Diameter server or Diameter agent that supports the DOIC extension <Ulrich> and decided to take the role of a reacting DOIC endpoint and/or reporting DOIC endpoint </Ulrich>.

  DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC association--> DOC  node
  Direction of request message for a transaction ----->
  Direction of answer message for a transaction <----- <Ulrich> this depends on the point of view: one node's downstream DOIC association is another node's upstream DOIC association. </Ulrich> <Ulrich> The general case is:

DOIC association 1 is for realm type requests; DOIC association 2 is for request for which A4 selects the server DOIC association 3 is for host type requests

1. the client that does not support DOIC sends 1.xxR (realm type request not containing destination host) to the next hop; 1.xxR does not contain an OC-Supported-Features AVP 2. the agent A1 that does not support DOIC forwards the request to the next hop; 2.xxR still dos not contain an OC-Supported-Feature AVP.

  - Scenario 1 - There is both an upstream and downstream DOIC association.
<Ulrich> for example see A4 in the figure above </Ulrich>
  - Scenario 2 - There is no upstream DOIC association <Ulrich> do you mean "There is a downstream DOIC association but no upstream DOIC association"? Not covered in the figure above. </Ulrich>
  - Scenario 3 - There is no downstream DOIC association <Ulrich> do you mean "There is an upstream DOIC association but no downstream DOIC association"? for example see A2 in the figure above </Ulrich>
  - Scenario 4 - No DOIC association in either direction <Ulrich> for example see A3 in the figure above </Ulrich>

Answer message handling:

When an agent receives the  answer message that corresponds to the above request message <Ulrich> i.e. the request message into which the agent has inserted its OC-Supported-Features AVP </Ulrich> , the agent must act as the DOIC endpoint for the upstream DOIC association.  

Scenario 2 - No downstream DOIC association with an upstream association <Ulrich> wasn't that scenario 3? </Ulrich>

Answer message handling

Scenario 3 - Downstream DOC association with no upstream DOIC association <Ulrich> wasn't this scenario 2? </Ulrich>

Answer message handling:

Answer message handling:

When receiving a host type request (a request that contains a Destination-Host AVP) that contains an OC-Supported-Feature AVP the agent is in scenario 4 (no upstream DOIC association, no downstream DOIC association) When receiving a realm type request (a request that does not contain a Destination-Host AVP) that contains an OC-Supported-Feature AVP and the agent is configured to act as reporting node for that realm, the agent is scenario 1 or 2 (there is a downstream DOIC association). Whether its 1 or 2 depends on whether or not an OLR is received in the corresponding answer.

---

From: Steve Donovan <[email-masked]>
Date: Mon, 10 Feb 2014 09:56:55 -0600

We are dealing with two different definitions of endpoints.  Ulrich
diagram is all wrong when using my definition of endpoints.  Ulrich's
diagram is correct when using Ulrich's definition of endpoints.

The basic difference between the two definitions is when an agent
becomes an endpoint.

In my definition an agent that supports DOIC is an endpoint for all
transactions.

In Ulrich's definition an agent is only an endpoint if it needs to be
either a reporting node (in the case that is is acting as a server front
end or reporting realm overload) or a reacting node (when it is doing
abatement for an non supporting client).

I think that the behavior of Diameter clients and servers are the same
for both of these definitions, but we still don't have enough behavior
definition to say for sure.

I'm not ready to say which approach is better, especially when factoring
extensions to DOIC.  Maybe we can have a discussion on this topic in London.

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 11 Feb 2014 10:32:53 +0000

Hi Maria Cruz,

please find the diagram attached.

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Maria Cruz Bartolome
Sent: Monday, February 10, 2014 11:55 AM
To: [email-masked]
Subject: Re: [Dime] DOIC Endpoint behavior -- Capability Exchange

Hello Ulrich et all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: martes, 04 de febrero de 2014 14:44
To: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] DOIC Endpoint behavior -- Capability Exchange

Steve,

Regards
Ulrich

All,

Regards,

Steve

-----

Answer message handling:

Answer message handling

Answer message handling:

Answer message handling: