tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6080

Proposed STD
Pages: 54
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: SIPPING

A Framework for Session Initiation Protocol User Agent Profile Delivery

Part 1 of 3, p. 1 to 14
None       Next RFC Part

 


Top       ToC       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.

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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part