draft-ietf-dhc-packetcable-01.txt   draft-ietf-dhc-packetcable-02.txt 
DHC Working Group B. Beser Internet Engineering Task Force B. Beser
Internet Draft Pacific Broadband Communications INTERNET DRAFT Juniper Networks
Document: draft-ietf-dhc-packetcable-01.txt October 2000 DHC Working Group P. Duffy (ed.)
Category: Informational Document: draft-ietf-dhc-packetcable-02.txt Cisco Systems
June 2002
DHCP Option for PacketCable VoIP Client Configuration DHCP Option for CableLabs Client Configuration
Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts.
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts Internet-Drafts are draft documents valid for a maximum of six
as reference material or to cite them other than as "work in months and may be updated, replaced, or obsoleted by other documents
progress." 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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
1. Abstract 2. Abstract
The Voice over IP work carried over in the PacketCable project This document defines a DHCP option that will be used to configure
conducted by CableLabs. The configuration of the PacketCable Voice various devices deployed within CableLabs architectures.
over IP client is achieved using DHCP messaging. Specifically, the document describes DHCP option content that will be
used to configure one class of CableLabs client device: a PacketCable
Media Terminal Adapter (MTA). It is expected that the option content
defined within this document will be extended as future CableLabs
client devices are developed.
This document contains the definition of the PacketCable VoIP Client 3. Table of Contents
configuration option.
2. Conventions used in this document 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 CableLabs Client 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", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC-2119 [2]. this document are to be interpreted as described in RFC-2119 [2].
3. DHCP Terminology 5. Terminology
o "DHCP client" Definitions of terms used throughout this document:
A DHCP client or "client" is an Internet host using DHCP to obtain * "Telephony Service Provider" or "TSP"
configuration parameters such as a network address.
o "DHCP server" The business entity from which a subscriber receives telephony
service.
Beser Informational Expiration May 2000 1 See RFC2131[5] for additional DHCP terminology.
PacketCable VoIP Client Configuration October 2000
A DHCP server of "server"is an Internet host that returns 6. Introduction
configuration parameters to DHCP clients.
o "binding" Cable Television Laboratories, Inc. (CableLabs) is a non-profit
research and 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.
A binding is a collection of configuration parameters, including at The PacketCable project is aimed at architecting, qualifying, and
least an IP address, associated with or "bound to" a DHCP client. supporting Internet-based multimedia services over cable-based packet
Bindings are managed by DHCP servers. networks. These new multimedia services will include telephony and
videoconferencing, delivered using the basic Internet Protocol (IP)
technology that is used to send data via the Internet.
4. Introduction Beser & Duffy Expires December 2002 2
PacketCable 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 Media Terminal Adapter (MTA). The CM
converts the cable RF signals to/from various IP voice protocols,
while the MTA converts the VoIP protocols into analog telephony
compatible with a common telephone.
PacketCable is a project conducted by Cable Television Laboratories, The CM and MTA may be packaged together or separately. If packaged
Inc. (CableLabs) and its member companies aimed at identifying, together, the unit is referred to as an Embedded-MTA (EMTA - depicted
qualifying, and supporting Internet-based voice and video products in Figure 1). If packaged separately, the MTA is referred to as a
over cable systems. These products will represent new classes of Standalone MTA (SMTA).
services utilizing cable-based packet communication networks. New
service classes include telephone calls and videoconferencing over
cable networks and the Internet. The services would be delivered
using the basic Internet Protocol (IP) technology that is used to
send data via the Internet.
The PacketCable embedded-MTA (MTA) is a single physical device with |----------------------------------------------|
dual personality: a Cable Modem (CM) and a VoIP device. Both of | |
these devices are administered by different entities. Both of the | |-----------| |-------------| |
personalities have different IP addresses and different IP | | | | | |
configurations. Telephony | | Media | internal | Cable | | RF Link
---------_|---| Terminal |===========| Modem |----|-------
Link | | Adapter | connection| | |
| |-----------| |-------------| |
| |
|----------------------------------------------|
PacketCable project produced specifications of VoIP elements, which Figure 1. PacketCable 1.0 Embedded-MTA
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 CM and MTA are distinct IP devices: each has its own MAC address
and IP configuration. The CM and MTA utilize the DHCP protocol to
obtain IP configuration. It is assumed that the CM and MTA may be
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's) DHCP servers.
The code for this option is TBD. The PacketCable architecture requires that the business entity
controlling configuration of the CM also determines which business
entities control the configuration of the MTA. This is similar to
the example found in the PSTN system: individuals can pick their long
distance carriers even though the ultimate control of their telephone
remains with the local carrier.
The PacketCable VoIP Client Configuration option is used by the Due to specific needs of the MTA configuration process (described in
PacketCable VoIP clients to identify a list of valid PacketCable [7]), a new CableLabs Client Configuration (CCC) option is needed for
specific network servers. the DHCP protocol. Both CM and MTA DHCP clients will request this
option. When requested, both the CM and TSP DHCP servers will
populate this option into DHCP responses.
The option sub-fields contain information regarding these servers. 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 to support various non VOIP applications. Use of
the CCC option does not necessarily mean that the service provider is
a TSP.
The option is included in DHCP OFFER-s, and is laid out as depicted Beser & Duffy Expires December 2002 3
below: 7. CableLabs Client Configuration Option Format
------------------------------------------------------------- The option begins with a tag octet containing the option code (code
| TBD | Length | Subfield 1 | Subfield 2 | ... | Subfield n | 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:
Each sub-field is in the form of: +------+--------+--------------+--------------+---+--------------+
| Code | Length | Sub-option 1 | Sub-option 2 |...| Sub-option n |
+------+--------+--------------+--------------+---+--------------+
Beser Informational Expires May 2000 2 A sub-option begins with a tag octet containing the sub-option code.
PacketCable VoIP Client Configuration October 2000 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-field Number | Length | Subfield information | | Sub-option Code | Length | Sub-option information |
--------------------------------------------------- +-------------------+--------+------------------------+
Each sub-field of the PacketCable VoIP Client Configuration The sub-option codes are summarized below.
identifies 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 | | Sub- | Used by | Description |
==================================================================== | option | | |
| TBD | 1 | Telephony Service Provider Primary DHCP | | Code | | |
| | | Server Address | +===================+============================================+
| |----------------------------------------------------------- | 1 | CM | TSP's Primary DHCP Server Address |
| | 2 | Telephony Service Provider Secondary DHCP | +---------+---------+--------------------------------------------+
| | | Server Address | | 2 | CM | TSP's Secondary DHCP Server Address |
| |----------------------------------------------------------- +---------+---------+--------------------------------------------+
| | 3 | Telephony Service Provider SNMP Server Address| | 3 | MTA | TSP's SNMP Entity Address |
| |----------------------------------------------------------- +---------+---------+--------------------------------------------+
| | 4 | Telephony Service Provider Network Primary | | 4 | MTA | TSP's Primary Domain Name Server Address |
| | | Domain Name Server Address | +---------+---------+--------------------------------------------+
| |----------------------------------------------------------- | 5 | MTA | TSP's Secondary Domain Name Server Address |
| | 5 | Telephony Service Provider Network Secondary | +---------+---------+--------------------------------------------+
| | | Domain Name Server Address | | 6 | MTA | TSP's Kerberos Realm Name |
-------------------------------------------------------------------- +---------+---------+--------------------------------------------+
| 7 | 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 |
+---------+---------+--------------------------------------------+
6. PacketCable VoIP Client option Sub-field Definitions Beser & Duffy Expires December 2002 4
8. CableLabs Client Configuration Option: Sub-Option Definitions
The following parts provide detailed descriptions of each sub-field The following sections provide detailed descriptions of each sub-
of DHCP PacketCable VoIP Client option. Note that UDP port numbers option. There are a few general formatting rules:
are normally standard values as defined in [4]. The port numbers
MAY be omitted, if the standard protocol ports are to be used as
defined in [4]. E.g.:the standard DNS UDP port number is 42/udp. If
non-standard port numbers are used, these MUST be appended as shown
below.
6.1. Telephony Service Provider's DHCP Server Address - Several sub-options permit specification of a port number. When
specified, port numbers MUST be encoded as 16 bit unsigned
integers in 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 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).
The Telephony Service Provider's (TSP) DHCP Server Address identifies 8.1. TSP's DHCP Server Address Sub-Options
the DHCP server 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 of the network's primary Telephony Service The TSP DHCP Server Address sub-options identify the DHCP servers
Provider DHCP server IP Address. Sub-field 2 is the address of the that will be used by an MTA to obtain IP configuration.
network's secondary Telephony Service Provider DHCP server. Sub-field
2 MAY be specified to identify a redundant or backup DHCP server.
Beser Informational Expires May 2000 3 Sub-option 1 is the address of the TSP's primary DHCP server. Sub-
PacketCable VoIP Client Configuration October 2000 option 2 is the address of the TSP's secondary DHCP server. Both sub-
options 1 and 2 MAY specify a DHCP server port number.
The encoding syntax for sub-field 1 and sub-field 2 is as follows: The encoding syntax for 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
|Sub-field | Value | Description and Comments | and the sub-option MUST include the DHCP server's IPv4 address as
===================================================================== follows:
| 1 |[x.y.z.y]:port | IP address of Primary TSP DHCP Server |
| | | The port number is to be used only if |
| | | different than the default port number |
| | | is to be used. |
---------------------------------------------------------------------
| 2 |[x.y.z.y]:port | IP address of Secondary TSP DHCP Server|
| | | The port number is to be used only if |
| | | different than the default port number |
| | | is to be used. |
---------------------------------------------------------------------
6.2. Telephony Service Provider's SNMP Entity Address Code Len Address
+-----+-----+-----+-----+-----+-----+
| 1/2 | 4 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+
The Telephony Service Provider's SNMP Entity Address is the network The default DHCP port number is assumed.
address of the default server for a given telephony service
provider's network administrative domain. The Telephony Service
Provider'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: 2. IPv4 address with a specific port. The sub-option length MUST be
6. The sub-option MUST include and DHCP server's IPv4 address and
port number as follows:
-------------------------------------------------------------------- Code Len Address Port
|Sub-field | Value | Description and Comments | +-----+-----+-----+-----+-----+-----+------+-----+
==================================================================== | 1/2 | 6 | a1 | a2 | a3 | a4 | p1 | p2 |
| 3 |[x.y.z.y]:port | Either the IP address or the FQDN will| +-----+-----+-----+-----+-----+-----+------+-----+
| |---------------| be configured. The port number is to |
| | FQDN:port | be used only if different than the |
| | | default port number is to be used. |
--------------------------------------------------------------------
6.3. DNS system 8.2. TSP's SNMP Entity Address Sub-Option
The Telephony Service Provider's DNS server is required to resolve a Beser & Duffy Expires December 2002 5
PacketCable device's FQDN into an IPv4 address. The DNS server's This option contains the address of the TSP's network SNMP Entity.
address MUST be specified in the IPv4 format. MTAs communicate with the SNMP entity at various stages in their
provisioning process. For complete details of this provisioning
process, see [7].
Sub-field 4 is the address of the network's primary DNS server IP The address can be configured as either an IPv4 address with optional
Address. Sub-field 5 is the address of the network's secondary DNS port number or as an FQDN with optional port number. The encoding of
server. Sub-field 5 MAY be specified to identify a redundant or sub-option 3 will adhere to one of 4 formats.
backup DNS server.
The encoding syntax for sub-field 4 and sub-field 5 is as follows: 1. IPv4 address using the default port. The sub-option length MUST
be 5. 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:
Beser Informational Expires May 2000 4 Code Len Type Address
PacketCable VoIP Client Configuration October 2000 +-----+-----+-----+-----+-----+-----+-----+
| 3 | 5 | 0 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+-----+
--------------------------------------------------------------------- 2. IPv4 address using a specific port. The sub-option length MUST be
|Sub-field | Value | Description and Comments | 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
| 4 |[x.y.z.y]:port | IP address of Primary TSP DNS Server | to 0 to indicate an IPv4 address. The type octet MUST be followed by
| | | The port number is to be used only if | 4 octets of IPv4 address. A port number MUST follow the IPv4
| | | different than the default port number | address:
| | | is to be used. |
---------------------------------------------------------------------
| 5 |[x.y.z.y]:port | IP address of Secondary TSP DNS Server |
| | | The port number is to be used only if |
| | | different than the default port number |
| | | is to be used. |
---------------------------------------------------------------------
6.4. Procedure for adding call control server types Code Len Type Address Port
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 3 | 7 | 0 | a1 | a2 | a3 | a4 | p1 | p2 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
A vendor may add a new sub-field by issuing an internet draft that 3. FQDN using the default port. The length octet MUST be followed by
contains the new sub-field. The new sub-field code MUST be labeled a single octet that indicates the specific address type that follows.
"TBD." This draft will then be submitted to the DHC working group, This type octet MUST be set to 1 to indicate an FQDN. The type octet
and, if accepted for inclusion in the DHCP specification, a sub- MUST be followed by the encoded FQDN:
option field code is assigned and the sub-option specification will
be published as an RFC, which will update this RFC.
6.5 Typical us of PacketCable VoIP Client Configuration option Code Len Type FQDN
+-----+-----+-----+-----+-----+ +-----+
| 3 | n+1 | 1 | f1 | f2 |...| fn |
+-----+-----+-----+-----+-----+ +-----+
MTA 4. FQDN with specific port. The length octet MUST be followed by a
--------------_______ Telephony single octet that indicates the specific address type that follows.
VoIP CM CM DHCP Server DHCP Server 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
(MTA boots up) | | FQDN:
| | | |
| | broadcast DISCOVER (1)| |
| |---------------------->| |
| | | |
| | CM IP configuration + | |
| | TSP DHCP Serv. IP@ (2)| |
| |<----------------------| |
| PCC (3) | | |
|<===========| | |
| | | |
| unicast DISCOVER (4) |
|----------------------------------------------------------->|
| | |
| | VoIP IP configuration + |
| | PacketCable Client Configuration (5) |
|<-----------------------------------------------------------|
| | |
(Telephony registration via |
Telephony Service Provider SNMP Server) |
Figure 1 Typical MTA IP Configuration via DHCP Beser & Duffy Expires December 2002 6
Code Len Type FQDN Port
+-----+-----+-----+-----+-----+ +-----+-----+-----+
| 3 | n+3 | 1 | f1 | f2 |...| fn | p1 | p2 |
+-----+-----+-----+-----+-----+ +-----+-----+-----+
Beser Informational Expires May 2000 5 8.3. TSP's Domain Name Server Address Sub-Options
PacketCable VoIP Client Configuration October 2000
The PacketCable VoIP Client Configuration option is used on the DHCP The TSP's DNS servers resolve PacketCable FQDN's into an IPv4
messaging of both CM and VoIP device personalities. A typical MTA addresses. The MTA requires DNS capability.
boot operation is depicted in Figure 1 and can be described as
below:
1. When MTA boots the CM personality sends a broadcast DISCOVER Sub-option 4 is the address of the TSP's primary DNS server. Sub-
message with proper Vendor Client Identifier Option. 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.
2. The DHCP server gives a proper address from CM IP address pool, The encoding syntax for sub-options 4/5 takes on two forms depending
along with the PacketCable VoIP Client Configuration Option on whether a port number is included or not.
populated with (at least) Telephony Service Provider DHCP Server IP
address(es).
3. The CM passes the PacketCable Client Configuration (PCC) 1. IPv4 address using default port. The sub-option length MUST be 4
information to VoIP device. and the sub-option MUST include the DNS server's IPv4 address as
follows:
4. The VoIP device uses the information in the Telephony Service Code Len Address
Provider IP DHCP Server Address field and unicasts the DISCOVER +-----+-----+-----+-----+-----+-----+
message to the address(es). | 4/5 | 4 | a1 | a1 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+
5. Telephony Service Provider IP DHCP Server returns the IP The default DNS port number is assumed.
configuration for VoIP personality and PacketCable Client
Configuration information.
From this point on the MTA uses the FQDN information for PacketCable 2. IPv4 address using a specific port. The sub-option length MUST be
SNMP server using Telephony Service Provider DNS servers, and 6. The sub-option MUST include and DNS server's IPv4 address and
registers for service. port number as follows:
7. Security Considerations Code Len Address Port
+-----+-----+-----+-----+-----+-----+------+-----+
| 4/5 | 6 | a1 | a2 | a3 | a4 | p1 | p2 |
+-----+-----+-----+-----+-----+-----+------+-----+
This draft relies on DHCP protocol [5] for authentication and 8.4. TSP's Kerberos Realm Name Sub-Option
security, i.e. it does not provide either in excess of what DHCP is
(or will be) providing.
9. References 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 | (1..30) |
+-----+-----+---------+
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 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
The length octet of this sub-option MUST contain the value 12.
Beser & Duffy Expires December 2002 8
The length octet MUST be followed by 4 octets containing the AS-
REQ/AS-REP nominal (initial) timeout value. This value is a 32 bit
unsigned quantity, in units of seconds, encoded per network byte
ordering rules.
The next 4 octets MUST contain the AS-REQ/AS-REP maximum timeout
value. This value is a 32 bit unsigned quantity, in units of
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 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 below:
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 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 32 bit
unsigned quantity, in units of seconds, encoded per network byte
ordering rules.
The next 4 octets MUST contain the AP-REQ/AP-REP maximum timeout
value. This value is a 32 bit unsigned quantity, in units of
seconds, encoded per network byte ordering rules.
The final 4 octets MUST contain the 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
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 option code described
in this document.
Beser & Duffy Expires December 2002 9
11. Legacy Use Information
The CableLabs Client Configuration option initially used the site-
specific option value of 177 (0xB1). The use of the 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 Sub-options", located in the BOOTP-DHCP
Parameters Registry. The initial sub-option codes are described in
sections of this document.
IANA is requested to register codes for future CableLabs Client
Configuration 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 Internet Drafts that describe the 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 in excess of what DHCP is (or will
be) providing. 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 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, September 1996.
2. Bradner, S., "Key words for use in RFCs to Indicate Requirement 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
3. Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 3. Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC-2132, March 1997. Extensions", RFC-2132, March 1997.
4. Reynolds, J., Postel, J., _ASSIGNED NUMBERS_, RFC 1340, July 1992. 4. Reynolds, J., Postel, J., _ASSIGNED NUMBERS_, RFC 1340, July 1992.
5. Droms, R., "Dynamic Host Configuration Protocol", RFC-2131, March 5. Droms, R., "Dynamic Host Configuration Protocol", RFC-2131, March
1997. 1997.
Beser Informational Expires May 2000 6 6. CableLabs, "Radio Frequency Interface Specification", SP-RFIvX.X.
PacketCable VoIP Client Configuration October 2000 http://www.cablemodem.com/specifications.html
10. Acknowledgments 7. PacketCable, "MTA Device Provisioning Specification", PKT-SP-
PROV-XXX-XXXXXX. http://www.packetcable.com/specifications.html
I would like to extend a heartfelt thanks to all those who Beser & Duffy Expires December 2002 10
contributed to the development of PacketCable Provisioning 15. Acknowledgments
specification. Particular thanks are given Angela Lyda, Rick Morris
(Arris Interactive); Steven Bellovin (AT&T); Jiri Matousek (Bay
Networks); Klaus Hermanns, Azita Kia, Michael Thomas, Rich Woundy
(Cisco); Deepak Patil (Com21); Jeff Ollis, Rick Vetter, Sasha
Medvinsky, Raj Deshpande (Motorola); Roger Loots (Lucent); Roy
Spitzer (Telogy), Aviv Goren (Terayon); and Prithivraj Narayanan
(Wipro). Last but not least special thanks to Steve Gonczi (Network
Engines) for suggestions.
11. Author's Addresses The authors would like to extend a heartfelt thanks to all those who
contributed to the development of the PacketCable Provisioning
specifications:
Sumanth Channabasappa (Alopa Networks); Angela Lyda, Rick Morris,
Rodney Osborne Arris Interactive); Steven Bellovin and Chris Melle
(AT&T); Eugene Nechamkin Broadcom); John Berg, Maria Stachelek, Matt
Osman (CableLabs); Klaus Hermanns, Azita Kia, Michael Thomas, Paul
Duffy (Cisco); Deepak Patil (Com21); Jeff Ollis, Rick Vetter
(General Instrument/Motorola); Roger Loots, David Walters (Lucent);
Burcak Beser (Pacific Broadband); Peter Bates (Telcordia); Patrick
Meehan (Tellabs); Satish Kumar, Itay Sherman, Roy Spitzer
(Telogy/TI), Aviv Goren (Terayon); Prithivraj Narayanan (Wipro); and
Rich Woundy (AT&T Broadband).
16. Author's Addresses
Burcak Beser Burcak Beser
Pacific Broadband Communications Juniper Networks
3103 North First Street, 1194 North Matilda Avenue
San Jose, CA, 95134 Sunnyvale, CA, 94089
Phone: (408) 468 6265 Email: burcak@juniper.net
Email: Burcak@pbc.com
Beser Informational Expires May 2000 7 Paul Duffy
Cisco Systems
300 Apollo Drive
Chelmsford, MA, 01824
Email: 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 & Duffy Expires 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
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/