Content for TS 29.229 Word version: 18.0.0

3.1 Definitions 3.2 Abbreviations 5.1 Securing Diameter Messages 5.2 Accounting functionality 5.3 Use of sessions 5.4 Transport protocol 5.5 Routing considerations 5.6 Advertising Application Support
...

1 Scope p. 7

The present document defines a transport protocol for use in the IP multimedia (IM) Core Network (CN) subsystem based on Diameter base protocol as specified in RFC 6733.

The present document is applicable to:

The Cx interface between the I-CSCF/S-CSCF and the HSS.
The Dx interface between the I-CSCF/S-CSCF and the SLF.

Whenever it is possible, this document specifies the requirements for this protocol by reference to specifications produced by the IETF within the scope of Diameter base protocol as specified in RFC 6733. Where this is not possible, extensions to Diameter base protocol as specified in RFC 6733 are defined within this document.

2 References p. 7

The following documents contain provisions, which through reference in this text constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TS 29.228: "IP Multimedia (IM) Subsystem Cx and Dx interface; signalling flows and message contents".

[2]

TS 33.210: "3G Security; Network Domain Security; IP Network Layer Security".

[3]

RFC 3261: "SIP: Session Initiation Protocol".

[4]

RFC 2396: "Uniform Resource Identifiers (URI): generic syntax".

[5] Void.

[6] Void.

[7]

RFC 2234: "Augmented BNF for syntax specifications".

[8]

RFC 3966: "The tel URI for Telephone Numbers".

[9] Void.

[10] Void.

[11]

TS 29.329: "Sh Interface based on the Diameter protocol; protocol details".

[12]

RFC 3589: "Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5".

[13]

TS 23.003: "Numbering, addressing and identification".

[14] Void.

[15]

RFC 4740: "Diameter Session Initiation Protocol (SIP) Application".

[16]

TS 29.328: "IP Multimedia (IM) Subsystem Sh interface; Signalling flows and message contents".

[17]

RFC 3327: "Session Initiation Protocol Extension Header Field for Registering Non-Adjacent Contacts".

[18]

TS 29.273: "3GPP EPS AAA interfaces".

[19]

RFC 4005: "Diameter Network Access Server Application".

[20]

RFC 4590: " RADIUS Extension for Digest Authentication".

[21]

RFC 4960: "Stream Control Transmission Protocol".

[22]

RFC 3162: "RADIUS and IPv6".

[23]

RFC 7683: "Diameter Overload Indication Conveyance".

[24]

TS 23.380: "IMS Restoration Procedures".

[25]

draft-holmberg-sipcore-auth-id-01: "Authorization server identity".

[26]

RFC 7944: "Diameter Routing Message Priority".

[27]

RFC 8583: "Diameter Load Information Conveyance".

[28]

RFC 6733: "Diameter Base Protocol".

[29]

RFC 7616: "HTTP Digest Access Authentication".

3 Definitions, symbols and abbreviations p. 8

3.1 Definitions p. 8

Refer to RFC 6733 for the definitions of some terms used in this document.

For the purposes of the present document, the following terms and definitions apply.

Attribute-Value Pair:

see RFC 6733, it corresponds to an Information Element in a Diameter message.

Diameter Multimedia client:

a client that implements the Diameter Multimedia application. The client is one of the communicating Diameter peers that usually initiate transactions. Examples in 3GPP are the I-CSCF and S-CSCF.

Diameter Multimedia server:

a server that implements the Diameter Multimedia application. A Diameter Multimedia server that also supported the NASREQ and MobileIP applications would be referred to as a Diameter server. An example of a Diameter Multimedia server in 3GPP is the HSS.

Registration:

SIP-registration.

Server:

SIP-server.

User data:

user profile data.

3.2 Abbreviations p. 9

For the purposes of the present document, the following abbreviations apply:

AAA

Authentication, Authorization and Accounting

ABNF

Augmented Backus-Naur Form

AVP

Attribute-Value Pair

Core Network

CSCF

Call Session Control Function

DSCP

Differentiated Services Code Point

DRMP

Diameter Routing Message Priority

HSS

Home Subscriber Server

IANA

Internet Assigned Numbers Authority

I-CSCF

Interrogating CSCF

IETF

Internet Engineering Task Force

IMS

IP Multimedia Subsystem

NDS

Network Domain Security

RFC

Request For Comments

S-CSCF

Serving CSCF

SCTP

Stream Control Transport Protocol

SIP

Session Initiation Protocol

SLF

Server Locator Function

UCS

Universal Character Set

URL

Uniform Resource Locator

UTF

UCS Transformation Formats

WAF

WebRTC Authentication Function

WWSF

WebRTC Web Server Function

4 General p. 9

The Diameter base protocol as specified in RFC 6733 shall apply except as modified by the defined support of the methods and the defined support of the commands and AVPs, result and event codes specified in clause 5 of this specification. Unless otherwise specified, the procedures (including error handling and unrecognised information handling) are unmodified.

5 Use of the Diameter base protocol p. 9

With the clarifications listed in the following clauses the Diameter base protocol defined by RFC 6733 shall apply.

5.1 Securing Diameter Messages p. 9

For secure transport of Diameter messages, see TS 33.210.

5.2 Accounting functionality p. 9

Accounting functionality (Accounting Session State Machine, related command codes and AVPs) is not used on the Cx interface.

5.3 Use of sessions p. 9

Both between the I-CSCF and the HSS and between the S-CSCF and the HSS, Diameter sessions are implicitly terminated. An implicitly terminated session is one for which the server does not maintain state information. The client does not need to send any re-authorization or session termination requests to the server.

The Diameter base protocol includes the Auth-Session-State AVP as the mechanism for the implementation of implicitly terminated sessions.

The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as described in RFC 6733. As a consequence, the server does not maintain any state information about this session and the client does not need to send any session termination request. Neither the Authorization-Lifetime AVP nor the Session-Timeout AVP shall be present in requests or responses.

5.4 Transport protocol p. 10

Diameter messages over the Cx and the Dx interfaces shall make use of SCTP RFC 4960.

5.5 Routing considerations p. 10

This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host.

If an I-CSCF or S-CSCF knows the address/name of the HSS for a certain user, both the Destination-Realm and Destination-Host AVPs shall be present in the request. Otherwise, only the Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node, e.g. the SLF or a Diameter Proxy Agent (see TS 29.228), based on the Diameter routing table in the client.

If the next Diameter node is an SLF, then once the SLF has returned the address or the destination HSS (using Redirect-Host AVP), the redirected request to the HSS shall include both Destination-Realm and Destination-Host AVPs. If the next Diameter node is a Diameter Proxy Agent, the Diameter Proxy Agent shall determine the destination HSS. The Diameter Proxy Agent, based on the result of this determination of the destination HSS, shall modify the Destination-Realm AVP and Destination-Host AVP of the request appropriately. The Diameter Proxy Agent shall then append a Route-Record AVP to the request and shall send the request to the destination HSS. Consequently, the Destination-Host AVP is declared as optional in the ABNF for all requests initiated by an I-CSCF or an S-CSCF.

If the response is routed back to a Diameter Proxy Agent, the Diameter Proxy Agent shall send the response back to the I-CSCF or S-CSCF without modifying the Origin-Realm AVP and Origin-Host AVP. The response shall contain the Origin-Realm AVP set to the realm of the HSS together with the Origin-Host AVP set to the HSS that sent the response. The S-CSCF shall store the HSS realm and HSS address for each Public Identity, after the first request sent to the User Identity to HSS resolution function.

Requests initiated by the HSS towards an S-CSCF shall include both Destination-Host and Destination-Realm AVPs. The HSS obtains the Destination-Host AVP to use in requests towards an S-CSCF, from the Origin-Host AVP received in previous requests from the S-CSCF. Consequently, the Destination-Host AVP is declared as mandatory in the ABNF for all requests initiated by the HSS.

Destination-Realm AVP is declared as mandatory in the ABNF for all requests.

5.6 Advertising Application Support p. 10

The HSS, S-CSCF and I-CSCF shall advertise support of the Diameter Multimedia Application by including the value of the application identifier (see clause 6) in the Auth-Application-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands.

The vendor identifier value of 3GPP (10415) and ETSI (13019) shall be included in the Supported-Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, and in the Vendor-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands.