Dynamic port configuration of network equipment

Technical field

The present invention pertains to an arrangement and a method for dynamic port configuration of network equipment for communication in a broadband network, specifically through the DHCP protocol server and in accordance with the present invention a central managing database.

Background art

During the past few years, broadband networks have grown steadily. A number of network elements, typically routers, switches, DSLAM (Digital Subscriber Line Access Multiplexer) and other types of equipment are utilized to provide broadband services.

Traditional dial-up services consist of a smaller number of centrally placed modem servers that an end-user or client/customer applies the telephone system to dial into. But with broadband networks, the equipment connecting the end-user has to be located much closer to the actual location of the end-user. This location is, for example, typically in the basement of an apartment building, or in a location within a few hundred meters of single-homes.

Each network element typically connects from 10 to 100 end-users at most. And this naturally means that there will be numerous network elements in any fairly large sized broadband network. This introduces a number of problems, like: <ul id="ul0001" list-style="dash"><li>The huge number of network elements should have similar configuration to make the administration of equipment easier.</li><li>The network elements require man-resources for administration and deployment.</li><li>End-users have different demands for quality and functionality, which leads to special configuration for some users.</li><li>Limitations in how network elements are maintained makes introduction of new services requiring additional configuration cumbersome.</li></ul>

These problems often lead to a lot of resources being spent on maintaining and adjusting network element configuration to cope with demands from customers. These problems are more readily understood through an example.

Assuming a network with 100,000 customers and network-elements with a typical port-density of 24 ports. If each customer is assigned one port there will be just over 4000 network elements in such a network.

Hereby, offering an Internet access service with two choices for connection speed (500kbit/s and 2000kbit/s) where the connection speed is configured on the port connecting to the customer. Off the shelf network equipment today requires that a network operator logs into network equipment, enters configuration mode and sets the port speed to whatever a customer has ordered. This naturally implies that when customers upgrade, downgrade, subscribe or unsubscribe from the service port configuration on the 4000 network elements, they have to be constantly updated. A port cannot be open unless there is an active subscriber, and the port must not be set to a port speed higher than what the subscriber is paying for.

If other services, requiring yet other configuration parameters, are available in the network, the complexity grows even more. When a customer calls in to order a service, the port where the customer is connected has to be identified. The appropriate configuration for the service has to be designed and then applied in the network. Configuring a specific network element has to be accomplished manually by a person. It is frequently a requirement of a network operator to maintain as few standardized configuration templates as possible to simplify the task of network administration.

Prior art provides that an end-user has to make a phone call to the broadband operator, and verbally ask for a new parameter setting. Thereby, the operator manually through, for example, a PC has to re-program the router in question for this new request changing the parameter settings for an end-user PC port. It is thus easily understood how huge workloads the operator staff can encounter, especially for end-users whose demands for dynamic parameter settings are frequent, and with regard to the possibility of having, as an example, 100 000 end-users in their broadband network.

Applying a customer specific configuration for each customer quickly grows out of proportion when it comes to keeping records about who got which configuration for what reason. This means that the introduction of new services or exceptions to the existing services can cause problems.

Several problems are thus issued, such as: <ul id="ul0002" list-style="dash"><li>Customer identification; where in the network is the customer located?</li><li>Configuration template identification; the configuration template for the service the customer subscribes to has to be identified.</li><li>Configuration template adjustment; the template typically has a few parameters that have to be adjusted such as e.g. customer network address, port speed settings, etc.</li><li>Configuration deployment; the network element connecting the customer has to receive new configuration parameters.</li></ul>

<patcit id="pcit0001" dnum="WO0244922A"><text>WO02/44922</text></patcit> discloses a method and system that allow subscribers to dynamically change their service level by communicating with the cable modem manager that manages their cable modems. The subscriber can begin employing the new service flows without reinitializing their cable modem or otherwise having their data service disrupted. However, this document only discloses updating of end-user equipment, not of network intermediate means.

<patcit id="pcit0002" dnum="WO9826530A"><text>WO98/26530</text></patcit> discloses a system, device and method for routing DHCP packets in a public data network wherein a relay agent inserts a source identifier into DHCP request packets. A server extracts the source identifier from the DHCP request packets and inserts the information into DHCP response packets. The relay agent uses the information to determine a destination for the DHCP response packets.

Summary of the described invention

An aim of the present invention is to solve problems mentioned and others related to configuration of network equipment in a broadband network. For this purposes the present invention sets forth an arrangement for dynamic port configuration of network equipment for communication in a broadband network. It thus comprises: <ul id="ul0003" list-style="none" compact="compact"><li>a network intermediate means connecting end-user equipment, having a MAC address, to the network through ports: <ul id="ul0004" list-style="none" compact="compact"><li>a means for activating a DHCP relay agent in the intermediate means;</li><li>a filter in the intermediate means filtering by capturing all broadcasted packets from end-user equipment to a DHCP server, packets from a network DHCP server and relay agent packets;</li><li>in the intermediate means the relay agent deploying remote-id and circuit-id relay options adding information to the packet about a unique MAC address of the end-user equipment and physical port where the packet is received, thus enabling the network DHCP server to uniquely identify, through the relay agent and port-id, to which intermediate means the end-user equipment is connected;</li><li>a central managing database reachable through the intermediate means and in connection with the DHCP server keeping templates with recordings of end-user service parameters for intermediate means port settings, thus enabling dynamic updating of port settings by conveying the parameter recordings from the database through a protocol means, recognizing the address to the intermediate means through a relay agent packet to the intermediate means and updating the parameter settings.</li></ul></li></ul>

In one embodiment it is provided that the intermediate means filter masquerades the DHCP server address when capturing packets by replacing it with the intermediate means address when communicating with end-user equipment, enabling the intermediate means to take the role of the DHCP server in responding to DHCP renewals even if the central DHCP server does not respond thereby increasing service availability.

Another embodiment enables the intermediate means to conceal the true DHCP server address, which increases network security, as the DHCP server becomes less exposed.

A further embodiment provides that a DHCP snooping feature enables the intermediate means capturing a packet, whereby options contained in the DHCP packet can be replaced by the intermediate means filter for the purpose of upholding a communication with the DHCP server by ensuring that the remote-id/circuit-id are actually delivered to the DHCP-server.

A still further embodiment provides that the original packet before being replaced is stored, thus when receiving a reply from the DHCP server, the intermediate means reinstalling original options before forwarding the reply to the end-user equipment.

Yet a further embodiment provides that the central management database is able to policy decisions including at least the following of them: <ul id="ul0005" list-style="none"><li>if an address is granted at all at this time; and</li><li>if configuration parameters should be installed in some other network element as a result of an end-user address request. Such configuration parameters, in one embodiment are at least one of the following: <ul id="ul0006" list-style="none"><li>packet filters;</li><li>rate-limiting;</li><li>packet priority processing; and</li></ul></li></ul> access control to multicast groups.

A further embodiment provides that information about an assigned IP address, learned through the DHCP, enables the intermediate means to inject a host route to the assigned address into its routing table. Thus, the host route can be announced by IGP (Interior Gateway Protocol) or EGP (Exterior Gateway Protocol) protocols to other routers, enabling them to learn a specific route to a local destination.

Yet a still further embodiment comprises that the parameter settings are enabling or disabling configuration at a specific date/time.

Yet another embodiment provides that the recordings in the management database record billing, security and other services that have been deployed to a customer at any given time.

A further embodiment comprises that the recordings determine the connection speed to the network at any given time.

Another embodiment comprises that an end-user equipment connects to the central managing database through an end-user interface to the templates in order to change parameter settings.

Furthermore, the present invention sets forth a method for dynamic port configuration of end-user equipment for communication in a broadband network. It thus comprises the steps of: <ul id="ul0007" list-style="none" compact="compact"><li>connecting end-user equipment, having a MAC address, through a network operator intermediate means having ports;</li><li>activating a DHCP relay agent residing in the intermediate means;</li><li>filtering in the intermediate means by capturing all broadcasted packets from end-user equipment to a DHCP server, packets from a network DHCP server and relay agent packets;</li><li>deploying in the intermediate means through the relay agent remote-id and circuit-id relay options adding information to the packet about a unique MAC address of the end-user equipment and physical port where the packet is received, thus enabling the network DHCP server to uniquely identify, through the relay agent and port-id, to which intermediate means the end-user equipment is connected;</li><li>keeping templates through a central managing database, reachable through the intermediate means in connection with the DHCP server, with recordings of intermediate means parameters for their physical port settings and deployed services, thus enabling dynamic updating of port settings by conveying the parameter recordings from the database through a protocol means, recognizing the address to the intermediate means through a relay agent packet to the intermediate means and updating the parameter settings.</li></ul>

Further method steps are set forth in the attached set of dependent method claims, which adhere to the mentioned embodiments of the present invention.

Brief description of the drawings

Henceforth reference is had to the following description taken in conjunction with the accompanying drawing, together with given examples and embodiments for a better understanding of the present invention, in which the single figure: <ul id="ul0008" list-style="none" compact="compact"><li>Fig. schematically illustrates an end-user connecting to a broadband network in accordance with the present invention.</li></ul>

Tables

The following tables are attached and found at the end of the present description, in which: <ul id="ul0009" list-style="none" compact="compact"><li><b>Table 1</b> depicts the DHCP message format and its field descriptors; and</li><li><b>Table 2</b> depicts the definition of its field descriptors.</li></ul>

Detailed description of preferred embodiments

In order to be able to communicate using the Internet Protocol a host has to have a set of parameters. This includes an unique IP address, a subnet mask of the subnet to which the host is connected, a default-gateway for communication outside the local subnet and optionally a name server address for translation between Internet names (<u style="single">www.packetfront.com</u>) and the corresponding IP address of a host. The Dynamic Host Configuration Protocol (DHCP) allows this configuration information to be assigned to a host at startup. An alternative is to have the configuration statically configured on the host.

The primary advantage of dynamically configuring these parameters is a simplified network administration, if renumbering is necessary the configuration is accomplished on the DHCP server and the host has to reboot to obtain new parameters, and thus a more efficient use of address space is accomplished. A host returns the address when disconnecting from the network meaning that the address immediately becomes available for assignment to another host.

DHCP consists of two components a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocation of network addresses to hosts.In addition to the basic configuration parameters described above, DHCP may also deliver additional configuration information to the host. One feature of the protocol is the use of a DHCP relay agent. A relay agent is a software program, for example, residing in a router, which supplements information in a DHCP packet and sends the packet from, for example, a router to the DHCP server.

In accordance with the present invention, the relay agent supplements information about remote-id and circuit-id before a packet is forwarded to the DHCP server. By utilizing the relay agent it is possible to centralize the DHCP server operation so that each physical subnet does not have to contain its own DHCP server. DHCP is built on a client-server model, where designated DHCP servers allocate network addresses and deliver configuration parameters to dynamically configured hosts. DHCP is working on the network layer in the OSI model.

The present information regarding DHCP has been collected from relevant DHCP RFC documents (Request For Comment documents). RFC is for the development of TCP/IP standards and controlled by the Internet Engineering Task Force (IETF).

There are three mechanisms for IP address allocation supported by DHCP: <ul id="ul0010" list-style="bullet"><li>Automatic allocation - A permanent IP address is assigned to the end-user by DHCP.</li><li>Dynamic allocation - An IP address with a limited lease time is assigned to the end-user.</li><li>Manual allocation - Allows a network administrator to assign a specific IP address to the end-user.</li></ul>

The format of DHCP messages is based on the format of BOOTP messages, to capture the BOOTP relay agent behavior which allows interoperability of existing BOOTP clients with DHCP servers. Utilizing BOOTP relay agents eliminates the necessity of having a DHCP server on each physical network segment. The Bootstrap Protocol (BOOTP) is explained in RFC951, Bootstrap Protocol. W.J. Croft, J. Gilmore. Sep-01-1985. Further information about the BOOTP can be extracted from updates by RFC1395, RFC1497, RFC1532, RFC1542. RFC documents can be retrieved from <u style="single">http://www.rfc-editor.org</u>.

The attached Table 1 depicts the DHCP message format, and the field descriptors are depicted through Table 2, both found at the end of the present description as described in RFC2131.

For a more detailed description regarding the DHCP message format it is referred to RFC 2131 - Dynamic Host Configuration Protocol.

In the interaction between an end-user and the DHCP server the following messages are used: <ul id="ul0011" list-style="bullet"><li>DHCPDISCOVER - Client broadcast to locate available servers.</li><li>DHCPOFFER - Server to client in response to DHCPDISCOVER with offer of configuration parameters.</li><li>DHCPREQUEST - Client message to servers either <ol id="ol0001" compact="compact" ol-style=""><li>(a) requesting offered parameters from one server and implicitly declining offers from all others,</li><li>(b) confirming correctness of previously allocated address after, e.g., system reboot, or</li><li>(c) extending the lease on a particular network address.</li></ol></li><li>DHCPACK - Server to client with configuration parameters, including committed network address.</li><li>DHCPNAK - Server to client indicating client's notion of network address is incorrect (e.g., client has moved to new subnet) or client's lease has expired</li><li>DHCPDECLINE - Client to server indicating network address is already in use.</li><li>DHCPRELEASE - Client to server relinquishing network address and cancelling remaining lease.</li><li>DHCPINFORM - Client to server, asking only for local configuration parameters; client already has externally configured network address.</li></ul>

The following is an example of a common prior art communication between an end-user (Host A) and a DHCP server. <tables id="tabl0001" num="0001"><table frame="none"><tgroup cols="3" colsep="0" rowsep="0"><colspec colnum="1" colname="col1" colwidth="40mm" /><colspec colnum="2" colname="col2" colwidth="23mm" /><colspec colnum="3" colname="col3" colwidth="25mm" /><thead><row><entry valign="top"><b>Host A</b></entry><entry valign="top" /><entry valign="top"><b>DHCP server</b></entry></row></thead><tbody><row><entry>DHCPDISCOVER ----→</entry><entry>Broadcast</entry>&lt;entry /&gt;</row><row>&lt;entry /&gt;<entry>Unicast ←----</entry><entry>DHCPOFFER</entry></row><row><entry>DHCPREQUEST ----→</entry><entry>Broadcast</entry>&lt;entry /&gt;</row><row>&lt;entry /&gt;<entry>Unicast ←----</entry><entry>DHCPACK</entry></row></tbody></tgroup></table></tables>

If more than one DHCP server is responding on an end-users DHCP discover packet, due to multiple DHCP server configuration, the client can request either one of the DHCP offers by answering with a DHCP request. But usually the client requests the IP address from the first DHCP offer packet that it receives.

Just because a DHCP server is offering an IP address to an end-user it is not assured that the client receives that address. The server could have offered the same IP address to more than one client, but usually the server reserves the offered IP address until the client has had a chance to respond.

If a server and client are on different physical subnets the DHCP requests and replies have to be relayed. Relay agents tamper with the header in the incoming DHCP request, changing the gateway IP address field, before forwarding the packet out on another interface towards the DHCP server. The DHCP Relay Agent information is available through RFC 3046 DHCP Relay Agent Information Option. M. Patrick. January 2001.

If a relay agent receives a packet with the gateway IP address field (within the header) containing 0.0.0.0, it is the closest relay agent to the client.

The DHCP relay agent is a DHCP option which has two sub-options: <ul id="ul0012" list-style="bullet"><li>Agent Circuit ID sub-option</li><li>Agent Remote ID sub-option</li></ul>

This sub-option may be added by DHCP relay agents, which terminate switched or permanent circuits. It encodes an agent-local identifier of the circuit from which a DHCP client-to-server packet was received. Agents in relaying DHCP responses back to the proper circuit intend it for use. Possible uses of this field include: <ul id="ul0013" list-style="bullet"><li>Router interface number</li><li>Switching Hub port number</li><li>Remote Access Server port number</li><li>Frame Relay DLCI</li><li>ATM virtual circuit number</li><li>Cable Data virtual circuit number</li></ul>

Servers may use the Circuit ID for IP and other parameter assignment policies. The Circuit ID should be considered an opaque value, with policies based on exact string match only; that is, the Circuit ID should not be internally parsed by the server. An opaque value is defined by that it should be left as it is, i.e., not be modified by an intermediate system.

The DHCP server should report the Agent Circuit ID value of current leases in statistical reports including its Management Information Base (MIB) and it logs. Since the Circuit ID is local only to a particular relay agent, a circuit ID should be qualified with the giaddr value, see tables, which identifies the relay agent.

This sub-option may be added by DHCP relay agents which terminate switched or permanent circuits and have mechanisms to identify the remote host end of the circuit. The Remote ID field may be used to encode, for instance: <ul id="ul0014" list-style="bullet"><li>a "caller ID" telephone number for dial-up connection</li><li>a "user name" prompted for by a Remote Access Server</li><li>a remote caller ATM address</li><li>a "modem ID" of a cable data modem</li><li>the remote IP address of a point-to-point link</li><li>a remote X.25 address for X.25 connections</li></ul>

The remote ID has to be globally unique.

DHCP servers may use this option to select parameters specific to particular users, hosts, or subscriber modems. The option should be considered an opaque value, with policies based on exact string match only; that is, the option should not be internally parsed by the server. The relay agent may use this field in addition to or instead of the Agent Circuit ID field to select the circuit on which to forward the DHCP reply (e.g., Offer, Ack, or Nak). DHCP servers should report this value in any reports or MIBs associated with a particular client.

The solution in accordance with the present invention provides that DHCP is used to deliver configuration information to the end-user (customers, clients) equipment (PC, host etc.) through an intermediate means, such as a router, switch or the like, parameter settings. The invention extends the use of remote-id and circuit-id options added to the DHCP packets to include identification of configuration parameters to be installed in an intermediate device (router or switch), thus enabling the network equipment connecting the end-user to the network to be dynamically configured with the service parameters required to provide the end-user with its selected service whenever the end-user connects its host to the network.

For a more comprehensive understanding of the present description, the network element or intermediate means connecting the end-user/client is referred to as an Access Switch Router (ASR) but the present invention itself is not limited only to such a device.

The attached single Fig. schematically illustrates a traffic path in a network 10 arrangement in accordance with the present invention. It depicts typical equipment e.g. a PC 12, TV-set 14, telephone 16 connected to a residential broadband network 10. A double pointed arrow indicates the direction of signaling and data traffic. In this example with three devices 12, 14, 16 connected to one end-user equipment port, a switch 18 directs data traffic to an ASR 20.

Moreover, the residential network 10 has a connection (not shown) to other networks such as Internet 22. Further depicted in the Fig. is the DHCP server 24, which is in connection with a central management database 26, in accordance with the present invention, storing templates with records containing parameter settings for end-user equipment ports in the ASR 20.

In the following, one embodiment in accordance with the present invention, involving the PC 12 requesting an IP address, is described with reference to the attached Fig. Single broken line arrows with reference numerals indicate the steps taken in order to receive an IP address and a correct ASR 20 parameter setting in accordance with the present invention.

Client/end-user/customer requests 100 an IP address through his PC 12 by broadcasting the request (DHCP). An ASR 20 filter in accordance with the present invention captures/ snoops/intercepts it. The ASR 20 filter DHCP relay options identifies 110 the end-user equipment MAC-address and port-id 12 and conveys the IP address request to the DHCP server 24. Hence in accordance with the present invention, the DHCP server 24 is connected to a central management database 26, storing templates with parameter settings for the ASR 20 port connecting to the end-user. Parameters can be of the type which services are requested by the end-user, broadband connection speeds e.g. 500 kbit/sek or 2000 kbit/sek, time periods settings for different services, for example different connection speeds related to day and night communication etc.

The filter in accordance with the present invention resides in the ASR or other equipment making up an intermediate means, whereby it monitors all traffic to and from it and captures all packets from the UDP port 68 and/or to the UDP port 67 (UDP, User Datagram Protocol). These ports are defined as standards in DHCP.

Prior art provides that the end-user has to make a phone call to the broadband operator, and verbally ask for a new parameter setting. Thereby, the operator manually through, for example, a PC has to re-program the ASR 20 for this new request changing the parameter settings for the end-user PC 12 port. It is thus easily understood how huge workloads the operator staff can encounter, especially for end-users whose demands for dynamic parameter settings are frequent, and with regard to the possibility of having, as an example, 100,000 end-users in their broadband network.

The DHCP server 24 checks the central management database 26 for a template with parameter settings that match the specific end-user and its equipment 12, 14, 16, and the database 26 locates the end-users services. After completing the match, the database returns information to the DHCP server 24, which responds to the end-user equipment (PC 12). When the ASR 20 intercepts the DHCP offer to the client, it contacts the central database 26 through a suitable protocol such as COPS (Common Open Policy Server) and/or FTP (File Transfer Protocol) to request configuration for the end-user port. The database sends a dynamic configuration to the ASR 20 and its filter, whereby the port settings for the end-user equipment 12 is set in accordance with the dynamic configuration of the present invention. The PC 12 now having an IP address and parameter settings as once requested through the template in the database 26 and establishes communication, for example with the Internet 22.

The database 26 templates can be changed or updated on end-user preferences whenever wanted, for example, by accessing the database 26 and bring about the template on the PC 12 screen and fill out a template form for new settings. This end-user database communication can take place through the Internet.

One embodiment of the present invention sets forth an arrangement for dynamic port configuration of network equipment for communication in a broadband network. The arrangement comprises a network intermediate means 20, for example, an ASR connecting end-user equipment 12, 14, 16, which has a MAC address, to the network through ports 21. It also comprises a means for activating a DHCP relay agent in the intermediate means, and a filter in the intermediate means filtering all broadcasted packets from end-user equipment to a network DHCP server and/or vice versa by capturing them.

In the intermediate means 20, the relay agent deploys remote-id and circuit-id relay options adding information about a unique MAC address of the end-user equipment and physical port, where the packet is received, to the packet. Hence, enabling the network DHCP server to uniquely identify, through the port-id, where the end-user equipment is situated in the network.

Furthermore it comprises a central managing database 26 reachable through the end-user equipment 12, 14, 16 and in connection with the DHCP server keeping templates with recordings of end-user equipment parameters for their physical port settings and deployed services. This enables dynamic updating of port settings by conveying the parameter recordings from the database 26 through a protocol means, recognizing the address to the intermediate means through the relay agent packet, to the intermediate means 20.

In the solution in accordance with the present invention, the ASR filters all User Datagram Protocol packets (UDP packets), as mentioned, are destined for UDP port 67 and 68. This allows the ASR to capture - or snoop - all DHCP packets between the end-user and the central DHCP server. The ASR is designed to work as a relay agent using the remote-id and circuit-id relay agent options to add information about the unique ethernet MAC-address of the source and physical port (interface) where the DHCP packet was received. This enables the central DHCP server to uniquly identify the end-user. The port-id is unique in the network because only that port exist on only one ASR. The MAC address is world unique, but if forged, it is still unique on that particular port.

By additional features in the DHCP snooping algorithm and the central DHCP server system in accordance with the present invention, it is possible to address other issues of updating network element configuration with customer specific parameters based on configuration templates stored at a central location 26. Such a configuration template may be unique for a single customer, or may be used to provide a common service to a great number of customers.

Important for this solution is that the configuration template is administrated in one central system and deployed into the network by computer control at the moment when the customer connects to the network (by requesting a network address).

The solution as a whole thereby solves the issues of uniquely identifying the customer, the customer location in the network, the configuration to be applied, the modifications to that configuration necessary for the individual customer and the deployment of the configuration to the appropriate network element(s) in the network.

In addition to standard relay agent operation, with relay agent options as described, the ASR DHCP snooping enables the following features.

It enables a feature, which accomplishes it to masquerade the DHCP server address and replace it with the ASR address in the communication with the end-user. This enables the ASR to take the role of the DHCP server in responding to DHCP renewals even if the central DHCP server does not respond thereby increasing service availability. It further enables the ASR 20 to conceal the true DHCP server address which increase network security as that system becomes less exposed.

The information about an assigned IP addresses enables the ASR 20 to inject a host route to the assigned address into its routing table. This host route can then be announced by IGP or EGP protocols to other routers, enabling them to learn a specific route to the local destination. IGP and EGP are Internet protocols for exchanging routing information within and between autonomous systems.

If there are one or multiple forwarder(s) between the requesting end-user and the ASR, the DHCP snooping feature will still enable the ASR to intercept the packet. Any options contained in the DHCP packet can be replaced by the ASR for the purpose of upholding a communication with the DHCP server by securing that the remote-id/circuit-id are actually delivered to the DHCP-server. When the reply is received the ASR can reinstall the original options (kept from the original packet) before forwarding the reply to the end-user.

This feature is particularly useful, but not limited to, when the relay agent option is already present in the DHCP packet from the end-user. An intermediate device may have added the information with-or-without purpose, but the ASR feature intervenes and ensures that the correct circuit-id and remote-id information is sent to the DHCP server.

The central management system is also able to make a number of policy decisions including but not limited to the following: <ul id="ul0015" list-style="dash"><li>If address is granted at all at this time.</li><li>If configuration parameters should be installed in some other network element as a result of this end-user address request.</li></ul>

Such configuration parameters can be, but are not limited to the following: <ul id="ul0016" list-style="dash"><li>Packet filters.</li><li>Rate-limiting.</li><li>Packet priority processing.</li><li>Other configuration parameters such as access control to multicast groups (i.e. controlling which multicast groups the particular end-user on the particular port is allowed to join)</li></ul>

By maintaining information about assigned addresses in the database, the central management system can, based on this knowledge, dynamically reconfigure network elements in a timely fashion as required, for instance, enabling or disenabling configuration at a specific date/time. It also enables the network management system to keep track of, for billing, security and other purposes, which services that have been deployed to which customer at any given time.

Although the advantages of the present invention have been described through given examples and embodiments, it is not limited to those. The attached set of claims provides further embodiments for a person skilled in the art.

Tables

<tables id="tabl0002" num="0002"><img file="EP1540885B1_D0001.tif" /></tables><tables id="tabl0003" num="0003"><table frame="all"><title><u style="single">Table 2.</u></title><tgroup cols="2"><colspec colnum="1" colname="col1" colwidth="18mm" /><colspec colnum="2" colname="col2" colwidth="148mm" /><thead><row><entry valign="top">FIELD</entry><entry valign="top">DESCRIPTION</entry></row></thead><tbody><row><entry>op</entry><entry>Message opcode/message type 1- BOOTREQUEST, 2 - BOOTREPLY</entry></row><row><entry>htype</entry><entry>Hardware address type, se ARP section in "Assigned Numbers" RFC; (e.g. '1'=10mb Ethernet)</entry></row><row><entry>hlen</entry><entry>Hardware address length (e.g. '6' for 10mb Ethernet)</entry></row><row><entry>hops</entry><entry>Client sets to zero, optionally used by relay agents when booting via a relay agent.</entry></row><row><entry>xid</entry><entry>Transaction ID, a random number chosen by the client, used by the client and server to associate messages and responses between them.</entry></row><row><entry>Secs</entry><entry>Set by the client; Seconds elapsed since client began address acquisition or renewal process.</entry></row><row><entry>Flags</entry><entry>Flags (not shown)</entry></row><row><entry>Ciaddr</entry><entry>Client IP address; only filled in if client is in BOUND, RENEW or BINDING state and can respond to ARP request.</entry></row><row><entry>Yiaddr</entry><entry>'Your' (client) IP address</entry></row><row><entry>Siaddr</entry><entry>IP address of next server to use in bootstrap; returned in DHCPOFFER and DHCPACK by server.</entry></row><row><entry>Giaddr</entry><entry>Relay agent IP address, used in booting via a relay agent.</entry></row><row><entry>Chadder</entry><entry>Client hardware address</entry></row><row><entry>Sname</entry><entry>Optional server host name, NULL terminated string</entry></row><row><entry>File</entry><entry>Boot file name, null terminated string; "generic" name or NULL in DHCPDISCOVER, fully qualified directory path name in DHCPOFFER</entry></row><row><entry>Options</entry><entry>Optional parameters field.</entry></row></tbody></tgroup></table></tables>