Chapter 18 - Service Conﬁguration in the IMS pot

18.2 Downloading an XML Document, Attribute, or Element When an XDMC wants to receive an XML document, or a part of it, e.g., an attribute or element, it invokes the HTTP GET request in

Trang 1

Chapter 18

Service Configuration in the IMS

Chapter 17 provided a description of the protocols at the user’s disposal for configuring services on the Internet We saw that the service configuration architecture assumes an XML document stored on a server The client retrieves a copy of the XML document, makes changes to it, and sends the delta back to the server

In IMS, the architecture for service configuration architecture is developed around the XML Document Management (XDM) architecture created by the Open Mobile Alliance (OMA) in the XDM [244] set of specifications XDM allows a user to modify XML documents stored in remote network servers It also allows the local copy of those XML documents in the IMS terminal to be synchronized with the copy stored in network servers,

so that if the user makes changes to one XML document from a given IMS terminal, other terminals are updated with the latest changes Last, the XDM architecture also provides limited support for searches of information stored in these XML documents

18.1 XDM architecture

Let us describe the XDM architecture with the help of Figure 18.1 The XDM architecture assumes a terminal that implements the role of an XCAP client, and one or more servers, called XDM servers, that implement the role of XCAP servers XML documents are stored

in any of the servers and kept synchronized with the copy in the client When a user wants to change a configuration setting in a service, such as adding a friend to a presence list, the user changes the local copy of the XML document in the client and sends the change to the server, which applies it, and stores an updated version of the XML configuration document The XDM architecture introduces the following concepts

XDM client (XDMC) This is an XCAP client running in the IMS terminal The XDMC

implements the core XDM features and some application-specific features

Aggregation proxy This is an HTTP proxy that is configured as an HTTP reverse proxy.

The Aggregation Proxy authenticates the XDMC towards an XDMS It may also route XCAP requests towards an XDMS or towards an Aggregation Proxy located in remote network It also routes search requests towards the Search proxy When receiving responses, it can compress the body of the response

´ıa- M ar t´ın

The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition

Gonzalo Camarillo and Miguel A Garc

Trang 2

Figure 18.1: XDM architecture

Search proxy This is an HTTP proxy that processes search requests received from XDMCs

towards XDMSs or remote Aggregation Proxies On received responses, the Search proxy combines the results of the responses received from XDMSs and remote Aggregation Proxies before forwarding them to the XDMC

Shared XDM servers XDM servers (XMDSs) that are used by several applications Shared

XDMSs are effectively XCAP servers There are specialized shared XDMSs: shared list XDMS, shared group XDMS, shared profile XDMS, and shared policy XDMS

XDMSs This is an application-specific server for service configuration purposes

Effec-tively, XDMSs are XCAP servers that serve a single application

Most of the interfaces of the XDM architecture are implemented with XCAP This is the

case of the interfaces XDM-3, XDM-4, XDM-8 However, interfaces XDM-1 and XDM-2 are

used for subscription to changes in XML documents, based on the XCAP event package for

SIP Consequently, 1 and 2 are SIP interfaces Interfaces 5, 6,

XDM-7, and XDM-9 implement the Limited XQuery over HTTP protocol Unnamed interfaces in

Figure 18.1 are defined by their respective applications, but they typically consist of XCAP, SIP for subscriptions to XCAP event packages, and Limited XQuery over HTTP

The XDM architecture considers different applications that can be customers of the XDM service (or enabler, as it is called by the OMA) For example, the presence service is a customer of XDM, because the list of watchers, the authorization policies, etc., are all stored

in XML documents managed by XDM Other services that use XDM include Push-to-talk

Trang 3

18.2 DOWNLOADING AN XML DOCUMENT, ATTRIBUTE, OR ELEMENT 391

over Cellular and PSTN/ISDN simulation services Owing to this diversity of customers of XDM, the XDM architecture considers the existence of different XDM servers, each one perhaps specialized in serving a given application An XDMS is a logical representation of the service configuration aspects of a service or application In real products, it is expected that XDM servers are integrated into the specific server (e.g., presence server, PoC server, etc.)

Similarly, XDMCs are not really new entities, but just the logical representation of an XDM client in an IMS terminal

18.2 Downloading an XML Document, Attribute, or Element

When an XDMC wants to receive an XML document, or a part of it, e.g., an attribute

or element, it invokes the HTTP GET request in XCAP The basic HTTP GET operation according to the XDM architecture is shown with the help of Figure 18.2 The XDMC sends an HTTP GET request (1) to the Aggregation Proxy It is assumed that the address

of the Aggregation Proxy is pre-provisioned in the IMS terminal An example of this

HTTP GET request (1) is shown in Figure 18.3 The Request-URI is set to the part of the

XCAP URI that is identified in HTTP, thus, excluding the host name Of relevance in the HTTP GET request is the inclusion of an X-3GPP-Intended-Identity header field that

is populated with the identity that the user wants to present to the Aggregation Proxy The HTTP X-3GPP-Intended-Identity header field is specified in 3GPP TS 24.109 [9] and contains a SIP Public User Identity of the user This Public User Identity is also present as a username in the XCAP URI of the GET request

Figure 18.2: XDM: basic GET operation

GET /resource-lists/users/sip:alice@home1.com/index HTTP/1.1 Host: xdm.home1.com

User-Agent: XDM-client/OMA2.0

Date: Thu, 04 Mar 2008 22:10:45 GMT

X-3GPP-Intended-Identity: "sip:alice@home1.com"

Accept-Encoding: gzip

Figure 18.3: HTTP GET request (1)

Trang 4

The Aggregation Proxy first needs to authenticate the user There are several approaches

to authenticate a user One of them consist of using the Generic Authentication Architecture (GAA, specified in 3GPP TS 33.222 [15]) Essentially, GAA uses HTTP over TLS (specified

in RFC 4346 [121]), for security purposes, and then either a certificate in the client or a share password So, if GAA is used, all of the authentication takes place at the TLS level and not

at the HTTP level

However, Figure 18.2 shows another authentication mechanism based on HTTP Digest Authentication (specified in RFC 2617 [145]) The Aggregation Proxy receives an HTTP GET request (1) and issues a 401 (Unauthorized) response (2) that contains a challenge in the WWW-Authenticate header field As a minimum, the challenge contains the realm where the user will be authenticated, and a nonce, which is a random value that prevents against replay attacks An example of this 401 (Unauthorized) response is shown in Figure 18.4

HTTP/1.1 401 Unauthorized

Server: XDM-proxy/OMA2.0

Date: Thu, 04 Mar 2008 22:10:46 GMT

WWW-Authenticate: Digest realm="home1.com", qop=auth-int,

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093" Content-Length: 0

Figure 18.4: HTTP 401 (Unauthorized) response (2)

The IMS terminal receives the 401 (Unauthorized) response (2), extracts the challenge, computes the response to that challenge (considering the username, realm, password, and nonce), and generates a second HTTP GET request (3) that contains that response to the challenge in the Authorization header field An example of this HTTP GET request (3) is shown in Figure 18.5

GET /resource-lists/users/sip:alice@home1.com/index HTTP/1.1

Host: xdm.home1.com

Date: Thu, 04 Mar 2008 22:10:49 GMT

Authorization: Digest realm="home1.com", qop=auth-int,

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", username="sip:alice@home1.com", nc=00000001, uri="/resource-lists/users/sip:alice@home1.com/index", response="2c8ee200cec7f6e966c932a9242554e4",

cnonce="3bb96fe6e98a02ccb4555609c1b1bb56"

The Aggregation Proxy, upon receiving of this new HTTP GET request (3) that contains the credentials, first evaluates the response to the presented challenge and computes

if it matches the response provided by the XDMC If the response to the challenge

is correct, then it removes the Authorization header field and continues processing the request The Aggregation Proxy adds its own Via header field, and preserves the

X-3GPP-Intended-Identity header field Then it inspects the Request-URI, determines,

Trang 5

18.3 DIRECTORY RETRIEVAL 393

based on the Application Unique ID (AUID), the actual server that is responsible for serving the request, and forwards the HTTP GET request (4) to that server In the example, the AUID

is set to resource-list; the Shared List XDMS is responsible for that application, thus is the recipient of the HTTP GET request (4) An example of the forwarded request is shown in Figure 18.6

GET /resource-lists/users/sip:alice@home1.com/index HTTP/1.1 Host: xdm.home1.com

Via: HTTP/1.1 proxy.home1.com

Date: Thu, 04 Mar 2008 22:10:50 GMT

The Shared List XDMS then provides the requested XML document, element, or attribute

in a 200 (OK) response (5), and forwards the response back to the Aggregation Proxy An example of this response is shown in Figure 18.7

HTTP/1.1 200 OK

Server: XDM-serv/OMA2.0

Date: Thu, 04 Mar 2008 22:10:50 GMT

Etag: "asd92d092"

Content-Type: application/resource-lists+xml

Content-Length: 238

<?xml version="1.0" encoding="UTF-8"?>

<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">

</list>

</resource-lists>

Figure 18.7: 200 (OK) response (5)

The Aggregation Proxy then compresses the body of the 200 (OK) response, i.e., the XML document, according to any of the supported algorithms specified by the XDMC in the HTTP GET request (3) It also adds an Authentication-Info header field that contains the next nonce that the XDMC can use in a future HTTP request (so, future requests can directly include the response to a challenge and avoid one round trip) Then it forwards it back to the XDMC An example of this response is shown in Figure 18.8

18.3 Directory Retrieval

Sometimes users may need to retrieve all of their XML configuration documents that pertain

to one or more application usages This might be the case, for example, if the user is configuring a new IMS terminal The XDM architecture offers a mechanism to do perform

Trang 6

HTTP/1.1 200 OK

Via: HTTP/1.1 proxy.home1.com

Date: Thu, 04 Mar 2008 22:10:51 GMT

Etag: "asd92d092"

Authentication-Info: nextnonce="2a219bcb2ad25ae32cbe280c249f" Content-Encoding: gzip

Content-Type: application/resource-lists+xml

Content-Length: 159

[binary compressed data]

Figure 18.8: 200 (OK) response (6)

this type of operation The mechanism is briefly described in Figure 18.9, which for the sake

of brevity shows only two shared XDMSs

Figure 18.9: Directory retrieval with XDM

According to Figure 18.9, when the XDMC wants to obtain a directory retrieval for one or more applications, the XDMC sends an HTTP GET request (1) to its Aggregation Proxy Figure 18.9 assumes that the user is in possession of the next nonce value, obtained

in a previous HTTP operation, so the XDMC can compose a response to a challenge to authenticate towards the Aggregation Proxy An example of this HTTP request (1) is shown

in Figure 18.10

What makes the HTTP GET request (1) in Figure 18.10 different, so that it is

interpreted as a directory retrieval operation? The Request-URI, which partially contains

the URI of the resource, is the key The Request-URI contains a special AUID

called “org.openmobilealliance.xcap-directory”, which indicates the directory retrieval operation In addition, the Request-URI refers to a special document called

“directory.xml” which is available under the user’s tree The OMA defines the structure

of the XML document “directory.xml” in the XDM specification [245]

The Aggregation Proxy, once it has verified the identity of the user, forwards the GET request (2, 3) to each of the XDMSs Then, each XDMS returns a 200 (OK) response (4, 5) that contains a “directory.xml” document that lists all of the XML documents belonging

to that user and stored in that server for that application usage An example of one of the

Trang 7

18.3 DIRECTORY RETRIEVAL 395 GET /org.openmobilealliance.xcap-directory/users/sip:alice@home1.com /directory.xml HTTP/1.1

Host: xdm.home1.com

Date: Thu, 05 Mar 2008 22:10:49 GMT

nonce="102b98b7102dd2f0e8b11d0f600bfb0c789", username="sip:alice@home1.com", nc=00000002, uri="/org.openmobilealliance.xcap-directory/users /sip:alice@home1.com/directory.xml",

response="3a59fff43373a95592464948595c2e45", cnonce="abc123e6e98a02251455360951b1a900"

Figure 18.10: Directory retrieval: HTTP GET request (1)

200 (OK) response (5) is shown in Figure 18.11 The “directory.xml” is identified with a MIME type of vnd.oma.xcap-directory+xml

HTTP/1.1 200 OK

Date: Thu, 05 Mar 2008 22:10:52 GMT

Etag: "9sda09s"

Content-Type: application/vnd.oma.xcap-directory+xml

Content-Length: 432

<xcap-directory xmlns="urn:oma:xml:xdm:xcap-directory" >

<entry uri="http://xdm.home1.com/org.openmobilealliance.groups

/users/sip:alice@home1.com/family" etag="2098ds" />

/users/sip:alice@home1.com/co-workers" etag="39s09s" />

</folder>

</xcap-directory>

Figure 18.11: Directory retrieval: 200 (OK) response (5)

The Aggregation Proxy waits sufficient time to receive all of the responses and then combines all the received “directory.xml” documents into a single one, which is included

in a 200 (OK) response (6) to the XDMC (see Figure 18.12) Each folder element contains

an auid attribute that indicates the application usage to which the included data pertains This allows the XDMC to distinguish the application usages for which the user has XML documents, and the list of documents of each application usage

XDM not only allows a user to retrieve a directory of all of their documents stored in all servers, but also allows all user documents pertaining to a given XCAP application usage to

be retrieved This is done with a smart trick: XCAP allows a single element to be requested that is part of an XML document; the XDMC requests the folder element of the requested

Trang 8

HTTP/1.1 200 OK

Date: Thu, 05 Mar 2008 22:10:55 GMT

Etag: "x98w2k920"

Authentication-Info: nextnonce="3a2154334ce3409fd24e26872024"

Content-Type: application/vnd.oma.xcap-directory+xml

Content-Length: 599

/users/sip:alice@home1.com/family" etag="2098ds" />

/users/sip:alice@home1.com/co-workers" etag="39s09s" />

</folder>

<entry uri="http://xdm.home1.com/resource-lists/users

/sip:alice@home1.com/index" etag="0s982k" />

</folder>

</xcap-directory>

Figure 18.12: Directory retrieval: Aggregated 200 (OK) response (6)

application usage which is included in the overall directory.xml document The flow is shown in Figure 18.13

Figure 18.13: Directory retrieval with XDM for a given XCAP application usage

The XDMC sends an HTTP GET (1) whose Request-URI includes the pointer to the

folder element whose auid attribute matches the requested application usage in the directory.xml document In order to request a fraction of the directory.xml document,

the Request-URI also contains the special AUID

org.openmobilealliance.xcap-directory

as well as the special file “directory.xml” Figure 18.14 shows an example of this HTTP GET request (1) The notation

/xcap-directory/folder%5b@auid=%22resource-lists%22%5d

Trang 9

18.4 DATA SEARCH WITH XDM 397

is an escaped representation of

/xcap-directory/folder[@auid="resource-lists"]

which is the XCAP mechanism to indicate the folder element whose auid attribute is set

to the value resource-lists

GET /org.openmobilealliance.xcap-directory/users/sip:alice@home1.com /directory.xml/~~/xcap-directory

/folder%5b@auid=%22resource-lists%22%5d HTTP/1.1

Host: xdm.home1.com

Date: Thu, 18 Mar 2008 00:14:33 GMT

nonce="a126802384820945208bp98c0808e0f8021", username="sip:alice@home1.com", nc=00000003, uri="/org.openmobilealliance.xcap-directory /users/sip:alice@home1.com/directory.xml /~~/xcap-directory

/folder%5b@auid=%22resource-lists%22%5d", response="2143cc17309a58b37459b3745b38bb39", cnonce="c2948330a8530498d43309835d942531"

Figure 18.14: Directory retrieval of a specific application usage: HTTP GET request (1)

Upon receiving this HTTP GET request (1), the Aggregation Proxy verifies the credentials included in the request, and forwards the request (2) to the appropriate server The address

of this server depends on the application usage In this case, the Shared List XDMS is responsible for the resource-list application usage The Shared List XDMS builds an XCAP document that contains the request element This is a special XCAP MIME type application/xcap-el+xml that is used to denote an element of an XML document, as opposed to the complete XML document Figure 18.15 shows an example of this 200 (OK) response (3) The Aggregation Proxy merely forwards this response to the XDMC (4)

18.4 Data Search with XDM

XDM provides a limited search function, allowing XDMCs to search for data remotely stored

in XDMSs The search sequence flow is shown in Figure 18.16 In general, search requests originated in an XDMC are sent to an Aggregation Proxy, which forwards it to an appropriate Search Proxy, which further forwards it to the appropriate XDMS As usually, the architecture defines functional elements that, in real implementations, can be combined in single boxes

So, it is appropriate to combine the Aggregation Proxy and the Search Proxy into the same physical equipment Then, the actual search takes place in the XDMS, which returns the results of the search operation in an HTTP response

When an XDMC wishes to search some data in one or more remotely stored XML document, the XDMC creates an HTTP POST request (1) that contains all of the details required to perform the search This POST request encodes some details of the search

operation in the Request-URI, but the complete detailed parameters of the search are included

Trang 10

HTTP/1.1 200 OK

Date: Thu, 18 Mar 2008 00:14:35 GMT

Etag: "209d29d"

Content-Type: application/xcap-el+xml

Content-Length: 428

/users/sip:alice@home1.com/family" etag="9203" />

/users/sip:alice@home1.com/co-workers" etag="0293" />

</folder>

</xcap-directory>

Figure 18.15: Directory retrieval of a specific application usage: 200 (OK) response (3)

in a special XML document called the Search XML document, which is included as a body

of the POST request The search function reuses the XQuery 1.0 specification [88] XQuery provides mechanisms to extract and manipulate data from XML documents In the context of XDM Search operations, XQuery expressions are included in Search XML documents which are transported in HTTP POST requests

One of the parameters that characterize the search operation consists of the list of input documents where the search takes place The document or documents where the search takes place can be composed of either all documents of all users pertain-ing to a given XCAP application usage, all documents pertainpertain-ing to a given applica-tion usage and a given user, or a particular document For example, let AUID be the AUID, sip:alice@home1.com a Public User Identity, and mylist.xml an XML

docu-ment If the search takes place over all documents stored under the “users” directory

of the AUID, the document list is encoded as “[AUID]/users/”; if the search is re-stricted to Alice’s documents for the AUID application, then the search is encoded as

“[AUID]/users/sip:alice@home1.com/”; finally, if the search is restricted to a single user’s document, then the list of documents is encoded with the following pattern:

“[AUID]/users/sip:alice@home1.com/mylist.xml”

So, where is this document list encoded in HTTP? It is encoded in two different places:

in the Search XML document that is included in the HTTP POST request (1), and in the

target parameter of the Request-URI of the same HTTP POST request (1) The reason for

encoding the request in two places is twofold: on the one side, the Search XML document contains very detailed and extensive information of the search parameter, more than just the input documents, so, this justifies the presence of search documents in the Search XML body; on the other side, the Search Proxy requires knowledge of the AUID and the user’s name for routing the HTTP POST request (1) to the appropriate XDMS Making this routing information accessible, e.g., in a parameter of the Request-URI makes things easy for the Search Proxy that, otherwise, would need to open the body and parse the Search XML document to route the HTTP POST request (1)

Định dạng
Số trang	15
Dung lượng	529,08 KB