Network Working Group Anthony McAuley
INTERNET-DRAFT Subir Das
Internet Engineering Task Force Sunil Madhani
draft-itsumo-drcp-01.txt Telcordia Technologies
Date: July 14, 2000 Shinichi Baba
Expires: January 14, 2001 Yasuro Shobatake
Toshiba America Research Inc.
Dynamic Registration and Configuration Protocol (DRCP)
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of sections 10 of RFC 2026.
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
The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts [DHC]. DHCP was,
however, designed for hosts on a fixed LAN, not for nodes roaming
among commercial wireless networks. A Mobile IP [MIP] Foreign Agent
gives some powerful plug and play capability for roaming hosts,
especially when combined with some recent proposals [e.g., MIPA,
MIPC, MIPD, MIPN, HAW, CEL, TIA]. Mobile IP functionality, however
is not always needed and for some dynamic networks it may be
undesirable to use Foreign Agents. This draft proposes a lightweight
dynamic configuration protocol, called the Dynamic Registration and
Configuration Protocol (DRCP). DRCP borrows heavily from DHCP and
can switch to using DHCP protocol if only DHCP servers are present in
the network; but adds features critical to roaming users. Most
importantly, DRCP allows rapid configuration by moving address
consistency checking from the critical path. Other new features
allow: a) clients to know when to get a new address independent of
the layer-2 access technology, b) efficient use of scarce wireless
bandwidth, c) clients to be routers, d) dynamic addition or deletion
of address pools to any DRCP node, and e) message exchange without
broadcast.
ITSUMO Group Expires January 2001 [Page 1]
Internet Draft DRCP July 2000
1. Introduction
Most future networks will use IP technology. To provide
heterogeneity and flexibility, devices will likely access this
IP-based network by directly sending IP packets. In such an
environment it is natural to consider using IP-based protocols for
user-network signaling, since it can be used across any wired or
wireless access network.
The functions needed to support users' roaming among IP-based
networks vary, depending on network, movement, and application
characteristics. Three common functions are Registration,
Configuration and Dynamic Address Binding. Registration allows
roaming users to rapidly and automatically register their presence
and their requirements with networks. Configuration allows networks
to automatically configure roaming users to the particular network
characteristics. Dynamic Binding allows corresponding nodes to
locate roaming users and to allow continuous communication as the
user moves among networks. This draft is concerned with the first
two functions; it has nothing to say about dynamic binding, except
that it should be a feature independent of the registration and
configuration protocol. However, Dynamic Registration and
Configuration Protocol does not mandate compulsory registration to
the MN but it provides registration parameters to roaming users (such
as local AAA server's address).
Alhough DRCP adds some new configuration capability, it has no other
functions. DRCP may provide information about the location of a
network registration, service negotiation, or mobility agent; but it
must be combined with other protocols to perform these functions
(e.g., use of Mobile IP protocol in co-located mode to register with
a Home Agents). Furthermore, there are interesting possible
application of DRCP, beyond the realm of configuring nodes roaming
among a fixed infrastructure. An example of this is to combine DRCP
with an address distribution protocol, such as DAAP [DAAP], to allow
complete network autoconfiguration.
1.1 Architecture
Figure 1 shows an example of a high level functional architecture of
a future IP-based network, with a roaming node attaching to various
wired or wireless access networks. The access network may contain
multiple hubs or base stations with at least one Edge Router and
Controller (ERC) with connections to the rest of the network. We
assume the mobile node keeps the same IP address anywhere within an
access network, since micro mobility (e.g., among base stations) is
handled at layer 2. The mobile node may need, however, to get a new
IP address when it moves to a new subnet (protocols such as HAWAII
[HAW] or Cellular IP can be used [CEL] to allow node to keep their IP
address within a single domain ). The Regional Backbone connects all
the edge router and controller in a single administrative domain and
the global Internet interconnects all the regional networks.
ITSUMO Group Expires January 2001 [Page 2]
Internet Draft DRCP July 2000
. <---- DOMAIN 1 ----> . . <---- DOMAIN 2 ----> .
. . +-------------+ . .
. +---------------+ . | Inter Domain| . +---------------+ .
. | Domain Agent | . | Agent | . | Domain Agent | .
. | | . | | . | | .
. +---------------+ . +-------------+ . +---------------+ .
. | . | . | .
. __|__ . __|__ . __|__ .
. / \ . / \ . / \ .
. / \ . / \ . / \ .
. / Regional\_________/ Global \_________/ Regional\ .
. \ Backbone/ . \ Internet/ . \ Backbone/ .
. ---\ /--- . \ / . ---\ /--- .
. | \_____/ | . \_____/ . | \_____/ | .
. | | . . | | .
. +---------+ +---------+ . . +---------+ +---------+ .
. | Edge | | Edge | . . | Edge | | Edge | .
. |Router & |...|Router & | . . |Router & |...|Router & | .
. |Controller |Controller . . |Controller |Controller .
. +---------+ +---------+ . . +---------+ +---------+ .
. | | . . | | .
. __|__ __|__ . . __|__ __|__ .
. / \ / \ . . / \ / \ .
. / \ / \ . . / \ / \ .
. / Access \.../ Access \ . . / Access \.../ Access \ .
. \ Network / \ Network / . . \ Network / \ Network / .
. \ / \ / . . \ / \ / .
. \_____/ \_____/ . . \_____/ \_____/ .
. | | . . | | .
v v v v
+---------+ global macro
| Mobile | *******************> ************>
| Node | mobility mobility
+---------+
Figure 1: Example Functional Network Architecture for Supporting
Universal Mobile Operation
1.2 DHCP Extensions
As discussed in the draft "Requirements for Extending DHCP into New
Environments," [DHCR] the Dynamic Host Configuration Protocol (DHCP)
represents the best and most flexible protocol for configuring nodes
[DHC]. Recent proposals provide some enhancements to DHCP for
roaming users. For example there are proposals to adding
authentication [DHCA], LDAP database management [DHCL], and dynamic
updating of DNS [DHCD]. Unfortunately, these additions not only add
to its complexity, they also leave some key configuration problems
including:
o R1 Rapid client configuration (milliseconds rather than seconds).
o R2 Rapid client reconfiguration (independent of lease time or
layer-2 access technology).
o R3 Efficient use of scarce wireless bandwidth.
ITSUMO Group Expires January 2001 [Page 3]
Internet Draft DRCP July 2000
o R4 Allowing clients to be routers.
o R5 Dynamic addition or deletion of address pools on any node.
o R6 Message exchange without broadcast.
These six requirements are discussed in detail in [DHCR].
1.3 Requirements 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 [REQ].
1.4 Overview
This draft proposes a light weight version of DHCP for roaming users,
called the Dynamic Registration and Configuration Protocol (DRCP).
DRCP adds many new features including rapid client configuration and
efficient use of wireless bandwidth. Section 2 describes DRCP
operations with client-server model while Section 3 presents the DRCP
format.
1.5 Terminology
This document uses the following terms:
o "DHCP"
The Dynamic Host Configuration Protocol (DHCP) used to configure
Internet hosts.
o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain
configuration parameters such as a network address.
o "DHCP relay agent"
A relay agent is an Internet host that passes DHCP messages
between DHCP clients and DHCP servers.
o "DHCP server"
A DHCP server is an Internet node that returns configuration
parameters to DHCP clients.
o "DRCP"
The Dynamic Registration and Configuration Protocol (DRCP) used to
configure nodes.
o "DRCP client"
A DRCP client is an Internet node (host or router) using DRCP to
register with the network and obtain configuration parameters such
as a network address.
o "DRCP server"
A DRCP server is an Internet node that owns a pool of IP
addresses. The server can lease addresses from this pool to other
DRCP nodes in its domain. Each domain running DRCP must have at
ITSUMO Group Expires January 2001 [Page 4]
Internet Draft DRCP July 2000
least one server, though there could be more in larger domains.
o "Edge Router and Controller"
An Edge Router and Controller (ERC) is an Internet node with a
DRCP server that provides a centralized service to DRCP clients
along with routing and other controlling functionalities.
o TBD = To Be Determined
2. Protocol Summary
The Dynamic Registration and Configuration Protocol (DRCP) uses many
of the features found in DHCP. We require a new protocol, however,
because DRCP's extended goals requires major enhancements to DHCP
[DHCR].
2.1 DRCP Overview - Components
The Dynamic Registration and Configuration Protocol (DRCP) is based
on a client-server model. Figure 2 shows how the client and server
could map onto the network architecture shown in Figure 1. In
general, however, the DRCP-server could be on any node in the subnet,
not necessarily a router.
DRCP-Clients DRCP-server
+-------------+ +------------------------+
| Mobile Node |<----->|Edge Router & Controller|
+-------------+ +------------------------+
.
.
+-------------+ +------------------------+
| Mobile Node |<----->|Edge Router & Controller|
+-------------+ | +------------------------+
: |
: |
+-------------+ |
| Mobile Node |<---
+-------------+
Figure 2 DRCP Client-Server model
The DRCP client-server model is similar to the client-server model of
DHCP. There is, however, two subtle distinctions. First, any DRCP
node (including client) can be on a router or host. The second
distinction is that all DRCP nodes run the same program. The only
thing that makes a DRCP node a server is that it has configuration
information, including an address pool and other configuration
parameters to be used on an interface. A DRCP server must configure
its own interface using the configuration information for that
subnet. As we will show this allows for more flexible and robust
operation.
2.2 DRCP Messages
ITSUMO Group Expires January 2001 [Page 5]
Internet Draft DRCP July 2000
DRCP messages have the same basic semantics as those used in DHCP.
For example, the DHCPOFFER [DHC] has the same basic functions (and
name) as DRCP_OFFER. New messages are needed in order to minimize
message size (see Section 3). Like DHCP, DRCP uses UDP as its
transport protocol. There are two types of DRCP signaling messages
running on three different UDP ports:
a) All messages from a client are sent to the `DRCP_SERVER_PORT' port
(number TBD).
b) All messages from a server are sent to the `DRCP_CLIENT_PORT' port
(number TBD), except the DRCP_ADVERTISMENT.
c) DRCP_ADVERTISMENT messages from a server are sent to the
`DRCP_ADVERTISEMENT_PORT' port (number TBD) on the client.
Figure 3 shows a general architecture for DRCP operation on a local
subnet. In general a subnet requires only one server (as shown in
Figure 2); however, we show the more general with redundant servers.
+--------------+ +--------------+ +--------------+
| DRCP Server | | DRCP Server | ... | DRCP Server |
| | | | | |
+--------------+ +--------------+ +--------------+
| | |
____|__________________|______________________|____
/ \
/ \
/ Local \
\ Subnet /
\ /
\___________________________________________________/
| | |
| | |
+---------+ +---------+ +---------+
| DRCP | | DRCP | ... | DRCP |
| Client | | Client | | Client |
+---------+ +---------+ +---------+
Figure 3 DRCP Node configuration on a Local Subnet
2.2.1 Messages from DRCP client
o DRCP_DISCOVER:
Registration message sent by a DRCP-client on its local subnet to
request a new address and other configuration parameters. While a
DHCPDISCOVER message must be broadcast [DHC], a DRCP_DISCOVER
message may be broadcast or unicast depending whether the client
knows the address of a DRCP Server (e.g., from a
DRCP_ADVERTISEMENT].
o DRCP_REQUEST:
Registration message sent by a DRCP-client on its local subnet to
request extending the lease on an address.
o DRCP_INFORM:
Registration message sent by a DRCP-client on its local subnet to
request new configuration parameters. This could be used, for
example, if the client already has an externally configured network
ITSUMO Group Expires January 2001 [Page 6]
Internet Draft DRCP July 2000
address.
o DRCP_DECLINE:
Registration message sent by a DRCP-client on its local subnet to
request a different address, either because the one assigned is not
acceptable (e.g., it is already in use by another client) or
because the client has moved to a new subnet.
o DRCP_RELEASE:
De-registration message sent by a DRCP-client on its local subnet
to relinquish a network address and cancel remaining lease.
o DRCP_ACCEPT
Registration message sent by a DRCP-client on its local subnet in
response to an OFFER from servers. The client accepts offered
parameters from one server and implicitly declining offers from all
others.
2.2.2 Messages from a DRCP server
o DRCP_OFFER:
Configuration message sent back to client on the same subnet where
the DRCP server node received a DRCP_DISCOVER message.
o DRCP_ACK:
Configuration message broadcast by a Server on its local subnet in
response to a DRCP_ACCEPT.
o DRCP_NAK
Message sent to a client or clients (may be broadcast) to tell them
not to use an address or other service they requested. (e.g., when
a client is using a wrong address).
o DRCP_ADVERTISEMENT:
Server periodically broadcasts (or unicast in response to a client
using an incorrect address) the network information (such as Server
IP address or Network address). Listening to this, client can
understand the subnet change.
2.3 Basic Operation
A DRCP node is initially assumed only to know which of its interfaces
is configuring using DRCP. If there are multiple interfaces, each
interface may be configured in a different way. One interface may be
configured by DRCP, another using a locally stored address, and a
third as a DHCP-client. After boot-up, however, any interface
configured as a DRCP interface listens to messages on
DRCP_ADVERTISMENT_PORT. During any message exchange a transaction id
is used between the client and server and they must match for a given
exchange.
2.3.1 Basic DRCP Client Operation
If a DRCP interface does not have a local address pool it becomes a
ITSUMO Group Expires January 2001 [Page 7]
Internet Draft DRCP July 2000
DRCP client. The client first broadcasts a DRCP_DISCOVER message
(similar to a DHCPDISCOVER message) to the DRCP_SERVER_PORT. If it
gets no response after DRCP_RETX_TIMEOUT, then it resends the
DRCP_DISCOVER message. This process repeats for up to DRCP_RETX_MAX
retransmissions.
If an unconfigured DRCP client receives a DRCP_ADVERTISEMENT message
(on the DRCP_ADVERTISEMENT_PORT), then it will change to a unicast
state, so the next DRCP_DISCOVER message will be unicast to the
source address of the DRCP_ADVERTISEMENT.
If the client receives a DRCP_OFFER message, then it can immediately
configure its interface with that address. There is no requirement
to do check (e.g., using ARP) for others using the same address (as
there is in DHCP).
After getting an address the client may periodically send out
DRCP_REQUEST messages to renew the lease. These message are
retransmitted until acknowledged by a DHCP_ACK message.
If a configured DRCP client receives a DRCP_ADVERTISEMENT message (on
the DRCP_ADVERTISEMENT_PORT), then it will check if it can still use
the same IP address. If it cannot use the same IP address, then the
client must unicast a new DRCP_DISCOVER message in order to get a new
address. This helps to detect the subnet change. It happens only
when a client moves to a new subnet.
2.3.2 Basic DRCP Server Operation
If a DRCP interface has a local configuration information (including
an address pool) for that interface, then it becomes a DRCP server.
The DRCP server must first use the first address from the address
pool to configure its own interface. It can then use the rest of the
address pool to allocate individual addresses directly to clients on
the same subnet as that interface.
The server may send periodic DRCP_ADVERTISEMENT messages (on the
DRCP_ADVERTISMENT_PORT) every DRCP_ADVERTISMENT_PERIOD time.
The server listens for DHCP_DISCOVER broadcast or unicast to the
DRCP_SERVER_PORT. If it gets a DHCP_DISCOVER message, then the DRCP
server can immediately send a DRCP_OFFER message with valid IP
address and other configuration parameters from its configuration
information. The DRCP_OFFER will be resent every DRCP_OFFER_PERIOD
for up to DRCP_SERVER_MAX retransmissions, or until it receives a
DRCP_ACCEPT or DRCP_DECLINE from the client.
2.4. Example Applications
This section considers the operation of DRCP in the type of network
shown in Figure 1.
2.4.1 Client Moves into a New Domain
If a client has just been rebooted or moves to a new domain, then
there may be a flow of messages such as that shown below.
ITSUMO Group Expires January 2001 [Page 8]
Internet Draft DRCP July 2000
client Server
| ADVERTISEMENT |
|<----------------|
| |
| DISCOVER |
|---------------->|
time | |
| | OFFER |
V |<----------------|
| |
| ACCEPT/DECLINE |
|---------------->|
| |
| |
Figure 4 DRCP Client Moves into a New Domain/Subnet
The figure above shows the server initiates periodic ADVERTISEMENT
messages. Upon receiving the ADVERTISEMENT message, the client
transmits and retransmits the DISCOVER message until it gets an OFFER
message or the timer expires. The server transmits and retransmits
the OFFER message until it gets an ACCEPT or DECLINE message or timer
expires.
One key difference from DHCP is that there is no ACK message from the
server (and the client accepts with an ACCEPT rather than a REQUEST
message). A second key difference is that we assume the
configuration can be used as soon as the OFFER is received (duplicate
detection is handled in the background).
2.4.2 Client Renews/Release existing lease
If a DRCP client wants to renew or release its lease, then there will
be a flow of DRCP messages such as that shown below.
client Server
| REQUEST/RELEASE |
|---------------->|
time | |
| | ACK |
V |<----------------|
| |
Figure 5 Extending the lease within a domain
The server sends an ACK message in response to the REQUEST/RELEASE.
Re-negotiates an OFFER
If a DRCP client does not like an OFFER, then it can request a new
ITSUMO Group Expires January 2001 [Page 9]
Internet Draft DRCP July 2000
offering using message flow as shown below.
client Server
| |
| OFFER |
|<----------------|
| |
| DECLINE |
|---------------->|
time | |
| | OFFER |
V |<----------------|
| |
| ACCEPT/DECLINE |
|---------------->|
| |
| |
Figure 6 DRCP Client Re-negotiating an OFFER
Upon receiving the DECLINE message the DRCP server can either do
nothing or can send a new OFFER message. In response to the new
OFFER message, the client can either decline again (send another
DECLINE message) or accept (send an ACCEPT message).
3. DRCP Message Format
All DRCP messages are sent in UDP/IP packets to special DRCP ports
and are 32-bit aligned.
3.1 Common Header Format
3.1.1 Common Header for Message from the Client
All DRCP message from the client (to the DRCP_SERVER_PORT) have
the same general format (size shown in braces):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| op (1) | htype (1) | hlen (1) | xid (1) |
+---------------+---------------+---------------+---------------+
| |
| chaddr (variable) |
| |
| |
+---------------------------------------------------------------+
| |
| options (variable) |
+---------------------------------------------------------------+
Figure 8 Format of a DRCP client message
ITSUMO Group Expires January 2001 [Page 10]
Internet Draft DRCP July 2000
The various fileds are See Section 3.2 for details):
FIELD OCTETS DESCRIPTION
----- ------ -----------
op 1 Message OpCode.
htype 1 Hardware address type.
hlen 1 Hardware address length in bytes.
xid 1 Transaction ID.
chaddr var. Client hardware address (e.g 16 bytes for 802.X)
options var. Optional parameters field.
3.1.2 Common Header for Message from the Server
All DRCP message from the server (to the DRCP_CLIENT_PORT) have
the same geenral format (except a DRCP_ADVERTISEMENT):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| op (1) | htype (1) | hlen (1) | xid (1) |
+---------------+---------------+---------------+---------------+
| |
| chaddr (variable) |
| |
| |
+---------------------------------------------------------------+
| ciaddr (4) |
+---------------------------------------------------------------+
| |
| options (variable) |
+---------------------------------------------------------------+
Figure 8 Format of a DRCP client message
The fileds are the same as for the client except that it includes
FIELD OCTETS DESCRIPTION
----- ------ -----------
ciaddr 4 Client IP address
3.1.3 DRCP_ADVERTIEMENT
The format of the DRCP_ADVERTISEMENT is under review.
3.2 Common Header Content
The opcode field consists of version number (ver), message type
(mtype) and broadcast(B) flag as shown in figure 9.
ITSUMO Group Expires January 2001 [Page 11]
Internet Draft DRCP July 2000
0 1 2 3 4 5 6 7 8
+----+----+----+----+----+----+----+----+
| ver | O | B | mtype |
+----+----+----+----+----+----+----+----+
Figure 9 Op Code Field
FIELD BITS DESCRIPTION
----- ---- -----------
ver 2 Version Number. Currentlty 001 (binary).
O 1 Options Flag (`1` if at least one option is present).
B 1 BroadCast Flag. Similar to DHCP broadcast flag.
mtype 4 Message type.
Possible values for Message types are
Message Value Message Type
------------- --------------
0 0 0 1 DRCP_DISCOVER
0 0 1 0 DRCP_REQUEST
0 0 1 1 DRCP_INFORM
0 1 0 0 DRCP_ACCEPT
0 1 0 1 DRCP_DECLINE
0 1 1 1 DRCP_RELEASE
1 0 0 1 DRCP_OFFER
1 0 1 0 DRCP_ACK
1 0 1 1 DRCP_NAK
1 1 1 1 DRCP_ADVERTISEMENT
See ARP section in "Assigned Numbers" RFC. For example: Htype =
'1' means it is a 10mb ethernet.
Length of chaddr field in bytes. For example Hlen is set to '6'
for 10mbps ethernet.
A random number chosen by the client. It is used by the client
and server to associate messages and responses between a client
and a server.
The IP address assigned to a client by a server.
3.3 Options
All information, other than what is in the common header, must be
included as options. All options have a common 4 byte header shown
below:
ITSUMO Group Expires January 2001 [Page 12]
Internet Draft DRCP July 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option code (2) | oplen (2) |
+-------------------------------+-------------------------------+
| |
| option data (variable) |
+---------------------------------------------------------------+
Figure 11 Format of Option field
FIELD OCTETS DESCRIPTION
----- ------ -----------
option code 2 Defines the code of the option field. Same as in DHCP
options
oplen 2 Length of the option data following
option data var Option data
4. DRCP Interface Messages
DRCP has the feature that its configuration information can be
changed dynamically. This section contains the API to DRCP that
allows users or other processes to interact with DRCP. However, the
APIs and other features are TBD.
5. Security Considerations
DRCP is built directly on UDP and IP which are inherently insecure.
IPsec and other security protocols can not be used since the client
does not have any IP address. However, client-server authentication
to provide for authetication of the source and contents of DRCP
messages are under review.
6. Acknowledgments
The authors wish to acknowledge the contributions of other members of
the ITSUMO (Internet Technologies Supporting Universal Mobile
Operation) team from Telcordia (P. Agrawal, J.C. Chen, A. Dutta,
D. Famolari, F. Vakil, P. Ramanathan, H. Sherry and R. Wolff)
and Toshiba America Research Incorporated (T. Kodama).
Some of the initial ideas of DRCP came out of a project on complete
autoconfiguration within a domain, funded by the U.S. Army Research
Laboratory (ARL) under the Advanced Telecommunications and
Information Distribution Research Program (ATIRP) Consortium.
6. References
[CEL] A. Campbell, J. Gomez, C-Y. Wan, S. Kim, Z. Turanyi and A.
ITSUMO Group Expires January 2001 [Page 13]
Internet Draft DRCP July 2000
Valko, "Cellular IP", Internet draft,
<draft-ietf-mobileip-cellularip-00.txt>, January 2000, Work in
progress.
[DAAP] A. McAuley and K. Manousakis, "Self-Configuring Networks",
To appear in Proceedings of MILCOM2000, October 2000.
[DHC] R. Droms, `` Dynamic Host Configuration Protocol,'' Request
for Comments 2131, Mar 1997.
[DHCA] R. Droms, "Authentication for DHCP Messages",
<draft-ietf-dhc- authentication-14.txt>, July 2000 Work in
progress.
[DHCD] Y. Rekhter, M. Stapp, "Interaction between DHCP and DNS,"
<draft-ietf-dhc-dhcp-dns-12.txt>, March 2000, Work in
progress.
[DHCL] A. Bennett, B. Volz, A. Westerinen, " DHCP Schema for
LDAP," <draft-ietf-dhc-schema-02.txt>, March 2000, Work in
progress.
[DHCR] A. Mcauley, S. Das, S. Baba and Y. Shobatake,
"Requirements for Extending DHCP into New Environments",
<draft-ietf-dhc-enhance -requirements-00.txt>, March 2000,
Work in progress.
[HAW] R. Ramjee, T. La Porta, S. Thuel and K. Varadhan: "IP
micro- mobility support using HAWAII",
<draft-ramjee-micro-mobility-hawaii-00.txt>, June 1999, Work
in progress.
[MIP] Perkins, C., Editor: "IP Mobility Support", RFC 2002, October
1996.
[MIPA] S. Glass, T. Hiller, S. Jacobs, C. Perkins, "Mobile IP
Authentication, Authorization, and Accounting
Requirements,"<draft-ietf-mobileip-aaa-reqs-04.txt>, June
2000. Work in progress
[MIPC] E. Gustafsson, A. Jonsson, E. Hubbard, J. Malmkvist, A.
Roos, "Requirements on Mobile IP from a Cellular Perspective,"
<draft-ietf-mobileip-cellular-requirements-01.txt>, June 1999.
Work in progress.
[MIPD] P. R. Calhoun and C.E. Perkins, "DIAMETER Mobile IP
Extensions", Internet draft,
<draft-calhon-diameter-mobileip-09.txt>, July 2000, Work in
Progress.
[MIPN] P. Calhoun and C.E. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000.
[REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC-2119, March 1997.
[TIA] Tom Hiller, et al. "3G Wireless Data Provider Architecture
ITSUMO Group Expires January 2001 [Page 14]
Internet Draft DRCP July 2000
Using Mobile IP and AAA," draft-hiller-3gwireless-00.txt,
March 1999.
7. Authors' Addresses
Anthony J. McAuley
MCC 1C235B, Telcordia
445 South Street, Morristown, NJ 07960
Phone: +1 973 829 4698
email: mcauley@research.telcordia.com
Subir Das
MCC 1D210R, Telcordia
445 South Street, Morristown, NJ 07960
Phone: +1 973 829 4959
email: subir@research.telcordia.com
Sunil Madhani
MCC 1B246B, Telcordia
445 South Street, Morristown, NJ 07960
Phone: +1 973 829 5162
email: sunil@research.telcordia.com
Shinichi Baba
Toshiba America Research Inc.
P.O. Box 136 Convent Station, NJ 07961-0136
Phone: +1 973 829 4759
email: sbaba@tari.toshiba.com
Yasuro Shobatake
Toshiba America Research Inc.
P.O. Box 136 Convent Station, NJ 07961-0136
Phone: +1 973 829 3951
email: yasuro.shobatake@toshiba.co.jp
ITSUMO Group Expires January 2001 [Page 15]