Internet Engineering Task Force D. Petrie Internet Draft Pingtel Document: draft-petrie-sip-config-framewk-reqs-00.txt Expires: July 2001 February 1, 2001 Requirements for a SIP User Agent Configuration Framework Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines a set of high level requirements for an extensible framework to configure SIP user agents Petrie Informational - Expires July 2001 1 Requirements for a SIP User Agent February 2001 Configuration Framework Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1 Overview.......................................................3 2 Conventions used in this document..............................3 3 Assumptions....................................................3 3.1 Network configuration........................................3 3.2 Firewalls....................................................4 3.3 Terminology..................................................4 3.4 Simplicity...................................................4 4 Requirements...................................................4 4.1 Configuration Service Discovery..............................5 4.2 Configuration Consumer Registration..........................5 4.3 Configuration Retrieval......................................6 4.4 Configuration Change Notification............................6 4.5 Configuration Modification...................................7 5 References.....................................................8 6 Author's Address...............................................8 Petrie Informational - Expires July 2001 2 Requirements for a SIP User Agent February 2001 Configuration Framework 1 Overview There is a general need to standardize methods for adding, configuring, and maintaining SIP user agents within a VoIP system. When one considers the effort needed to set up systems with hundreds or thousands of user agents, the need for reducing set up time is obvious. After a system is set up, ongoing maintenance in the form of changing the configuration of the user agents, or upgrading the software or firmware on a large population of user agents, is likely to be necessary and requires a similar administrative effort. In addition to these scaling problems, it is likely that the population of user agents in any given VoIP system will be heterogeneous: the configuration strategy must be flexible enough to accommodate different needs for different users. Consequently, for VoIP system administration sanity and cost practicality, a multi- vendor configuration standard is needed. Due to the highly divergent capabilities and purposes of the SIP user agent population, it seems impractical to propose a single set of data content to configure all possible variations. Common data sets, or content profiles, can probably be defined, but special purpose user agents or vendor value-added features are always likely to need specific configuration data sets beyond any defined norm This document proposes a general framework to support the use of open data sets for configuring SIP user agents. Discussion of the requirements for the content and format of these data profiles is left for another document. 2 Conventions used in this document 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 [1]. 3 Assumptions 3.1 Network configuration An assumption is made that basic network configuration can be completed for the user agent device, based on the availability of either: - DHCP - a manual, vendor-specific method for providing static network settings to the user agent device Once basic network configuration is completed through one of these methods, the configuration task that remains is to make the device functional within its SIP domain. Petrie Informational - Expires July 2001 3 Requirements for a SIP User Agent February 2001 Configuration Framework 3.2 Firewalls There are two basic network topologies that need to be supported by a standard SIP UA configuration: · Hosted VoIP Services · Enterprise Based VoIP systems The primary difference between these topologies, from a configuration standpoint, is the placement of the server(s) that provide the configuration and the devices relative to a firewall. This spec does not propose to solve the firewall issue. At least one protocol (or set of protocols if more than one are used for configuration purposes) must be usable through a firewall, where the devices are on the inside and the server is on the outside. 3.3 Terminology Because a configuration server must perform a number of logical functions, implementers may decide to spread different functions across multiple servers. However, this document references this potential collection of configuration servers in the singular as the server. A user agent device may actually be software running on a general purpose computer, or a specially built hardware appliance. The user agent to be configured is referenced as the device. 3.4 Simplicity There are likely to be a wide range of configuration servers implemented (for example, to provide scalability range, feature sets, etc.). It is intended that the requirement defined here will allow the server to be active and feature rich. However, it should also be possible to build a simple server that meets the minimum requirement for devices by delivering nearly static configuration content. 4 Requirements The requirements for the configuration of a SIP user agent can be divided into the following high-level functions: · Discovery · Registration · Configuration Retrieval · Notification of Configuration Changes · Configuration upload/change These functional groups are intended only to provide a means to think about and organize the requirements. They are not required to be discrete steps, and they do not dictate a specific model. Petrie Informational - Expires July 2001 4 Requirements for a SIP User Agent February 2001 Configuration Framework 4.1 Configuration Service Discovery Once the network configuration has been resolved using either DHCP or some static method, the first problem for a new SIP user agent to solve is where to get its configuration. There are a number of well- defined ways to resolve this configuration service discovery problem. Most existing solutions are trivial to implement, although each has pros and cons. It is likely that a number of the existing solutions should be supported to perform this function as either the network environment or administration may dictate which solutions will work or be allowed. · A device MUST be able to determine where to retrieve its configuration without manual provisioning. 4.2 Configuration Consumer Registration The next operation that a new device in the network must perform is to register with the configuration server. The server may require notification of a devices presence in order to create a new set of configuration data values, allocate resources, etc. · A device that is new to the configuration domain MUST make the configuration server aware of its presence before it can retrieve configuration data for the first time. · A server MUST be able to uniquely identify every device in its management domain. · A devices identity MUST NOT change through its lifetime in a management domain. · A device MUST have specific identifying configuration values (for example, Vendor, Model number, Software or firmware version, serial number, MAC address, etc.). · To facilitate hardware swap out, it MUST be possible for device-specific configuration values, stored in the server, to be reassigned ). · The device MUST be able to specify the configuration data profiles that it requires (for example, the SIP parameters, software or firmware updates, CPL scripts, applications, etc.) so that the server can identify which devices are affected by a given configuration change. · The server MUST be able to specify the configuration data profiles that it can provide. Petrie Informational - Expires July 2001 5 Requirements for a SIP User Agent February 2001 Configuration Framework · The configuration server MUST be able to communicate the locations(s) (in the form of URL(s) or address(es), for example) from which the device may retrieve specific configuration data. · It MUST be possible, over time, to change the location(s) from which configuration data is retrieved (as the result of failure, administration changes, etc.). · The server MAY require authentication and authorization of the device in order for it to join the configuration servers management domain. . · The device MAY require authentication of the server. · The device MAY support the ability to authenticate the configuration server. 4.3 Configuration Retrieval Configuration requirements and data are likely to vary widely from device to device. As a result, it is proposed that the mechanism for retrieval be a framework as opposed to closed and single purpose Where common sets of data can be derived across multiple vendors, data profiles can be defined to contain that common data in a standard format. These profiles should be named so that upon registration, a device can specify which profiles it requires However, it is unreasonable to expect that a single profile can be used to configure all devices, great and small. On the other hand, it is reasonable to define a single profile (or set of profiles) that will configure a device as a basic SIP user agent. Extended features and functions can then be configured through separate additional profiles. · A device MAY retrieve configuration data for a specified user. · The server MUST support the retrieval of device- and user- specific configuration data values by a device. · The server MAY infer a default user specific to that device, if the device does not specify a user for the configuration data retrieved. · The server and device MAY support secure retrieval of configuration data. · The server MAY require authorization for data retrieval. 4.4 Configuration Change Notification Configuration data is not static. It is likely to be changed over time on the server by either this standard, or by some proprietary Petrie Informational - Expires July 2001 6 Requirements for a SIP User Agent February 2001 Configuration Framework interface. It is up to the implementer to provide the business logic as to when devices should be notified after some configuration change occurs on the server. As a result, a standard means of notifying the device that changes in the configuration data of interest have occurred is proposed. In some environments it may not be possible for the server to initiate configuration change notifications. · The server MAY notify the device of configuration data changes. · The device SHOULD perform the necessary operations to retrieve and make effective the configuration changes indicated by the change notification. · The server and the device SHOULD support an expiration period for configuration data. When this period ends, the device SHOULD automatically retrieve refreshed data or confirm that no changes have occurred. · The server MAY specify in advance that a configuration change is to occur (that is, schedule changes). 4.5 Configuration Modification In addition to data changes made on the server, the device (or other consumers of device configuration) may provide a facility for modifying the data. The device therefore requires a means of communicating such configuration modifications back to the server. · The device MAY upload configuration changes to the server. · The server MAY require authentication and authorization for the configuration changes. · The server MAY enforce authentication and authorization scopes at a finer granularity than on a single vs. whole configuration profile (that is, some end users may not be permitted to modify all parameters). · The user requesting the configuration change MAY be different than the user to whom the configuration profile applies. Petrie Informational - Expires July 2001 7 Requirements for a SIP User Agent February 2001 Configuration Framework 5 References [1] S. Bradner, "The Internet Standards Process -- Revision 3", RFC2026 (BCP), IETF, October 1996. [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol", Request for Comments (Proposed Standard) 2543, Internet Engineering Task Force, Mar1999. [3] H. Schulzrinne, Configuring IP Telephony End Systems, Internet Draft, Internet Engineering Task Force, December 28, 2000 Work in progress. 1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 6 Author's Address Dan Petrie Pingtel Corp. 400 W. Cummings Park Phone: 1-781-938-5306 Suite 2200 Email: dpetrie@pingtel.com Woburn, MA 01801 USA Petrie Informational - Expires July 2001 8