Abstract:
The Dynamic Host Control Protocol (DHCP) is a text-based protocol that functions over the Internet Protocol layer. The main use for this protocol is to configure rebooting networking equipment. DHCP servers can assign dynamic IP addresses to DHCP clients from a pool of addresses, or can assign static addresses manually assigned by network administrators. Along with its assigned IP address, a DHCP client is subject to receive a plethora of other useful configuration information. DHCP information, called options in DHCP lore, are typically registered with the IANA (Internet Assigned Numbers Authority), and can have virtually any format for their data field. The present invention describes a generic way of adding new options of a DHCP client by specifying the data type for the option. This allows easy customization of DHCP clients. Typical examples of this optional information are the local subnet mask and the local router&#39;s IP address.

Description:
FIELD OF THE INVENTION  
         [0001]    The present invention relates to Dynamic Host Control Protocol (DHCP). More specifically, the present invention is concerned with a generic method for customization of DHCP options.  
         BACKGROUND OF THE INVENTION  
         [0002]    The Dynamic Host Control Protocol (DHCP) is a well-known text-based protocol that functions over the Internet protocol layer. DHCP allows to configure networking equipment, and to assign dynamic IP addresses from a pool of addresses to DHCP clients. Alternatively, DHCP may allow network administrators to assign static addresses manually. Clients can thus identify themselves using a unique key, for example, the MAC (Media Access Control) address, which is a globally assigned number for all network-enabled hardware devices.  
           [0003]    Along with its assigned IP address, a DHCP client is subject to receive other useful configuration information. Most of the DHCP information, called options in DHCP lore, is registered with the IANA (Internet Assigned Numbers Authority).  
           [0004]    [0004]FIG. 1 of the appended drawings illustrates the typical DHCP message structure, as defined by the IANA. The lengths, in bytes, of the fields  12  of the static structure  10  illustrated in FIG. 1 are found in parentheses.  
           [0005]    The standard format of DHCP options, which can be found in the “options” field  14  on FIG. 1, is illustrated in FIG. 2.  
           [0006]    The options field  14  of the DHCP message  10  contains the various options required for the session, as stored by an IP application. Typically, the client can ask for specific options, and normally, servers are pre-configured to give out specific options as well.  
           [0007]    The options field  14  of a DHCP message includes three subfields: a “code” subfield  16 , a “len” subfield  18 , and a data subfield  20 .  
           [0008]    The code subfield  16  identifies the options and is one byte long (as is indicated in parentheses). Possible “code” values therefore lie in the range [0, 255]. Such values are also known as “opcodes”.  
           [0009]    In particular, the options identified by the values 0 and 255 are respectively “Pad” and “End” options. These two DHCP options are exceptions, as they do not have the typical structure of DHCP options. The “Pad” and “End” options facilitate encoding and decoding of DHCP options in a DHCP message. Since these two options are believed to be well known in the art, they will not be described herein in further detail.  
           [0010]    Furthermore, as it is commonly known in the art, the options identified by opcodes ranging in [1, 127] are dedicated to IANA assignations. It is to be noted that most of these assignations are already predetermined. On the contrary, the range [128, 254] is unassigned and cannot be assigned through the IANA. Opcodes in this range are called site-specific opcodes, and are purely application specific. Any application may customize any of these opcodes. Lastly, the opcode  43  identifies the vendor-specific option.  
           [0011]    An example of a DHCP option assigned by the IANA is the option specifying the subnet mask, identified by the opcode  1 . This option is in the form of an IP address and its length is therefore set to 4 bytes.  
           [0012]    [0012]FIGS. 3 and 4 respectively illustrate the vendor-specific ( 43 ) and site-specific ([128, 254]) options structures  22  and  24 .  
           [0013]    As can be seen by comparing FIGS. 3 and 4 to FIG. 2, the structures of the vendor-specific  22  and site-specific options  24  have generally the same format as an IANA designated DHCP option  14 . However, the format of their “data” fields, respectively  26  and  28 , are application-specific, i.e. it can be specified by the application requiring the DHCP client.  
           [0014]    Indeed, since the format of data fields  26 - 28  are not defined by IANA, any format required by the IP application using a DHCP client may be chosen for these fields. However, as an implicit convention in the art, the vendor-specific and site-specific options are encoded in a DHCP message as a sequence of code/length/data fields, identical in syntax to the other DHCP option fields (see FIG. 2).  
           [0015]    The site and vendor specific options  22 - 24  allow extending the possibility of the DHCP. However, since their format and content may vary depending on the IP application that requires them, these options require rewriting a code from one application to another in order to interpret the content of the corresponding option fields.  
           [0016]    For example, Internet Protocol (IP) telephony products, and more specifically, network-enabled embedded devices, such as the Mediatrix 1124 from Mediatrix Telecom Inc., rely on DHCP information for configuration in accordance to the local network.  
           [0017]    Generally, different software applications running in such devices or other similar devices requires different implementations of their DHCP option retrieval methods. This can be seen as a drawback, since each time it requires rewriting code to parse and create DHCP option fields.  
         SUMMARY OF THE INVENTION  
         [0018]    More specifically, in accordance with the present invention, there is provided a method for customization of Dynamic Host Control Protocol (DHCP) options, the method comprising:  
           [0019]    providing a library of data types; and  
           [0020]    defining a DHCP option as an optionrule; the optionrule including an opcode identifying the DHCP option, and at least one datarule; the at least one datarule including one of one of the data types and an optionrule.  
           [0021]    According to a second aspect of the present invention, there is further provided a method for configuring an Internet Protocol (IP) application to use Dynamic Host Control Protocol (DHCP) options, the method comprising:  
           [0022]    providing a library of data types;  
           [0023]    registering a list of opcodes to be used by the IP application;  
           [0024]    each of the opcodes identifying a DHCP option; and  
           [0025]    registering optionrules corresponding to the opcodes; each of the optionrules including an opcode identifying the DHCP option, and at least one datarule; the at least one datarule being defined by one of one of the data types and an optionrule.  
           [0026]    According to a third aspect of the present invention, there is also provided a method for communicating Dynamic Host Control Protocol (DHCP) messages between a DHCP server and an Internet Protocol (IP) application, the method comprising:  
           [0027]    a) accessing a library of data types;  
           [0028]    b) upon sending a DHCP message from the IP application to the DHCP server:  
           [0029]    retrieving an option list including options to encode and an opcode for each of the options;  
           [0030]    for each of the opcodes:  
           [0031]    b)i) retrieving an optionrule corresponding to the current opcode; the optionrule including at least one datarule; the at least one datarule being defined by one of one of the data types and an optionrule;  
           [0032]    b)ii) retrieving data corresponding to each of the options in the option list; and  
           [0033]    b)iii) encoding, in the DHCP message to send, each of the retrieved data in a DHCP options field identified by the opcode, by interpreting the optionrule using the datarule and the library of data types; and  
           [0034]    c) upon receiving a DHCP message to the IP application from the DHCP server:  
           [0035]    retrieving in the received DHCP message, a list of opcodes to decode;  
           [0036]    for each of the opcodes in the opcode list:  
           [0037]    c)i) retrieving an optionrule corresponding to the current opcode; and  
           [0038]    c)ii) for each optionrule, decoding in the received DHCP message data corresponding to the opcode, by interpreting the optionrule using the datarule and the library, yielding decoded DHCP data.  
           [0039]    Other objects, advantages and features of the present invention will become more apparent upon reading the following non restrictive description of preferred embodiments thereof, given by way of example only with reference to the accompanying drawings. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0040]    In the appended drawings:  
         [0041]    [0041]FIG. 1, which is labelled “prior-art”, is a schematic view illustrating a DHCP message structure;  
         [0042]    [0042]FIG. 2, which is labelled “prior-art”, is a schematic view illustrating a DHCP option structure in the DHCP message of FIG. 1;  
         [0043]    [0043]FIG. 3, which is labelled “prior-art”, is a schematic view illustrating the vendor-specific option field in the DHCP message of FIG. 1;  
         [0044]    [0044]FIG. 4, which is labelled “prior-art”, is a schematic view illustrating the site-specific data field structure in the DHCP message structure of FIG. 1;  
         [0045]    [0045]FIG. 5 is a flowchart illustrating a method for customization of DHCP options, according to an embodiment of the present invention;  
         [0046]    [0046]FIGS. 6 a - 6   c  are schematic views illustrating examples of option rules according to embodiments of the present invention;  
         [0047]    [0047]FIG. 7 is a flowchart illustrating a method for configuring an IP application for using DHCP options, according to an embodiment of the present invention; and  
         [0048]    [0048]FIG. 8 is a flowchart illustrating a method for communicating DHCP messages between an IP application and a DHCP server during a DHCP session, according to an embodiment of the present invention. 
     
    
     DESCRIPTION OF THE PREFERRED EMBODIMENT  
       [0049]    Turning now to FIG. 5 of the appended drawings, a method  100  for customization of DHCP options for an IP application, according to a first aspect of the present invention, is illustrated.  
         [0050]    Generally stated, the method  100  consists in performing the following steps in sequence:  
         [0051]    [0051] 102 —providing a library of data types;  
         [0052]    [0052] 104 —defining each DHCP option as an optionrule; and  
         [0053]    [0053] 106 —storing the optionrule in an option field of a DHCP message.  
         [0054]    Each of these steps will now be described in further detail.  
         [0055]    In step  102 , a library of basic data types is provided. As will be explained in more detail hereinbelow, these data types will be used as atomic data items to characterize the data element in data subfields  20 ,  26  and  28  in a DHCP message (see FIGS. 2,3 and  4 ).  
         [0056]    A library of data types is advantageous because some data types in the DHCP specification are redundant. Examples of such redundant data are IP addresses in numeric or doffed string form, token strings that need to be matched, integer values, etc.  
         [0057]    The following is an example of a library of data types according to an embodiment of the present invention, in the Augmented Backus-Naur Form (ABNF):  
         [0058]    Dhcp Option=OptionRule  
         [0059]    OptionRule=Opcode [Length *DataRule ] 
         [0060]    Length=(0×00−0×FF)  
         [0061]    Opcode=(0×00−0×FF)  
         [0062]    DataRule=(TerminalType|OptionRule)  
         [0063]    TerminalType=(Bool|Byte|Dword|Word|MultipleBool|MultipleByte|MultipleDword|MultipleWord|VarLenIntegerString|IpAddr|DottedIpAddr|MultipleIpAddr|String|VarLenString|TokerString|ExtensionItem)  
         [0064]    Bool=(0×00|0×01)  
         [0065]    Byte=(0×00−0×FF)  
         [0066]    Dword=(0×00000000−0×FFFFFFFF)  
         [0067]    Word=(0×0000−0×FFFF)  
         [0068]    MultipleBool=2*Bool  
         [0069]    MultipleByte=2*Byte  
         [0070]    MultipleDword=2*Dword  
         [0071]    MultipleWord=2*Word  
         [0072]    VarLenIntegerString=1*10(DIGIT)  
         [0073]    IpAddr=(0×00000000−0×FFFFFFFF)  
         [0074]    DottedIpAddr= 3 (1*3DIGIT “.”)1*3DIGIT  
         [0075]    MultipleIpAddr=2*IpAddr  
         [0076]    String=1*n(CHAR)  
         [0077]    VarLenString=1*(CHAR)  
         [0078]    TokenString=String (The token is specified and must be matched exactly)  
         [0079]    ExtensionItem=New data type.  
       EXAMPLE OF A LIBRARY OF DATA TYPES  
       [0080]    The above example of library data types shows that even complex data items can be decomposed into a number of simpler data items.  
         [0081]    Obviously, other data types may be defined in the library depending on the requirements of the IP application.  
         [0082]    In the following, a data type will be said to be terminal if it can be used directly to encode/decode information in a DHCP message.  
         [0083]    Of course, the IP application is advantageously provided with a DHCP client that is configured with instructions for translating the data types, so as to encode/decode DHCP information in the data subfield of a DHCP option.  
         [0084]    The concepts of datarule and optionrule will now be described.  
         [0085]    A datarule is used to indicate to an appropriately configured DHCP client a rule allowing to encode and decode an atomic item. Each datarule characterizes one or more data items in a DHCP option and includes the type of the data items (for example, a byte, an integer, a string of characters, etc.) as defined in the library.  
         [0086]    Indeed, a great deal of diverse information may be associated with a DHCP option, especially with vendor-specific and site-specific options. A datarule is advantageously associated with each complete information required by a DHCP option. Since such complete information may include more than one element of information, a datarule may include one or more data items, globally resulting in one of the information required by a DHCP option.  
         [0087]    In addition to the type of the data items, a datarule may also include other typical characteristics of data items in a DHCP option. Examples of these characteristics are: mandatory status (must this data item be absolutely present for the option to be valid?), the maximum/minimum/fixed length of the data field, or a predetermined value to find for this data item (for example, must equal “1” or a certain character string). For example, to represent a Datarule that must be equal to the string “Mediatrix”, we would create a datarule with the type TokenString (see the above example of library of data types) and assign “Mediatrix” to the token. When decoding, the library will then look for the specific word “Mediatrix”. Of course, other characteristics may also be used.  
         [0088]    Other types of information may also optionally be present in a datarule to help with other tasks related to the encoding and decoding of the DHCP option. For example, a unique identificator can be included for the data item. This identificator is to be used with a separate mechanism, implemented in the IP application, for retrieving the data to encode and store the data that was parsed. That identificator would also uniquely identify a database item that would be the decoded value for the datarule, which can be used by the IP enabled application. The IP enabled application is configured to access the decoded information by knowing the identificator that was assigned to the datarule. Similarly, for encoding, the application sets the value in the database using the identificator, and the encoding entity (the code library) gets the value from the database before encoding it.  
         [0089]    The DHCP protocol states that more than one DHCP server can answer a DHCP client&#39;s request (the DHCP client&#39;s request is typically broadcasted over the local network). In that case, the client uses an application-specific algorithm to choose which server the DHCP client will acknowledge. A typical way of doing this is to assign a value to every DHCP option that is found in the server&#39;s response, and then select the server that best suits the client&#39;s needs. This can be easily achieved by extending a datarule to contain not only an identificator that maps it to a database, but also a value for this datarule&#39;s presence in the DHCP message. For example, the assigned IP address would have a higher presence value than the subnet mask, and so if having to choose between these two messages, a DHCP client would chose the IP address. The server&#39;s proposal can be weighed by the total of its datarule&#39;s values. The assigned value will also be referred to herein as a server-choosing algorithm identificator.  
         [0090]    An optionrule includes an opcode identifying the DHCP option, and at least one datarule specifying the format of the optionrule data field.  
         [0091]    Optionally, an optionrule includes other information such as mandatory state and a server-choosing algorithm identificator.  
         [0092]    In some cases, an optionrule may be considered invalid, and therefore unusable, if one of its datarules is invalid.  
         [0093]    [0093]FIGS. 6 a  and  6   b  illustrate two examples of implementation of the method for customization of DHCP options according to a preferred embodiment of the present invention.  
         [0094]    A first example is given in FIG. 6 a . The optionrule  108  for the subnet option, corresponding, according to IANA, to the opcode  3 , is illustrated. As can be seen in FIG. 6 a , the optionrule  108  includes the opcode value 3 (reference number  110 ), and a single datarule  112 , which specifies in this particular case that the type of data expected for the subnet option is IpAddr, as defined in the library provided in step  102 . This data type corresponds to an IP address in digital format.  
         [0095]    A second example is illustrated in FIG. 6 b . In this example, the optionrule  114  for the message type, corresponding to the opcode  53 , is illustrated. As can be seen in FIG. 6 b , the optionrule  114  includes the opcode value 53 (reference number  116 ), and a single datarule  118 , which specifies here that the type of data expected for the message type is byte, as defined in the library provided in step  102 . Expected values for this optionrule are defined in the DHCP standard.  
         [0096]    As can be seen from the above two examples of optionrules, optionrules and datarules may advantageously be used to encode and decode DHCP options defined and assigned by IANA, in addition to vendor and site-specific options.  
         [0097]    Since the DHCP subnet and message type options are believed to be well known in the art, they will not be described herein in further detail.  
         [0098]    As can be seen in the above example of library (step  102 ), the optionrule is advantageously defined as a data type. Considering the optionrule as an atomic item advantageously allows to create optionrules in which the data field is composed of one or more optionrules as in the vendor-specific option. Thus, the optionrule may become a basic type that can be used to specify datarules. In that case, in contrast with other basic types of datarules, optionrules that are used as a basic type of a datarule does not have an associated database identificator, since they are not used to map directly to one single data item.  
         [0099]    A further example of an optionrule will now be presented. FIG. 6 c  of the appended drawings illustrates an example of an optionrule that includes a data field composed of optionrules.  
         [0100]    The optionrule  120  includes the opcode value 43 (reference number  122 ), corresponding to a vendor-specific option.  
         [0101]    The optionrule  120  further includes two datarules  124  and  126 , each defining the expected data type as being optionrules. thus, this example illustrates a possible implementation of the vendor-specific option allowing to decode/encode optionrules corresponding to site-specific options corresponding to both the opcodes  129  and  152  (respectively labelled  128  and  130 ).  
         [0102]    The optionrules labelled  128  includes the datarules labelled  132  defining the expected value for the corresponding option as being defined by an IP address (type IpAddr in the library), while the optionrules labelled  130  includes the datarules labelled  134  defining the expected value for the corresponding option as being defined as a byte.  
         [0103]    It is to be noted that the datarules  124  and  126  in the optionrule  120  are not terminal since they define the expected values for this data field as being optionrules. The two datarules  132  and  134  are, however, terminal.  
         [0104]    As illustrated in the above examples, datarules and optionrules are used for specifying the format, and optionally the container for the encoded/decoded data.  
         [0105]    As stated hereinabove, the DHCP client that is used to encode and decode the DHCP options is configured so as to use the above-described library of data types to encode and decode optionrules according to the present invention.  
         [0106]    The library advantageously includes sufficiently flexible data types for the datarules so that the DHCP client should not require any changes from one application to another.  
         [0107]    Accordingly, to handle new DHCP options, appropriate datarules are created and associated to an optionrule for a particular purpose of the IP application.  
         [0108]    Thus, the present invention allows customization of DHCP clients by providing a generic way of adding new DHCP options by pre-defining the data types for the options In accordance with this design, any user of the DHCP client is enabled to change the list of supported DHCP options, and to redefine vendor and site-specific data field formats to suit their application&#39;s needs.  
         [0109]    The method for customization of DHCP options, according to the present invention, is advantageously based on a reusable code, therefore avoiding the writing of an unnecessary code in order to parse and/or create DHCP options. Moreover, the method provides a means to express more complex DHCP options without any changes in the core source code.  
         [0110]    Turning now to FIG. 7, a method for configuring an IP application for using DHCP options, according to a second aspect of the present invention, is illustrated.  
         [0111]    It will be apparent that the method  200  of FIG. 7 is implemented in a computer system (not shown) in the form of hardware or software. More specifically, the method is advantageously implemented in the context of a DHCP client (not shown).  
         [0112]    Indeed, in addition to the IP application, the computer system advantageously includes a DHCP client in order to communicate DHCP messages to a DHCP server.  
         [0113]    The computer system, IP application and DHCP client may all be in the form of a single IP product, for example, a network-enabled embedded device, such as an Internet phone adapter. The Mediatrix 1124 from Mediatrix Telecom Inc. is an example of such an IP product.  
         [0114]    Since a DHCP client and a DHCP server are believed to be well known in the art, and for concision purposes, they will not be described herein in further detail.  
         [0115]    Generally stated, the method  200  consists in performing the following steps:  
         [0116]    [0116] 202 —initializing the IP application;  
         [0117]    [0117] 204 —providing a library of data types;  
         [0118]    [0118] 206 —registering the list of opcodes to be used by the IP application; and  
         [0119]    [0119] 208 —registering optionrules corresponding to the opcodes.  
         [0120]    Obviously, before configuring the IP application to use DHCP options, the IP product or IP application has to boot.  
         [0121]    Each of the steps of method  200  will now be described in greater detail.  
         [0122]    In step  202 , the IP application is initialized. Step  202  advantageously includes: initialization of the IP stack (to prepare to send DHCP messages) and other non-DHCP related bootup tasks such as provisioning, etc.  
         [0123]    As will be explained hereinbelow, the method  200  makes use of the concept of datarules and optionrules, as described hereinabove, and as is obvious, also makes use of the library of data types. Therefore, the pre-defined library of data types is provided so as to be accessed by the DHCP client. In step  204 , the library is either stored in a Random Access Memory (RAM) of the system or is pre-programmed into the system.  
         [0124]    Of course, the library of data types defines data types necessary to encode and decode the DHCP options required by the IP application and is therefore compatible with it.  
         [0125]    Obviously, step  204  may be included in the initialization step  202 .  
         [0126]    In step  206 , the list of opcodes to be used by the IP application is registered. Similarly to the library of data types, the opcode list is made available to the DHCP client. A correspondence table is advantageously provided to associate opcode values to corresponding DHCP options. Alternatively, a list of options may directly be provided.  
         [0127]    It is to be noted that the expression “registering” will be used herein as the action of making the corresponding information available to the IP application and/or to the DHCP client.  
         [0128]    The list of opcodes is previously stored in the system that includes the IP application, or is alternatively pre-programmed in the IP application code. The opcode may also be selected from a more thorough list using, for example, a user interface. This advantageously allows easy configuration of the IP application according to, for example, user preferences. Where the IP application is implemented in software form in a computer system, a conventional menu list may be used by the user of the IP application to select appropriate DHCP options.  
         [0129]    In step  208 , optionrules corresponding to the opcodes registered in step  206  are registered. In addition to an identifying opcode, each optionrule includes at least one datarule, as explained hereinabove.  
         [0130]    Attention is drawn to the fact that the method  200  advantageously allows the DHCP client (and thus the IP application) to be configured to encode and decode DHCP messages.  
         [0131]    Turning now to FIG. 8 a method  300  for communicating DHCP messages between an IP application and a DHCP server during a DHCP session, according to a further aspect of the present invention, is illustrated.  
         [0132]    Generally stated, the method  300  consists in performing the following steps:  
         [0133]    upon sending a DHCP message from the IP application to the DHCP server  
         [0134]    [0134] 302 —providing an option list, including an opcode for each of the options in the list;  
         [0135]    for each of the opcodes:  
         [0136]    [0136] 304 —retrieving an optionrule corresponding to the opcode;  
         [0137]    [0137] 306 —retrieving datarules related to the retrieved optionrule; and  
         [0138]    [0138] 308 —encoding, in the DHCP message to send, each of the datarules, by interpreting the optionrule, using the library of data types; and  
         [0139]    upon receipt of a DHCP message from the DHCP server to the IP application:  
         [0140]    [0140] 310 —retrieving, in the received DHCP message, a list of opcodes to decode;  
         [0141]    [0141] 312 —for each opcode in the list, retrieving an optionrule corresponding to the opcode that needs to be decoded; and  
         [0142]    for each optionrule:  
         [0143]    [0143] 314 —decoding, in the received DHCP message, data corresponding to the opcode, by interpreting the optionrule using the library; and optionally  
         [0144]    [0144] 316 —storing the decoded data.  
         [0145]    As with the configuration method  200  described hereinabove, the DHCP client (and thus the IP application) has access to the library of data types for the communication method  300 .  
         [0146]    Each of the steps of the method  300  will now be described in further detail.  
         [0147]    As can be seen in FIG. 8, the method  300  may actually be divided into two methods: a method for encoding a message to be sent by the IP application to a DHCP server ( 302 - 308 ), and a method for decoding a DHCP received by the application from the DHCP server ( 310 - 316 ).  
         [0148]    Although each of these two processes uses the library of data types, optionrules and datarules, they may be executed independently.  
         [0149]    Steps  302 - 308  concern the encoding DHCP options upon the IP application sending a DHCP message to the. DHCP server.  
         [0150]    In step  302 , a list of options is provided for encoding. As has been discussed hereinbelow, the list of opcodes is preferably provided to the DHCP client during the configuration process  200 , but it can also be provided before encoding the options.  
         [0151]    The list of options also includes a corresponding opcode value for each option. It is to be noted that options are uniquely identified by their opcode.  
         [0152]    Steps  304 - 308  are performed for each opcode.  
         [0153]    In step  304 , an optionrule corresponding to the current opcode is retrieved. As discussed hereinabove, the optionrule includes at least one datarule defined by either of the data types or an optionrule.  
         [0154]    In step  306 , the data related to the corresponding options is also retrieved.  
         [0155]    The list of opcodes, the optionrules and the data may have been previously stored in the system that includes the IP application (or in a memory of the IP product). Alternatively, it is included in the IP application code. The opcode list may also be selected from a more thorough list using, for example, a user interface. Providing the opcodes, a table of correspondence may provide the corresponding optionrule and data.  
         [0156]    The retrieved data is then encoded in the DHCP message to be sent by interpreting the optionrules using the library of data types (step  308 ).  
         [0157]    The second method comprised in method  300  is described through steps  310 - 316 . It concerns the decoding of DHCP options upon the IP application&#39;s receipt of a DHCP message from the DHCP.  
         [0158]    In step  310 , a list of options to decode with corresponding opcodes is retrieved in the option field of the received DHCP message. However, it is to be noted that the list of options is usually already known by the DHCP client, since the DHCP message is received in response to a previous DHCP message sent by the DHCP client to the DHCP server (see steps  302 - 308 ).  
         [0159]    Steps  312  to  316  are performed for each of the retrieved opcodes.  
         [0160]    The list of options is then used to associate an optionrule and an opcode corresponding to each option in the list ( 312 ).  
         [0161]    In step  314 , the data included in the option field of the received DHCP message is decoded by interpreting the optionrules associated with the current opcode, using the library of data types.  
         [0162]    The decoded data is then preferably stored for later retrieval by the IP application. The data is advantageously stored in Random Access Memory (RAM) of the system hosting the IP application (or in the a memory of the IP product). Alternatively, any other memory means may be used, including Read Only Memory (ROM), cache, swap files, local storage means, etc.  
         [0163]    As illustrated in FIG. 8, a test may be performed during the encoding or decoding process to assess whether all DHCP options to encode/decode have been processed.  
         [0164]    If any error is found during the communication process  300 , the IP application is advantageously configured to display an error message on a display device.  
         [0165]    Since datarules are defined using a library of predefined data types, the length of the data in the DHCP options data fields is implicitly defined by specifying the data type.  
         [0166]    The methods  100 ,  200  and  300  are advantageously implemented in C++. Alternatively, other languages may also be used without departing from the spirit and nature of the present invention.  
         [0167]    The present invention can be used to create any kind of parsers/encoders for text-strings.  
         [0168]    Although the present invention has been described hereinabove by way of preferred embodiments thereof, it can be modified without departing from the spirit and nature of the subject invention, as defined in the appended claims.