4.2. OC-Feature-Vector AVP The OC-Feature-Vector AVP (AVP code TBD6) is type of Unsigned64 and contains a 64 bit flags field of announced capabilities of an overload control endpoint. The value of zero (0) is reserved. The following capabilities are defined in this document: OLR_DEFAULT_ALGO (0x0000000000000001) When this flag is set by the overload control endpoint it means that the default traffic abatement (loss) algorithm is supported. OLR_CLIENT_SPECIFIC_THROTTLING (0x0000000000000002) When this flag is set by the reacting overload control endpoint it means that client specific throttling is supported. When this flag is set by the reporting overload control endpoint it means that client specific throttling is requested. When the reacting overload control endpoint did not indicate support of client specific throttling, the reporting overload control endpoint shall not request client specific throttling. Note: Reacting nodes which are clients trivially do support client specific throttling. Similarly, reacting nodes which are agents that perform throttling on behalf of a single client do support client specific throttling. In contrast, reacting nodes which are agents that perform throttling on behalf of several clients are not required to support client specific throttling. next modification 4.6. OC-Report-Type AVP The OC-Report-Type AVP (AVP code TBD5) is type of Enumerated. The value of the AVP describes what the overload report concerns. The following values are initially defined: 0 A host report. The overload treatment should apply to requests for which all of the following conditions are true: The Destination-Host AVP is present in the request and its value matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. If client specific throttling is supported and requested: The value of the Origin-Host AVP in the request matches the value of the Origin-Host AVP of the previously sent request that corresponds to the received message that contained the OC-OLR AVP, and the value of the Origin-Realm AVP in the request matches the value of the Origin-Realm AVP of the previously sent request that corresponds to the received message that contained the OC-OLR AVP. 1 A realm report. The overload treatment should apply to requests for which all of the following conditions are true: The Destination-Host AVP is absent in the request. The value of the Destination-Realm AVP in the request matches the value of the Origin-Realm AVP of the received message that contained the OC-OLR AVP. The value of the Application-ID in the Diameter Header of the request matches the value of the Application-ID of the Diameter Header of the received message that contained the OC-OLR AVP. If client specific throttling is supported and requested: The value of the Origin-Host AVP in the request matches the value of the Origin-Host AVP of the previously sent request that corresponds to the received message that contained the OC-OLR AVP, and the value of the Origin-Realm AVP in the request matches the value of the Origin-Realm AVP of the previously sent request that corresponds to the received message that contained the OC-OLR AVP. Editor's note: There is still an open issue on the definition of Realm reports and whether what report types should be supported. There is consensus that host reports should be supported. There is discussion on Realm reports and Realm-Routed-Request reports. The above definition applies to Realm-Routed-Request reports where Realm reports are defined to apply to all requests that match the realm, independent of the presence, absence or value of the Destination-Host AVP. The default value of the OC-Report-Type AVP is 0 (i.e. the host report). The OC-Report-Type AVP is envisioned to be useful for situations where a reacting node needs to apply different overload treatments for different "types" of overload. For example, the reacting node(s) might need to throttle differently requests sent to a specific server (identified by the Destination-Host AVP in the request) and requests that can be handled by any server in a realm. The example in Appendix B.1 illustrates this usage. When defining new report type values, the corresponding specification MUST define the semantics of the new report types and how they affect the OC-OLR AVP handling. The specification MUST also reserve a corresponding new feature, see the OC-Supported-Features and OC- Feature-Vector AVPs. next modification 5.5.1. Overload Control State Both reacting and reporting nodes maintain an overload control state (OCS) for each endpoint (a host or a realm) they communicate with and both endpoints have announced support for DOIC. See Sections 4.1 and 5.3 for discussion about how the support for DOIC is determined. 5.5.1.1. Overload Control State for Reacting Nodes A reacting node maintains the following OCS per supported Diameter application: o A host-type Overload Control State for each Destination-Host towards which it sends host-type requests and o A realm-type Overload Control State for each Destination-Realm towards which it sends realm-type requests. A host-type Overload Control State may be identified by the pair of Application-Id and Destination-Host. A realm-type Overload Control State may be identified by the pair of Application-Id and Destination-Realm. The host-type/realm-type Overload Control State for a given pair of Application and Destination-Host / Destination- Realm could include the following information: o Sequence number (as received in OC-OLR) o Time of expiry (deviated from validity duration as received in OC- OLR and time of reception) o Selected Abatement Algorithm (as received in OC-Supported- Features) o Algorithm specific input data (as received within OC-OLR, e.g. Reduction Percentage for Loss) 5.5.1.2. Overload Control States for Reporting Nodes A reporting node maintains per supported Diameter application and per supported (and eventually selected) Abatement Algorithm an Overload Control State. Reporting nodes that support client specific throttling may maintain client specific overload control states if so supported by the reacting node. An Overload Control State may be identified by the pair of Application-Id and supported Abatement Algorithm. The Overload Control State for a given pair of Application and Abatement Algorithm could include the information: o Sequence number o Validity Duration and Expiry Time o Algorithm specific input data (e.g. Reduction Percentage for Loss) Overload Control States for reporting nodes containing a validity duration of 0 sec. should not expire before any previously sent (stale) OLR has timed out at any reacting node.