BEST MODE FOR CARRYING OUT THE INVENTION

[0026] The disclosed embodiment is directed to generating secure care of addresses for mobile networks based on generating local router prefixes specifying null or invalid address prefixes. Local router prefixes are generated by top level mobile routers to be null or invalid address prefixes that are not reachable via a wide area network according to existing routing protocols. Typically in a stateless configuration, a mobile router broadcasts an advertisement message that advertises a global mobile prefix, and a visiting mobile node (e.g., host or mobile router) uses the global mobile prefix and generate its own suffix to generate a care-of address. The mobile node will then advertise its presence in the mobile network, and send a binding update to its home agent. However, routing information is supplied with a transmitted IPv6 packet using the reverse routing header as described in the above-incorporated Internet Draft by Thubert et al.

[0027] Two privacy issues arise in mobile networking, namely the privacy of the visiting mobile node and the privacy of the mobile network providing a point of attachment to a wide area network for the visiting mobile node. The privacy of the visiting mobile node, addressed by the IETF RFC 3041, available on the world wide web at http://www.ietf.org/rfc/rfc3041.txt?number=3041 (and incorporated in its entirety herein by reference), includes preventing usage of care-of addresses based on the mobile host's unique EUI-64 MAC address, which may reveal the identity of the mobile host by its unique MAC address.

[0028] The disclosed embodiment addresses the privacy of the mobile network providing a point of attachment for the visiting mobile host. Currently the Mobile IP protocol described in the above-incorportated Internet Draft by Johnson et al. does not provide a method of hiding the identity of a mobile router: whereas fixed routers as part of the wide area network infrastructure are not concerned with privacy, a mobile host attaches to a mobile router in a nested manner—hence, the unique prefix of the mobile router would reveal the mobile router identity to the mobile host. Hence, the visiting mobile host (and any node that receives a packet from the mobile host) would discover that the mobile router was serving the mobile host. Privacy concerns also arise because it may be undesirable for others to be able to determine the location of the mobile router (e.g., based on determining that the mobile router was associated with the visiting mobile host).

[0029] According to the disclosed embodiment, the mobile network prefix of the mobile router is hidden from visiting mobile nodes. Further, the mobile network prefix, while hidden from the visiting mobile nodes, are still available to local fixed nodes that are attached to the mobile router. For example, a mobile vehicle having a top level mobile router will have local fixed nodes (e.g., GPS receiver, engine sensors, onboard computer, etc.) which will use the mobile network prefix for local communications between each other. A visiting mobile node, however, will attach to the top level mobile router using an anonymous prefix for its care-of address, and use its home address for address routing: in other words, since a reverse routing header is used by the visiting mobile node in sending packets to its home agent, the care-of address is merely an artifact used solely by the top level mobile router (the device having generated the anonymous prefix) in routing an incoming packet to the visiting mobile node.

[0030] Hence, since routing to the visiting mobile node from the wide area network is based on reaching the globally reachable IPv6 care-of address of the top level mobile router (which is based on the address prefix of the fixed access router), the identity (i.e., IPv6 address) of the top level mobile router (TLMR) of a mobile network remains anonymous to unknown mobile hosts, ensuring that the home agent of the unknown mobile hosts cannot perform attacks on the IPv6 address of the TLMR.

[0031] FIG. 1 is a diagram illustrating in detail a network system 10 that includes a wide area network 12 such as the Internet, a mobile network 20 having mobile routers 30 configured for forming Mobile IP attachments and routing packets according to the above-incorporated Internet Draft by Johnson et al., home agents 14 for serving assigned mobile routers 30 , and an attachment router (AR) access router 15 configured for providing a point of attachment for the mobile network 20 .

[0032] As illustrated in FIG. 1 , the attachment router access router 15 is configured for providing an attachment point for the top level mobile router 30 a by outputting a router advertisement message 32 a (RA 1 ) as specified in the IETF RFC 2461, entitled “Neighbor Discover for IPv6” available on the world wide web at http://www.ietf.org/rfc/rfc2461.txt?number=2461 (the disclosure of which is incorporated in its entirety herein by reference). The attachment router access router 15 , which has an IPv6 address “9CAC:2157::0553”, is configured for advertising on the wide area network 12 that address prefixes 34 a having a value of “9CAC:2157::/64” are reachable via the attachment router access router 15 .

[0033] The top level mobile router 30 a is configured for attaching to the attachment router access router 15 based on the router advertisement message 32 a that specifies the address prefix “9CAC:2157::/64” 34 a. The top level mobile router 30 a attaches to the attachment router access router 15 by assuming a care of address 36 a of “9CAC:2157:0A00”. Once the top level mobile router 30 a has attached to the attachment router access router 15 , the top level mobile router 30 a sends a binding update message to its home agent 14 a as specified in RFC 2461 and the above-incorporated Internet Draft by Thubert et al.

[0034] The top level mobile router 30 a also is configured for establishing the mobile network 20 according to a tree-based network topology model, for example using the attachment techniques described in commonly-assigned, copending application Ser. No. 10/218,515, filed Aug. 15,2002, entitled “ARRANGEMENT FOR OPTIMIZING CONNECTIONS BETWEEN ROAMING MOBILE ROUTERS IN A MOBILE NETWORK” (attorney docket 95-484), the disclosure of which is incorporated in its entirety herein by reference.

[0035] The top level mobile router 30 a serves as an attachment point for mobile routers 30 b and 30 c that are part of the same home network (e.g., that share the same home agent 14 a ). Note that the mobile routers 30 b and 30 c also may be local fixed nodes (LFNs), for example in the case of the mobile network 20 being implemented in a mobile vehicle. Mobile routers 30 a, 30 b, and 30 c are identifiable as belonging to the same home network based on their respective home addresses 38 a, 38 b, and 38 c having the same prescribed mobile network prefix 40 a (“ABCD:01::/96”). In this case, the top level mobile router 30 a would output a router advertisement message 32 b based on receiving a router solicitation message having a source address specifying the same address prefix as the prescribed mobile network prefix 40 a to the top level mobile router 30 a.

[0036] According to the disclosed embodiment, the top level mobile router 30 a also is configured for utilizing a local router prefix to provide anonymous route connections for untrusted, visiting mobile notes. For example, a visiting mobile router 30 d, 30 e or mobile node may detect an unsolicited router advertisement message, or may request attachment to the mobile network 20 . In this case, only the top level mobile router uses the access router address prefix 34 a: the top level mobile router 30 a will output a different router advertisement message 32 c that specifies a null address prefix 40 b that is an invalid address prefix that is not reachable via the wide area network 12 . Hence, any care of address 36 d, 36 e, 36 f specifying the local router prefix 40 b will be an invalid IPv6 address in the Internet 12 , ensuring the identity of the top level mobile router 30 a remains anonymous. However, the care of addresses 36 d, 36 e and 36 f to specify the local router prefix 40 b are still routable within the mobile network 20 by the top level mobile router 30 a, since the top level mobile router 30 a will include a routing table entry that specifies the local router prefix 40 b.

[0037] Hence, since the top level mobile router has stored routing table entries that specify the local router prefix 40 b, the top level mobile router 40 b can route incoming packets from the Internet 12 (via the access router 15 ) having type 2 routing headers specifying the local router prefix 40 b to the visiting mobile hosts 30 d or 30 e. As described below with respect to FIGS. 4 and 5 , the local router prefix 40 b can be used in conjunction with reverse routing headers (type 4 routing headers) and type 2 routing headers, as specified in the above-incorporated Internet Draft by Thubert et al. to route packets between the visiting mobile routers 30 d, 30 e, and 30 f and the home agent 14 b.

[0038] The local router prefix 40 b is inserted by the TLMR 30 a in a reverse routing header only to ensure that any return packet from the Internet 12 will include the local router prefix 40 b in the corresponding type 2 routing header. Hence, only the TLMR 30 a that generated the local router prefix 40 b will need to route the packet using the local router prefix 40 b.

[0039] Hence, packets from the Internet 12 will not reach the mobile network 20 unless they specify in their respective destination address fields the care-of address 36 a (“9CAC:2157::0A00”) for the top level mobile router 30 a, reachable via the access router according to the advertised prefix 34 a (“9CAC:2157::/64”). Once the TLMR 30 a receives the packet from the AR 15 , it parses the type 2 routing header, detects the local router prefix 40 b within the type 2 routing header, and routes the packet based on detecting a routing table entry that specifies the local router prefix 40 b.

[0040] FIG. 2 is a diagram illustrating a mobile router 30 (e.g., 30 a, 30 b, and 30 c of FIG. 1 ) configured for generating a local router prefix for anonymous route connections, according to an embodiment of the present invention.

[0041] Each mobile router includes an IPv6 interface 50 for sending and receiving IPv6 packets, and a routing resource 52 . The routing resource 52 includes an attachment resource 54 configured for performing router attachment selection and router registration, and generating binding updates. The routing resource 52 also includes a reverse routing header resource 56 configured for reverse routing header processing, described below. The routing resource 52 also includes a router advertisement resource 58 configured for generating the mobile router advertisement messages (e.g., 32 b, 32 c ), based on using a prescribed mobile network prefix resource 60 a or a router local prefix (RLP) resource 60 b. The routing resource 52 also includes a source routing resource 62 configured for routing a packet based on a detected type 2 routing header, and based on retrieving routing table entries 64 from a routing table 65 .

[0042] The attachment resource of the mobile router 30 is configured for associating with a router advertisement originator by storing the information in the RA message in its default router list 55 , and selecting the source of the RA message as its attachment router; the attachment resource 54 then sends a registration message to the attachment router to request it to be a member of the tree.

[0043] Router information in the internal default router list 55 is obtained using known router discovery techniques, and by detecting unsolicited router advertisement messages. The router advertisement messages may include a tree information option 66 , described in the above-incorporated Thubert et al. and illustrated below with respect to FIG. 3 , enabling the mobile router to store within the default router list the attributes of each detected router, as well as the attributes of the tree to which the detected router is attached.

[0044] Once the mobile router (e.g., 30 c ) selects a default router (e.g., 30 b ) to be used as an attachment router, the mobile router sends a registration request to the TLMR (e.g., 30 a ) via the routing protocol used inside the cluster, e.g., MANET protocol, or an extension of Mobile IP. Each mobile router (e.g., 30 b ) along the path to the TLMR detects the registration request from the originating mobile router (e.g., 30 c ), and stores in its routing table 64 the care-of address 36 c of the originating mobile router ( 30 c ) and the source-route path to the originating mobile router.

[0045] Hence, the TLMR can store, within its routing table 65 : a default route to a wide area network (e.g., the Internet) via its attachment router (as described in the above-incorporated application Ser. No. 10/218,515); and source-route paths to the prefixes inside their cluster (e.g., 40 a, 40 b ).

[0046] Each router having received the registration message registers the specified mobile router 30 c as a mobile router having sent the registration message and stores in its routing table 65 the address prefix, plus the route path specified by the Source Routing.

[0047] FIG. 3 is a diagram illustrating in detail a router advertisement message 32 generated by the router advertisement resource 58 , according to an embodiment of the present invention. The RA message 32 includes an IPv6 source address (SA) field 61 , an IPv6 destination address (DA) field 63 , and additional router advertisement fields as described in RFC 2461 (e.g., hop limit, router lifetime, reachable time etc.). According to the disclosed embodiment, a tree information option field 66 is added to the RA message 32 that includes attributes 68 , generated by a tree information generator resource within the router advertisement resource 58 , that specify the network topology model utilized by the router advertisement originator, identified by its corresponding IP source address (SA) field 61 in the IPv6 header.

[0048] For example, the tree information option field 66 includes a tree identifier 68 a, a tree group identifier 68 b, a preference field 68 c, a tree depth field 68 d, a fixed/mobile field 68 e, and a delay timer field 68 f. The tree identifier field 68 a is configured for storing an IP address of the top level mobile router, or the router local prefix 40 b. The tree group field 68 b is configured for storing a tree group identifier, for example an IPv6 address of a mobile router connected to a TLMR or a null care-of address, enabling an attachment resource 54 to distinguish between multiple tree groups (i.e., branches) within the same cluster. The preference field 68 c is configured for storing a preference value for the originating mobile router as stored in a corresponding preference register, enabling a mobile router receiving the RA message 32 to decide whether to associate with the source of the RA message 32 .

[0049] The tree depth field 68 d is configured for storing the depth of the mobile router within the tree, enabling other routers receiving the RA message to determine the relative position of the router advertisement originator within the tree 32 . The fixed/mobile field 68 e is configured for specifying whether the corresponding tree is a grounded tree or a floating tree. In particular, a tree is deemed to be fixed if the top level mobile router is connected to a fixed router. The delay timer field 68 f is configured for storing a prescribed delay interval utilized by other routers to delay subsequent topology changes, thereby delaying propagation of subsequent RA messages in response to the RA message 32 .

[0050] The tree information option (TIO) 66 also may include a path checksum field (not shown in FIG. 3 ), enabling a mobile router to determine whether the path through the tree above it has changed or not; in other words, a path checksum change indicates real path change. When propagating a TIO, an intermediate mobile router builds a byte string using the checksum it receives in a TIO and the 16 bytes of its care of address; the mobile router then overwrites the checksum in the TIO with the result. This operation is performed at the same time as the tree depth incrementing. The TLMR uses a checksum of zeroes for its computation.

[0051] FIG. 4 is a diagram illustrating updating of a reverse routing header 90 a, 90 b, and 90 c by an originating mobile router 30 e, the intermediate mobile router 30 d, and the top level mobile router 30 a, respectively. In particular, FIG. 4 illustrates a packet 100 having a source address field 102 , a destination address field 104 , extended headers 106 , a reverse routing header (e.g., 90 a ) and an inner packet 108 having been generated by an originating source.

[0052] As described in the above incorporated draft by Thubert et al., the mobile router 30 e, as the originating mobile router, outputs the packet 100 having the source address field 102 specifying the care of address 36 e (MR 4 _CoA) of the mobile router 30 c, and a selected number of empty address slots 114 within the reverse routing header 90 a. The empty slots enable the routers 30 b and 30 a to store their respective care of addresses within the IPv6 header (e.g., within the reverse routing header or the source address field 102 ).

[0053] As illustrated in FIGS. 1 and 4 , the mobile routers 30 d and 30 e are assigned the care of addresses MR 4 _CoA 36 e and MR 3 _CoA 36 d to have the router local address prefix 40 b; hence, the care-of addresses of MR 4 _CoA 36 e and MR 3 _CoA 36 d are illustrated has having the respective values RLP_ 2 and RLP_ 1 . The TLMR 30 a is illustrated as having the care-of address AR_ 1 36 a (with the address prefix 34 a of the access router 15 ).

[0054] The reverse routing header resource 56 inserts the prescribed home address 38 e (MR 4 _HAddr) for the mobile router 30 e in the first slot (slot 0 ), and specifies a routing header of type “4” within a type field 118 . The RRH resource 56 inserts the care of address 36 e of the mobile router 30 e (RLP_ 2 ) in the source address field 102 , and the address 120 (MR 4 _HA) of the corresponding home agent 14 b in the destination address field 104 , and outputs the packet 100 to its attachment router 30 d.

[0055] The mobile router 30 d, in response to detecting the reverse routing header 90 a, updates the reverse routing header by inserting the source address value 36 e into the detected empty entry field “slot1”, resulting in the updated reverse routing header 90 b. The mobile router 30 d inserts its own care of address 36 d (RLP_ 1 ) into the source address field 102 , and outputs the packet to its attachment router 30 a.

[0056] The mobile router 30 a, in response to detecting the reverse routing header 90 a, selectively updates the reverse routing header by inserting the source address value 112 b into the detected empty entry field “slot2”, resulting in the updated reverse routing header 90 a. The mobile router 30 a inserts its own care of address 36 a (AR_ 1 ) into the source address field 102 , and outputs the packet to the access router 15 for delivery to the home agent 14 b for the mobile router 30 e.

[0057] The home agent 14 b reads the bottom entry to identify the home address of the mobile router 30 e, using the entry as if it was a mobile IPv6 home address destination option (i.e., as an index into the binding cache). The home agent 14 b now can send a packet directly back by using the reverse routing header 90 c and the source address 102 in building a type 2 routing header 113 , illustrated in FIG. 5 .

[0058] FIG. 5 is a diagram illustrating a packet 109 , received by the TLMR 30 a via the AR 15 , that specifies a type 2 routing header 113 generated by the home agent 14 b based on the reverse routing header 90 c of FIG. 4 . The packet 109 includes a source address field 102 that specifies the IPv6 address 120 (MR 4 _HA) of the home agent 14 b, a destination address field 104 that specifies the care-of address 36 a of the top-level mobile router, and a type 2 routing header 113 that includes the home address 116 of the mobile router (MR 4 ) 30 e having sent the original packet having the reverse routing header 90 a.

[0059] Note that the home agent address (MR 4 _HA) 120 in the source address field 102 , the care-of address (TLMR_CoA, AR_ 1 ) 36 a of the TLMR 30 a, and the home address (MR 4 _HAddr) 116 of the mobile router in the type 2 routing header 113 are valid (i.e., globally reachable) IPv6 addresses. In contrast, the care of addresses 115 and 117 for the respective mobile routers 30 d and 30 e in the routing header 113 are null prefixes (i.e., not reachable from the Internet 12 via the AR 15 ). Hence, the mobile prefix 40 a remains anonymous along the entire path from the home agent 14 b to the end mobile node 30 e.

[0060] The TLMR 30 a, however, will include a route table entry 64 (for a limited time interval) that specifies the null prefix. In particular, the TLMR 30 a builds a connected route to that prefix over the ingress interface for the lifespan of that ‘NULL’ prefix. Hence, the TLMR 30 a will be able to route the packet to an interface (e.g., a virtual LAN (VLAN)) specified in the matching route table entry. Hence, an entry in the routing header 113 is only read by the mobile router that wrote the corresponding entry in the RRH 90 b or 90 c.

[0061] FIGS. 6A and 6B are diagrams summarizing the method by the routing resource 52 of a mobile router 30 (e.g., the TLMR 30 a ) for generating anonymous routes according to an embodiment of the present invention. The steps described herein with respect to FIGS. 6 and 7 can be implemented as executable code stored on a computer readable medium (e.g., floppy disk, hard disk, EEPROM, CD-ROM, etc.), or propagated via a computer readable transmission medium (e.g., fiber optic cable, electrically-conductive transmission line medium, wireless electromagnetic medium, etc.).

[0062] The method begins in step 200 of FIG. 6A , where the attachment resource 54 of the mobile router 30 (e.g., 30 a ) attaches to an attachment router (e.g., 15 ) based on adding a care of address specifying an attachment router prefix in the default router list 55 : the care of address is based on the router advertisement message received from the attachment router and specifying the corresponding attachment router prefix. For example, the top level mobile router 30 a builds its care of address 36 a based on the address prefix 34 a advertised by the attachment router 15 in the router advertisement message 32 a. Similar attachment procedures are performed by the remaining mobile routers of the tree 20 , and including the mobile routers 30 b and 30 c that belong to the same home network as the top level mobile router 30 a.

[0063] If in step 202 the mobile router 30 is configured for outputting unsolicited router advertisement messages, the router local prefix resource 60 b of the mobile router 30 outputs in step 204 a router advertisement message that specifies a null router local prefix (RLP) 40 b (e.g., “000A:0001::/64”) in the relevant address field (e.g., source address field), and an expiration interval indicating the lifetime of any connections using the advertised null router local prefix 40 b. The mobile router 30 also updates its routing table 65 to include a route table entry 64 that specifies the router local prefix and the corresponding expiration interval.

[0064] The mobile router 30 also will selectively output a router advertisement message that specifies a null router local prefix 40 b in response to a router solicitation message from an unknown source. In particular, assume in step 206 that the mobile router 30 receives a router solicitation message. If in step 208 the router advertisement resource 58 determines that the address prefix of the source address matches the prescribed mobile network prefix 40 a of the mobile router 30 , the mobile network prefix resource 60 a of the mobile router 30 outputs in step 210 a router advertisement message that specifies the prescribed mobile network prefix 40 a. Hence, mobile nodes belonging to the same mobile network can be configured to share the same prescribed mobile network prefix 40 a. However, the mobile router 30 also may be configured to always output router advertisement messages having the null router local prefix.

[0065] If in step 208 the router advertisement resource 58 determines that the address prefix of the router solicitation message does not match the prescribed mobile network prefix 40 a, the mobile router 30 needs to output a router advertisement message that specifies the null router local prefix. If in step 212 the router is not a top level mobile router, for example mobile router 30 c which is further down the tree established by the TLMR 30 a, the RLP resource 60 b of the mobile router sends in step 214 a request to the top level mobile router for a new connection using a null router local prefix assigned by the top level mobile router. The router local prefix resource 60 b of the top level mobile router responds to the request sent in step 214 by outputting a router advertisement message that specifies the null router local prefix.

[0066] In response to receiving in step 216 the router local prefix from the top level mobile router, the attachment resource 54 of the mobile router 30 creates a new attachment using the router local prefix by adding the router local prefix as an entry to the default router list 55 . The mobile router 30 can then output in step 204 the router advertisement message advertising the null router local prefix in step 204 . Hence, generation of null router local prefix by the top level mobile router 30 a ensures that all routers between the originating mobile node and its home agent are anonymous.

[0067] Assume now that the mobile router 30 receives in step 220 a message from an attached node and that specifies a reverse routing header 90 . The reverse routing header resource 56 of the mobile router 30 updates the reverse routing header in step 222 by moving the source address value (e.g., 36 e ) to an empty slot 114 , and adding its care of address to the source address field 102 , as illustrated in FIG. 4 . The mobile router 30 sends in step 224 the message with the updated reverse routing header to its attachment router for delivery via the wide area network 12 .

[0068] Also note that the router advertisement resource 58 may be configured to advertise in step 226 a new router local prefix prior to expiration of the existing router local prefix. The mobile router 30 then deletes in step 228 the existing router local prefix from the routing table entry 64 upon entry of the corresponding expiration timer. The rebuilding of care of addresses provides additional security, since it becomes more difficult to forage and replay reverse routing header packets.

[0069] Once the destination of the packet receives the packet including the reverse routing header, the destination (e.g., the home agent 14 b ) can send a reply by generating a type 2 routing header 113 as illustrated in FIG. 5 , specifying the care of address 36 a of the top level mobile router 30 a in the destination address field 104 and the care of addresses for the remaining hops in the next hop fields 115 and 117 .

[0070] Referring to FIG. 6B , once the mobile router 30 receives in step 230 the packet specifying the mobile router's care of address in the destination address field and including the type 2 routing header, the source routing resource 62 checks in step 232 whether the next-hop address in the routing header 113 has a prefix which is specified within a route table entry 64 . As described above, any address prefix having been advertised by the mobile router 30 will have been added to the routing table 65 , regardless of whether the address prefix corresponds to a valid IPv6 address or a null router local prefix. Hence, if the source routing resource 62 detects in step 232 a valid table entry for the next hop address, the source routing resource 60 to updates in step 234 the destination address field and routing header, and outputs in step 236 the packet. However if in step 232 the next hop address does not specify an address prefix in the table entry, the packet is dropped in step 238 .

[0071] According to the disclosed embodiment, use of reverse routing headers and null address prefixes enables routers to maintain an anonymous route for visiting mobile nodes, increasing security for mobile networks. Use of the null address prefix, instead of the unique mobile network prefix, enables the mobile router to remain anonymous by avoiding disclosure of the unique mobile network prefix. Hence, destination nodes are prevented from forging routing headers, and the privacy of the mobile network 20 is maintained. Note that the disclosed visiting mobile routers 30 e and 30 f alternatively may be mobile host computers configured for generating reverse routing headers.

[0072] Note that the null address prefix 40 b may be generated dynamically by the TLMR 30 a. In particular, a cryptographic resource may be added to the router local prefix resource 60 b of FIG. 2 to generate a single null prefix per host. Hence, each new mobile host, in response to detecting an absence of any router advertisement messages, will send a router solicitation message; the TLMR 30 a, in response, can dynamically generate a new null address prefix based on the address information (e.g., MAC address) supplied by the new mobile host. The TLMR can then verify that a packet is received from the new mobile host based on its care-of address specifying the dynamically generated null prefix. The TLMR also can use the crypto-generated null address prefix to verify the authenticity of any packets from the Internet 12 having type 2 routing headers 113 . Further, the null prefix may be changed over time, enhancing security by using the null address prefix as a time-dependent signature.

[0073] Note that the existence of the null address prefix in the Internet 12 is inconsequential, since the only user of that address prefix is the mobile router 30 a itself when forwarding a routing header type 2. Further, the mobile router 30 a has a connected route to the destination mobile node (e.g., 30 e ) that is preferred over the route to the “real” address prefix that exists in the Internet 12 . Hence, the TLMR 30 a would never send a packet (specifying the null address prefix as the destination) over the Internet, but instead would route the packet over the preferred route on its ingress interface.

[0074] While the disclosed embodiment has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.