Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6080

A Framework for Session Initiation Protocol User Agent Profile Delivery

Pages: 54
Proposed Standard
Part 1 of 3 – Pages 1 to 14
None   None   Next

Top   ToC   RFC6080 - Page 1
Internet Engineering Task Force (IETF)                         D. Petrie
Request for Comments: 6080                                     SIPez LLC
Category: Standards Track                          S. Channabasappa, Ed.
ISSN: 2070-1721                                                CableLabs
                                                              March 2011


A Framework for Session Initiation Protocol User Agent Profile Delivery

Abstract

This document specifies a framework to enable configuration of Session Initiation Protocol (SIP) user agents (UAs) in SIP deployments. The framework provides a means to deliver profile data that user agents need to be functional, automatically and with minimal or no User and Administrative intervention. The framework describes how SIP user agents can discover sources, request profiles, and receive notifications related to profile modifications. As part of this framework, a new SIP event package is defined for notification of profile changes. The framework provides minimal data retrieval options to ensure interoperability. The framework does not include specification of the profile data within its scope. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6080.
Top   ToC   RFC6080 - Page 2
Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.
Top   ToC   RFC6080 - Page 3

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 6 3.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Profile Types . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Profile Delivery Stages . . . . . . . . . . . . . . . . . 9 3.5. Supported Device Types . . . . . . . . . . . . . . . . . . 10 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Simple Deployment Scenario . . . . . . . . . . . . . . . . 10 4.2. Devices Supporting Multiple Users from Different Service Providers . . . . . . . . . . . . . . . . . . . . 12 5. Profile Delivery Framework . . . . . . . . . . . . . . . . . . 14 5.1. Profile Delivery Stages . . . . . . . . . . . . . . . . . 14 5.2. Securing Profile Delivery . . . . . . . . . . . . . . . . 22 5.3. Additional Considerations . . . . . . . . . . . . . . . . 24 5.4. Support for NATs . . . . . . . . . . . . . . . . . . . . . 33 6. Event Package Definition . . . . . . . . . . . . . . . . . . . 33 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 33 6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 33 6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 36 6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 37 6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 37 6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 37 6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 38 6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 38 6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 39 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 39 6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 39 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7.1. Example 1: Device Requesting Profile . . . . . . . . . . . 39 7.2. Example 2: Device Obtaining Change Notification . . . . . 42 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 8.1. SIP Event Package . . . . . . . . . . . . . . . . . . . . 46 8.2. Registry of SIP Configuration Profile Types . . . . . . . 46 9. Security Considerations . . . . . . . . . . . . . . . . . . . 47 9.1. Local-Network Profile . . . . . . . . . . . . . . . . . . 48 9.2. Device Profile . . . . . . . . . . . . . . . . . . . . . . 49 9.3. User Profile . . . . . . . . . . . . . . . . . . . . . . . 50 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 11.1. Normative References . . . . . . . . . . . . . . . . . . . 52 11.2. Informative References . . . . . . . . . . . . . . . . . . 53
Top   ToC   RFC6080 - Page 4

1. Introduction

SIP user agents require configuration data to function properly. Examples include information specific to local networks, devices, and users. A configuration data set specific to an entity is termed a profile. For example, device profile contains the configuration data related to a device. The process of providing devices with one or more profiles is termed "profile delivery". Ideally, this profile delivery process should be automatic and require minimal or no user intervention. Many deployments of SIP user agents require dynamic configuration and cannot rely on pre-configuration. This framework provides a standard means of providing dynamic configuration that simplifies deployments containing SIP user agents from multiple vendors. This framework also addresses change notifications when profiles change. However, the framework does not define the content or format of the profile, leaving that to future standardization activities. This document is organized as follows. The normative requirements are contained in Section 5 (framework operations) and Section 6 (the event package definition). The rest of the document provides introductory and supporting explanations. Section 3 provides a high- level overview of the abstract components, profiles, and the profile delivery stages. Section 4 provides some motivating use cases. Section 7 follows with illustrative examples of the framework in use.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document also reuses the SIP terminology defined in [RFC3261] and [RFC3265], and it specifies the usage of the following terms. Device: software or hardware entity containing one or more SIP user agents. It may also contain applications such as a DHCP client. Device Provider: the entity responsible for managing a given device. Local Network Provider: the entity that controls the local network to which a given device is connected. SIP Service Provider: the entity providing SIP services to users. This can refer to private or public enterprises.
Top   ToC   RFC6080 - Page 5
   Profile:  configuration data set specific to an entity (e.g., user,
      device, local network, or other).

   Profile Type:  a particular category of profile data (e.g., user,
      device, local network, or other).

   Profile Delivery Server (PDS):  the source of a profile, it is the
      logical collection of the Profile Notification Component (PNC) and
      the Profile Content Component (PCC).

   Profile Notification Component (PNC):  the logical component of a
      Profile Delivery Server that is responsible for enrolling devices
      and providing profile notifications.

   Profile Content Component (PCC):  the logical component of a Profile
      Delivery Server that is responsible for storing, providing access
      to, and accepting profile content.

   Profile Delivery Stages:  the processes that lead a device to obtain
      profile data, and any subsequent changes, are collectively called
      profile delivery stages.

   Bootstrapping:  Bootstrapping is the process by which a new (or
      factory reset) device, with no configuration or minimal "factory"
      pre-configuration, enrolls with the PDS.  The device may use a
      temporary identity and credentials to authenticate itself to
      enroll and receive profiles, which may provide more permanent
      identities and credentials for future enrollments.

3. Overview

This section provides an overview of the configuration framework. It presents the reference model, the motivation, the profile delivery stages, and a mapping of the concepts to specific use cases. It is meant to serve as a reference section for the document, rather than providing a specific logical flow of material, and it may be necessary to revisit these sections for a complete appreciation of the framework. The SIP UA Profile Delivery Framework uses a combination of SIP event messages (SUBSCRIBE and NOTIFY; [RFC3265]) and traditional file retrieval protocols, such as HTTP [RFC2616], to discover, monitor, and retrieve configuration profiles. The framework defines three types of profiles (local-network, device, and user) in order to separate aspects of the configuration that may be independently managed by different administrative domains. The initial SUBSCRIBE message for each profile allows the UA to describe itself (both its implementation and the identity requesting the profile), while
Top   ToC   RFC6080 - Page 6
   requesting access to a profile by type, without prior knowledge of
   the profile name or location.  Discovery mechanisms are specified to
   help the UA form the Subscription URI (the Request-URI for the SIP
   SUBSCRIBE).  The SIP User Agent Server (UAS) handling these
   subscriptions is the Profile Delivery Server (PDS).  When the PDS
   accepts a subscription, it sends a NOTIFY to the device.  The initial
   NOTIFY from the PDS for each profile may contain profile data or a
   reference to the location of the profile, to be retrieved using HTTP
   or similar file retrieval protocols.  By maintaining a subscription
   to each profile, the UA will receive additional NOTIFY messages if
   the profile is later changed.  These may contain a new profile, a
   reference to a new profile, or a description of profile changes,
   depending on the Content-Type [RFC3261] in use by the subscription.
   The framework describes the mechanisms for obtaining three different
   profile types, but does not describe the data model they utilize (the
   data model is out of scope for this specification).

3.1. Reference Model

The design of the framework was the result of a careful analysis to identify the configuration needs of a wide range of SIP deployments. As such, the reference model provides for a great deal of flexibility, while breaking down the interactions to their basic forms, which can be reused in many different scenarios. The reference model for the framework defines the interactions between the Profile Delivery Server (PDS) and the device. The device needs the profile data to function effectively in the network. The PDS is responsible for responding to device requests and providing the profile data. The reference model is illustrated in Figure 1. +-------------------------+ +--------+ | Profile Delivery Server | | Device |<==========================>| +---+ +---+ | +--------+ | |PNC| |PCC| | | +---+ +---+ | +-------------------------+ PNC = Profile Notification Component PCC = Profile Content Component Figure 1: Framework Reference Model The PDS is subdivided into two logical components: o Profile Notification Component (PNC), responsible for enrolling devices for profiles and providing profile change notifications.
Top   ToC   RFC6080 - Page 7
   o  Profile Content Component (PCC), responsible for storing,
      providing access to, and accepting modifications related to
      profile content.

3.2. Motivation

The motivation for the framework can be demonstrated by applying the reference model presented in Section 3.1 to two scenarios that are representative of the two ends of a spectrum of potential SIP deployments. In the simplest deployment scenario, a device connects through a network that is controlled by a single provider who provides the local network, manages the devices, and offers services to the users. The provider propagates profile data to the device that contains all the necessary information to obtain services in the network (including information related to the local network and the users). This is illustrated in Figure 2. An example is a simple enterprise network that supports SIP-based devices. -------------- / Local Network, \ | Device & Service | \ Provider / ---------------- | | -------- | Device | -------- | | ---- |User| ---- Figure 2: Simple Deployment Model In more complex deployments, devices connect via a local network that is not controlled by the SIP service provider, such as devices that connect via available public WiFi hot spots. In such cases, local network providers may wish to provide local network information such as bandwidth constraints to the devices. Devices may also be controlled by device providers that are independent of the SIP service provider who provides user services, such as kiosks that allow users to access services from remote
Top   ToC   RFC6080 - Page 8
   locations.  In such cases, the profile data may have to be obtained
   from different profile sources: local network provider, device
   provider, and SIP service provider.  This is indicated in Figure 3.

      --------
    /   SIP    \
   |   Service  |                -> Provides 'user' profile
   |  Provider  |                   data (e.g., services
    \          /                    configuration)
      --------      --------
          |       /          \
          |      |   Device   |  -> Provides 'device' profile
          |      |  Provider  |     data (e.g., device specifics)
          |       \          /
          |         ---------
          |        /
          |       /    -------
          |      /   /  Local  \
          |     /   |  Network  |
          |    |    |  Provider | -> Provides 'local-network' profile
          |    |     \         /     data (e.g., bandwidth)
          |    |       -------
          |    |        /
          |    |       /
          |    |      |
     ===================
    (   Local Network   )
     ===================
             |
             |
          --------
         | Device |              -> Needs the 'local-network'
          --------                  and 'device' profile
          /     \
         /       \
       ------   ------
      |User A| |User B|          -> Users need 'user' profiles
       ------   ------

                    Figure 3: Complex Deployment Model

   In either case, Providers need to deliver to the device, profile data
   that is required to participate in their network.  Examples of
   profile data include the list of codecs that can be used and the SIP
   proxies to which to connect for services.  Pre-configuration of such
   information is one option if the device is always served by the same
   set of Providers.  In all other cases, the profile delivery needs to
   be automated and consistent across Providers.  Given the presence of
Top   ToC   RFC6080 - Page 9
   a number of large deployments where pre-configuration is neither
   desired nor optimal, there is a need for a common configuration
   framework such as the one described in this document.

   Further, the former deployment model can be accomplished by the
   device obtaining profile data from a single provider.  However, the
   latter deployment model requires the device to obtain profile data
   from different providers.  To address either deployment or any
   variation in between, one needs to allow for profile delivery via one
   or more Providers.  The framework accomplishes this by specifying
   multiple profile types and a set of profile delivery stages to obtain
   them.  These are introduced in the subsections to follow.

3.3. Profile Types

The framework handles the presence of potentially different Providers by allowing for multiple profile types. Clients request each profile separately, and obtain them from the same, or different, Providers. A deployment can also choose to pre-configure the device to request only a subset of the specified profile types. The framework specifies three basic profile types, as follows: Local Network Profile: contains configuration data related to the local network to which a device is directly connected, provided by the local network provider. Device Profile: contains configuration data related to a specific device, provided by the device provider. User Profile: contains configuration data related to a specific User, as required to reflect that user's preferences and the particular services to which it is subscribed. It is provided by the SIP service provider. Additional profile types may also be specified by future work within the IETF. The data models associated with each profile type are out of scope for this document.

3.4. Profile Delivery Stages

The framework specified in this document requires a device to explicitly request profiles. It also requires one or more PDSs, which provide the profile data. The processes that lead a device to obtain profile data, and any subsequent changes, can be explained in three stages, termed the profile delivery stages.
Top   ToC   RFC6080 - Page 10
   Profile Enrollment:  the process by which a device requests, and if
      successful, enrolls with a PDS capable of providing a profile.  A
      successful enrollment is indicated by a notification containing
      the profile information (contents or content indirection
      information).  Depending on the request, this could also result in
      a subscription to notification of profile changes.

   Profile Content Retrieval:  the process by which a device retrieves
      profile contents, if the profile enrollment resulted in content
      indirection information.

   Profile Change Notification:  the process by which a device is
      notified of any changes to an enrolled profile.  This may provide
      the device with modified profile data or content indirection
      information.

3.5. Supported Device Types

The examples in this framework tend to associate devices with entities that are accessible to end-users. However, this is not necessarily the only type of device that can utilize the specified framework. Devices can be entities such as SIP Phones or soft clients, with or without user interfaces (that allow for device configuration), entities in the network that do not directly communicate with any users (e.g., gateways, media servers, etc.) or network infrastructure elements (e.g., SIP servers). The framework is extensible for use with such device types. However, it is to be noted that some of these other device types (e.g., network elements) may also be configurable using other mechanisms. The use of this framework in conjunction with other mechanisms (specified outside of this document), is out of scope.

4. Use Cases

This section provides a small, non-comprehensive set of representative use cases to further illustrate how this framework can be utilized in SIP deployments. The first use case is simplistic in nature, whereas the second is relatively complex. The use cases illustrate the effectiveness of the framework in either scenario. For security considerations, please refer to Sections 5 and 9.

4.1. Simple Deployment Scenario

Description: Consider a deployment scenario (e.g., a small private enterprise) where a participating device implements this framework and is configured, using previously obtained profile data, to request only the device profile. Assume that the device operates in the same
Top   ToC   RFC6080 - Page 11
   network as the PDS (i.e., there is no NAT) and it obtains its IP
   configuration using DHCP.  Typical communication between the device
   and the PDS will traverse one or more SIP proxies, but is not
   required, and is omitted in this illustration.

   Figure 4 illustrates the sequence of events that includes device
   start-up and a successful profile enrollment for the device profile
   that results in device profile data.  It then illustrates how a
   change in the profile data is delivered via Profile Change
   Notification.

                                         +----------------------+
    +--------+                           |  Provider's Network  |
    | Device |                           |                      |
    |        |                           |                      |
    +--------+                           |  DHCP        PDS     |
                                         +----------------------+
         |                                   |          |
    (A)  |<============== DHCP =============>|          |
         |                                              |
         |                                              |
         |                                              |
    (B)  |<=========== Profile Enrollment  ============>|
         |                                              | Profile data
         |                                              | is modified
         |                                              |
    (C)  |<============ Profile Change  ================|
         |               Notification                   |
         |                                              |
         |                                              |

                           Figure 4: Use Case 1

   The following is an explanation of the interactions in Figure 4.

   (A)  Upon initialization, the device obtains IP configuration
        parameters such as an IP address using DHCP.

   (B)  The device requests profile enrollment for the device profile.
        Successful enrollment provides it with a notification containing
        the device profile data.

   (C)  Due to a modification of the device profile, a profile change
        notification is sent across to the device, along with the
        modified profile.
Top   ToC   RFC6080 - Page 12

4.2. Devices Supporting Multiple Users from Different Service Providers

Description: Consider a single device that allows multiple users to obtain services from different SIP service providers, e.g., a kiosk at an airport. The following assumptions apply: o Provider A is the device and local network provider for the device, and the SIP service provider for user A; Provider B is the SIP service provider for user B. o Profile enrollment always results in content indirection information requiring profile content retrieval. o Communication between the device and the PDSs is facilitated via one or more SIP proxies (only one is shown in the illustration). Figure 5 illustrates the use case and highlights the communications relevant to the framework specified in this document.
Top   ToC   RFC6080 - Page 13
     User User
       A   B        +----------------------+  +----------------------+
    +--------+      |       Provider       |  |       Provider       |
    | Device |      |           A          |  |          B           |
    |        |      |                      |  |                      |
    +--------+      | DHCP    PROXY   PDS  |  |  PROXY        PDS    |
                    +----------------------+  +----------------------+
         |              |        |      |          |           |
     (A) |<====DHCP====>|        |      |          |           |
         |                       |      |          |           |
         |                       |      |          |           |
         |  Profile Enrollment   |      |          |           |
     (B) |<local-network profile>|<====>|          |           |
         |
         |   <<Profile content retrieval>>
         |
         |
         |  Profile Enrollment   |      |          |           |
     (C) |<== device profile ==> |<====>|          |           |
         |
         |   <<Profile content retrieval>>
         |
                      .
                      .
                      .

         |   Profile Enrollment  |      |          |           |
     (D) |<= user profile (A) => |<====>|          |           |
         |                       |      |          |           |
         |
         |   <<Profile content retrieval>>
                              .
             [[User A obtains services]]
                      .
                      .
                      .
         |
         |            Profile Enrollment           |           |
     (E) |<=========== user profile (B) ==========>|<=========>|
         |                                         |           |
         |   <<Profile content retrieval>>
         |

             [[User B obtains services]]

                           Figure 5: Use Case 2
Top   ToC   RFC6080 - Page 14
   The following is an explanation of the interactions in Figure 5.

   (A)  Upon initialization, the device obtains IP configuration
        parameters using DHCP.  This also provides the local domain
        information to help with local-network profile enrollment.

   (B)  The device requests profile enrollment for the local network
        profile.  It receives an enrollment notification containing
        content indirection information from Provider A's PDS.  The
        device retrieves the profile (this contains useful information
        such as firewall port restrictions and available bandwidth).

   (C)  The device then requests profile enrollment for the device
        profile.  It receives an enrollment notification resulting in
        device profile content retrieval.  The device initializes the
        user interface for services.

   (D)  User A with a pre-existing service relationship with Provider A
        attempts communication via the user interface.  The device uses
        the user supplied information (including any credential
        information) and requests profile enrollment for user A's
        profile.  Successful enrollment and profile content retrieval
        results in services for user A.

   (E)  At a different point in time, user B with a service relationship
        with Provider B attempts communication via the user interface.
        It enrolls and retrieves user B's profile and this results in
        services for user B.

   The discovery mechanisms for profile enrollment described by the
   framework, or the profile data themselves, can result in outbound
   proxies that support devices behind NATs, using procedures specified
   in [RFC5626].



(page 14 continued on part 2)

Next Section