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