One document matched: draft-ietf-dhc-enhance-requirements-00.txt
Network Working Group Anthony McAuley
INTERNET-DRAFT Subir Das
Internet Engineering Task Force Telcordia Technologies
draft-ietf-dhc-enhance-requirements-00.txt Shinichi Baba
Date: March 8, 2000 Yasuro Shobatake
Expires: August, 2000 Toshiba America Research Inc.
Requirements for Extending DHCP into New Environments
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 widely
deployed framework for host registration and configuration [DHC].
DHCP, however, was designed only for fixed hosts on physically secure
LANs. Other protocols fill some of the gap. PPP [PPP] is a good
solution for many commercial service providers (where framing is
needed). Mobile IP [MIP] is ideal for registering and configuring
roaming users (when transparent address binding is needed). This
still leaves many environments where there is no ideal solution,
such as: roaming users who do not need transparent address binding
ITSUMO Group Expires August 2000 [Page 1]
Internet Draft Requirements for Extending DHCP March 3, 2000
(e.g., a mobile web browser), and commercial service providers
who want to support home networking with multiple nodes. This draft
proposes DHCP as the best protocol to meet these new needs, because
it leave open how (and whether) to provide other functions, such as
framing (e.g., PPP), locating (e.g., Mobile IP in co-located mode),
inter-domain AAA (e.g., [AAAR]), or address distribution (e.g.,
[DAAP]). We describe and solicit feedback on seven new requirements
that would be placed on DHCP to meet these needs.
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
they can be used across any wired or wireless access network.
1.1 Architecture
Figure 1 shows a high level functional architecture of a future IP-
based network, with both a fixed and a roaming clients attaching
to various wired or wireless Access Networks. We assume the client
has at least one physical interface onto the access network, but
can also have other physical and virtual interfaces. The access
network, which may contain multiple Layer 2 nodes (such as hubs),
connects to at least one Edge Router and Edge Agent (that may be
co-located). The Regional Backbone connects all the Edge Routers in
an administrative domain and the Global Internet interconnects all
the regional networks.
We assume the network may need to change client configuration of even
fixed nodes at any time, but that typically clients keep the same
configuration (e.g., IP address) while they are within a given access
network. Micro mobility within the access network is handled at Layer
2. Depending on how routing is done, the client may or may not need a
new configuration when it moves to a new access network within the
same domain (macro mobility) [CEL] [HAW]. We assume, however, that
clients must be reconfigured when moving to a new domain (global
mobility).
ITSUMO Group Expires August 2000 [Page 2]
Internet Draft Requirements for Extending DHCP March 3, 2000
. <---- DOMAIN 1 ----> . . <---- DOMAIN 2 ----> .
. +---------+ . +--------------+ . +---------+ .
. | Domain | . | Inter-domain | . | Domain | .
. | Agent | . | Agent | . | Agent | .
. +---------+ . +--------------+ . +---------+ .
. | . | . | .
. __|__ . __|___ . __|__ .
. / \ . / \ . / \ .
. / \ . / \ . / \ .
. / Regional\________/ Global \_________/ Regional\ .
. \ Backbone/ . \ Internet / . \ Backbone/ .
. ____\ /____ . \ / . ____\ /____ .
. / \_____/ \ . \______/ . / \_____/ \ .
. / | \ . . / | \ .
. / | \ . . / | \ .
. +--------+ . . +--------+ .
. .. | Edge | .. . . .. | Edge | .. .
. | Router | . . | Router | .
. +--------+ . . +--------+ .
. .. | | .. . . .. | | .. .
. +--------+ | | +--------+ . . +--------+ | | +--------+ .
. | Edge | | | | Edge | . . | Edge | | | | Edge | .
. | Agent | | | | Agent | . . | Agent | | | | Agent | .
. +--------+ | | +--------+ . . +--------+ | | +--------+ .
. | | | | . . | | | | .
. | _____ | | _____ | . . | _____ | | _____ | .
. |/ \__| |__/ \| . . |/ \__| |__/ \| .
. / \ / \ . . / \ / \ .
. / Access \ .. / Access \ . . / Access \ .. / Access \ .
. \ Network / \ Network / . . \ Network / \ Network / .
. \ / \ / . . \ / \ / .
. \_____/ \_____/ . . \_____/ \_____/ .
. | | . . | | .
| | | |
+---------+ +---------+ global macro
| Fixed | | Mobile | ****************> *************>
| Client | | Client | mobility mobility
+---------+ +---------+
Figure 1: Functional Network Architecture
ITSUMO Group Expires August 2000 [Page 3]
Internet Draft Requirements for Extending DHCP March 3, 2000
Figure 1 is meant to be very general functional diagram. It does not,
for example, specify where a Base Station (BS) is located. BSs could
be within the access networks (Layer 2 BS) or in the Edge Router (IP
BS). The Domain and Inter-Domain agents which perform functions such
as registration and AAA, are shown as single boxes; but both could be
implemented as multiple nodes (possibly in a hierarchical structure).
1.2 Functional Scope
The functions needed to support users' accessing IP-based networks
vary, depending on network, user, and application characteristics.
Some basic functions include:
o Registration: Users indicate their presence and their requirements
to a network (e.g., give a user name [NAI]).
o Configuration: Networks adapt nodes to the particular network
characteristics (e.g., give an IP address).
o Framing: Indicates the start and end of packets in a data stream.
o Compression: Compress RTP/UDP/TCP/IP header and data over an
access network.
o Dynamic Address Binding: Allows corresponding nodes to locate
users and allows continuous communication as the user moves among
networks.
This draft is concerned only with the first two functions, which we
believe have a natural association (see Section 3.5). This draft
considers only server based methods for registration and
configuration within a single IP domain. The network servers are
themselves configured with information such as an IP address pool;
but, server configuration is beyond the scope of this draft. We
assume each access network has at least one edge server (possibly
co-located with the edge router), though it could be as simple as a
relay agent.
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].
ITSUMO Group Expires August 2000 [Page 4]
Internet Draft Requirements for Extending DHCP March 3, 2000
1.4 Terminology
This document uses the following terms:
o "AAA"
Authentication, authorization and accounting
o "BOOTP"
The Bootstrap Protocol (BOOTP) [BOO1] [BOO2].
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 "Domain Agent"
An Internet node that provides a centralized service within a
domain (e.g., DHCP server)
o "Edge Router"
An IP router connecting an IP subnet to other networks.
o "Edge Agnet"
An IP node (host or router) that is connected to an IP subnet and
provides services (e.g., DHCP relay agent).
o "Inter-domain Agent"
An Internet node that provides services for a node anywhere in the
Internet.
o "NAI"
Network Access Identifier of the form user@domain [NAI].
ITSUMO Group Expires August 2000 [Page 5]
Internet Draft Requirements for Extending DHCP March 3, 2000
2 Registration and Configuration Protocols
There are several TCP/IP protocol choices for performing registration
and configuration:
o The Point-to-Point Protocol (PPP).
o The Mobile IP protocol (MIP).
o The Dynamic Host Configuration Protocol (DHCP).
2.1 PPP
Although its primary function is packet framing, PPP also provides
well tested and widely deployed registration and configuration
capabilities. PPP [PPP] clients sends registration information, such
as login and password to an access concentrator on the Layer 2
network to which the client is connected. The access concentrator can
then either directly configure the client or use the Layer 2
Tunneling Protocol [PPPL] to tunnel PPP packets to and from a server
anywhere in the Internet. The powerful PPP registration and
configuration capabilities are now even used when framing is not
needed (e.g., PPPoE [PPPE]). The only cost is that it leaves some of
the PPP framing overhead (2 bytes for framing, 2 bytes for CRC, up to
4 other bytes, and bit or byte stuffing overhead).
2.2 Mobile IP
Although its primary function is providing location service and
continuous connectivity to roaming users, Mobile IP [MIP] [MIP6] also
provides a flexible registration and configuration capabilities. The
Mobile IP client sends registration information to a Foreign Agent
[MIPA] [MIPC] [MIPD] [MIPN] [MIPS] [MIPT] on the Layer 2 network to
which the client is connected. The Foreign Agent can then configure
the client, after getting authorization from the user's Home Agent.
The registration and configuration capabilities could be provided by
Mobile IP for all roaming users, even when transparent binding is not
needed (e.g., for web browsing) or may need alternative mechanisms
(viz., SIP for real-time applications [SIP] [SIPM]). The only costs
are: a) triangular routing, b) having to configure a permanent home
address, and c) depending on a home network.
ITSUMO Group Expires August 2000 [Page 6]
Internet Draft Requirements for Extending DHCP March 3, 2000
2.3 DHCP
DHCP provides a well tested and widely deployed framework for passing
configuration information to hosts [DHC]. A DHCP client in a host
broadcasts a DISCOVER control message to the access network. A
server picks up the message and either a) returns an OFFER message
(server) or b) relays the message to a central DHCP server. DHCP is
unique in that it:
o Has no additional functions (e.g., framing or address binding).
o Requires no client preconfiguration (e.g., for home addresses).
o No overhead to data traffic (out-of-band signaling).
o Allows nodes to go on and off without re-registration.
o Allows a single network server per domain (using relay agents).
DHCP is likely to continue to gain in popularity with recent
enhancements, such as Server fail-over [DHCF], Load balancing [DHCB],
Dynamic updating of DNS [DHCD], LDAP database management [DHCL], and
Authentication [DHCA].
2.4 Choice
PPP, Mobile IP and DHCP were designed for different environments.
Thus, network designers select the registration and configuration
protocol that best fits the types of access network and likely client
applications. For example, networks using phone lines for access will
typically use PPP; wireless providers supporting roaming TCP
application, such as telnet and ftp, will use Mobile IP; and
corporate networks will use DHCP.
The open question is what registration and configuration protocol
will be used in environments that do not fit into the PPP, Mobile IP,
or DHCP assumptions? Examples of these environments are:
o Commercial service providers who want to support flexible home
networking.
o Roaming users who either do not need transparent binding (e.g.,
just web browsing) or prefer alternative mechanisms (e.g., SIP for
real-time applications).
PPP, Mobile IP and DHCP could all be adapted to better some or all of
these environments. This draft proposes DHCP as the best protocol to
meet these new needs, because it leave open how (and whether) to
provide other functions, such as framing (e.g., PPP), locating (e.g.,
Mobile IP in co-located mode), inter-domain AAA (e.g., [AAAR]), or
address distribution (e.g., [DAAP]). We describe the new requirements
that would be placed on DHCP in the next Section.
ITSUMO Group Expires August 2000 [Page 7]
Internet Draft Requirements for Extending DHCP March 3, 2000
3. Requirements for Extending DHCP into New Environments
Though DHCP has many desirable features, the following requirements
created by new environments are not fully met by DHCP:
o R1 Rapid client configuration (milliseconds rather than seconds).
o R2 Rapid client reconfiguration (independent of lease time).
o R3 Efficient use of scarce wireless bandwidth.
o R4 Allowing clients to be routers.
o R5 Enhanced registration (e.g, user identification and security).
o R6 Flexible proxies that can act as both relay or server.
o R7 Allowing dynamic server and relay reconfiguration.
This section gives a brief description and motivation for each new
requirement.
3.1 Rapid configuration
Configuration latency is critical to users roaming among wireless
networks. A DHCP client accepts an OFFER by returning a REQUEST
message to the server (which the server ACKS). The client, however,
only configures its new address after checking that no other node on
the subnet is using it. The DHCP specification [DHC] says a client
SHOULD do ARP checking before an assigned address is used. This
"in-line" checking results in long delay (typically 3-15 seconds)
before communication can resume after a move; too long for many
roaming users. While duplicate detection is desirable, it need not be
part of the critical path. One possible alternative, for example,
would be to have the server do ARP checking on addresses before they
are requested.
The goal is to get configuration in milliseconds (bounded mostly by
by the speed of the access link) rather than seconds.
ITSUMO Group Expires August 2000 [Page 8]
Internet Draft Requirements for Extending DHCP March 3, 2000
3.2 Rapid reconfiguration
A recent draft [DHCR] has proposed a new DHCP FORCERENEW message
that allows servers to force clients to immediately reconfigure.
To enable rapid reconfiguration (e.g., when a roaming user moves into
a new subnet or topology changes), clients must rapidly detect the
server request. Today, DHCP clients typically go into sleep mode,
not listening to DHCP messages until the lease is due for renewal.
Clients can use external triggers, such as a layer 2 hand-off
indication or an SNMP V3 request message, to jump DHCP into a new
state. These triggers, however, may not always: a) be available,
b) be standardized, c) have enough information. The information may
help client to decide if it is in a new subnet or to get the location
of a DHCP server (to prevent having to broadcast).
The goal is to be able to rapidly reconfigure DHCP clients, at any
time, without relying on external triggers.
3.3 Bandwidth Efficiency
DHCP message overhead is considerably larger than needed, mainly
because DHCP kept the same syntax as BOOTP [BOO1] [BOO2] [BOOD]. This
was not a problem in the old paradigm where hosts connect to DHCP
servers over high speed LANs; especially since DHCP overhead mainly
occurs when a host first boots and DHCP adds nothing to normal packet
communication overhead. The overhead is perhaps only a problem for
roaming nodes using some wireless access networks. Depending on the
size of the IP subnets, roaming users might need to reconfigure as
fast as every few seconds. Depending on the speed and error rate of
the wireless access networks, reducing DHCP message size could
significantly improve bandwidth efficiency. (The error rate can be
important since larger messages result in higher probability of loss,
that increases latency and bandwidth needs.)
The goal is to minimize DHCP message size, by reducing the size of
individual DHCP messages and possibly by reducing the total number of
messages.
ITSUMO Group Expires August 2000 [Page 9]
Internet Draft Requirements for Extending DHCP March 3, 2000
3.4 Clients as Routers
DHCP specification [DHC] says clients must be hosts and that it "is
not intended for use in configuring routers." This was not a problem
in the old paradigm, where routers were typically part of a
hierarchical network that could be manually configured by a system's
administrator. As the size and complexity of networks increase
(e.g., with more small devices with low power wireless interfaces),
routing functionality becomes desirable in places where manual
configuration is not desirable. We are NOT proposing that DHCP be
extended to simultaneously configure multiple router interfaces or
to distribute address pools; only that DHCP could configure a single
router interface over a subnet where there is a DHCP server (or
relay). This would require no change in DHCP functionality; only a
change in allowable application.
The goal is to allow DHCP to configure hosts and routers.
3.5 Enhanced Registration
Commercial service providers need a scalable way to identify and
authenticate users. In addition they may need other registration
information such as: a) the location of the client's AAA server
(for inter-domain authentication [DHCZ], b) negotiate service
requirements and costs, and c) trigger other services (possibly
based on a user profile). Many of these features are now being
defined for DHCP, but filling the missing needs would be helpful.
We assume that DHCP itself only deals with intra-domain registration;
a separate AAA protocol [AAAD] [AAAR] meets the inter-domain
requirements.
The registration and configuration could be done in separate
protocols; however we believe integrating the two functions is
desirable. First, it reduces the latency, since it requires only
one round trip from the client to the network. Second, it forces
users to register before they can be configured. Clearly, devious
users could still configure themselves, but now they cannot use
DHCP to do this.
The goal is to allow DHCP to meet the registration needs of diverse
service providers.
ITSUMO Group Expires August 2000 [Page 10]
Internet Draft Requirements for Extending DHCP March 3, 2000
3.6 DHCP Proxies
A DHCP client must either connect to a node acting as a DHCP server
or connect to a DHCP relay. When a client first activates or moves
into a new domain, DHCP message are best relayed to a central server
(such as the Domain Agent in Figure 1); however, when users roaming
among subnets within a domain DHCP message may best be handled
locally. This would require no change in DHCP functionality; only a
change in allowable application.
The goal is to allow a subnet proxy to act as both a relay and
server, depending on a client's status.
3.7 Dynamically changing server (and relay) parameters
In some networks it may be desirable to dynamically change the
preconfigured information in DHCP servers (and relay agents). For
example, the address-pool may change if a topology change occurs
[DAAP]. While DHCP should have nothing to do with updating
address-pools, it should be able to handle dynamic changes in this
information. If an external application changed the information,
DHCP should gracefully handle the change (e.g., it may immediately
update all its clients). This would require no change in DHCP
protocol, only that: a) there is a common configuration framework
(e.g., [DHCL]), and b) that DHCP servers and relay agents allow
dynamic changes in preconfigured information.
The goal is to allow dynamic modification of DHCP server (and relay)
configured parameters, such as the address-pool, by an external
entity.
ITSUMO Group Expires August 2000 [Page 11]
Internet Draft Requirements for Extending DHCP March 3, 2000
4 Discussion
The purpose of this draft is to stimulate discussion and solicit
feedback on enhancing DHCP into new environments. These environments
include roaming users who do not need transparent address binding
(e.g., a mobile web browser) or commercial service providers whose
access network provides framing (e.g., a cable access network).
Given the large paradigm shift created by these new environments, it
is an open question on how to achieve these changes. At the highest
level we could slowly enhance DHCP, while maintaining backwards
compatibility. A more radical approach would be the creation of a
sister protocol such as DRCP [DRCP]. We have not given specific
approaches or mechanisms here, except as examples, because we
initially want to focus on the requirements.
5. Acknowledgments
The authors 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,
S. Madhani, F. Vakil, P. Ramanathan, H. Sherry and R. Wolff) and
Toshiba America Research Incorporated (T. Kodama). Also thanks to
Steve Gonczi of Process Software for his helpful suggestions.
The initial ideas came out of a project on complete network
autoconfiguration within a domain [DAAP], funded by the U.S. Army
Research Laboratory (ARL) under the Advanced Telecommunications and
Information Distribution Research Program (ATIRP) Consortium.
6. References
[AAAD] P. Calhoun and A. Rubens, "DIAMETER Base Protocol," Internet
draft, Work in Progress, Nov 1998.
[AAAR] C. Rigney, A. Rubens, W. Simpson, and S. Willens, "Remote
Authentication Dial in User Service (RADIUS)," Request for
Comments 2138, Apr 1997.
[BOO1] B. Croft & J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
Stanford and SUN Microsystems, September 1985.
[BOO2] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, Carnegie Mellon University, October 1993.
ITSUMO Group Expires August 2000 [Page 12]
Internet Draft Requirements for Extending DHCP March 3, 2000
[BOOD] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534,
Bucknell University, October 1993.
[CEL] Valko, A., Campbell, A. and Gomez, J.: "Cellular IP", Internet
draft, <draft-valko-cellularip-00.txt>, Work in progress,
November 1998.
[DAAP] A. McAuley and K. Manousakis, "Self-Configuring Networks."
To appear Proc. of 4'th Advanced Telecommunications and
Information Distribution Research (ATIRP) Conference,
University of Maryland, March 2000.
[DHC] R. Droms, "Dynamic Host Configuration Protocol," Request for
Comments 2131, Mar 1997.
[DHCA] R. Droms, W. Arbaugh, "Authentication for DHCP Messages",
<draft-ietf-dhc-authentication-12.txt>, Work in progress,
October 1999.
[DHCB] B. Volz, S. Gonczi, T. Lemon, R. Stevens, "DHC load balancing
algorithm," <draft-ietf-dhc-loadb-00.txt>, Work in progress,
October 1999.
[DHCD] Y. Rekhter, M. Stapp, "Interaction between DHCP and DNS,"
<draft-ietf-dhc-dhcp-dns-10.txt>, Work in progress, June 1999.
[DHCL] A. Bennett, B. Volz, A. Westerinen, "DHCP Schema for LDAP,"
<draft-ietf-dhc-schema-00.txt>, Work in progress, June 1999.
[DHCF] R. Droms, K. Kinnear, M. Stapp, B. Volz, S. Gonczi, G. Rabil,
M. Dooley, A. Kapur, "DHCP Failover Protocol,"
<draft-ietf-dhc-failover-05.txt>, Work in progress,
October 1999.
[DHCR] P. De Schrijver, Y. T'Joens, C. Hublet, "Dynamic host
configuration : DHCP reconfigure extension,"
<draft-ietf-dhcpv4-reconfigure-01.txt>, Work in progress,
March 2000.
[DHCZ] S. Das, A. McAuley, S.Baba, and Y.Shobatake, "Authentication,
Authorization, and Accounting Requirements for Roaming Nodes
using DHCP," <draft-ietf-dhc-aaa-reqs-00.txt>, Work in
Progress, March 2000.
[DRCP] A. McAuley, S. Das, S.Baba, and Y.Shobatake, "Dynamic
Registration and Configuration Protocol (DRCP),"
<draft-itsumo-drcp-00.txt>, Work in Progress, October 1999.
ITSUMO Group Expires August 2000 [Page 13]
Internet Draft Requirements for Extending DHCP March 3, 2000
[HAW] R. Ramjee, T. La Porta, S. Thuel and K. Varadhan: "IP micro-
mobility support using HAWAII",
<draft-ramjee-micro-mobility-hawaii-00.txt>, Work in progress,
June 1999.
[MIP] C. Perkins, "IP Mobility Support", RFC 2002, October 1996.
[MIP6] D. Johnson and C. Perkins, "Mobility Support in IPv6,"
<draft-ietf-mobileip-ipv6-09.txt>, Work in Progress, Oct 1999.
[MIPA] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication,
Authorization, and Accounting Requirements,"
<draft-ietf-mobileip-aaa-reqs-00.txt>, Work in progress,
October 1999.
[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>, Work in
progress, June 1999.
[MIPD] P. Calhoun and C.E. Perkins, "DIAMETER Mobile IP Extensions,"
Internet draft, Work in Progress, Nov 1998.
[MIPN] P. Calhoun and C.E. Perkins, "Mobile IP Network Access
Identifier Extension," <draft-ietf-mobileip-mn-nai-05.txt>
Work in progress, October 1999.
[MIPS] B. Patil, R. Narayanan & E. Qaddoura, "Security Requirements/
Implementaion Guidelines for Mobile IP using IP security"
Internet draft, Work in Progress, June,1999.
[MIPT] Tom Hiller, et al. "3G Wireless Data Provider Architecture
Using Mobile IP and AAA," <draft-hiller-3gwireless-00.txt>,
Internet draft, Work in progress, October 1999.
[NAI] B. Aboba and M. A. Beadles, "The network access identifier,"
RFC 2486, January 1999.
[PPP] W. Simpson, "The Point to Point Protocol (PPP),: Internet STD
51, July 1994.
[PPPE] L. Mamakos, et al., "Method for Transmitting PPP Over Ethernet
(PPPoE)," RFC 2516, February 1999.
[PPPL] W. Townsley, et al, "Layer Two Tunneling Protocol L2TP," RFC
2661, August 1999.
ITSUMO Group Expires August 2000 [Page 14]
Internet Draft Requirements for Extending DHCP March 3, 2000
[REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels," RFC-2119, March 1997.
[SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP:
Session Initiation Protocol," RFC 2543, March 1999.
[SIPM] E. Wedlund and H. Schulzrinne, "Mobility Support using SIP",
Proc. of second ACM International Workshop on Wireless
Mobile Multimedia (WOWMOM'99), pp 76-82, August, 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
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 August 2000 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-24 14:55:14 |