[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 02

Network Working Group                                       K. Taniguchi
INTERNET DRAFT                                                   NEC USA
Expire in six months                                          T. Nishida
                                                                 NEC USA
                                                           18 March 1997


              DSCP: Dynamic Subnet Configuration Protocol
                <draft-ietf-dhc-dyn-subnet-conf-00.txt>

Status of this Memo

   This document is an Internet-Draft. 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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).



Abstract

   The Dynamic Subnet Configuration Protocol (DSCP) provides a framework
   for passing configuration information to administrative servers on a
   TCP/IP network which allows dynamic subnet configuration. Examples of
   administrative servers, which are DSCP clients, are a network
   administrator's host, DHCP server, etc.  DSCP is built on a client
   server model.  The DSCP server allocates subnet configuration
   parameters to dynamically configured subnetworks.  DSCP is an
   extension of DHCP [1,2]. This document describes DSCP model and
   defines a new DHCP options to allow the subnet configuration
   dynamically.





1. Introduction

   Recent data link layer technology, especially switching and wireless
   network, can be created subnetworks dynamically. Since, using these
   technologies, we do not need a IP router function for segmenting IP
   subnetwork, subnet domain can create/delete in accordance with user's
   application.  Typical applications are virtual LAN, VPN (virtual
   private network), CUG (Closed Users Group) and ad-hoc network.  Users
   can overlay subnetworks freely on a single physical network for
   creating intranet and extranet.

   On the other hand, internet engineers have been attacking to improve
   the network layer technology.  One of such challenge is an invention
   of a function which changes configuration of hosts, route and name
   space dynamically.  For example, DHCP assigns IP address.  Dynamic
   routing protocol like RIP detects link status change and gives the
   right route information.  Moreover, DNS are going to accept a dynamic
   record update by linking a DHCP server.  These technologies
   contribute easier configuration for a host connection and host
   movement.  This proposal adds another dimension of dynamic internet
   configuration in conjunction with virtual subnetworking technologies.
   A new protocol, called DSCP (Dynamic Subnet Configuration Protocol),
   which is an extension of DHCP, assigns subnet resources to a
   dynamically created subnetwork. This draft proposes a model for
   dynamic subnet resource configuration, and for this purpose, adding a
   few new options in DHCP message format is necessary.

2. Model

   There are three models to consider; administrator driven, leader
   driven and DHCP server driven.

   An administrator driven model supports requirements of a network
   administrator who needs a new subnet address.  Then, an administrator
   invokes a DSCP client function.  The client negotiates with DSCP
   servers, and normally gets a set of new subnet address according to
   the administrator's request.  Then the administrator may manually
   change the subnet table and configure router's IP address
   information.  In this model, the server only provides an available IP
   subnet address to the administrator and marks that address as
   reserved.

   A leader driven model supports requirements of a leader of a specific
   group who may not be a network administrator and needs a new subnet
   address temporary for creating a new subnet.  A leader executes a
   DSCP client.  The client negotiates with DSCP servers to get a new IP
   subnet address.  The DSCP servers create a new IP host table to
   manage a leased subnet address space and prepare to accept DHCP
   requests from a host who wants to join the newly created IP subnet.
   After that, hosts of members belonging to the same group join newly
   created IP subnet using DHCP.  The server allocates an IP address to
   those hosts.

   A DHCP server driven model supports requirements of a DHCP server who
   needs a new IP subnet address.  The DHCP server as DSCP client
   requests a new IP subnet address and creates a new IP host address
   list for a new IP subnet address.  Then, the DHCP server leases an IP
   address in new IP subnet address space.

3. Design Concept

   There are two methods to define a protocol to manage IP subnets
   mentioned above. One is to create new protocol.  The other is to have
   an extension of some existing protocol. This proposal adopts the
   latter approach, i.e. an extension of DHCP coping with the cost of
   new protocol.

   To extend DHCP as DSCP has some advantages.  First, DHCP has already
   a temporary address leasing mechanism.  DHCP server also has already
   a temporary IP address management database.  DHCP client has already
   finite state machine to assign an unique IP resource in a multiple
   DHCP server environment.  Therefore, the cost of defining, developing
   and deploying would be minimized.  Moreover, the existing network has
   a relay agent mechanism which is capable of supporting the DSCP
   function.

4. Term Definition

4.1. subnet address expiration time

   This is the expiration time of a subnet address leased by DSCP
   servers.  The subnet address expiration time must be later (longer)
   than all host address expiration time within the subnet address
   range.

4.2. subnet name

   In this document, all subnets must have an unique name.  The name is
   used to identify itself.  If DSCP server has enough address space, a
   client with the same subnet name can get the same subnet address
   again even after the expiration of leased time.

4.3. subnet address table

   In case of a fixed length subnet mask, each entry of the subnet
   address table has 6 fields: subnet address, subnet mask, broadcast
   address, lease status, subnet address expiration time, and subnet
   name.  The lease status is one of the following: FREE, RESERVED or
   OFFERED.

   In case of a variable length subnet mask, although the format of the
   subnet address table becomes more complex, its format is similar to
   that of a fixed subnet mask fixed.

5. Protocol Description

5.1. Normal operation

   In this section, to simplify the protocol description, exceptional
   operations are not mentioned.  In a network with multiple DSCP
   servers, each server maintains a separate subnet address space.  In
   other words, multiple servers do not manage a specific subnet address
   at the same time.

   First, a client sends a DSCPDISCOVER message to servers.  To transmit
   the message, one or more relay agents may forward the message.  Or
   the client may use broadcast, multicast, or unicast.  (Since the
   transfer method is one of the interesting issues for this protocol
   architecture, this issue is discussed later.)

   A server searches an unused subnet address from its subnet address
   table.  If there is no unused subnet addresses, the server rejects
   the request silently, i.e., without any responses.  Otherwise, the
   server returns a DSCPOFFER message to the client.  If the client has
   specified a subnet mask, the server may select a subnet address which
   has the same subnet mask.  If the server has already leased a subnet
   address to a client which requested previously with an identical
   subnet name, the DSCP server should not send any DSCPOFFER messages.

   In receiving a DSCPOFFER message, the client may send a DSCPRESERVE
   message immediately to the responding server, or it may wait to
   receive another DSCPOFFER message for some amount of time, e.g.,
   several seconds, then it selects the best offer and sends a
   DSCPRESERVE message to that particular server.

   The server receiving a DSCPRESERVE message must immediately check
   whether the requested subnet address is available or not.  If it is
   still available, the server must reserve it and return a DSCPACK
   message to the requesting client.  Otherwise, the server must return
   a DSCPNACK message to the client.

   The client which receives a DSCPACK message, can use the subnet
   address.  The client which receives a DSCPNACK message may send a
   DSCPDISCOVER message again and repeat the whole operation.

5.2. Protocol architecture issues

5.2.1. Who manages new IP subnet address space?

   As described in section 2, there are two cases that a DSCP client
   requests management of the leased IP subnet address space as a leader
   driven model, and that it undertakes management of the leased IP
   subnet address space as an administrator driven model and a DHCP
   server driven model.  To present which one manages the new IP address
   space, a new option is needed.

   This option is named "new subnet option." The option number is T.B.D.
   The length of this option is 1.  If the value of this option is 0,
   the server does not manage the new IP address space.  If it is 1, the
   server manages the new address space.  If it is another value, the
   server must treat those messages as error messages.

5.2.2. First message from a client

   Coping with any DSCP model mentioned in Section 2, a DSCP client is
   assumed to be assigned to a host address in advance, which is
   received via DHCP, manual configuration or other method.  Therefore,
   a DSCP client can unicast messages to a DSCP server if the client
   knows the server's address.  Otherwise it may send messages using
   broadcast, anycast or multicast.

   The advantage of using unicast is to minimize the traffic.  The
   advantage of broadcast, multicast or anycast is that a client does
   not need to know the server's address.  And a relay agent supports
   the forwarding of the DSCP message to a server.

5.2.3. Subnet mask negotiation

   For simple implementation, a server maintains only a fixed length
   subnet mask.

   For efficiency of address space utilization, however, the variable
   network mask should be adopted.  In this case, a client may indicate
   its preferable subnet mask length by including subnet mask option
   into the DSCPDISCOVER message.  A server may negotiate the subnet
   mask length with the requesting client by changing the value of the
   option.  If the client accepts it, it sends a DSCPREQUEST message.
   Otherwise, the client selects another DSCPOFFER message with a
   different subnet mask length.

   To accommodate both fixed and variable subnetworks, a DSCP server and
   client interpret the subnet mask option as "peer's will."  A server
   may change it, and a client may reject it.

5.2.4. Consistency

   DSCP uses a subnet name as an identification of a particular subnet.
   If a new subnet address is requested and if the subnet name has
   already been reserved by another request, the server rejects the
   request.

   In a multiple DSCP servers environment, a server need to know the
   other server's status, e.g., whether a subnet name is reserved,
   whether a subnet address has already been leased.  Otherwise,
   inconsistency among servers may occur.

   To avoid such inconsistency accessing multiple servers, the simplest
   method is to limit the number of servers to one for specified subnet
   name space.  However this is not fault tolerant.  Another method is
   that servers strive for database synchronization for all requests.
   This method increases the servers' load.

   This issue will be resolved by further study.

5.3. Architecture of subnet address table

5.3.1. Table format

   Subnet address table must have at least the following entries.

   1. Subnet address (base)

   2. Subnet mask

   3. Broadcast address

   4. Leasing status (see below)

   5. Subnet address expiration date

   6. Subnet name (leasing currently or leased last time)

5.3.2. Status of subnet address on server

   A subnet address in a subnet address table has three status.

   IDLE

   For the idle status, no clients use the subnet address.

   OFFERED

   For the offered status, DSCP server has received a DSCPDISCOVER
   message and sent a DSCPOFFER message including the subnet address.
   If the DSCP server receives the DSCPDISCOVER message which has an
   identical subnet name with the "offered" status subnet from another
   client, the DSCP server must returns the same DSCPOFFER message. The
   DSCP server should not offer the subnet address in the "offered"
   status to another requester.  The DSCP server must set timer, when it
   changes the status of subnet address to "offered."  The server stops
   the timer and changes the status to "reserved", when the server
   receives the DSCPRESERVE message before the timer expires.  When the
   timer expires, the server changes the status to "idle." In this
   status, subnet name field is specified.

   RESERVED

   For the reserved status, the address has already been leased.  In
   this status, the address must have a subnet name and expiration time.
   The server must not lease this address to another requester.  Yet,
   the server may extend the expiration time, if the original requester
   sends the DSCPRESERVE message.

5.4. DHCP server issue

   A DHCP server which has a leased IP subnet address from a DSCP server
   must abide by the following rules.

    * When T1 timer expires for a subnet address, the DHCP server should
   extend its lease period as a DSCP client.

    * If the subnet address is expired, the DHCP server must not lease
   any hosts address.

    * DHCP server must not lease a host address with a lease time longer
   than one of the subnet address.

    * Before releasing a subnet address, the DHCP server must make sure
   no host address in the subnet are used.

    * If lease time of the subnet address is infinite and the DHCP
   server would like to release the address, the server must stop
   releasing new host addresses first, wait until all host addresses
   become free, and then send the DSCPRELEASE message to its DHCP
   server.

5.5. Subnet resource representation

   When a DSCP server acts as a DHCP server, the DSCP server needs to
   have the subnet resource information, such as default router, DNS
   server, mail server, etc.  Therefore, when the DSCP server creates a
   new subnet, the client must specify the subnet resource.  There are
   two simple methods to implement this.

   The first one is that a DSCP client specifies all resources in the
   existing DHCP option.  Upon receiving the DSCPREQUEST message, the
   DSCP server remembers the options in that message.  After creating a
   new subnet, DSCP servers set this information on the DHCP server.

   The second one is that a newly created subnet shares another existing
   subnet resource.  For this purpose, a new option "subnet resource
   inheritance" is defined.  It includes a name of a subnet whose
   resources are shared by the new subnet.  If the specified subnet name
   does not exist, the DSCP server must treat that message as an error.

7. Security Considerations

   Security issue is not discussed here.

Reference

   [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531,
   Bucknell University, October 1993.

   [2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
   USC/Information Sciences Institute, August 1993.

Author's Address

   Kunihiro Taniguchi
   Multimedia Software Laboratory
   NEC USA Inc.
   110 Rio Robles,
   San Jose, CA 94086

   Phone: (408) 943-3032

   EMail: taniguti@ccrl.sj.nec.com

   Takeshi Nishida
   Multimedia Software Laboratory
   NEC USA Inc.
   110 Rio Robles,
   San Jose, CA 94086

   Phone: (408) 943-3030

   EMail: nishida@ccrl.sj.nec.com


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