Patent Application
20050271050
This invention relates generally to address-based network communications and more particularly to determination of a prefix portion of an address.
Communication networks of various kinds are known. Many such networks anticipate that various communication nodes or elements, such as a client platform, will have a unique (or at least a sufficiently unique) network address to facilitate the appropriate routing of messages to and from such platforms. In some cases these addresses are more or less permanently assigned to a given corresponding platform. In other cases, however, and particularly when working to accommodate mobile client platforms, temporary addresses are often better suited to the task.
Since most (if not all) networks typically have only a finite number of potential address resources, provision of temporary addresses can present problems. For example, without proper management the demand for concurrent allocation of temporary addresses can appear to outstrip available resources. Accordingly, many modem networks employ processes to aid in ensuring that temporary addresses are more likely to be issued and maintained only as and while genuinely needed.
While suitable for at least some operational contexts, present address allocation schemes do not necessarily provide a satisfactory answer for all settings. Consider Internet Protocol version 6 (IPv6) as one illustrative example. IPv6 addresses are comprised of a 64 bit prefix and a 64 bit interface identifier. When a mobile client (or other device seeking a temporary address) establishes a point-to-point protocol connection with a packet data switching node it negotiates the interface identifier portion of the address during a network control protocol interaction (conforming, for example, to IPv6CP) stage of establishing the point-to-point protocol connection. After the point-to-point protocol link converges, the mobile client receives a router advertisement from the packet data switching node that contains one more prefixes. The mobile client typically combines one of these prefixes with the negotiated interface identifier and configures its IPv6 address accordingly.
In some cases, overall communications and/or resource management can be better facilitated if a given mobile client is assigned one prefix as versus another prefix that may also be available for such assignment. For example, a given network may support mobile clients that are associated with differing domains (or with mobile clients that themselves are capable of seeking affiliation at any given time with a given domain that is but one of many candidates). At present, such networks have no viable mechanism to accommodate such circumstances.
The above needs are at least partially met through provision of the domain-influenced prefix assignment method and apparatus described in the following detailed description, particularly when studied in conjunction with the drawings, wherein:
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will also be understood that the terms and expressions used herein have the ordinary meaning as is usually accorded to such terms and expressions by those skilled in the corresponding respective areas of inquiry and study except where other specific meanings have otherwise been set forth herein.
Generally speaking, pursuant to these various embodiments, the assignment of a network identifier to a wireless network user is facilitated by providing a pool of candidate prefix identifiers, wherein at least one of the candidate prefix identifiers is pre-associated with a specific network domain name and wherein at least one of the candidate prefix identifiers is not pre-associated with any network domain names. Upon receiving a communication from the wireless network user, one determines whether the communication identifies the specific network domain name. When true, one then at least attempts to affiliate the wireless network user with the candidate prefix identifier that is pre-associated with that specific network domain name. When not true, one then at least attempts to affiliate the wireless network user with the candidate prefix identifier that not pre-associated with any specific network domain name.
Depending upon the application, the pool of candidate prefix identifiers can include additional candidate prefix identifiers. If desired, some of these candidates can be pre-associated with yet other supported network domain names. Pursuant to another approach, a plurality of candidate prefix identifiers can be pre-associated with a corresponding single network domain name.
Pursuant to one embodiment, the prefix identifiers as correspond to a given domain name can be comprised of at least one fixed portion and at least one non-fixed portion. So configured, the non-fixed portion can be allocated to assure uniqueness amongst all mobile clients that are affiliating with a common domain name while the fixed portion of the prefix identifier will be the same for these same mobile clients.
Referring now to the drawings, and in particular to
A network element 10 (such as but not limited to a packet data switching node, a home agent, an authentication, authorization, and accounting server, a gateway general packet radio service support node, and the like) can comprise a prefix identifier assignment engine 11 that operably couples to a memory 12 and a network interface 13. Many network elements comprise partially or wholly programmable platforms. Such network elements can therefore be readily programmed to accord with these teachings and to, in particular, provide the prefix identifier assignment engine capabilities described herein. If desired, of course, a dedicated purpose platform could be provided in lieu of a programmable solution.
The network interface 13 will preferably comprise an interface that supports compatible interaction between the network element 10 and a network to which the network element couples. For example, the network interface 13 can comprise a session initiation protocol-compatible interface that compatibly interacts using appropriate voltage levels, signaling protocols, and the like as may correspond to the network in order to facilitate communications with one or more network users (and particularly network users who seek to establish a network connection).
In general, such platforms and interfaces are well understood in the art. In addition, these teachings are not especially owing to a selection of any particular platform, network, protocol, or the like. Therefore, for the sake of brevity and the preservation of focus, additional details in this regard will not be provided except where appropriate and/or helpful by way of illustration.
In a preferred embodiment, the memory 12 contains one or more specific domain names and a pool of candidate prefix identifiers comprising one or more different prefix identifiers. In a preferred approach, at least one of the prefix identifiers is pre-correlated to one of the domain names and another of the prefix identifiers is not pre-correlated to any of the domain names.
So configured, the prefix identifier assignment engine 11 serves to provide prefix identifiers to network users that seek to establish a network connection. More particularly, and as will be presented with greater elaboration below, the prefix identifier assignment engine 11 can apportion such prefix identifiers as a function, at least in part, of a domain name as may be presented by such a network user when seeking to establish that network connection.
Referring now to
As noted earlier, at least one of these candidate prefix identifiers is preferably pre-correlated to a given corresponding domain name. When the process 20 supports multiple domain names, then various of the multiple domain names will preferably each be pre-correlated with at least one of the candidate prefix identifiers. In a preferred approach, at least one of these candidate prefix identifiers will also not be pre-correlated with any specific domain name (and, in many embodiments, a plurality of such candidates will not be pre-correlated with any specific domain names).
Upon then receiving 22 a communication from a network user (such as, for example, a wireless network user) seeking to establish a network connection (such as, for example, a network control protocol IPv6-compatible communication that seeks to establish a point-to-point protocol communication), the process 20 then determines 23 whether that network user presents a domain name in conjunction with that communication. When that network user does present a domain name, this process 20 then preferably identifies 24 a prefix identifier (or plurality of identifiers) (for example, from amongst the plurality of candidate prefix identifiers when so provided) that is pre-correlated to that domain name.
Upon identifying such a prefix identifier (or identifiers), the process 20 then provides 26 such prefix identifier (or identifiers) to the network user. Provisioning this prefix identifier can be accomplished in any of many various ways. Pursuant to one approach, advertising (as per, for example, the accommodations of IPv6) can be used to advise the network user of this prefix identifier (or identifiers). Such advertising can be effected, for example, through use of a router advertisement message in accord with known prior art technique. The network user can then make use of that advertised or otherwise provided prefix identifier to configure and comprise its own address for use during subsequent network interactions.
When the process 20 identifies 24 more than one candidate prefix identifier, more than one candidate can be provided 26 to the network user. For example, if 15 candidate prefix identifiers are so identified, the process 20 can provide all 15 candidates, or some lesser subset, to the network user (again, for example, through use of a router advertising message). Pursuant to this approach, the recipient network user can then select at least a given one of the provided plurality of prefix identifiers for use as noted above.
When this process 20 does not discern presentation of a domain name by a network user, the process 20 instead then identifies 25 a candidate prefix identifier (or identifiers) that are reserved for use with network users that do not present a domain name. This identified prefix identifier (or plurality of prefix identifiers) is then again provided 26 to the network user to permit use of that prefix identifier to formulate and establish its own network address.
To illustrate, and referring now to
Such prefix identifiers can be utterly distinct from one another and without any content or formatting relationship to one another if so desired. These teachings are also applicable, however, to use with a more orderly process. For example, a given plurality of prefix identifiers may be identical to one another with respect to a certain portion of the prefix and only differ with respect to one another as per the contents of another portion of the prefix. To illustrate, and referring now to
To illustrate, if the complete prefix comprises an eight bit expression, then the first four bits might be identical for each prefix while the remaining four bits vary. Such a scheme would yield, for example, the following pool of candidate prefixes:
These teachings encompass an approach wherein such a plurality of prefix identifiers are all associated with a given domain name (such as, for example, “domain1.net”). So apportioned, all prefixes that begin with “1111” would be used exclusively in support of network users that present “domain1.net” as their domain (by presenting, for example, “networkuser@domain1.net”). The remaining prefix portions could then be allocated as needed amongst appropriate network users. For example, a first network user might receive “11110000” as their prefix identifier while a next network user presenting this same domain name might receive a next sequential prefix identifier (i.e., “11110001”). In this way a given network user will receive a prefix identifier having at least one portion that is correlated to a specific domain name and that will be shared with other network users and another prefix identifier portion that serves to uniquely identify this particular network user.
Such an approach can be readily used in an IPv6 context. IPv6 provides for a 64 bit prefix identifier. A first portion of that prefix identifier, such as the first 48 bits, could be fixed for a given plurality of prefix identifiers as are correlated to a given corresponding domain name. The remaining 16 bits could then comprise a variable portion that serve to facilitate unique identification of each network user as corresponds to the given domain name.
Those skilled in the art will appreciate that such prefix identifiers as comprise both a fixed and a non-fixed portion can be stored and/or allocated in various ways. By one approach, each possible complete prefix identifier can be stored in a table in conjunction with a corresponding domain name (or the absence of a domain name). By another approach, only the fixed portion of such a prefix identifier need be stored in a table. So configured, the fixed portion would be extracted as being correlated to a given presented domain name and the non-fixed portion could then be allocated on, for example, a round robin or sequentially incremented basis. Though a same basic end result occurs, the latter approach likely requires less memory than the first approach.
So configured, a network element such as a packet data switching node can maintain a table that correlates domain names with associated prefixes (either complete prefixes or fixed portions thereof as explained above) as well as prefixes that are reserved for use with network users that present no domain information (including, if desired, unrecognized and/or unsupported domain information). When a network user presents a domain name (or fails to present a domain name) during, for example, point-to-point protocol negotiation and/or its network access identifier during, for example, Mobile Internet Protocol registration, the network element can use this domain name information to lookup a corresponding prefix identifier (or identifier portion) and facilitate a router advertisement that presents that prefix identifier (or identifiers when more than one prefix identifier are to be presented).
These teachings readily facilitate the efficient handling and support of network users that present differing domain names. Prefix management in particular can be efficiently controlled to accommodate various system management goals and practices.
Those skilled in the art will recognize that a wide variety of modifications, alterations, and combinations can be made with respect to the above described embodiments without departing from the spirit and scope of the invention, and that such modifications, alterations, and combinations are to be viewed as being within the ambit of the inventive concept. For example, a network user may from time to time present a domain name, but that domain name may be unrecognized or, for whatever reason, there may be no prefix identifiers that have a pre-established correlation to that domain name. In such a case, the above process can be readily applied by treating the unrecognized or otherwise unsupported domain name as no domain name. In such a case, a prefix identifier as corresponds to no domain name could then be allocated.
