[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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.


2.4.3 Client  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

3.2.1 OpCode

      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


3.2.2 Htype
      See ARP section in "Assigned  Numbers" RFC.  For example:  Htype =
      '1' means it is a 10mb ethernet.

3.2.3 Hlen
      Length of chaddr  field in bytes.  For example  Hlen is set to '6'
      for 10mbps ethernet.

3.2.4 Xid
      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.

3.2.5 Ciaddr
      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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/