Internet Engineering Task Force                    B. Beser
   INTERNET DRAFT                                     Juniper Networks
   DHC Working Group                                              B. Beser
Internet Draft                         Pacific Broadband Communications                                  P. Duffy (ed.)
   Document: draft-ietf-dhc-packetcable-01.txt                October 2000
Category: Informational draft-ietf-dhc-packetcable-02.txt        Cisco Systems
                                                      June 2002

              DHCP Option for PacketCable VoIP CableLabs Client Configuration

   1.   Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1]. 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 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.

1.

   2.   Abstract

   The Voice over IP work carried over in

   This document defines a DHCP option that will be used to configure
   various devices deployed within CableLabs architectures.
   Specifically, the PacketCable project
   conducted by CableLabs. The configuration document describes DHCP option content that will be
   used to configure one class of the PacketCable Voice
   over IP CableLabs client device: a PacketCable
   Media Terminal Adapter (MTA).  It is achieved using DHCP messaging.

   This document contains expected that the definition option content
   defined within this document will be extended as future CableLabs
   client devices are developed.

   3.   Table of Contents

   1.   Status of this Memo..........................................1
   2.   Abstract.....................................................1
   3.   Table of Contents............................................1
   4.   Conventions used in this document............................2
   5.   Terminology..................................................2
   6.   Introduction.................................................2
   7.   CableLabs Client Configuration Option Format.................4
   8.   CableLabs Client Configuration Option: Sub-Option Definitions 5
   8.1.   TSP's DHCP Server Address Sub-Options.......................5

  Beser & Duffy                                                     1 
   8.2.   TSP's SNMP Entity Address Sub-Option........................5
   8.3.   TSP's Domain Name Server Address Sub-Options................7
   8.4.   TSP's Kerberos Realm Name Sub-Option........................7
   8.5.   TSP's Ticket Granting Server Utilization Sub-Option.........8
   8.6.   TSP's Provisioning Timer Sub-Option.........................8
   8.7.   TSP's AS-REQ/AS-REP Backoff and Retry.......................8
   8.8.   TSP's AP-REQ/AP-REP Backoff and Retry.......................9
   9.   Typical use of the PacketCable VoIP CableLabs Client
   configuration option.

2. Configuration Option.....9
   10.  IANA Considerations..........................................9
   11.  Legacy Use Information......................................10
   12.  Procedure for Adding Additional Sub-options.................10
   13.  Security Considerations.....................................10
   14.  References..................................................10
   15.  Acknowledgments.............................................11
   16.  Author's Addresses..........................................11
   17.  Full Copyright Statement....................................11

   4.   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 [2].

3. DHCP

   5.   Terminology

   o "DHCP client"

   A DHCP client or "client" is an Internet host using DHCP to obtain
   configuration parameters such as a network address.

   o "DHCP server"

Beser            Informational  Expiration May 2000                1
        PacketCable VoIP Client Configuration           October 2000

   A DHCP server of "server"is an Internet host that returns
   configuration parameters to DHCP clients.

   o "binding"

   A binding is a collection

   Definitions of configuration parameters, including at
   least an IP address, associated with terms used throughout this document:

      *  "Telephony Service Provider" or "bound to" "TSP"

   The business entity from which a subscriber receives telephony
   service.

   See RFC2131[5] for additional DHCP client.
   Bindings are managed by DHCP servers.

4. terminology.

   6.   Introduction

   PacketCable is a project conducted by

   Cable Television Laboratories, Inc. (CableLabs) is a non-profit
   research and its member companies development consortium that serves the cable television
   industry via design and specification of new and emerging broadband
   service architectures. Several CableLabs initiatives define DHCP
   clients that have specific DHCP configuration requirements.  One such
   initiative is the PacketCable project.

   The PacketCable project is aimed at identifying, architecting, qualifying, and
   supporting Internet-based voice and video products
   over cable systems. These products will represent new classes of multimedia services utilizing over cable-based packet communication
   networks. New
   service classes These new multimedia services will include telephone calls and videoconferencing over
   cable networks telephony and the Internet. The services would be
   videoconferencing, delivered using the basic Internet Protocol (IP)
   technology that is used to send data via the Internet.

   The

  Beser & Duffy         Expires December 2002                       2 
   PacketCable embedded-MTA (MTA) is a single physical device with
   dual personality: 1.0 provides Voice over IP (VoIP) service delivery. The
   VoIP service is supported at the customer site by two key components:
   a Cable Modem (CM) and a VoIP device. Both of
   these devices are administered by different entities. Both of Media Terminal Adapter (MTA).  The CM
   converts the
   personalities have different IP addresses and different cable RF signals to/from various IP
   configurations.

   PacketCable project produced specifications of VoIP elements, which
   can be found in www.packetcable.com. The PacketCable VoIP Client uses
   DHCP for configuration. Due to specific needs of PacketCable client a
   new DHCP option is needed. The new option is designed to have a
   number of sub-information, which is laid down in DHCP option fashion
   [3].

5. PacketCable VoIP Client Configuration Option

   The code for this option is TBD.

   The PacketCable VoIP Client Configuration option is used by voice protocols,
   while the MTA converts the
   PacketCable VoIP clients to identify protocols into analog telephony
   compatible with a list of valid PacketCable
   specific network servers.

   The option sub-fields contain information regarding these servers. common telephone.

   The option is included in DHCP OFFER-s, CM and MTA may be packaged together or separately.  If packaged
   together, the unit is laid out referred to as an Embedded-MTA (EMTA - depicted
   below:

   -------------------------------------------------------------
   | TBD | Length | Subfield 1 | Subfield 2 | ... | Subfield n |
   -------------------------------------------------------------

   Each sub-field is
   in Figure 1). If packaged separately, the form of:

Beser              Informational  Expires May 2000                  2
        PacketCable VoIP Client Configuration           October 2000

   ---------------------------------------------------
   | Sub-field Number | Length | Subfield information |
   ---------------------------------------------------

   Each sub-field of the PacketCable VoIP Client Configuration
   identifies MTA is referred to as a particular type of PacketCable server. Sub-fields 1 and
   2 identify the primary and secondary PacketCable network DHCP
   servers, sub-field 3 identifies the PacketCable service provider's
   SNMP entity, and sub-fields 4 and 5 identify the primary and
   secondary PacketCable network DNS servers. The Sub-fields are
   summarized below:

   --------------------------------------------------------------------
   |Option |Sub-field | Description and Comments                      |
   ====================================================================
   | TBD   |     1
   Standalone MTA (SMTA).

              |----------------------------------------------|
              | Telephony Service Provider Primary DHCP                                              |
              |   |-----------|           |-------------|    |
              | Server Address   |           |       |-----------------------------------------------------------           |             |     2    |
    Telephony Service Provider Secondary DHCP     |
   |       |          | Server Address                                |
   |       |----------------------------------------------------------- |   |     3    | Telephony Service Provider SNMP Server Address|  Media    |       |----------------------------------------------------------- internal  |   Cable     |     4    | Telephony Service Provider Network Primary RF Link
    ---------_|---| Terminal  |===========|   Modem     |----|-------
    Link      |   | Adapter   | connection|             | Domain Name Server Address    |
              |       |-----------------------------------------------------------   |-----------|           |-------------|    |
              |     5                                              | Telephony Service Provider Network Secondary  |
   |       |          | Domain Name Server Address                    |
   --------------------------------------------------------------------

6.
              |----------------------------------------------|

                     Figure 1. PacketCable VoIP Client option Sub-field Definitions 1.0 Embedded-MTA

   The following parts provide detailed descriptions of each sub-field
   of DHCP PacketCable VoIP Client option. Note that UDP port numbers CM and MTA are normally standard values as defined in [4]. distinct IP devices: each has its own MAC address
   and IP configuration. The port numbers
   MAY be omitted, if CM and MTA utilize the standard DHCP protocol ports are to be used as
   defined in [4]. E.g.:the standard DNS UDP port number
   obtain IP configuration. It is 42/udp. If
   non-standard port numbers are used, these MUST assumed that the CM and MTA may be appended as shown
   below.

6.1. Telephony Service Provider's DHCP Server Address
   administered by different business entities.  The CM communicates
   with and is configured by the data access provider's DHCP servers.
   Likewise, the MTA communicates with and is configured by the
   Telephony Service Provider's (TSP) (TSP's) DHCP Server Address identifies
   the DHCP server servers.

   The PacketCable architecture requires that will be used to obtain an MTA-unique IP address
   for a given telephony service provider's network administrative
   domain.

   Sub-field 1 is the address business entity
   controlling configuration of the network's primary Telephony Service
   Provider DHCP server IP Address. Sub-field 2 CM also determines which business
   entities control the configuration of the MTA.  This is similar to
   the address example found in the PSTN system: individuals can pick their long
   distance carriers even though the ultimate control of their telephone
   remains with the
   network's secondary Telephony Service Provider DHCP server. Sub-field
   2 MAY be specified local carrier.

   Due to identify specific needs of the MTA configuration process (described in
   [7]), a redundant or backup DHCP server.

Beser              Informational  Expires May 2000                  3
        PacketCable VoIP new CableLabs Client Configuration           October 2000

   The encoding syntax (CCC) option is needed for sub-field 1
   the DHCP protocol.  Both CM and sub-field 2 is as follows:

   ---------------------------------------------------------------------
   |Sub-field | Value         | Description MTA DHCP clients will request this
   option.  When requested, both the CM and Comments               |
   =====================================================================
   |     1    |[x.y.z.y]:port | IP address of Primary TSP DHCP Server  |
   |          |               | The port number is servers will
   populate this option into DHCP responses.

   It should be noted that, although the CCC option will be initially
   deployed to support PacketCable VOIP applications, the CCC option
   will also be used only if  |
   | to support various non VOIP applications. Use of
   the CCC option does not necessarily mean that the service provider is
   a TSP.

  Beser & Duffy         Expires December 2002                       3 
   7.   CableLabs Client Configuration Option Format

   The option begins with a tag octet containing the option code (code
   TBD). A length octet follows the tag octet.  The value of the length
   octet does not include itself or the tag octet. The length octet is
   followed by "length" octets of sub-option content (total length, not
   sub-option count).  The option layout is depicted below:

      +------+--------+--------------+--------------+---+--------------+
      | Code | different than Length | Sub-option 1 | Sub-option 2 |...| Sub-option n |
      +------+--------+--------------+--------------+---+--------------+

   A sub-option begins with a tag octet containing the default port number sub-option code.
   A length octet follows the tag octet.  The value of the length octet
   does not include itself or the tag octet. The length octet is
   followed by "length" octets of sub-option information.  The sub-
   option layout is depicted below:

      +-------------------+--------+------------------------+
      | Sub-option Code   | Length | Sub-option information | is to be used.
      +-------------------+--------+------------------------+

   The sub-option codes are summarized below.

      +---------+---------+--------------------------------------------+
      |
   ---------------------------------------------------------------------  Sub-   |     2    |[x.y.z.y]:port Used by | IP address of Secondary TSP DHCP Server| Description                                |
      | option  | The port number is to be used only if         |                                            |
      |  Code   | different than the default port number         |                                            |
      +===================+============================================+
      |    1    | is to be used.  CM     |
   ---------------------------------------------------------------------

6.2. Telephony Service Provider's SNMP Entity TSP's Primary DHCP Server Address

   The Telephony Service Provider's SNMP Entity          |
      +---------+---------+--------------------------------------------+
      |    2    |  CM     | TSP's Secondary DHCP Server Address is the network
   address of the default server for a given telephony service
   provider's network administrative domain. The Telephony Service
   Provider's        |
      +---------+---------+--------------------------------------------+
      |    3    |  MTA    | TSP's SNMP Entity Address component MUST be capable of accepting
   SNMP traps. This address can be configured as either an FQDN or as an
   IPv4 address.

   The encoding of sub-field 3 is as follows:

   --------------------------------------------------------------------
   |Sub-field                  | Value
      +---------+---------+--------------------------------------------+
      | Description and Comments    4    |
   ====================================================================  MTA    |     3    |[x.y.z.y]:port TSP's Primary Domain Name Server Address   | Either the IP address or the FQDN will|
      +---------+---------+--------------------------------------------+
      |          |---------------| be configured. The port number is to    5    |  MTA    | TSP's Secondary Domain Name Server Address | FQDN:port
      +---------+---------+--------------------------------------------+
      | be used only if different than the    6    |  MTA    | TSP's Kerberos Realm Name                  |
      +---------+---------+--------------------------------------------+
      | default port number is to be used.    7    |
   --------------------------------------------------------------------

6.3. DNS system

   The Telephony Service Provider's DNS server is required to resolve a
   PacketCable device's FQDN into an IPv4 address.  MTA    | TSP's Ticket Granting Server Utilization   |
      +---------+---------+--------------------------------------------+
      |    8    |  MTA    | TSP's Provisioning Timer Value             |
      +---------+---------+--------------------------------------------+
      |    9    |         | Reserved for future CableLabs use          |
      +---------+---------+--------------------------------------------+
      |   10    |  MTA    | TSP's AS-REQ/AS-REP Backoff and Retry      |
      +---------+---------+--------------------------------------------+
      |   11    |  MTA    | TSP's AP-REQ/AP-REP Backoff and Retry      |
      +---------+---------+--------------------------------------------+
      |12 - 255 |         | Reserved for future CableLabs use          |
      +---------+---------+--------------------------------------------+

  Beser & Duffy         Expires December 2002                       4 
   8.   CableLabs Client Configuration Option: Sub-Option Definitions

   The DNS server's
   address following sections provide detailed descriptions of each sub-
   option. There are a few general formatting rules:

   - Several sub-options permit specification of a port number. When
     specified, port numbers MUST be specified encoded as 16 bit unsigned
     integers in the network byte order. If omitted, standard protocol port
     numbers, as defined in [4], are assumed.
   - FQDN's MUST be encoded per RFC 1035 section 3.1. Note that a
     terminating 0 is required.
   - IPv4 format.

   Sub-field addresses MUST be encoded as 4 binary octets in network byte-
     order.
   - All multi-octet quantities MUST be encoded per network byte-
     ordering (high-order byte first).

   8.1. TSP's DHCP Server Address Sub-Options

   The TSP DHCP Server Address sub-options identify the DHCP servers
   that will be used by an MTA to obtain IP configuration.

   Sub-option 1 is the address of the network's TSP's primary DNS server IP
   Address. Sub-field 5 DHCP server. Sub-
   option 2 is the address of the network's TSP's secondary DNS DHCP server. Sub-field 5 Both sub-
   options 1 and 2 MAY be specified to identify specify a redundant or
   backup DNS server. DHCP server port number.

   The encoding syntax for sub-field sub-options 1/2 takes on two forms depending
   on whether a port number is included or not.

   1. IPv4 address using default port. The sub-option length MUST be 4
   and sub-field 5 is the sub-option MUST include the DHCP server's IPv4 address as
   follows:

Beser              Informational  Expires May 2000                  4
        PacketCable VoIP Client Configuration           October 2000

   ---------------------------------------------------------------------
   |Sub-field | Value         | Description and Comments

        Code  Len          Address
      +-----+-----+-----+-----+-----+-----+
      |
   ===================================================================== 1/2 |  4    |[x.y.z.y]:port  | IP address of Primary TSP DNS Server  a1 |  a2 |  a3 |  a4 |
      +-----+-----+-----+-----+-----+-----+

   The default DHCP port number is to assumed.

   2. IPv4 address with a specific port. The sub-option length MUST be used only if  |
   6.  The sub-option MUST include and DHCP server's IPv4 address and
   port number as follows:

       Code   Len          Address             Port
      +-----+-----+-----+-----+-----+-----+------+-----+
      | 1/2 |  6  | different than the default port number  a1 |  a2 |  a3 |  a4 | is to be used.  p1  |
   ---------------------------------------------------------------------  p2 |
      +-----+-----+-----+-----+-----+-----+------+-----+

   8.2. TSP's SNMP Entity Address Sub-Option

  Beser & Duffy         Expires December 2002                       5    |[x.y.z.y]:port | IP 
   This option contains the address of Secondary TSP DNS Server |
   |          |               | The port number is to be used only if  |
   |          |               | different than the default TSP's network SNMP Entity.
   MTAs communicate with the SNMP entity at various stages in their
   provisioning process.  For complete details of this provisioning
   process, see [7].

   The address can be configured as either an IPv4 address with optional
   port number |
   |          |               | is to be used.                         |
   ---------------------------------------------------------------------

6.4. Procedure for adding call control server types

   A vendor may add a new sub-field by issuing or as an internet draft that
   contains FQDN with optional port number.  The encoding of
   sub-option 3 will adhere to one of 4 formats.

   1. IPv4 address using the new sub-field. default port.  The new sub-field code sub-option length MUST
   be labeled
   "TBD."  This draft will then 5.  The length octet MUST be submitted to the DHC working group,
   and, if accepted for inclusion in the DHCP specification, followed by a sub-
   option field code is assigned and single octet that
   indicates the sub-option specification will specific address type that follows.  This type octet
   MUST be published as set to 0 to indicate an RFC, which will update this RFC.

6.5 Typical us IPv4 address.  The type octet MUST be
   followed by 4 octets of PacketCable VoIP Client Configuration option

           MTA
   --------------_______                                Telephony
   VoIP         CM              CM DHCP Server          DHCP Server
   |            |                       |                       |
   (MTA boots up)                       |                       |
   |            |                       |                       |
   |            | broadcast DISCOVER (1)|                       |
   |            |---------------------->|                       |
   |            |                       |                       |
   |            | CM IP configuration + IPv4 address:

       Code   Len   Type        Address
      +-----+-----+-----+-----+-----+-----+-----+
      |  3  |  5  |  0  | TSP DHCP Serv. IP@ (2)|  a1 |  a2 |            |<----------------------|  a3 |  a4 |  PCC (3)
      +-----+-----+-----+-----+-----+-----+-----+

   2. IPv4 address using a specific port.  The sub-option length MUST be
   7. The length octet MUST be followed by a single octet that indicates
   the specific address type that follows.  This type octet MUST be set
   to 0 to indicate an IPv4 address.  The type octet MUST be followed by
   4 octets of IPv4 address.  A port number MUST follow the IPv4
   address:

       Code   Len   Type         Address            Port
      +-----+-----+-----+-----+-----+-----+-----+-----+-----+
      |  3  |  7  |
   |<===========|  0  |  a1 |  a2 |  a3 |  a4 |  p1 |  p2 | unicast DISCOVER (4)
      +-----+-----+-----+-----+-----+-----+-----+-----+-----+

   3. FQDN using the default port.  The length octet MUST be followed by
   a single octet that indicates the specific address type that follows.
   This type octet MUST be set to 1 to indicate an FQDN.  The type octet
   MUST be followed by the encoded FQDN:

       Code   Len   Type            FQDN
      +-----+-----+-----+-----+-----+   +-----+
      |
   |----------------------------------------------------------->|  3  | n+1 |  1  |  f1 |  f2 |...|  fn |                       VoIP IP configuration +
      +-----+-----+-----+-----+-----+   +-----+

   4. FQDN with specific port. The length octet MUST be followed by a
   single octet that indicates the specific address type that follows.
   This type octet MUST be set to 1 to indicate an FQDN.  The type octet
   MUST be followed by the encoded FQDN.  A port number MUST follow the
   FQDN:

  Beser & Duffy         Expires December 2002                       6 
       Code   Len   Type            FQDN               Port
      +-----+-----+-----+-----+-----+   +-----+-----+-----+
      |  3  | n+3 |  1  |  f1 |  f2 |...|  fn |  p1 |  p2 |
      +-----+-----+-----+-----+-----+   +-----+-----+-----+

   8.3. TSP's Domain Name Server Address Sub-Options

   The TSP's DNS servers resolve PacketCable Client Configuration (5) FQDN's into an IPv4
   addresses.  The MTA requires DNS capability.

   Sub-option 4 is the address of the TSP's primary DNS server. Sub-
   option 5 is the address of the TSP's secondary DNS server.  Sub-
   option 5 MAY be specified to identify a redundant or backup DHCP
   server. Both sub-options 4 and 5 MAY specify a DNS server port
   number.

   The encoding syntax for sub-options 4/5 takes on two forms depending
   on whether a port number is included or not.

   1. IPv4 address using default port. The sub-option length MUST be 4
   and the sub-option MUST include the DNS server's IPv4 address as
   follows:

        Code  Len          Address
      +-----+-----+-----+-----+-----+-----+
      | 4/5 |  4  |  a1 |  a1 |  a3 |  a4 |
      +-----+-----+-----+-----+-----+-----+

   The default DNS port number is assumed.

   2. IPv4 address using a specific port. The sub-option length MUST be
   6.  The sub-option MUST include and DNS server's IPv4 address and
   port number as follows:

       Code   Len          Address             Port
      +-----+-----+-----+-----+-----+-----+------+-----+
      | 4/5 |  6  |  a1 |  a2 |  a3 |  a4 |  p1  |
   |<-----------------------------------------------------------|  p2 |
      +-----+-----+-----+-----+-----+-----+------+-----+

   8.4. TSP's Kerberos Realm Name Sub-Option

   The PacketCable architecture requires an MTA to authenticate itself
   to the TSP's network via the Kerberos protocol.  A Kerberos Realm
   name is required at the MTA to permit a DNS lookup for the address of
   the TSP's Kerberos Key Distribution Center (KDC) entity.

   The Kerberos Realm name is an FQDN.  The sub-option is encoded as
   follows:

  Beser & Duffy         Expires December 2002                       7 
       Code   Len   Kerberos Realm Name
      +-----+-----+-----+-----+   +-----+
      |  6  |  n  |  k1 |  k2 |...|  kn |
      +-----+-----+-----+-----+   +-----+

   8.5. TSP's Ticket Granting Server Utilization Sub-Option

   This sub-option encodes a boolean value which indicates whether an
   MTA should or should not utilize a TGT (Ticket Granting Ticket) when
   obtaining a service ticket for one of the PacketCable application
   servers. The encoding is as follows:

       Code   Len   Value
      +-----+-----+-----+
      |  7  |  1  | 1/0 |
      +-----+-----+-----+

   The length MUST be 1.  The last octet contains a Boolean value which
   MUST be either 0 or 1.  A value of 1 MUST be interpreted as true.  A
   value of 0 MUST be interpreted as false.

   8.6. TSP's Provisioning Timer Sub-Option

   The provisioning timer defines the maximum time allowed for the MTA
   provisioning process to complete. If this timer expires before the
   MTA has completed the provisioning process, the MTA should reset the
   timer and re-start its provisioning process from the beginning.

   The sub-option length MUST be 1 and a value between 1 and 30
   (minutes, inclusive) MUST be used. If any other value is specified,
   the MTA MUST treat the sub-option as non-populated.

       Code   Len    Value
      +-----+-----+---------+
      |  8  |  1  |
   (Telephony registration via (1..30) |
   Telephony Service Provider SNMP Server)
      +-----+-----+---------+

   8.7. TSP's AS-REQ/AS-REP Backoff and Retry

   This sub-option configures an MTA's Kerberos AS-REQ/AS_REP timeout,
   backoff, and retry mechanism.

   The encoding of this sub-option is depicted below:

      Code Len   Nom Timeout     Max Timeout     Max Retries
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      |10 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 |

   Figure 1 Typical MTA IP Configuration via DHCP
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   The length octet of this sub-option MUST contain the value 12.

  Beser              Informational  & Duffy         Expires May 2000                  5
        PacketCable VoIP Client Configuration           October 2000 December 2002                       8 
   The PacketCable VoIP Client Configuration option length octet MUST be followed by 4 octets containing the AS-
   REQ/AS-REP nominal (initial) timeout value.  This value is used on a 32 bit
   unsigned quantity, in units of seconds, encoded per network byte
   ordering rules.

   The next 4 octets MUST contain the DHCP
   messaging AS-REQ/AS-REP maximum timeout
   value.  This value is a 32 bit unsigned quantity, in units of both CM
   seconds, encoded per network byte ordering rules.

   The final 4 octets MUST contain the AS-REQ/AS-REP maximum retry
   count.  This value is a 32 bit unsigned quantity encoded per network
   byte ordering rules.

   8.8. TSP's AP-REQ/AP-REP Backoff and VoIP device personalities. A typical MTA
   boot operation Retry

   This sub-option configures an MTA's Kerberos AP-REQ/AP_REP timeout,
   backoff, and retry mechanism.

   The encoding of this sub-option is depicted in Figure 1 and can be described as below:

   1. When MTA boots

      Code Len   Nom Timeout     Max Timeout     Max Retries
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      |11 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   The length octet of this sub-option MUST contain the CM personality sends value 12.

   The length octet MUST be followed by 4 octets containing the AP-
   REQ/AP-REP nominal (initial) timeout value.  This value is a broadcast DISCOVER
   message with proper Vendor Client Identifier Option.

   2. 32 bit
   unsigned quantity, in units of seconds, encoded per network byte
   ordering rules.

   The DHCP server gives next 4 octets MUST contain the AP-REQ/AP-REP maximum timeout
   value.  This value is a proper address from CM IP address pool,
   along with 32 bit unsigned quantity, in units of
   seconds, encoded per network byte ordering rules.

   The final 4 octets MUST contain the PacketCable VoIP AP-REQ/AP-REP maximum retry
   count.  This value is a 32 bit unsigned quantity encoded per network
   byte ordering rules.

   9.   Typical use of the CableLabs Client Configuration Option
   populated with (at least) Telephony Service Provider

   Specific usage of the CableLabs Client Configuration option is
   described in [7].

   10.  IANA Considerations

   IANA has assigned a value of TBD for the DHCP Server IP
   address(es).

   3. option code described
   in this document.

  Beser & Duffy         Expires December 2002                       9 
   11.  Legacy Use Information

   The CM passes CableLabs Client Configuration option initially used the site-
   specific option value of 177 (0xB1). The use of the PacketCable site-specific
   option is to be deprecated when IANA issues an official option
   number.

   12.  Procedure for Adding Additional Sub-options

   IANA is requested to maintain a new number space of "CableLabs
   Client Configuration (PCC)
   information to VoIP device.

   4. The VoIP device uses the information Sub-options", located in the Telephony Service
   Provider IP DHCP Server Address field and unicasts the DISCOVER
   message BOOTP-DHCP
   Parameters Registry.  The initial sub-option codes are described in
   sections of this document.

   IANA is requested to the address(es).

   5. Telephony Service Provider IP DHCP Server returns the IP
   configuration register codes for VoIP personality and PacketCable future CableLabs Client
   Configuration information.

   From this point on Sub-options with an "Expert Review" approval policy as
   described in RFC 2434 [3]. Future proposed sub-options will be
   assigned a numeric code chosen by CableLabs, which will be
   documented in the MTA uses Internet Drafts that describe the FQDN information for PacketCable
   SNMP server using Telephony Service Provider DNS servers, and
   registers for service.

7. sub-options. The
   code assignment will be reviewed by a designated expert from the
   IETF prior to publication in an RFC.

   13.  Security Considerations

   This draft relies on the DHCP protocol [5] for authentication and
   security, i.e. it does not provide either in excess of what DHCP is (or will
   be) providing.

9. It does not expose any security threats beyond what is
   currently exposed by other DHCP options.

   14.  References

   1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP
   9, RFC 2026, October September 1996.

   2. Bradner, S., "Key words for use in RFCs to Indicate Requirement
   Levels", BCP 14, RFC 2119, March 1997.

   3. Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
   Extensions", RFC-2132, March 1997.

   4. Reynolds, J., Postel, J., _ASSIGNED NUMBERS_, RFC 1340, July 1992.

   5. Droms, R., "Dynamic Host Configuration Protocol", RFC-2131, March
   1997.

   6.  CableLabs, "Radio Frequency Interface Specification", SP-RFIvX.X.
   http://www.cablemodem.com/specifications.html

   7.  PacketCable, "MTA Device Provisioning Specification", PKT-SP-
   PROV-XXX-XXXXXX.  http://www.packetcable.com/specifications.html

  Beser              Informational  & Duffy         Expires May 2000                  6
        PacketCable VoIP Client Configuration           October 2000

10. December 2002                      10 
   15.  Acknowledgments

   I

   The authors would like to extend a heartfelt thanks to all those who
   contributed to the development of the PacketCable Provisioning
   specification. Particular thanks are given
   specifications:

   Sumanth Channabasappa (Alopa Networks); Angela Lyda, Rick Morris
   (Arris Morris,
   Rodney Osborne Arris Interactive); Steven Bellovin and Chris Melle
   (AT&T); Jiri Matousek (Bay
   Networks); Eugene Nechamkin Broadcom); John Berg, Maria Stachelek, Matt
   Osman (CableLabs); Klaus Hermanns, Azita Kia, Michael Thomas, Rich Woundy Paul
   Duffy (Cisco); Deepak Patil (Com21); Jeff Ollis, Rick Vetter, Sasha
   Medvinsky, Raj Deshpande (Motorola); Vetter
   (General Instrument/Motorola); Roger Loots Loots, David Walters (Lucent);
   Burcak Beser (Pacific Broadband); Peter Bates (Telcordia); Patrick
   Meehan (Tellabs); Satish Kumar, Itay Sherman, Roy Spitzer (Telogy),
   (Telogy/TI), Aviv Goren (Terayon); and Prithivraj Narayanan
   (Wipro). Last but not least special thanks to Steve Gonczi (Network
   Engines) for suggestions.

11. (Wipro); and
   Rich Woundy (AT&T Broadband).

   16.  Author's Addresses

   Burcak Beser
   Pacific Broadband Communications
   3103
   Juniper Networks
   1194 North First Street,
   San Jose, Matilda Avenue
   Sunnyvale, CA, 95134
   Phone: (408) 468 6265 94089
   Email: burcak@juniper.net

   Paul Duffy
   Cisco Systems
   300 Apollo Drive
   Chelmsford, MA, 01824
   Email: Burcak@pbc.com paduffy@cisco.com

   17.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

  Beser              Informational  & Duffy         Expires May 2000                  7 December 2002                      11 
   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

  Beser & Duffy         Expires December 2002                      12