Title of Invention

METHOD FOR ANYCAST/SHARED UNICAST ADDRESS ASSIGNMENT

Abstract

This invention relates to DHCPv6 (DHCP over IPv6) technology. More specifically, this invention relates to a method of assigning IPv6 Anycast Addresses to nodes using a new DHCPv6 option. This invention explains a method for anycastlshared unicast address assignment using DHCPV6 wherein the said method uses a new DHCPv6 option, the IA_AA option which is a construct through which a DHCPv6 client and server identifies, groups and manages a set of related IPv6 Anycast Addresses.

Full Text

FIELD OF TECHNOLOGY This invention relates to DHCPv6 (DHCP over IPv6) technology in networks. Further, this invention relates to assigning of Anycast Addresses in a network. More particularly, this invention relates to a method of assigning IPv6 Anycast Addresses to nodes using a new DHCPv6 option. DESCRIPTION OF RELATED ART DHCPv6 is the Dynamic Host Configuration Protocol over IPv6 which is used to allow nodes to obtain addresses and other related information dynamically. A node which intends to obtain information in this fashion runs a DHCPv6 client. The client contacts a DHCPv6 server and requests the desired information which is provided by the server. DHCPv6 base specification has given out the way for DHCPv6 client to get unicast permanent/temporary addresses from a DHCPv6 Server. And, Prefix Delegation extensions to DHCPv6 has brought the way a DHCPv6 Client running on a client can get prefixes from the DHCPv6 server running on a server. However, no method exists through which a node can obtain and assign an Anycast Address. Anycast Addresses have been found to be very useful for example where load balancing is desired. Currently, Anycast Addresses are generally defined for geographically distributed devices and the address assignment is from ISP or standard bodies which is done manually. Indian Patent application no. 1479/CHE/2004 titled "A Method and Device for Providing Similar Service at an Address from Multiple Devices" describes a method for Anycast Address assignment using layer 3 method. However, this method is suitable for only nodes which are in a single subnet. SUMMARY OF THE INVENTION The primary object of this invention is to propose a method for Anycast Address assignment It is another object of this invention to provide a technique using extensions to DHCPv6 that do not affect inter-operability or violate existing standards It is yet another object of this invention to define a new DHCPv6 option for this purpose so that any node within a domain consists of multiple subnets can be an anycast address from a single DHCPv6 Server. This invention describes a method for Anycast Address assignment using a new DHCPv6 option - the IA_AA option. An \A_AA is a construct through which a DHCPv6 client and server can identify, group and manage a set of related IPv6 Anycast Addresses. Each IA_AA consists of an IAID and associated configuration information. An IA__AA for Anycast Address is the equivalent of an IA_NA (described in RFC 3315) for unicast permanent addresses. The IAID uniquely identifies the IA__AA and must be chosen to be unique among all the lAIDs on the client. The IAID is chosen by the client. For any given use of an IA_AA by the client, the IAID for that IA_AA MUST be consistent across restarts of the client. The client may maintain consistency either by storing the IAID in non-volatile storage or by using an algorithm that will consistently produce the same IAID as long as the configuration of the client has not changed. If the client uses only one IAID, it can use a well-known value, e.g., zero. The configuration information in an IA_AA consists of one or more IPv6 Anycast Addresses for each service class along with the times T1 and T2 for the IA_AA. Accordingly, this invention explains a method for anycast / shared unicast address assignment using DHCPV6 wherein the said method uses a new DHCPv6 option, the IA_AA option which is a construct through which a DHCPv6 client and server identifies, groups and manages a set of related IPv6 Anycast Addresses. The said IA_AA option format comprises an option-code, option-length, IAID, T1, T2 and IA_AA-options. The said option-code OPTION_IA_AA encapsulates those options that are specific to this IA_AA. An IA_AA option appears in the options area of a DHCP message. A DHCP message contains multiple IA_AA options. The said option-length is given by adding 12 with the length of IA_AA options field. The said IAID is a unique identifier for this IA_AA and the said IAID is unique among the identifiers for all of this client's IA_Aas. The said T1 is the time at which the client contacts the server from which the anycast addresses in the IA_AA were obtained to extend the lifetimes of the anycast addresses delegated to the IA_AA where T1 is a time duration relative to the current time expressed in units of seconds. The said T2 is the time at which the client contacts any available server to extend the lifetimes of the anycast addresses assigned to the IA_AA where T2 is time duration relative to the current time expressed in units of seconds. The said IA_AA-options is an option associated with the IA_AA. The status of any operations involving the IA AA is indicated in a Status Code option in the IA AA options field. An IA_AA has no explicit "lifetime" or "lease length" of its own and when the valid lifetimes of all of the anycast addresses in an IA_AA gets expired, the IA_AA is considered as expired. T1 and T2 give the servers explicit control over when a client contacts the server about a specific IA_AA. In a message sent by a client to a server, values in the T1 and T2 fields indicate the client's preference for those parameters and the client sets T1 and T2 to zero if it has no preference for these values. In a message sent by a server to a client, the client uses the values in the T1 and T2 fields for the T1 and T2 parameters. The server selects the T1 and T2 times to allow the client to extend the lifetimes of any anycast addresses in the IA_AA before the lifetimes expire, even if the server is unavailable for short period of time. Recommended values for T1 and T2 are .5 and .8 times the shortest preferred lifetime of the anycast addresses in the IA_AA that the server is willing to extend. If the time at which the anycast addresses in an IA AA are to be renewed is to be left to the discretion of the client, the server sets T1 and T2 to 0. If a server receives an IA_AA with T1 greater than T2, and both T1 and T2 are greater than 0, the server ignores the invalid values of T1 and T2 and processes the IA_AA as though the server had set T1 and T2 to 0. If a client receives an IA_AA with T1 greater than T2, and both T1 and T2 are greater than 0, the client discards the IA_AA option and processes the remainder of the message as though the server had not included the IA_AA option. Another option appears once or multiple times as a sub-option in IA_AA options field where the said another option has an option-code, option-length, Service class and IASRVCLS options. The said option-code is given by OPTIONJASRVCLS and said option-length is given by adding 4 to the length of IASRVCLS options field. The said service class is the service class of the application for which the anycast address is required. The said IASRVCLS options are the options associated with this Service Class. An option appears once or multiple times as a sub-option in IASRVCLS options field comprising an option-code, option-length, Preferred life time, Valid life time and IPv6-Address. The said option-code is given by OPTION_SRVCLS_ACADDR and the said option-length is 24. The said Preferred life time and valid lifetime for the IPv6 anycast address is expressed in units of seconds. The said IPv6-Address is an IPv6 Anycast Address. In a message sent by a client to a server, the values in the fields is used to indicate the client's preference for those values where the client sends a value of zero to indicate no preference. A client discards any anycast addresses for which the preferred lifetime is greater than the valid lifetime. A server ignores the lifetimes set by the client if the preferred lifetime is greater than the valid lifetime and ignores the values for T1 and T2 set by the client if those values are greater than the preferred lifetime where the values in the preferred and valid lifetimes are the number of seconds remaining for each lifetime. An SRVCLS_ACADDR option appear only in an IASRVCLS option and more than one SRVCLS_ACADDR option appears in a single IASRVCLS option. The DHCPv6 Client that wants to get anycast addresses for a specific service class includes IA_AA option in the Solicitation and/or Request it sends with IASRVCLS as a sub-option in IA_AA If the client requires anycast addresses for multiple service classes, it can include multiple IA_SRVCLS options in the IA_AA options field. The DHCPv6 server checks the availability of the anycast addresses for the requested service class and if there is an anycast address available to assign to the client, then the server fills that anycast address in IA_ACADDR option inside IA_SRVCLS options field. If there are multiple anycast addresses available for the same service the server include multiple SRVCLS_ACADDR options in IASRVCLS options field. The other objects, features and advantages of the present invention will be apparent from ensuing the detailed description of the invention taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS Figure 1 shows the format of the IA_AA option. Figure 2 shows the service class option format. Figure 3 shows the Anycast Address option format. DETAILED DESCRIPTION OF THE INVENTION The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail. The invention describes a method for IPv6 Anycast address assignment. The proposed method uses a new DHCPv6 options namely the IA__AA option to achieve this purpose. An IA_AA is a construct through which a DHCPv6 client and server can identify, group and manage a set of related IPv6 Anycast Addresses. The IA_AA option is similar to the IA_NA option defined in the DHCPv6 base specification for obtaining unicast IPv6 addresses. Figure 1 shows the IA_AA option format option-code OPTIONJA_AA (IANA-TBA) option-length I AID T1 T2 IA_AA-options 12 + length of IA_AA options field The unique identifier for this IA_AA; the IAID must be unique among the identifiers for all of this client's IA_AAs The time at which the client should contact the server from which the anycast addresses in the IA_AA were obtained to extend the lifetimes of the anycast addresses delegated to the IA_AA; T1 is a time duration relative to the current time expressed in units of seconds The time at which the client should contact any available server to extend the lifetimes of the anycast addresses assigned to the IA_AA; T2 is time duration relative to the current time expressed in units of seconds. Options associated with this IA_AA The IA_AA-options field encapsulates those options that are specific to this IA_AA. For example, all of the IA_AA Service Class Options carrying the Service Classes (along with Anycast Addresses) associated with this IA_AA are in the IA_AA options field. An IA_AA option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_AA options. The status of any operations involving this IA AA is indicated in a Status Code option in the IA AA options field. Note that an IA_AA has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the anycast addresses in an IA_AA have expired, the IA_AA can be considered as having expired. T1 and T2 are included to give servers explicit control over when a client should contact the server about a specific IA_AA. In a message sent by a client to a server, values in the T1 and T2 fields indicate the client's preference for those parameters. The client sets T1 and T2 to zero if it has no preference for those values. In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 parameters. The values in the T1 and T2 fields are the number of seconds until T1 and T2. The server selects the T1 and T2 times to allow the client to extend the lifetimes of any anycast addresses in the IA_AA before the lifetimes expire, even if the server is unavailable for some short period of time. Recommended values for T1 and T2 are .5 and .8 times the shortest preferred lifetime of the anycast addresses in the IA_AA that the server is willing to extend, respectively. If the time at which the anycast addresses in an IA_AA are to be renewed is to be left to the discretion of the client, the server sets T1 and T2 to 0. If a server receives an IA_AA with T1 greater than T2, and both T1 and T2 are greater than 0, the server ignores the invalid values of T1 and T2 and processes the IA_AA as though the server had set T1 and T2 to 0. If a client receives an IA_AA with T1 greater than T2, and both T1 and T2 are greater than 0, the client discards the IA_AA option and processes the remainder of the message as though the server had not included the IA_AA option. Figure 2 shows the service class option format option-code OPTIONJASRVCLS (IANA-TBA) option-length 4 + length of IASRVCLS options field The service class of the application for Service class which the anycast address is required IASRVCLS options Options associated with this Service Class This option can only appear (may be once or multiple times) as a sub-option in IA_AA options field. Figure 3 shows the Anycast Address option format. OPTION_SRVCLS_ACADDR option-code (IANA-TBA) option-length 24 The recommended preferred lifetime for the IPv6 anycast address in the option, Preferred life time expressed in units of seconds. A value of OxFFFFFFFF represents infinity The valid lifetime for the IPv6 anycast address in the option, expressed in units Valid life time of seconds. A value of OxFFFFFFFF represents infinity I Pv6-Address An I Pv6 Anycast Address This option can only be used by a DHCPv6 server. This option can only appear (may be once or multiple times) as a sub-option in IASRVCLS options field. In a message sent by a client to a server, the values in the fields can be used to indicate the client's preference for those values. The client may send a value of zero to indicate no preference. In a message sent by a server the preferred and valid lifetimes should be set to the values of AdvPreferredLifetime and AdvValidLifetime as specified in section 6.2.1, "Router Configuration Variables" of RFC 2461 [4], unless administratively configured. A client discards any anycast addresses for which the preferred lifetime is greater than the valid lifetime. A server ignores the lifetimes set by the client if the preferred lifetime is greater than the valid lifetime and ignores the values for T1 and T2 set by the client if those values are greater than the preferred lifetime. The values in the preferred and valid lifetimes are the number of seconds remaining for each lifetime. An SRVCLS_ACADDR option may appear only in an IASRVCLS option. More than one SRVCLS_ACADDR Option can appear in a single IASRVCLS option. The DHCPv6 Client that wants to get anycast addresses for a specific service class includes IA_AA option in the Solicitation and/or Request it sends with IASRVCLS as a sub-option in IA_AA. If the client requires anycast addresses for multiple service classes, it can include multiple IA_SRVCLS options in the IA_AA options field. The DHCPv6 server then checks the availability of the anycast addresses for the requested service class. If there is an anycast address available to assign to the client, then the server fills that anycast address in IA_ACADDR option inside IA_SRVCLS options field. If there are multiple anycast addresses available for the same service the server can typically include multiple SRVCLS_ACADDR options in IASRVCLS options field. It will also be obvious to those skilled in the art that other control methods and apparatuses can be derived from the combinations of the various methods and apparatuses of the present invention as taught by the description and the accompanying drawings and these shall also be considered within the scope of the present invention. Further, description of such combinations and variations is therefore omitted above. It should also be noted that the host for storing the applications include but not limited to a microchip, microprocessor, handheld communication device, computer, rendering device or a multi function device. Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart therefrom. WE CLAIM 1. A method for anycast/shared unicast address assignment using DHCPV6 wherein the said method uses a new DHCPv6 option, the IA_AA option which is a construct through which a DHCPv6 client and server identifies, groups and manages a set of related IPv6 Anycast Addresses, 2. A method as claimed in claim 1 wherein the said IA__AA option format comprises an option-code, option-length, IAID, T1, T2 and IA_AA-options. 3. A method as claimed in claim 2 wherein the said option-code OPTION_IA_AA encapsulates those options that are specific to this IA_AA. 4. A method as claimed in claim 2 wherein an IA__AA option appears \n the options area of a DHCP message. 5. A method as claimed in claim 4 wherein a DHCP message contains multiple IA_AA options. 6. A method as claimed in claim 2 wherein the said option-length is given by adding 12 with the length of IA_AA options field. 7. A method as claimed in claim 2 wherein the said IAID is a unique identifier for this IA_AA and the said IAID is unique among the identifiers for all of this client's IA__Aas. 8. A method as claimed in claim 2 wherein the said T1 is the time at which the client contacts the server from which the anycast addresses in the IA_AA were obtained to extend the lifetimes of the anycast addresses delegated to the IA_AA where T1 is a time duration relative to the current time expressed in units of seconds. 9. A method as claimed in claim 2 wherein the said T2 is the time at which the client contacts any available server to extend the lifetimes of the anycast addresses assigned to the IA_AA where T2 is time duration relative to the current time expressed in units of seconds. 10. A method as claimed in claim 2 wherein the said IA_AA-options is an option associated with the IA_AA. 11. A method as claimed in claim 1 wherein the status of any operations involving the IA_AAis indicated in a Status Code option in the IA_AAoptions field. 12. A method as claimed in claim 1 wherein an IA_AA has no explicit "lifetime" or "lease length" of its own and when the valid lifetimes of all of the anycast addresses in an IA_AA gets expired, the IA_AA is considered as expired. 13. A method as claimed in claim 1 wherein T1 and T2 gives the servers explicit control over when a client contact the server about a specific IA_AA. 14. A method as claimed in claim 1 wherein in a message sent by a client to a server, values in the T1 and T2 fields indicate the client's preference for those parameters and the client sets T1 and T2 to zero if it has no preference for these values. 15. A method as claimed in claim 1 wherein in a message sent by a server to a client, the client use the values in the T1 and T2 fields for the T1 and T2 parameters. 16. A method as claimed in claim 1 wherein the server selects the T1 and T2 times to allow the client to extend the lifetimes of any anycast addresses in the IA_AA before the lifetimes expires, even if the server is unavailable for short period of time. 17. A method as claimed in claim 1 wherein recommended values for T1 and T2 are .5 and .8 times the shortest preferred lifetime of the anycast addresses in the IA_AA that the server is willing to extend. 18. A method as claimed in claim 1 wherein if the time at which the anycast addresses in an IA_AA are to be renewed is to be left to the discretion of the client, the server sets T1 and T2 to 0. 19. A method as claimed in claim 1 wherein if a server receives an IA_AA with T1 greater than T2, and both T1 and T2 are greater than 0, the server ignores the invalid values of T1 and T2 and processes the IA_AA as though the server had set T1 and T2 to 0. 20. A method as claimed in claim 1 wherein if a client receives an IA_AA with T1 greater than T2, and both T1 and T2 are greater than 0, the client discards the IA_AA option and processes the remainder of the message as though the server had not included the IA_AA option. 21. A method as claimed in claim 1 wherein another option appears once or multiple times as a sub-option in IA_AA options field where the said another option has an option-code, option-length, Service class and lASRVCLS options. 22. A method as claimed in claim 22 wherein the said option-code is given by OPTIONJASRVCLS and said option-length is given by adding 4 to the length of lASRVCLS options field. 23. A method as claimed in claim 22 wherein the said service class is the service class of the application for which the anycast address is required. 24. A method as claimed in claim 22 wherein the said lASRVCLS options is the options associated with this Service Class. 25. A method as claimed in claim 1 wherein an option appear once or multiple times as a sub-option in IASRVCLS options field comprising an option-code, option-length, Preferred life time, Valid life time and IPv6-Address. 26. A method as claimed in claim 25 wherein the said option-code is given by OPTION_SRVCLS_ACADDR and the said option-length is 24. 27. A method as claimed in claim 25 wherein the said Preferred lifetime and valid lifetime for the IPv6 anycast address is expressed in units of seconds. 28. A method as claimed in claim 25 wherein the said IPv6-Address is an IPv6 Anycast Address. 29. A method as claimed in claim 1 wherein in a message sent by a client to a server, the values in the fields is used to indicate the client's preference for those values where the client sends a value of zero to indicate no preference. 30. A method as claimed in claim 1 wherein a client discards any anycast addresses for which the preferred lifetime is greater than the valid lifetime. 31. A method as claimed in claim 1 wherein a server ignores the lifetimes set by the client if the preferred lifetime is greater than the valid lifetime and ignores the values for T1 and T2 set by the client if those values are greater than the preferred lifetime where the values in the preferred and valid lifetimes are the number of seconds remaining for each lifetime. 32. A method as claimed in claim 1 wherein an SRVCLS_ACADDR option appear only in an IASRVCLS option and more than one SRVCLS_ACADDR option appears in a single IASRVCLS option. 33. A method as claimed in claim 1 wherein the DHCPv6 Client that wants to get anycast addresses for a specific service class includes IA_AA option in the Solicitation and/or Request it sends with IASRVCLS as a sub-option in IA_AA. 34. A method as claimed in claim 1 wherein if the client requires anycast addresses for multiple service classes, it can include multiple IA_SRVCLS options in the IA_AA options field. 35. A method as claimed in claim 34 wherein the DHCPv6 server checks the availability of the anycast addresses for the requested service class and if there is an anycast address available to assign to the client, then the server fills that anycast address in IA_ACADDR option inside IA_SRVCLS options field. 36. A method as claimed in claim 34 wherein if there are multiple anycast addresses available for the same service the server include multiple SRVCLS_ACADDR options in IASRVCLS options field. 37. A method for anycast / shared unicast address assignment using DHCPV6 substantially described particularly with reference to the accompanying drawings. Dated this 6th day of October 2005

Documents:

1053-CHE-2004 CORRESPONDENCE OTHERS. 01-02-2013.pdf

1053-CHE-2004 EXAMINATION REPORT REPLY RECEIVED 26-09-2012.pdf

1053-CHE-2004 FER REPLY AMENDED PAGES OF SPECIFICATION 26-09-2012.pdf

1053-CHE-2004 FER REPLY AMENDED CLAIMS 26-09-2012.pdf

1053-CHE-2004 FER REPLY FORM-1 26-09-2012.pdf

1053-CHE-2004 FER REPLY POWER OF ATTORNEY 26-09-2012.pdf

1053-CHE-2004 FORM-13 19-06-2006.pdf

1053-CHE-2004 FORM-13 26-09-2012.pdf

1053-CHE-2004 AMENDED CLAIMS 26-03-2013.pdf

1053-CHE-2004 AMENDED PAGES OF SPECIFICATION 26-03-2013.pdf

1053-CHE-2004 CORRESPONDENCE OTHERS 26-03-2013.pdf

1053-CHE-2004 POWER OF ATTORNEY 26-03-2013.pdf

1053-che-2004-abstract.pdf

1053-che-2004-claims.pdf

1053-che-2004-correspondnece-others.pdf

1053-che-2004-description(complete).pdf

1053-che-2004-description(provisional).pdf

1053-che-2004-drawings.pdf

1053-che-2004-form 1.pdf

1053-che-2004-form 5.pdf