Abstract:
The present invention provides a method and apparatus for registering to a designated router in a rendezvous point in an anycast group in a multicast communication network, wherein the rendezvous point implements a joint-registering based on registering status of all rendezvous points in the anycast group. The main rendezvous point sends to the designated router the Register Stop message only when all rendezvous points in the anycast group do not need the Register message from the designated router; when any one of other rendezvous points does not need the Register message, sending the Register message to it is stopped. With the method and apparatus of the present invention, the cases resulting in the interruption of subscriber terminal multicast traffic can be reduced, and the CPU resource of the main rendezvous point and bandwidth resources between it and other rendezvous points are saved.

Description:
FIELD OF THE INVENTION 
     The present invention relates to a multicast communication network, and more particularly, to a rendezvous point in an anycast group in the multicast communication network. 
     BACKGROUND OF THE INVENTION 
     In an access and edge network, PIM-SM protocol (RFC4601, Protocol Independent Multicast-Sparse Mode: Protocol Specification (Revised)) is supported in edge nodes and core network nodes. A Rendezvous Point (RP) is the root of PIM-SM share tree. The anycast RP protocol using the PIM protocol (RFC4610, Anycast-RP Using Protocol Independent Multicast) is designed to provide load balancing and failover for the RP. However, there is no cooperation mechanism among anycast RPs in the protocol when sending Register-Stop Messages, which may result in subscriber terminals under some anycast RPs having interrupted multicast service and bandwidth waste among anycast RPs due to trashy Register Messages. 
     According to RFC4610, the RPs in an anycast group work as follows. 
     As shown in  FIG. 1 , RP 1 , RP 2  and RP 3  represent three RPs in an anycast group; each of R 1 , R 1 ′, R 2  and R 3  is a subscriber terminal in the group; DR stands for a Designated Router (DR) directly attached to a source S 1  which sends information to the anycast group. It is assumed that RP 1 , RP 2  and RP 3  are all assigned with the same IP address which is used as the anycast RP address and called an IPA. 
     When S 1  starts sending source data traffic, the flow to be obeyed is as follows. 
     1. S 1  sends a multicast packet, and the DR directly attached to the S 1  forms a PIM Register message to send to the anycast RP address (IPA) through adding a unicast header to the multicast packet. The unicast routing system delivers the PIM Register message to the nearest RP, in this case RP 1 . 
     2. The RP 1  uses its own IP address as the source address, and sends the Register message from the DR to the RP 2  and RP 3 , respectively. 
     3. The RP 1  sends a Register Stop message to the DR. 
     4. When receiving the Register message from the RP 1 , the RP 2  and the RP 3  send the Register Stop message to the RP 1  respectively. 
     5. The RP 1  receives the Register Stop messages from the RP 2  and the RP 3 , without any processing. 
     The problems in the above procedure comprise: firstly, the RP 1  sends the Register Stop message to the DR without considering that the RP 2  and RP 3  may still need the Register message from the DR, since the shortest multicast delivery paths (that is, the Shortest Path Tree) from the DR to the RP 2  and the RP 3  may haven&#39;t been established, which makes the subscriber terminals&#39; multicast service desultory. Secondly, the RP 1  sends Register messages to RP 2  and RP 3  without considering that RP 2  and RP 3  may not need them anymore recently, because the shortest multicast delivery paths from the DR to the RP 2  and the RP 3  may have been established or there is no subscriber terminal under RP 2  or RP 3 , which may results in waste of RP 1 &#39;s CPU resource and bandwidth among anycast RPs. 
     SUMMARY OF THE INVENTION 
     The present invention is provided to solve the problems of desultory multicast service and waste of bandwidth in anycast groups of the multicast communication network. 
     For the sake of convenient, a RP receiving the Register message from the DR first is called as a main RP. Each RP in the anycast group may become the main RP due to the dynamic change of network topology structure. Thus, instead of being limited to the main RP, the technical solution of the present invention is applicable to any RPs in the anycast group. 
     According to one aspect of the present invention, there is provided a method for registering to a designated router in a rendezvous point in an anycast group in a multicast communication network, wherein the rendezvous point implements a joint-registering based on registering status of all rendezvous points in the anycast group. 
     According to another aspect of the present invention, there is proposed a method for registering to a designated router in a rendezvous point in an anycast group in a multicast communication network, comprising the steps of: receiving a Register message from the designated router; detecting whether Register message is still needed by the rendezvous point and all other rendezvous points in the anycast group; and when none of the rendezvous point and all other rendezvous points needs the Register message, sending a Register Stop message to the designated router. 
     According to still another aspect of the present invention, there is proposed a registering apparatus for registering to a designated router in a rendezvous point in an anycast group in a multicast communication network, wherein the registering apparatus implements a joint-registering based on registering status of all rendezvous points in the anycast group. 
     According to yet another aspect of the present invention, there is proposed a registering apparatus for registering to a designated router in a rendezvous point in an anycast group in a multicast communication network, comprising a receiving means for receiving a Register message from the designated router, a first detecting means for detecting whether Register message is still needed by the rendezvous point and all other rendezvous points in the anycast group, and a sending means for sending a Register Stop message to the designated router when none of the rendezvous point and all other rendezvous points needs the Register message. 
     Before sending the Register Stop message to the DR and sending the Register message to any one of other anycast RPs, the main RP determines whether it has received the Register Stop message from any one of other anycast RPs recently. The main RP may send to the DR the Register Stop message only after all other anycast RPs have sent the Register Stop messages to the main RP recently. By doing so, the probability of interrupting the multicast traffic to the subscriber terminal is greatly reduced. The main RP only sends the Register message to the anycast RP when it has not received the Register Stop message from the anycast RP recently. Thus, the main RP saves its CPU resource and bandwidth resource between it and other RPs since it is unnecessary to unpack the Register message from the DR and repack it. 
    
    
     
       BRIEF DESCRIPTION ON THE DRAWINGS 
         FIG. 1  is a diagram showing a scene where the multicast traffic may be interrupted when an anycast group of RPs is used in a multicast communication network; 
         FIG. 2  is a diagram showing another scene where the multicast traffic may be interrupted when an anycast group of RPs is used in a multicast communication network; 
         FIG. 3  is a diagram showing yet another scene where the multicast traffic may be interrupted when an anycast group of RPs is used in a multicast communication network; 
         FIG. 4  is a flow chart showing a joint-registering solution in a RP in an anycast group in a multicast communication network according to an embodiment of the present invention; 
         FIG. 5  is a flowchart of determining whether Register message is still needed by any one of other RPs performed in a RP in an anycast group in a multicast communication network according to an embodiment of the present invention; 
         FIG. 6  is a flow chart, performed by a RP in the anycast group in a multicast communication network, for determining whether the Register message is still needed by itself according to an embodiment of the present invention; 
         FIG. 7  is a structural diagram showing a joint-registering apparatus in a RP in an anycast group in a multicast communication network according to an embodiment of the present invention; and 
         FIG. 8  is a diagram showing a network topology structure using an anycast group of RPs in a multicast communication network according to an embodiment of the present invention. 
     
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       FIG. 1  is a diagram showing a scene where the multicast traffic may be interrupted when an anycast group of RPs is used in a multicast communication network. In the network topology structure as shown in  FIG. 1 , there are included a multicast source S 1 , a designated router DR, three anycast RPs RP 1 , RP 2  and RP 3  and subscriber terminals R 1 , R 1 ′, R 2  and R 3 . It is assumed that the RP 1  is the main RP, and the dashed lines in the figure represent that the Shortest Path Trees from the DR to the RPs have not been established. 
     As shown in  FIG. 1 , during procedure P 11 , the Shortest Path Tree from the DR to the RP 1  has been established but the Shortest Path Trees from the DR to the RP 2  and RP 3  have not been established. According to the PIM-SM protocol, upon receiving a Register message, the RP 1  may send a Register Stop message to the DR. According to RFC4610, the RP 1  sends the Register Stop message to the DR without considering associating it with Register Stop messages from the RP 2  and RP 3 . During procedure P 12 , the RP 1  sends the Register Stop message to the DR before receiving the Register Stop messages from the RP 2  and the RP 3 . During procedure P 13 , upon receiving the Register Stop message, the DR does not send the Register message to the RP 1  for a moment (that is, during the running period of the Register-Stop Timer in the DR, please see PIM-SM protocol for details). Thus, during procedure P 14 , the RP 2  and RP 3  may not receive the Register messages from the RP 1 , and thus the multicast traffic to the R 2  and R 3  respectively may be interrupted. 
     Another serious traffic interruption is as shown in  FIG. 2 . In the case, there is no subscriber terminal under the RP 1 . During procedure P 21 , the Shortest Path Trees from the DR to the RP 2  and RP 3  haven&#39;t been established. According to the PIM-SM protocol registration mechanism and RFC4610, during the procedure P 22 , the RP 1  sends the Register Stop message to the DR after receiving the Register message from the DR since there is no subscriber terminal under it. However at the moment, the RP 1  has not received the Register Stop messages from the RP 2  and RP 3 . During procedure P 23 , upon receiving the Register Stop message from the RP 1 , the DR does not send the Register message to the RP 1  for a moment (that is, during the running period of the Register-Stop Timer in the DR, please see PIM-SM protocol for details). During procedure P 24 , the RP 2  and RP 3  can not obtain the corresponding Register message during the period, thus interrupting the multicast traffic to the subscriber terminals R 2  and R 3 . 
       FIG. 3  depicts how the bandwidth among RPs in an anycast group is wasted. In this scenario, during procedure P 31 , there is no subscriber terminal under the RP 2 , the Shortest Path Tree from the DR to the RP 3  has been established, but the Shortest Path Tree from the DR to the RP 1  has not been established completely. Thus, when receiving the Register message from the DR, during the procedure P 32 , the RP 1 , according to RFC4610, copies the Register message from the DR to the RP 2  and the RP 3 , respectively. According to the PIM-SM protocol, during procedure P 33 , the RP 2  and RP 3  would send Register Stop messages to the RP 1 , since there is no subscriber terminal under the RP 2  and the RP 3  has received the native multicast data packet via the Shortest Path Tree from the DR. According to RFC4610, there is no operation taken by the RP 1  when processing the Register Stop message, and thus the RP 1  continues sending the Register messages to the RP 2  and RP 3  without considering that the RP 2  and RP 3  do not need the Register messages any more recently. Hence, the RP 1  wastes its CPU resource and bandwidth due to sending trashy Register messages to the RP 2  and RP 3 . 
     Obviously, it is necessary to add a cooperation mechanism to the main RP. To solve the problems of interrupting multicast traffic and waste of CPU resource and bandwidth resulted from lack of the cooperation mechanism among RPs in the anycast group, the present invention proposes a method and apparatus of joint-registering to a DR by a main RP, being characterized in that a RP may send a Register Stop message to the DR only when both the RP and other RPs in the anycast group do not need the Register message from the DR, thereby implementing a joint-registering procedure. 
       FIG. 4  depicts a flow chart showing a joint-registering in a main RP in an anycast group in a multicast communication network according to an embodiment of the present invention. 
     At first, at step S 11 , the main RP receives a Register message from the DR. The Register message may experience multiple hops before arriving at the main RP. 
     Then, at step S 12 , the main RP detects whether Register message is still needed by itself and all other RPs in the anycast group. 
     At last, at step S 13 , when the RP and all other RPs do not need the Register message any more, the main RP sends to the DR a Register Stop message to tell the DR not to send the Register message to it. 
     In the main RP, there are many approaches to detect whether the Register message is still needed by the RP and other RPs. 
       FIG. 5  depicts steps, performed by the main RP in the anycast group in the multicast communication network, of determining whether Register message is still needed by any other RPs according to an embodiment of the present invention. 
     At first, at step S 1211 , the duration from the time when the last Registration Stop message is received from any one of other RPs is calculated. 
     Then, at step S 1212 , when the duration is less than a predefined value, it can be determined that the any one of other RPs does not need the Register message any more. 
     The above predefined value is PT, and a referenced value range of the PT is given below. 
     It is assumed that the transmission delays of Register Stop messages from other RPs (RP 1 , RP 2 , RPn) in the same anycast group to the main RP are respectively T 1 , T 2 , . . . , Tn, and T is defined by 
               T   =       max       i   ≠   j     ,   i   ,     j   ∈     {     1   ,           ⁢     …   ⁢           ⁢   n       }           ⁢     (       T   i     -     T   j       )         ,         
then the minimum value of PT should not be less than T. It is assumed that the transmission delay from the DR to the main RP is T 0 , the transmission delay from the main RP to the DR is T 0 ′. According to the PIM-SM protocol, if the value of the Register-Stop Timer in the DR is T v  (the Register-Stop Timer is one implementing manner of the register inhibition time duration, and the above register inhibition time duration is the default value of the Register-Stop Timer, wherein the value range of T v  can be found in the PIM-SM protocol), then the maximum value of PT should not be greater than (T v +T 0 +T 0 ′).
 
     When it is detected that any one of other RPs does not need the Register message any more, that is, the any one of other RPs has established the Shortest Path Tree from the DR to it (see the PIM-SM protocol) or there is no subscriber terminal under the RP desiring to receive the multicast packet in the Register message, a control is taken to stop forwarding the Register message to corresponding RP, which on one hand reduces the burden of the main RP&#39;s CPU since the main RP does not need to unpack the Register message from the DR and then forward it to corresponding RP which does not need the Register message any more after repacking the Register message, and on the other hand saves the bandwidth between the main RP and corresponding RP which does not need the Register message any more. 
     The RP detecting whether the Register message is still needed by itself has two cases: without a subscriber terminal desiring to receive the multicast traffic relating to the Register message via the RP or with it. In the first case, it is checked, based on the multicast address in the multicast packet in the Register message, whether there is a subscriber terminal receiving the multicast traffic corresponding to the multicast address. Generally, a multicast forwarding table is pre-established, the table comprises the corresponding relationship between the multicast address and a list of output interfaces on the RP to the subscriber terminal receiving the multicast traffic corresponding to the multicast address. Based on this table, a query can be carried out to determine whether there is any subscriber terminal desiring to receive the multicast traffic corresponding to the multicast address via the RP. In the latter case, when the Shortest Path Tree from the DR to the main RP has been established (the determining basis has been described in the PIM-SM protocol in detail), it can be deemed that the Register message is not needed any longer. The above two cases can have their respective flags or share one flag, which denoting that there is no need for the Register message. 
       FIG. 6  depicts steps, performed by a main RP in a anycast group in a multicast communication network, for determining whether the Register message is still needed by itself according to an embodiment of the present invention. 
     When the Register message from the DR is received, at first, it is checked whether there is any subscriber terminal desiring to receive the multicast traffic related to the Register message via the RP at step S 1221 . 
     If there is a subscriber terminal desiring to receive the multicast traffic related to the Register message, it is detected whether the Shortest Path Tree from the DR to the RP has been established at step S 1223 . 
     If the Shortest Path Tree has been established or it has been determined that there is no subscriber terminal desiring to receive the multicast traffic related to the Register message at step S 1221 , it is determined that the RP does not need the Register message from the DR anymore at step S 1224 . 
     To keep consistent with the PIM-SM protocol, the RP further sets a policy function SwitchToSptDesired according to the PIM-SM protocol. When its returned value is true, it means that the communication path from the DR to the RP is allowed to switch from unicast communication path receiving Register message currently to the Shortest Path Tree to implement multicast traffic communication; and when its returned value is false, it means that it is not allowed to switch from the unicast communication path receiving the Register message currently to the multicast Shortest Path Tree from the DR to the RP to implement the multicast traffic communication. The returned value can be set statically, or can be set during the running of the RP (see the PIM-SM protocol for details). Herein, to keep consistent with the PIM-SM protocol, at step S 1222 , when there is no subscriber terminal desiring to receive the multicast traffic related to the Register message via the RP and the returned value of SwitchToSptDesired is true, it can be determined that the RP does not need the Register message from the DR any more; and when there is no subscriber terminal desiring to receive the multicast traffic related to the Register message via the RP and the returned value of SwitchToSptDesired is false, it can be determined that the RP still needs the Register message from the DR. 
     The above procedure of determining by the main RP whether the Register message is stilled needed by itself is also applicable for other RPs. In fact, other RPs send the Register stop messages to the main RP after they determine that they do not need the Register messages based on the above procedure. In any one of other RPs, when the returned value of the policy function SwitchToSptDesired is true, it means that it is allowed to switch from the unicast communication path receiving the Register message from the DR via the main RP currently to the Shortest Path Tree from the DR to the RP to implement the multicast traffic communication; and when the returned value is false, it means that it is not allowed to switch from the unicast communication path receiving the Register message from the DR via the main RP currently to the multicast Shortest Path Tree from the DR to the RP to implement the multicast traffic communication. The procedure of setting its value is identical to that in the main RP, and thus the detailed description is omitted here. 
       FIG. 7  shows an illustrative diagram showing a register apparatus in the main RP in an anycast group in a multicast communication network according to an embodiment of the present invention, where only when both the RP and other RPs in the anycast group do not need the Register message from the DR, the Register Stop message is sent to the DR, thereby accomplishing a joint-registering procedure. The register apparatus  1  comprises a receiving means  11 , a first detecting means  12 , a sending means  13  and a sending control means  14 . The first detecting means  12  further comprises a calculating means  1211 , a first determining means  1212 , a second detecting means  1221 , a second determining means  1222 , a third detecting means  1223  and a third determining means  1224 . 
     At first, the receiving means  11  receives from the DR the Register message of which the header is a unicast data packet and which comprises a multicast data packet from the source S 1 . 
     And then, the first detecting means  12  detects whether the Register message from the DR is still needed by the RP and all other RPs. 
     At last, when the first detecting means  12  detects that none of the RPs in the anycast group needs the Register message from the DR, the sending means  13  sends the Register Stop message to the DR to instruct the DR not to send the Register message to the main RP anymore. 
     When there is no subscriber terminal desiring to receive the multicast data packet under the RP (to keep compatible with the PIM-SM protocol, the returned value of the policy function SwitchToSptDesired corresponding to the multicast traffic is true), or the Shortest Path Tree from the DR to the RP has been established, the RP does not need the Register message from the DR any more, and now the RP can set a flag bit so as to send the Register Stop message to the main RP when receiving the Register message from the main RP. 
     In the multicast communication network using the anycast group, RPs may be far away from each other physically, which results in that the main RP may have forwarded multiple Register messages when one of other RPs has sent the Register Stop message, and therefore the main RP may receive multiple Register Stop messages from a plurality of other RPs. 
     The calculating means  1211  in the first detecting means  12  calculates the duration from the time when the last Register Stop message from any one of other RPs is received. When the duration is less than a predefined value, the first determining means  1212  determines that the RP does not need the Register message any more. Then, the sending control means  14  controls the RP not to send the Register message to corresponding RP. A timer can be used herein to calculate the duration from the time when the last Register Stop message is received from any RP of all other RPs. 
     The predefined value for the duration is PT, and a referenced value range of the PT is given below. 
     It is assumed that the transmission delays of Register Stop messages from other RPs (RP 1 , RP 2 , . . . RPn) in the same anycast group to the main RP are respectively T 1 , T 2 , . . . , Tn, and T is defined by 
               T   =       max       i   ≠   j     ,   i   ,     j   ∈     {     1   ,           ⁢     …   ⁢           ⁢   n       }           ⁢     (       T   i     -     T   j       )         ,         
then the minimum value of PT should not be less than T. It is assumed that the transmission delay from the DR to the main RP is T 0 , the transmission delay from the main RP to the DR is T 0 . According to the PIM-SM protocol, if the value of the Register-Stop Timer in the DR is T v  (the Register-Stop Timer is one implementing manner of the register inhibition time duration, and the above register inhibition time duration is the default value of the Register-Stop Timer, wherein the value range of T v  can be found in the PIM-SM protocol), then the maximum value of PT should not be greater than (T v +T 0 +T 0 ′).
 
     The RP detecting whether the Register message is still needed by itself has two cases, without a subscriber terminal desiring to receive the multicast traffic relating to the Register message via the RP or with it. It is checked, based on the multicast address in the multicast packet in the Register message, whether there is a subscriber terminal receiving the multicast traffic corresponding to the multicast address. Generally a multicast forwarding table is pre-established. The table comprises the corresponding relationship between the multicast address and the list of output interfaces on the RP to the subscriber terminal receiving the multicast traffic corresponding to the multicast address. Based on this table, a query can be carried out to determine whether there is any subscriber terminal receiving the multicast traffic corresponding to the multicast address via the RP. In the latter case, when the Shortest Path Tree from the DR to the main RP has been established (the determining basis has been described in the PIM-SM protocol in detail), it can be determined that the Register message is not needed any longer. 
     The specific procedures are as follows. 
     At first, the second detecting means  1221  checks whether there is any subscriber terminal desiring to receive the multicast traffic related to the Register message via the RP. Herein, there is generally a list of output interfaces on the RP to the subscriber terminal desiring to receive a multicast traffic corresponding to each multicast traffic in each RP. If the list is empty, then it means that there is no subscriber terminal desiring to receive the multicast traffic via the RP, and then, to keep consistent with the PIM-SM protocol, it can be further determined whether the returned value of the policy function SwitchToSptDesired corresponding to the multicast traffic is true. In the case that the list is empty and the returned value of the policy function is true, then one flag bit can be set to denote the scenario, and the second determining means  1222  determines that the Register message related to the multicast traffic is not needed by the RP any more. And if it is further determined that the returned value of the SwitchToSptDesired is false, then the second determining means  1222  further determines that the Register message from the DR is still needed by the RP. 
     When the list is not empty, it means that there is one or more subscriber terminals desiring to receive the multicast traffic related to the Register message via the RP, and the third detecting means  1223  then detects whether the Shortest Path Tree related to the above multicast traffic from the DR to the RP has been established. And if established, the third determining means  1224  determines that the RP does not need the Register message any more. According to the PIM-SM protocol, a flag bit can be set in the main RP about whether the Shortest Path Tree has been established. 
     It should be noted that the second determining means  1222  can ignore the above policy function SwitchToSptDesired, and when there is no subscriber terminal desiring to receive the multicast traffic related to the Register message via the RP, it can be determined that the RP does not need the Register message related to the multicast traffic anymore directly. 
     The above procedure of determining, by the main RP, whether the Register message is stilled needed by itself is also applicable for other RPs. In practice, other RPs send the Register stop messages to the main RP after they determine that they do not need the Register messages any longer based on the above procedure. What is a little different is that the meaning of the policy function SwitchToSptDesired in the main RP and other RPs is different. When its returned value is true, in the main RP it means that it is allowed to switch from the unicast communication path receiving the Register message from the DR to the RP currently to the multicast Shortest Path Tree from the DR to the RP to implement the multicast traffic communication; in other RPs it means that it is allowed to switch from the unicast communication path receiving the Register message from the DR via the main RP currently to the multicast Shortest Path Tree from the DR to the RP to implement the multicast traffic communication. When its returned value is false, in the main RP it means that it is not allowed to switch from the unicast communication path receiving the Registration message from the DR to the RP currently to the multicast Shortest Path Tree from the DR to the RP to implement the multicast traffic communication; and in other RPs it means that it is not allowed to switch from the unicast communication path receiving the Register message from the DR via the RP currently to the multicast Shortest Path Tree from the DR to the RP to implement the multicast traffic communication. 
       FIG. 8  is a diagram showing a network topology structure using an anycast group of RPs in a multicast network according to an embodiment of the present invention. In the network topology structure as shown in  FIG. 8 , there are included a multicast source S 1 , a designated router DR, three anycast RPs RP 1 , RP 2  and RP 3  and subscriber terminals R 1 , R 1 ′, R 2  and R 3 . It is assumed that the RP 1  is the main RP. 
     During the procedure P 81 , when the RP 1  receives the Register Stop message from the RP 2  for the first time, the RP  1  starts a timer corresponding to the RP 2 , and the time value of the timer can be identical to the value of the Register-Stop Timer in the DR. And then, the timer is reset after the Register Stop message from the RP 2  is received again. Similarly, an identical timer is set for the RP 3 . During procedure P 82 , the RP 1  determines whether the timers corresponding to the RP 2  and the RP 3  are running before sending the Register Stop message to the DR. If both running, which means that the RP 2  and the RP 3  have sent the Register Stop message to the RP 1  respectively, and if now the RP 1  does not need the Register message either, then the RP 1  can send the Register Stop message to the DR. During procedure P 83 , the RP 1  should determine whether the timers of the RP 2  and the RP 3  are running before sending the Register messages from the DR to the RP 2  and the RP 3 . If both running, it means that the RP 1  does not need to send the Register messages to the RP 2  and the RP 3  corresponding to the timers. Otherwise, the RP 1  should send the Register messages to the RP 2  or RP 3  as described in the RFC4610. 
     The specific embodiments of the present invention have been described above. It should be appreciated that the present invention is not limited to the specific embodiments, and those skilled in the art can make various variation or modifications within the scope of the appended claims.