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

[Jouni Korhonen <[e-mail]>]

Steve,

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

> 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.  

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


> 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.
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime