idnits 2.17.1 draft-ietf-dime-group-signaling-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1049 has weird spacing: '...ly with wit...' == Line 1088 has weird spacing: '... answer servi...' == Line 1092 has weird spacing: '... answer user/...' -- The document date (December 28, 2018) is 1946 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions (DIME) M. Jones 3 Internet-Draft 4 Intended status: Standards Track M. Liebsch 5 Expires: July 1, 2019 6 L. Morand 7 December 28, 2018 9 Diameter Group Signaling 10 draft-ietf-dime-group-signaling-12.txt 12 Abstract 14 In large network deployments, a single Diameter node can support over 15 a million concurrent Diameter sessions. Recent use cases have 16 revealed the need for Diameter nodes to apply the same operation to a 17 large group of Diameter sessions concurrently. The Diameter base 18 protocol commands operate on a single session so these use cases 19 could result in many thousands of command exchanges to enforce the 20 same operation on each session in the group. In order to reduce 21 signaling, it would be desirable to enable bulk operations on all (or 22 part of) the sessions managed by a Diameter node using a single or a 23 few command exchanges. This document specifies the Diameter protocol 24 extensions to achieve this signaling optimization. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 1, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Building and Modifying Session Groups . . . . . . . . . . 4 64 3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . 4 65 3.3. Permission Considerations . . . . . . . . . . . . . . . . 4 66 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Session Grouping Capability Discovery . . . . . . . . . . 7 68 4.1.1. Explicit Capability Discovery . . . . . . . . . . . . 7 69 4.1.2. Implicit Capability Discovery . . . . . . . . . . . . 7 70 4.2. Session Grouping . . . . . . . . . . . . . . . . . . . . 7 71 4.2.1. Group assignment at session initiation . . . . . . . 8 72 4.2.2. Removing a session from a session group . . . . . . . 11 73 4.2.3. Mid-session group assignment modifications . . . . . 12 74 4.3. Deleting a Session Group . . . . . . . . . . . . . . . . 13 75 4.4. Performing Group Operations . . . . . . . . . . . . . . . 13 76 4.4.1. Sending Group Commands . . . . . . . . . . . . . . . 13 77 4.4.2. Receiving Group Commands . . . . . . . . . . . . . . 14 78 4.4.3. Error Handling for Group Commands . . . . . . . . . . 14 79 4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 15 80 5. Operation with Proxy Agents . . . . . . . . . . . . . . . . . 15 81 6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 16 82 6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 16 83 7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 17 84 7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . 17 85 7.2. Session-Group-Control-Vector AVP . . . . . . . . . . . . 18 86 7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . 18 87 7.4. Group-Response-Action AVP . . . . . . . . . . . . . . . . 19 88 7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 19 89 8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 19 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 91 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 20 92 9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 20 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 94 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 95 12. Normative References . . . . . . . . . . . . . . . . . . . . 21 96 Appendix A. Session Management -- Exemplary Session State 97 Machine . . . . . . . . . . . . . . . . . . . . . . 22 98 A.1. Use of groups for the Authorization Session State Machine 22 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 101 1. Introduction 103 In large network deployments, a single Diameter node can support over 104 a million concurrent Diameter sessions. Recent use cases have 105 revealed the need for Diameter nodes to apply the same operation to a 106 large group of Diameter sessions concurrently. For example, a policy 107 decision point may need to modify the authorized quality of service 108 for all active users having the same type of subscription. The 109 Diameter base protocol commands operate on a single session so these 110 use cases could result in many thousands of command exchanges to 111 enforce the same operation on each session in the group. In order to 112 reduce signaling, it would be desirable to enable bulk operations on 113 all (or part of) the sessions managed by a Diameter node using a 114 single or a few command exchanges. 116 This document describes mechanisms for grouping Diameter sessions and 117 applying Diameter commands, such as performing re-authentication, re- 118 authorization, termination and abortion of sessions to a group of 119 sessions. This document does not define a new Diameter application. 120 Instead it defines mechanisms, commands and AVPs that may be used by 121 any Diameter application that requires management of groups of 122 sessions. 124 These mechanisms take the following design goals and features into 125 account: 127 o Minimal impact to existing applications 129 o Extension of existing commands' Command Code Format (CCF) with 130 optional AVPs to enable grouping and group operations 132 o Fallback to single session operation 134 o Implicit discovery of capability to support grouping and group 135 operations in case no external mechanism is available to discover a 136 Diameter peer's capability to support session grouping and session 137 group operations 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 This document uses terminology defined in [RFC6733]. 147 3. Protocol Overview 149 3.1. Building and Modifying Session Groups 151 Client and Server can assign a new Diameter session to a group, e.g. 152 in case the subscription profile of the associated user has similar 153 characteristics as the profile of other users whose Diameter session 154 has been assigned to one or multiple groups. A single command can be 155 issued and applied to all sessions associated with such group(s), 156 e.g. to adjust common profile or policy settings. 158 The assignment of a Diameter session to a group can be changed mid- 159 session. For example, if a user's subscription profile changes mid- 160 session, a Diameter server may remove the session from its current 161 group and assign the session to a different group that is more 162 appropriate for the new subscription profile. 164 In case of mobile users, the user's session may get transferred to a 165 new Diameter client during handover and assigned to a different 166 group, which is maintained at the new Diameter client, mid-session. 168 A session group, which has sessions assigned, can be deleted, e.g. 169 due to a change in multiple users' subscription profile so that the 170 group's assigned sessions do not share certain characteristics 171 anymore. Deletion of such group requires subsequent individual 172 treatment of each of the assigned sessions. A node may decide to 173 assign some of these sessions to any other existing or new group. 175 3.2. Issuing Group Commands 177 Changes in the network condition may result in the Diameter server's 178 decision to close all sessions in a given group. The server issues a 179 single Session Termination Request (STR) command , identifying the 180 group of sessions which are to be terminated. The Diameter client 181 treats the STR as group command and initiates termination of all 182 sessions associated with the identified group. Subsequently, the 183 client confirms successful termination of these sessions to the 184 server by sending a single Session Termination Answer (STA) command, 185 which includes the identifier of the group. 187 3.3. Permission Considerations 189 Permission considerations in the context of this draft apply to the 190 permission of Diameter nodes to build new session groups, to assign/ 191 remove a session to/from a session group and to delete an existing 192 session group. 194 This specification follows the most flexible model where both, a 195 Diameter client and a Diameter server can create a new group and 196 assign a new identifier to that session group. When a Diameter node 197 decides to create a new session group, e.g. to group all sessions 198 which share certain characteristics, the node builds a session group 199 identifier according to the rules described in Section 7.3 and 200 becomes the owner of the group. This specification does not 201 constrain the permission to add or remove a session to/from a session 202 group to the group owner, instead each node can add a session to any 203 known group or remove a session from a group. A session group is 204 deleted and its identifier released after the last session has been 205 removed from the session group. Also the modification of groups in 206 terms of moving a session from one session group to a different 207 session group is permitted to any Diameter node. A Diameter node can 208 delete a session group and its group identifier mid-session, 209 resulting in individual treatment of the sessions which have been 210 previously assigned to the deleted group. Prerequisite for deletion 211 of a session group is that the Diameter node created the session 212 beforehand, hence the node became the group owner. 214 The enforcement of more constrained permissions is left to the 215 specification of a particular group signaling enabled Diameter 216 application and compliant implementations of such application MUST 217 enforce the associated permission model. Details about enforcing a 218 more constraint permission model are out of scope of this 219 specification. For example, a more constrained model could require 220 that a client MUST NOT remove a session from a group which is owned 221 by the server. 223 The following table depicts the permission considerations as per the 224 present specification: 226 +-------------------------------------------------+--------+--------+ 227 | Operation | Server | Client | 228 +-------------------------------------------------+--------+--------+ 229 | Create a new Session Group (Diameter node | X | X | 230 | becomes the group owner) | | | 231 +-------------------------------------------------+--------+--------+ 232 | Assign a Session to an owned Session Group | X | X | 233 +-------------------------------------------------+--------+--------+ 234 | Assign a Session to a non-owned Session Group | X | X | 235 +-------------------------------------------------+--------+--------+ 236 | Remove a Session from an owned Session Group | X | X | 237 +-------------------------------------------------+-----------------+ 238 | Remove a Session from a non-owned Session Group | X | X | 239 +-------------------------------------------------+--------+--------+ 240 | Remove a Session from a Session Group where the | X | X | 241 | Diameter node created the assignment | | | 242 +-------------------------------------------------+--------+--------+ 243 | Remove a Session from a Session Group where a | | | 244 | different Diameter node created the assignment | | | 245 +-------------------------------------------------+--------+--------+ 246 | Overrule a different Diameter node's | | | 247 | group assignment *) | | | 248 +-------------------------------------------------+--------+--------+ 249 | Delete a Session Group which is owned by the | X | X | 250 | Diameter node | | | 251 +-------------------------------------------------+--------+--------+ 252 | Delete a Session Group which is not owned by | | | 253 | the Diameter node | | | 254 +-------------------------------------------------+--------+--------+ 256 Default Permission as per this Specification 258 *) Editors' note: The protocol specification in this document does 259 not consider overruling a node's assignment of a session to a session 260 group. Here, overruling is to be understood as a node changing the 261 group(s) assignment as per the node's request. Group signaling 262 enabled applications may take such protocol support and associated 263 protocol semantics into account in their specification. One 264 exception is adopted in this specification, which allows a Diameter 265 server to reject a group assignment as per the client's request. 267 4. Protocol Description 268 4.1. Session Grouping Capability Discovery 270 Diameter nodes SHOULD assign a session to a session group and perform 271 session group operations with a node only after having ensured that 272 the node announced associated support beforehand. 274 4.1.1. Explicit Capability Discovery 276 New Diameter applications may consider support for Diameter session 277 grouping and for performing group commands during the standardization 278 process. Such applications provide intrinsic discovery for the 279 support of group commands and announce this capability through the 280 assigned application ID. 282 System- and deployment-specific means, as well as out-of-band 283 mechanisms for capability exchange can be used to announce nodes' 284 support for session grouping and session group operations. In such 285 case, the optional Session-Group-Capability-Vector AVP, as described 286 in Section 4.1.2 can be omitted in Diameter messages being exchanged 287 between nodes. 289 4.1.2. Implicit Capability Discovery 291 If no explicit mechanism for capability discovery is deployed to 292 enable Diameter nodes to learn about nodes' capability to support 293 session grouping and group commands, a Diameter node SHOULD append 294 the Session-Group-Capability-Vector AVP to any Diameter messages 295 exchanged with its nodes to announce its capability to support 296 session grouping and session group operations. Implementations 297 following the specification as per this document set the 298 BASE_SESSION_GROUP_CAPABILITY flag of the Session-Group-Capability- 299 Vector AVP. 301 When a Diameter node receives at least one Session-Group-Capability- 302 Vector AVP from a node with the BASE_SESSION_GROUP_CAPABILITY flag 303 set, the Diameter node maintains a log to remember the node's 304 capability to support group commands. 306 4.2. Session Grouping 308 This specification does not limit the number of session groups, to 309 which a single session is assigned. It is left to the application to 310 determine the policy of session grouping. In case an application 311 facilitates a session to belong to multiple session groups, the 312 application MUST maintain consistency of associated application 313 session states for these multiple session groups. 315 Either Diameter node (client or server) can initiate the assignment 316 of a session to a single or multiple session groups. Modification of 317 a group by removing or adding a single or multiple user sessions can 318 be initiated and performed mid-session by either Diameter node. 319 Diameter AAA applications typically assign client and server roles to 320 the Diameter nodes, which are referred to as relevant Diameter nodes 321 to utilize session grouping and issue group commands. Section 5 322 describes particularities about session grouping and performing group 323 commands when relay agents or proxies are deployed. 325 Diameter nodes, which are group-aware, MUST store and maintain an 326 entry about the group assignment together with a session's state. A 327 list of all known session groups should be locally maintained on each 328 node, each group pointing to individual sessions being assigned to 329 the group. A Diameter node MUST also keep a record about sessions, 330 which have been assigned to a session group by itself. 332 4.2.1. Group assignment at session initiation 334 To assign a session to a group at session initiation, a Diameter 335 client sends a service specific request, e.g. NASREQ AA-Request 336 [RFC7155], containing one or more session group identifiers. Each of 337 these groups MUST be identified by a unique Session-Group-Id 338 contained in a separate Session-Group-Info AVP as specified in 339 Section 7. 341 The client may choose one or multiple session groups from a list of 342 existing session groups. Alternatively, the client may decide to 343 create a new group to which the session is assigned and identify 344 itself in the portion of the Session-Group-Id AVP 345 as per Section 7.3. For all assignments of a session to an active 346 session group made by the client or the server, the 347 SESSION_GROUP_STATUS_IND flag in the Session-Group-Info AVP, which 348 identifies the session group, MUST be set. A set 349 SESSION_GROUP_STATUS_IND flag indicates that the identified session 350 group has just been created or is still active. 352 The client MUST set the SESSION_GROUP_ALLOCATION_ACTION flag of the 353 Session-Group-Control-Vector AVP in each appended Session-Group-Info 354 AVP to indicate that the session contained in the request should be 355 assigned to the identified session group. 357 The client may also indicate in the request that the server is 358 responsible for the assignment of the session in one or multiple 359 sessions owned by the server. In such a case, the client MUST 360 include the Session-Group-Info AVP in the request including the 361 Session-Group-Control-Vector AVP with the 362 SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP. 364 If the Diameter server receives a command request from a Diameter 365 client and the command comprises at least one Session-Group-Info AVP 366 having the SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group- 367 Control-Vector AVP set, the server can accept or reject the request 368 for group assignment. Reasons for rejection may be e.g. lack of 369 resources for managing additional groups. When rejected, the session 370 MUST NOT be assigned to any session group. 372 If the Diameter server accepts the client's request for a group 373 assignment, the server MUST assign the new session to each of the one 374 or multiple identified session groups when present in the Session- 375 Group-Info AVP. In case one or multiple identified session groups 376 are not already stored by the server, the server MUST store the new 377 identified group(s) to its local list of known session groups. When 378 sending the response to the client, e.g. a service-specific auth 379 response as per NASREQ AA-Answer [RFC7155], the server MUST include 380 all Session-Group-Info AVPs as received in the client's request. 382 In addition to the one or multiple session groups identified in the 383 client's request, the server may decide to assign the new session to 384 one or multiple additional groups. In such a case, the server MUST 385 add to the response the additional Session-Group-Info AVPs, each 386 identifying a session group to which the new session is assigned by 387 the server. Each of the Session-Group-Info AVP added by the server 388 MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in the 389 Session-Group-Control-Vector AVP set. 391 If the Diameter server rejects the client's request for a group 392 assignment, the server sends the response to the client, e.g. a 393 service-specific auth response as per NASREQ AA-Answer [RFC7155], and 394 MUST include all Session-Group-Info AVPs as received in the client's 395 request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION 396 flag of the Session-Group-Control-Vector AVP. The server MAY accept 397 the client's request for the identified session but refuse the 398 session's assignment to any session group. The server sends the 399 response to the client indicating success in the result code. In 400 such case the session is treated as single session without assignment 401 to any session group by the Diameter nodes. 403 If the Diameter server accepts the client's request for a group 404 assignment, but the assignment of the session to one or some of the 405 multiple identified session groups fails, the session group 406 assignment is treated as failure. In such case the session is 407 treated as single session without assignment to any session group by 408 the Diameter nodes. The server sends the response to the client and 409 MAY include as information to the client only those Session-Group- 410 Info AVPs for which the group assignment failed. The 411 SESSION_GROUP_ALLOCATION_ACTION flag of included Session-Group-Info 412 AVPs MUST be cleared. 414 If the Diameter server receives a command request from a Diameter 415 client and the command comprises one or multiple Session-Group-Info 416 AVPs and none of them includes a Session-Group-Id AVP, the server MAY 417 decide to assign the session to one or multiple session groups. For 418 each session group, to which the server assigns the new session, the 419 server includes a Session-Group-Info AVP with the Session-Group-Id 420 AVP identifying a session group in the response sent to the client. 421 Each of the Session-Group-Info AVPs included by the server MUST have 422 the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group- 423 Control-Vector AVP set. 425 If the Diameter server receives a command request from a Diameter 426 client and the command does not contain any Session-Group-Info AVP, 427 the server MUST NOT assign the new session to any session group but 428 treat the request as for a single session. The server MUST NOT 429 return any Session-Group-Info AVP in the command response. 431 If the Diameter client receives a response to its previously issued 432 request from the server and the response comprises at least one 433 Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION 434 flag of the associated Session-Group-Control-Vector AVP set, the 435 client MUST add the new session to all session groups as identified 436 in the one or multiple Session-Group-Info AVPs. If the Diameter 437 client fails to add the session to one or more session groups as 438 identified in the one or multiple Session-Group-info AVPs, the client 439 MUST terminate the session. The client MAY send a subsequent request 440 for session initiation to the server without requesting the 441 assignment of the session to a session group 443 If the Diameter client receives a response to its previously issued 444 request from the server and the one or more Session-Group-Info AVPs 445 have the SESSION_GROUP_ALLOCATION_ACTION flag of the associated 446 Session-Group-Control-Vector AVP cleared, the client MUST terminate 447 the assignment of the session to the one or multiple groups. If the 448 response from the server indicates success in the result code but 449 solely the assignment of the session to a session group has been 450 rejected by the server, the client treats the session as single 451 session without group assignment. 453 A Diameter client, which sent a request for session initiation to a 454 Diameter server and appended a single or multiple Session-Group-Id 455 AVPs but cannot find any Session-Group-Info AVP in the associated 456 response from the Diameter server proceeds as if the request was 457 processed for a single session. When the Diameter client is 458 confident that the Diameter server supports session grouping and 459 group signaling, the Diameter client SHOULD NOT retry to request 460 group assignment for this session, but MAY try to request group 461 assignment for other new sessions. 463 4.2.2. Removing a session from a session group 465 When a Diameter client decides to remove a session from a particular 466 session group, the client sends a service-specific re-authorization 467 request to the server and adds one Session-Group-Info AVP to the 468 request for each session group, from which the client wants to remove 469 the session. The session, which is to be removed from a group, is 470 identified in the Session-Id AVP of the command request. The 471 SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- 472 Vector AVP in each Session-Group-Info AVP MUST be cleared to indicate 473 removal of the session from the session group identified in the 474 associated Session-Group-id AVP. 476 When a Diameter client decides to remove a session from all session 477 groups, to which the session has been previously assigned, the client 478 sends a service-specific re-authorization request to the server and 479 adds a single Session-Group-Info AVP to the request which has the 480 SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id 481 AVP omitted. The session, which is to be removed from all groups, to 482 which the session has been previously assigned, is identified in the 483 Session-Id AVP of the command request. 485 If the Diameter server receives a request from the client which has 486 at least one Session-Group-Info AVP appended with the 487 SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server MUST remove 488 the session from the session group identified in the associated 489 Session-Group-Id AVP. If the request comprises at least one Session- 490 Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared 491 and no Session-Id AVP present, the server MUST remove the session 492 from all session groups to which the session has been previously 493 assigned. The server MUST include in its response to the requesting 494 client all Session-Group-Id AVPs as received in the request. 496 When the Diameter server decides to remove a session from one or 497 multiple particular session groups or from all session groups to 498 which the session has been assigned beforehand, the server sends a 499 Re-Authorization Request (RAR) or a service-specific server-initiated 500 request to the client, indicating the session in the Session-Id AVP 501 of the request. The client sends a Re-Authorization Answer (RAA) or 502 a service-specific answer to respond to the server's request. The 503 client subsequently sends service-specific re-authorization request 504 containing one or multiple Session-Group-Info AVPs, each indicating a 505 session group, to which the session had been previously assigned. To 506 indicate removal of the indicated session from one or multiple 507 session groups, the server sends a service-specific auth response to 508 the client, containing a list of Session-Group-Info AVPs with the 509 SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id 510 AVP identifying the session group, from which the session should be 511 removed. The server MAY include to the service-specific auth 512 response a list of Session-Group-Info AVPs with the 513 SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP 514 identifying session groups to which the session remains subscribed. 515 In case the server decides to remove the identified session from all 516 session groups, to which the session has been previously assigned, 517 the server includes in the service-specific auth response at least 518 one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION 519 flag cleared and Session-Group-Id AVP absent. 521 4.2.3. Mid-session group assignment modifications 523 Either Diameter node (client or server) can modify the group 524 membership of an active Diameter session according to the specified 525 permission considerations. 527 To update an assigned group mid-session, a Diameter client sends a 528 service-specific re-authorization request to the server, containing 529 one or multiple Session-Group-Info AVPs with the 530 SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP 531 present, identifying the session group to which the session should be 532 assigned. With the same message, the client may send one or multiple 533 Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag 534 cleared and the Session-Group-Id AVP identifying the session group 535 from which the identified session is to be removed. To remove the 536 session from all previously assigned session groups, the client 537 includes at least one Session-Group-Info AVP with the 538 SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id 539 AVP present. When the server received the service-specific re- 540 authorization request, it MUST update its locally maintained view of 541 the session groups for the identified session according to the 542 appended Session-Group-Info AVPs. The server sends a service- 543 specific auth response to the client containing one or multiple 544 Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag 545 set and the Session-Group-Id AVP identifying the new session group to 546 which the identified session has been assigned. 548 When a Diameter server enforces an update to the assigned groups mid- 549 session, it sends a Re-Authorization Request (RAR) message to the 550 client identifying the session, for which the session group lists are 551 to be updated. The client responds with a Re-Authorization Answer 552 (RAA) message. The client subsequently sends a service-specific re- 553 authorization request containing one or multiple Session-Group-Info 554 AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the 555 Session-Group-Id AVP identifying the session group to which the 556 session had been previously assigned. The server responds with a 557 service-specific auth response and includes one or multiple Session- 558 Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and 559 the Session-Group-Id AVP identifying the session group, to which the 560 identified session is to be assigned. With the same response 561 message, the server may send one or multiple Session-Group-Info AVPs 562 with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the 563 Session-Group-Id AVP identifying the session groups from which the 564 identified session is to be removed. When server wants to remove the 565 session from all previously assigned session groups, it sends at 566 least one Session-Group-Info AVP with the response having the 567 SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id 568 AVP present. 570 4.3. Deleting a Session Group 572 To delete a session group and release the associated Session-Group-Id 573 value, the owner of a session group appends a single Session-Group- 574 Info AVP having the SESSION_GROUP_STATUS_IND flag cleared and the 575 Session-Group-Id AVP identifying the session group, which is to be 576 deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated 577 Session-Group-Control-Vector AVP MUST be cleared. 579 4.4. Performing Group Operations 581 4.4.1. Sending Group Commands 583 Either Diameter node (client or server) can request the recipient of 584 a request to process an associated command for all sessions being 585 assigned to one or multiple groups by identifying these groups in the 586 request. The sender of the request appends for each group, to which 587 the command applies, a Session-Group-Info AVP including the Session- 588 Group-Id AVP to identify the associated session group. Both, the 589 SESSION_GROUP_ALLOCATION_ACTION flag as well as the 590 SESSION_GROUP_STATUS_IND flag MUST be set. 592 If the CCF of the request mandates a Session-Id AVP, the Session-Id 593 AVP MUST identify one of the single sessions which is assigned to at 594 least one of the groups being identified in the appended Session- 595 Group-Id AVPs. 597 The sender of the request MUST indicate to the receiver how multiple 598 resulting transactions associated with a group command are to be 599 treated by appending a single instance of a Group-Response-Action 600 AVP. When a server sends, as example, a Re-Authorization Request 601 (RAR) or a service-specific server-initiated request to the client, 602 it can indicate to the client whether to process the request, after 603 having sent the RAA to the server, with either sending a single RAR 604 message for all identified groups (server sets the Group-Response- 605 Action AVP to ALL_GROUPS (1)), or sending a single RAR message for 606 each identified group individually (server sets the Group-Response- 607 Action AVP to PER_GROUP (1)). The server may also request the client 608 to follow-up with a single RAR message per impacted session (server 609 sets the Group-Response-Action AVP to PER_SESSION). In such case, 610 the client sends only one RAR message for an impacted session in case 611 the session is included in more than one of the identified session 612 groups. 614 If the sender sends a request including the Group-Response-Action AVP 615 set to ALL_GROUPS (1) or PER_GROUP (2), it MUST expect some delay 616 before receiving the corresponding answer(s) as the answer(s) will 617 only be sent back when the request is processed for all the sessions 618 or all the session of a session group. If the process of the request 619 is delay-sensitive, the sender SHOULD NOT set the Group-Response- 620 Action AVP to ALL_GROUPS (1) or PER_GROUP (2). If the answer can be 621 sent before the complete process of the request for all the sessions 622 or if the request timeout timer is high enough, the sender MAY set 623 the Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2). 625 If the sender wants the receiver of the request to process the 626 associated command solely for a single session, the sender does not 627 append any group identifier, but identifies the relevant session in 628 the Session-Id AVP. 630 4.4.2. Receiving Group Commands 632 A Diameter node receiving a request to process a command for a group 633 of sessions, identifies the relevant groups according to the appended 634 Session-Group-Id AVP in the Session-Group-Info AVP and processes the 635 group command according to the appended Group-Response-Action AVP . 636 If the received request identifies multiple groups in multiple 637 appended Session-Group-Id AVPs, the receiver SHOULD process the 638 associated command for each of these groups. If a session has been 639 assigned to more than one of the identified groups, the receiver MUST 640 process the associated command only once per session. 642 4.4.3. Error Handling for Group Commands 644 When a Diameter node receives a request to process a command for one 645 or more session groups and the result of processing the command is an 646 error that applies to all sessions in the identified groups, an 647 associated protocol error MUST be returned to the source of the 648 request. In such case, the sender of the request MUST fall back to 649 single-session processing and the session groups, which have been 650 identified in the group command, MUST be deleted according to the 651 procedure described in Section 4.3. 653 When a Diameter node receives a request to process a command for one 654 or more session groups and the result of processing the command 655 succeeds for some sessions identified in one or multiple session 656 groups, but fails for one or more sessions, the Result-Code AVP in 657 the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per 658 Section 7.1.2 of [RFC6733]. 660 In case of limited success, the sessions, for which the processing of 661 the group command failed, MUST be identified using a Failed-AVP AVP 662 as per Section 7.5 of [RFC6733]. The sender of the request MUST fall 663 back to single-session operation for each of the identified sessions, 664 for which the group command failed. In addition, each of these 665 sessions MUST be removed from all session groups to which the group 666 command applied. To remove sessions from a session group, the 667 Diameter client performs the procedure described in Section 4.2.2. 669 4.4.4. Single-Session Fallback 671 Either Diameter node can fall back to single session operation by 672 ignoring and omitting the optional group session-specific AVPs. 673 Fallback to single-session operation is performed by processing the 674 Diameter command solely for the session identified in the mandatory 675 Session-Id AVP. In such case, the response to the group command MUST 676 NOT identify any group but identify solely the single session for 677 which the command has been processed. 679 5. Operation with Proxy Agents 681 In case of a present stateful Proxy Agent between a Diameter client 682 and a Diameter server, this specification assumes that the Proxy 683 Agent is aware of session groups and session group handling. The 684 Proxy MUST update and maintain consistency of its local session 685 states as per the result of the group commands which are operated 686 between a Diameter client and a server. In such case, the Proxy 687 Agent MUST act as a Diameter server in front of the Diameter client 688 and MUST act as a Diameter client in front of the Diameter server. 689 Therefore, the client and server behavior described in Section 4 690 applies respectively to the stateful Proxy Agent. 692 In case a stateful Proxy Agent manipulates session groups, it MUST 693 maintain consistency of session groups between a client and a server. 694 This applies to a deployment where the Proxy Agent utilizes session 695 grouping and performs group operations with, for example, a Diameter 696 server, whereas the Diameter client is not aware of session groups. 697 In such case the Proxy Agent must reflect the states associated with 698 the session groups as individual session operations towards the 699 client and ensure the client has a consistent view of each session. 700 The same applies to a deployment where all nodes, the Diameter client 701 and server, as well as the Proxy Agent are group-aware but the Proxy 702 Agent manipulates groups, e.g. to adopt different administrative 703 policies that apply to the client's domain and the server's domain. 705 Stateless Proxy Agents do not maintain any session state (only 706 transaction state are maintained). Consequently, the notion of 707 session group is transparent for any stateless Proxy Agent present 708 between a Diameter client and a Diameter server handling session 709 groups. Session group related AVPs being defined as optional AVP 710 SHOULD be ignored by stateless Proxy Agents and SHOULD NOT be removed 711 from the Diameter commands. If they are removed by the Proxy Agent 712 for any reason, the Diameter client and Diameter server will discover 713 the absence the related session group AVPs and will fall back to 714 single-session processing, as described in Section 4. 716 6. Commands Formatting 718 This document does not specify new Diameter commands to enable group 719 operations, but relies on command extensibility capability provided 720 by the Diameter Base protocol. This section provides the guidelines 721 to extend the CCF of existing Diameter commands with optional AVPs to 722 enable the recipient of the command applying the command to all 723 sessions associated with the identified group(s). 725 6.1. Formatting Example: Group Re-Auth-Request 727 A request for re-authentication of one or more groups of users is 728 issued by appending one or multiple Session-Group-Id AVP(s), as well 729 as a single instance of a Group-Response-Action AVP to the Re-Auth- 730 Request (RAR). The one or multiple Session-Group-Id AVP(s) identify 731 the associated group(s) for which the group re-authentication has 732 been requested. The Group-Response-Action AVP identifies the 733 expected means to perform and respond to the group command. The 734 recipient of the group command initiates re-authentication for all 735 users associated with the identified group(s). Furthermore, the 736 sender of the group re-authentication request appends a Group- 737 Response-Action AVP to provide more information to the receiver of 738 the command about how to accomplish the group operation. 740 The value of the mandatory Session-Id AVP MUST identify a session 741 associated with a single user, which is assigned to at least one of 742 the groups being identified in the appended Session-Group-Id AVPs. 744 ::= < Diameter Header: 258, REQ, PXY > 745 < Session-Id > 746 { Origin-Host } 747 { Origin-Realm } 748 { Destination-Realm } 749 { Destination-Host } 750 { Auth-Application-Id } 751 { Re-Auth-Request-Type } 752 [ User-Name ] 753 [ Origin-State-Id ] 754 * [ Proxy-Info ] 755 * [ Route-Record ] 756 [ Session-Group-Capability-Vector ] 757 * [ Session-Group-Info ] 758 [ Group-Response-Action ] 759 * [ AVP ] 761 7. Attribute-Value-Pairs (AVP) 763 +--------------------+ 764 | AVP Flag rules | 765 +----+---+------+----+ 766 AVP | | |SHOULD|MUST| 767 Attribute Name Code Value Type |MUST|MAY| NOT | NOT| 768 +-------------------------------------------------+----+---+------+----+ 769 |Session-Group-Info TBD1 Grouped | | P | | V | 770 |Session-Group-Control-Vector TBD2 Unsigned32 | | P | | V | 771 |Session-Group-Id TBD3 OctetString | | P | | V | 772 |Group-Response-Action TBD4 Unsigned32 | | P | | V | 773 |Session-Group-Capability-Vector TBD5 Unsigned32 | | P | | V | 774 +-------------------------------------------------+----+---+------+----+ 776 AVPs for the Diameter Group Signaling 778 7.1. Session-Group-Info AVP 780 The Session-Group-Info AVP (AVP Code TBD1) is of type Grouped. It 781 contains the identifier of the session group as well as an indication 782 of the node responsible for session group identifier assignment. 784 Session-Group-Info ::= < AVP Header: TBD1 > 785 < Session-Group-Control-Vector > 786 [ Session-Group-Id ] 787 * [ AVP ] 789 7.2. Session-Group-Control-Vector AVP 791 The Session-Group-Control-Vector AVP (AVP Code TBD2) is of type 792 Unsigned32 and contains a 32-bit flags field to control the group 793 assignment at session-group aware nodes. 795 The following control flags are defined in this document: 797 SESSION_GROUP_ALLOCATION_ACTION (0x00000001) 799 This flag indicates the action to be performed for the identified 800 session. When this flag is set, it indicates that the identified 801 Diameter session is to be assigned to the session group as 802 identified by the Session-Group-Id AVP or the session's assignment 803 to the session group identified in the Session-Group-Id AVP is 804 still valid. When the flag is cleared, the identified Diameter 805 session is to be removed from at least one session group. When 806 the flag is cleared and the Session-Group-Info AVP identifies a 807 particular session group in the associated Session-Group-Id AVP, 808 the session is to be removed solely from the identified session 809 group. When the flag is cleared and the Session-Group-Info AVP 810 does not identify a particular session group (Session-Group-Id AVP 811 is absent), the identified Diameter session is to be removed from 812 all session groups, to which it has been previously assigned. 814 SESSION_GROUP_STATUS_IND (0x00000010) 816 This flag indicates the status of the session group identified in 817 the associated Session-Group-Id AVP. The flag is set when the 818 identified session group has just been created or is still active. 819 If the flag is cleared, the identified session group is deleted 820 and the associated Session-Group-Id is released. If the Session- 821 Group-Info AVP does not comprise a Session-Group-Id AVP, this flag 822 is meaningless and MUST be ignored by the receiver. 824 7.3. Session-Group-Id AVP 826 The Session-Group-Id AVP (AVP Code TBD3) is of type UTF8String and 827 identifies a group of Diameter sessions. 829 The Session-Group-Id MUST be globally and eternally unique, as it is 830 meant to uniquely identify a group of Diameter sessions without 831 reference to any other information. 833 The default format of the Session-Group-id MUST comply to the format 834 recommended for a Session-Id, as defined in the section 8.8 of the 835 [RFC6733]. The portion of the Session-Group-Id 836 MUST identify the Diameter node, which owns the session group. 838 7.4. Group-Response-Action AVP 840 The Group-Response-Action AVP (AVP Code TBD4) is of type Unsigned32 841 and contains a 32-bit address space representing values indicating 842 how the node SHOULD issue follow up exchanges in response to a 843 command which impacts multiple sessions. The following values are 844 defined by this document: 846 ALL_GROUPS (1) 847 Follow up message exchanges associated with a group command should 848 be performed with a single message exchange for all impacted 849 groups. 851 PER_GROUP (2) 852 Follow up message exchanges associated with a group command should 853 be performed with a separate message exchange for each impacted 854 group. 856 PER_SESSION (3) 857 Follow up message exchanges associated with a group command should 858 be performed with a separate message exchange for each impacted 859 session. 861 7.5. Session-Group-Capability-Vector AVP 863 The Session-Group-Capability-Vector AVP (AVP Code TBD5) is of type 864 Unsigned32 and contains a 32-bit flags field to indicate capabilities 865 in the context of session-group assignment and group operations. 867 The following capabilities are defined in this document: 869 BASE_SESSION_GROUP_CAPABILITY (0x00000001) 871 This flag indicates the capability to support session grouping and 872 session group operations according to this specification. 874 8. Result-Code AVP Values 876 This document does not define new Result-Code [RFC6733] values for 877 existing applications, which are extended to support group commands. 878 Specification documents of new applications, which will have 879 intrinsic support for group commands, may specify new Result-Codes. 881 9. IANA Considerations 883 This section contains the namespaces that have either been created in 884 this specification or had their values assigned to existing 885 namespaces managed by IANA. 887 9.1. AVP Codes 889 This specification requires IANA to register the following new AVPs 890 from the AVP Code namespace defined in [RFC6733]. 892 o Session-Group-Info 894 o Session-Group-Control-Vector 896 o Session-Group-Id 898 o Group-Response-Action 900 o Session-Group-Capability-Vector 902 The AVPs are defined in Section 7. 904 9.2. New Registries 906 This specification requires IANA to create two registries: 908 o Session-Group-Control-Vector AVP registry for control bits with 909 two initial assignments, which are described in Section 7.2. The 910 future registration assignment policy is proposed to be 911 Specification Required. 913 o Session-Group-Capability-Vector AVP with one initial assignment, 914 which is described in Section 7.5. The future registration 915 assignment policy is proposed to be Standards Action. 917 The AVP names can be used as registry names. 919 10. Security Considerations 921 The security considerations of the Diameter protocol itself are 922 discussed in [RFC6733]. Use of the AVPs defined in this document 923 MUST take into consideration the security issues and requirements of 924 the Diameter base protocol. In particular, the Session-Group-Info 925 AVP (including the Session-group-Control-Vector and the Session- 926 Group-Id AVPs) should be considered as a security-sensitive AVPs in 927 the same manner than the Session-Id AVP in the Diameter base protocol 928 [RFC6733]. 930 The management of session groups relies upon the existing trust 931 relationship between the Diameter client and the Diameter server 932 managing the groups of sessions. This document defines a mechanism 933 that allows a client or a server to act on multiple sessions at the 934 same time using only one command. if the Diameter client or server is 935 compromised, an attacker could launch DoS attacks by terminating a 936 large number of sessions with a limited set of commands using the 937 session group management concept. 939 According to the Diameter base protocol [RFC6733], transport 940 connections between Diameter peers are protected by TLS/TCP, DTLS/ 941 SCTP or alternative security mechanisms that are independent of 942 Diameter, such as IPsec. However, the lack of end-to-end security 943 features makes it difficult to establish trust in the session group 944 related information received from non-adjacent nodes. Any Diameter 945 agent in the message path can potentially modify the content of the 946 message and therefore the information sent by the Diameter client or 947 the server. The DIME working group is currently working on solutions 948 for providing end-to-end security features. When available, these 949 features should enable the establishment of trust relationship 950 between non-adjacent nodes and the security required for session 951 group management would normally rely on this end-to-end security. 952 However, there is no assumption in this document that such end-to-end 953 security mechanism will be available. It is only assume that the 954 solution defined on this document relies on the security framework 955 provided by the Diameter based protocol. 957 In some cases, a Diameter Proxy agent can act on behalf of a client 958 or server. In such a case, the security requirements that normally 959 apply to a client (or a server) apply equally to the Proxy agent. 961 11. Acknowledgments 963 The authors of this document want to thank Ben Campbell and Eric 964 McMurry for their valuable comments to early versions of this draft. 965 Furthermore, authors thank Steve Donovan and Mark Bales for the 966 thorough review and comments on advanced versions of the WG document, 967 which helped a lot to improve this specification. 969 12. Normative References 971 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 972 Requirement Levels", BCP 14, RFC 2119, 973 DOI 10.17487/RFC2119, March 1997, 974 . 976 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 977 Ed., "Diameter Base Protocol", RFC 6733, 978 DOI 10.17487/RFC6733, October 2012, 979 . 981 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 982 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 983 . 985 Appendix A. Session Management -- Exemplary Session State Machine 987 A.1. Use of groups for the Authorization Session State Machine 989 Section 8.1 in [RFC6733] defines a set of finite state machines, 990 representing the life cycle of Diameter sessions, and which MUST be 991 observed by all Diameter implementations that make use of the 992 authentication and/or authorization portion of a Diameter 993 application. This section defines, as example, additional state 994 transitions related to the processing of the group commands which may 995 impact multiple sessions. 997 The group membership is session state and therefore only those state 998 machines from [RFC6733] in which the server is maintaining session 999 state are relevant in this document. As in [RFC6733], the term 1000 Service-Specific below refers to a message defined in a Diameter 1001 application (e.g., Mobile IPv4, NASREQ). 1003 The following state machine is observed by a client when state is 1004 maintained on the server. State transitions which are unmodified 1005 from [RFC6733] are not repeated here. 1007 The Diameter group command in the following tables is differentiated 1008 from a single-session related command by a preceding 'G' (Group). A 1009 Group Re-Auth Request, which applies to one or multiple session 1010 groups, has been exemplarily described in Section 6.1. Such Group 1011 RAR command is denoted as 'GRAR' in the following table. The same 1012 notation applies to other commands as per [RFC6733]. 1014 CLIENT, STATEFUL 1015 State Event Action New State 1016 --------------------------------------------------------------- 1017 Idle Client or Device Requests Send Pending 1018 access service 1019 specific 1020 auth req 1021 optionally 1022 including 1023 groups 1025 Open GASR received with Send GASA Discon 1026 Group-Response-Action with 1027 = ALL_GROUPS, Result-Code 1028 session is assigned to = SUCCESS, 1029 received group(s) and Send GSTR. 1030 client will comply with 1031 request to end the session 1033 Open GASR received with Send GASA Discon 1034 Group-Response-Action with 1035 = PER_GROUPS, Result-Code 1036 session is assigned to = SUCCESS, 1037 received group(s) and Send GSTR 1038 client will comply with per group 1039 request to end the session 1040 Open GASR received with Send GASA Discon 1041 Group-Response-Action with 1042 = PER_SESSION, Result-Code 1043 session is assigned to = SUCCESS, 1044 received group(s) and Send STR 1045 client will comply with per session 1046 request to end the session 1048 Open GASR received, Send GASA Open 1049 client will not comply with with 1050 request to end all session Result-Code 1051 in received group(s) != SUCCESS 1053 Discon GSTA Received Discon. Idle 1054 user/device 1056 Open GRAR received with Send GRAA, Pending 1057 Group-Response-Action Send 1058 = ALL_GROUPS, service 1059 session is assigned to specific 1060 received group(s) and group 1061 client will perform re-auth req 1062 subsequent re-auth 1064 Open GRAR received with Send GRAA, Pending 1065 Group-Response-Action Send 1066 = PER_GROUP, service 1067 session is assigned to specific 1068 received group(s) and group 1069 client will perform re-auth req 1070 subsequent re-auth per group 1072 Open GRAR received with Send GRAA, Pending 1073 Group-Response-Action Send 1074 = PER_SESSION, service 1075 session is assigned to specific 1076 received group(s) and re-auth req 1077 client will perform per session 1078 subsequent re-auth 1080 Open GRAR received and client will Send GRAA Idle 1081 not perform subsequent with 1082 re-auth Result-Code 1083 != SUCCESS, 1084 Discon. 1085 user/device 1087 Pending Successful service-specific Provide Open 1088 group re-authorization answer service 1089 received. 1091 Pending Failed service-specific Discon. Idle 1092 group re-authorization answer user/device 1093 received. 1095 The following state machine is observed by a server when it is 1096 maintaining state for the session. State transitions which are 1097 unmodified from [RFC6733] are not repeated here. 1099 SERVER, STATEFUL 1100 State Event Action New State 1101 --------------------------------------------------------------- 1103 Idle Service-specific authorization Send Open 1104 request received, and user successful 1105 is authorized service 1106 specific 1107 answer 1108 optionally 1109 including 1110 groups 1112 Open Server wants to terminate Send GASR Discon 1113 group(s) 1115 Discon GASA received Cleanup Idle 1117 Any GSTR received Send GSTA, Idle 1118 Cleanup 1120 Open Server wants to reauth Send GRAR Pending 1121 group(s) 1123 Pending GRAA received with Result-Code Update Open 1124 = SUCCESS session(s) 1126 Pending GRAA received with Result-Code Cleanup Idle 1127 != SUCCESS session(s) 1129 Open Service-specific group Send Open 1130 re-authoization request successful 1131 received and user is service 1132 authorized specific 1133 group 1134 re-auth 1135 answer 1137 Open Service-specific group Send Idle 1138 re-authorization request failed 1139 received and user is service 1140 not authorized specific 1141 group 1142 re-auth 1143 answer, 1144 cleanup 1146 Authors' Addresses 1148 Mark Jones 1150 Email: mark@azu.ca 1152 Marco Liebsch 1154 Email: marco.liebsch@neclab.eu 1156 Lionel Morand 1158 Email: lionel.morand@orange.com