| < draft-ietf-dime-group-signaling-09.txt | draft-ietf-dime-group-signaling-10.txt > | |||
|---|---|---|---|---|
| Diameter Maintenance and Extensions (DIME) M. Jones | Diameter Maintenance and Extensions (DIME) M. Jones | |||
| Internet-Draft | Internet-Draft | |||
| Intended status: Standards Track M. Liebsch | Intended status: Standards Track M. Liebsch | |||
| Expires: March 19, 2018 | Expires: July 12, 2018 | |||
| L. Morand | L. Morand | |||
| September 15, 2017 | January 8, 2018 | |||
| Diameter Group Signaling | Diameter Group Signaling | |||
| draft-ietf-dime-group-signaling-09.txt | draft-ietf-dime-group-signaling-10.txt | |||
| Abstract | Abstract | |||
| In large network deployments, a single Diameter node can support over | In large network deployments, a single Diameter node can support over | |||
| a million concurrent Diameter sessions. Recent use cases have | a million concurrent Diameter sessions. Recent use cases have | |||
| revealed the need for Diameter nodes to apply the same operation to a | revealed the need for Diameter nodes to apply the same operation to a | |||
| large group of Diameter sessions concurrently. The Diameter base | large group of Diameter sessions concurrently. The Diameter base | |||
| protocol commands operate on a single session so these use cases | protocol commands operate on a single session so these use cases | |||
| could result in many thousands of command exchanges to enforce the | could result in many thousands of command exchanges to enforce the | |||
| same operation on each session in the group. In order to reduce | same operation on each session in the group. In order to reduce | |||
| skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 42 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on March 19, 2018. | This Internet-Draft will expire on July 12, 2018. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| skipping to change at page 8, line 26 ¶ | skipping to change at page 8, line 26 ¶ | |||
| entry about the group assignment together with a session's state. A | entry about the group assignment together with a session's state. A | |||
| list of all known session groups should be locally maintained on each | list of all known session groups should be locally maintained on each | |||
| node, each group pointing to individual sessions being assigned to | node, each group pointing to individual sessions being assigned to | |||
| the group. A Diameter node MUST also keep a record about sessions, | the group. A Diameter node MUST also keep a record about sessions, | |||
| which have been assigned to a session group by itself. | which have been assigned to a session group by itself. | |||
| 4.2.1. Group assignment at session initiation | 4.2.1. Group assignment at session initiation | |||
| To assign a session to a group at session initiation, a Diameter | To assign a session to a group at session initiation, a Diameter | |||
| client sends a service specific request, e.g. NASREQ AA-Request | client sends a service specific request, e.g. NASREQ AA-Request | |||
| [RFC4005], containing one or more session group identifiers. Each of | [RFC7155], containing one or more session group identifiers. Each of | |||
| these groups MUST be identified by a unique Session-Group-Id | these groups MUST be identified by a unique Session-Group-Id | |||
| contained in a separate Session-Group-Info AVP as specified in | contained in a separate Session-Group-Info AVP as specified in | |||
| Section 7. | Section 7. | |||
| The client may choose one or multiple session groups from a list of | The client may choose one or multiple session groups from a list of | |||
| existing session groups. Alternatively, the client may decide to | existing session groups. Alternatively, the client may decide to | |||
| create a new group to which the session is assigned and identify | create a new group to which the session is assigned and identify | |||
| itself in the <DiameterIdentity> portion of the Session-Group-Id AVP | itself in the <DiameterIdentity> portion of the Session-Group-Id AVP | |||
| as per Section 7.3 | as per Section 7.3 | |||
| skipping to change at page 9, line 15 ¶ | skipping to change at page 9, line 15 ¶ | |||
| resources for managing additional groups. When rejected, the session | resources for managing additional groups. When rejected, the session | |||
| MUST NOT be assigned to any session group. | MUST NOT be assigned to any session group. | |||
| If the Diameter server accepts the client's request for a group | If the Diameter server accepts the client's request for a group | |||
| assignment, the server MUST assign the new session to each of the one | assignment, the server MUST assign the new session to each of the one | |||
| or multiple identified session groups when present in the Session- | or multiple identified session groups when present in the Session- | |||
| Group-Info AVP. In case one or multiple identified session groups | Group-Info AVP. In case one or multiple identified session groups | |||
| are not already stored by the server, the server MUST store the new | are not already stored by the server, the server MUST store the new | |||
| identified group(s) to its local list of known session groups. When | identified group(s) to its local list of known session groups. When | |||
| sending the response to the client, e.g. a service-specific auth | sending the response to the client, e.g. a service-specific auth | |||
| response as per NASREQ AA-Answer [RFC4005], the server MUST include | response as per NASREQ AA-Answer [RFC7155], the server MUST include | |||
| all Session-Group-Info AVPs as received in the client's request. | all Session-Group-Info AVPs as received in the client's request. | |||
| In addition to the one or multiple session groups identified in the | In addition to the one or multiple session groups identified in the | |||
| client's request, the server may decide to assign the new session to | client's request, the server may decide to assign the new session to | |||
| one or multiple additional groups. In such a case, the server MUST | one or multiple additional groups. In such a case, the server MUST | |||
| add to the response the additional Session-Group-Info AVPs, each | add to the response the additional Session-Group-Info AVPs, each | |||
| identifying a session group to which the new session is assigned by | identifying a session group to which the new session is assigned by | |||
| the server. Each of the Session-Group-Info AVP added by the server | the server. Each of the Session-Group-Info AVP added by the server | |||
| MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in the | MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in the | |||
| Session-Group-Control-Vector AVP set. | Session-Group-Control-Vector AVP set. | |||
| If the Diameter server rejects the client's request for a group | If the Diameter server rejects the client's request for a group | |||
| assignment, the server sends the response to the client, e.g. a | assignment, the server sends the response to the client, e.g. a | |||
| service-specific auth response as per NASREQ AA-Answer [RFC4005], and | service-specific auth response as per NASREQ AA-Answer [RFC7155], and | |||
| MUST include all Session-Group-Info AVPs as received in the client's | MUST include all Session-Group-Info AVPs as received in the client's | |||
| request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION | request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION | |||
| flag of the Session-Group-Control-Vector AVP. The server MAY accept | flag of the Session-Group-Control-Vector AVP. The server MAY accept | |||
| the client's request for the identified session but refuse the | the client's request for the identified session but refuse the | |||
| session's assignment to any session group. The server sends the | session's assignment to any session group. The server sends the | |||
| response to the client indicating success in the result code. In | response to the client indicating success in the result code. In | |||
| such case the session is treated as single session without assignment | such case the session is treated as single session without assignment | |||
| to any session group by the Diameter nodes. | to any session group by the Diameter nodes. | |||
| If the Diameter server accepts the client's request for a group | If the Diameter server accepts the client's request for a group | |||
| skipping to change at page 21, line 30 ¶ | skipping to change at page 21, line 30 ¶ | |||
| thorough review and comments on advanced versions of the WG document, | thorough review and comments on advanced versions of the WG document, | |||
| which helped a lot to improve this specification. | which helped a lot to improve this specification. | |||
| 12. Normative References | 12. Normative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, | ||||
| "Diameter Network Access Server Application", RFC 4005, | ||||
| DOI 10.17487/RFC4005, August 2005, | ||||
| <https://www.rfc-editor.org/info/rfc4005>. | ||||
| [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, | [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, | |||
| Ed., "Diameter Base Protocol", RFC 6733, | Ed., "Diameter Base Protocol", RFC 6733, | |||
| DOI 10.17487/RFC6733, October 2012, | DOI 10.17487/RFC6733, October 2012, | |||
| <https://www.rfc-editor.org/info/rfc6733>. | <https://www.rfc-editor.org/info/rfc6733>. | |||
| [RFC7155] Zorn, G., Ed., "Diameter Network Access Server | ||||
| Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, | ||||
| <https://www.rfc-editor.org/info/rfc7155>. | ||||
| Appendix A. Session Management -- Exemplary Session State Machine | Appendix A. Session Management -- Exemplary Session State Machine | |||
| A.1. Use of groups for the Authorization Session State Machine | A.1. Use of groups for the Authorization Session State Machine | |||
| Section 8.1 in [RFC6733] defines a set of finite state machines, | Section 8.1 in [RFC6733] defines a set of finite state machines, | |||
| representing the life cycle of Diameter sessions, and which MUST be | representing the life cycle of Diameter sessions, and which MUST be | |||
| observed by all Diameter implementations that make use of the | observed by all Diameter implementations that make use of the | |||
| authentication and/or authorization portion of a Diameter | authentication and/or authorization portion of a Diameter | |||
| application. This section defines, as example, additional state | application. This section defines, as example, additional state | |||
| transitions related to the processing of the group commands which may | transitions related to the processing of the group commands which may | |||
| End of changes. 10 change blocks. | ||||
| 13 lines changed or deleted | 12 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||