the following terms , when used herein , shall have the meanings set forth below : 802 . 11 : an ieee standard for layer 2 wireless local - area networks . the standard includes , by way of example but not limitation , 802 . 11b , 802 . 11a , and 802 . 11 g , which define the layer 1 physical media behavior of different types of wireless networks . access point , or “ ap ”: a wireless device or a logical function that bridges wireless / 802 . 11 enabled devices from the wireless 802 . 11 network to the wired networks . 802 . 16 : an ieee standard for layer 2 wireless networks , comprising an interface for fixed broadband wireless access systems . base station or “ bs ”: an 802 . 16 equivalent of an 802 . 11 ap . ietf : refers to that certain standards body known as the internet engineering task force . mesh network : a set of access points colluding together as a mesh of nodes to deliver layer 2 traffic between the access points . local mac : a centrally controlled wireless architecture where wireless encryption / decryption and bridging of 802 . 11 to 802 . 3 is performed on the access point . split mac : a centrally controlled wireless architecture where bridging of 802 . 11 to 802 . 3 and / or wireless encryption / decryption is performed on a centralized device , such as , by way of non - limiting example , a wireless lan switch ethernet : a widely deployed wired layer 2 technology for connecting devices , defined by ieee 802 . 3 . mac layer : media access control layer , also known as “ layer 2 ”; refers to the packet formatting and protocol used to communicate between two devices . client : for hardware , refers to a client device , such as , by way of example but not limitation , a pc , pda , or other wireless client device . for software , refers to the layer 2 or layer 3 software entity that enables communications on client hardware . encryption : scrambling of data to prevent viewing , tampering , and replay from unauthorized sources . authentication server : server that distributes encryption keys to the wireless mesh node via security protocols . by way of example but not limitation , a set of protocols for 802 . 11 meshes are 802 . 11i for signaling the security hints regarding keys , 802 . 1x for transmitting keys , and radius for key and user information . layer 1 : communications between different devices at the physical layer ( by way of example but not limitation , wired , optical , or wireless ). layer 2 : communications between two devices and the data link layer / mac layer . devices may use the same packet formats and mac layer protocols , but may use different physical media . layer 3 : communications between two devices at the network layer , usually implying ip communications . devices communicating at layer 3 need not use the same layer 2 / mac layer protocols . layer 3 and ip may be used to communicate between different layer 2 devices over the internet . heavyweight access point : an access point that implements all of the 802 . 11 mac layer for an access point . a heavyweight access point may provide user authentication , encryption , data forwarding , and management capabilities . lightweight access point : an ap that typically implements only time - sensitive components of the 802 . 11 protocol . some lightweight access points also implement data encryption . lightweight access points may be used in conjunction with a wireless lan switch . link state path vector : refers to routing algorithms and protocols that are further described in 5 , u . s . utility application ser . no . 10 / 648 , 758 , dated aug . 25 , 2003 , inventor susan hares , entitled “ systems and methods for routing employing link state and path vector techniques ” bss or 802 . 11 “ basic service set ”: a set of wireless stations attached to a single ap and identified by a bssid . ess : an “ extended service set ” in 802 . 11 , comprised of a logical wireless lan spanning multiple bsss . ssid : service set identifier for an ess advertised in 802 . 11 management frames to aid wireless clients in discovering the ess . tunnel : a logical link between two elements of a network , that may use encapsulation to traverse diverse or routed networks . a non - limiting example of a tunnel is a gre tunnel between two ip endpoints . null tunnel : a logical tunnel between network elements using no additional encapsulation other than the native encapsulation of the link between them . as a non - limiting example of a null tunnel , network elements may be directly connected to each other via an ethernet cable . roaming : refers to wireless clients moving from one radio attachment point to another in a wireless network . mobility : a wireless network feature which preserves the current ( logical ) link between a wireless client and a wireless network . by way of non - limiting example , this may refer to layer 2 or layer 3 links . pfe : packet forwarding engine — a data forwarding abstraction used in this invention implemented in hardware or software . wifi vpn : a set of capwap and vpn protocols using wifi technologies described in u . s . patent application ser . no . 10 / 982 , 598 , which is hereby incorporated by reference in its entirety . x . 509 : public key certificate format — iso standard 9594 - 8 : 2001 , itu - t recommendation x . 509 , march 2000 . unicast traffic : unicast traffic may include layer 2 frames or layer 3 packets sent from a source machine to one remote machine . a non - limiting example of a layer 2 frame is an ethernet frame with destination mac address without the “ group ” bit set . a non - limiting example of a unicast layer 3 packet is an ip packet with a destination address that is a unicast ip address . multicast traffic : multicast traffic may include layer 2 frames or layer 3 packets sent from a source machine to multiple destinations . a non - limiting example of a layer 2 frame is an ethernet frame with a destination mac address with the “ group ” bit set . a non - limiting example of a multicast layer 3 packet is a ip packet with a destination address that contains a multicast ip address . embodiments of the invention include extensions to link state algorithms and to link state path vector algorithms that support the creation of secure scalable wireless mesh networks based on a hybrid wired / wireless routing infrastructure . these extensions form orthogonal pieces of functionality that can be implemented individually or a groups to provide secure scalable wireless mesh . these extensions include : support for flexible calculation of path networks based on any combination of one or more of the following parameters : wireless mesh based radio aware constraints ( such as , by way of example but not limitation , quality of relevant radio channels ), wireless mesh topology constraints ( such as , by way of example , power constraints , network topologies ), application and network qos , traffic engineering , user - administered policies , resource constraints , existence of security services , wired network connectivity and connectivity between multiple wireless meshes . in embodiments of the invention , these extensions may include additional data fields in type - length - value form that are passed as part of the link - state database update , stored in the link - state database , and used in the path calculation . calculation of multicast forwarding trees using link - state algorithms that support trees for any group mac address , or any pair of source or group mac addresses . calculation of multicast forwarding trees using link - state path vector algorithms that allow default or manually set policies to set the tie - breaking criteria between multicast forwarding paths . link state database exchange algorithms that minimize the database information transmitted on limited bandwidth broadcast media ( such as , by way of non - limiting example , radio networks ) and support a two ( 2 ) stage update process that queries link - state announcement sequence numbers before updating the link state database . a radio - aware light weight routing protocol ( referred to herein as “ ra - hello ”) that supports 1 hop and 2 hop radio aware topologies as well as the exchange of security and routing information , and on - demand secure multicast path using alternate group keys for encrypting multicast data between nodes — in such embodiments , routing and security systems interact to set - up a new set of keys and multicast forwarding paths for a specific set of group mac addresses . upon detection that a mesh node ( i . e ., a node in a mesh network ) wants to receive data from “ on - demand ” secure group mac , the mesh node allocates and uses an alternate group key for multicast forwarding to that secure mac . embodiments of this invention include extensions to a link state protocol ( such as , by way of example , isis or ospf ) or a link state path vector protocol to : pass routing information in type - length - value ( tlv ) descriptions that can be added the data base distribution packets . storing the type - length - value descriptions in the link state database , and using the information from the tlvs as part of constraint based path calculations for network traffic . database distribution packets may be , by way of example , link state packets in is - is , link state announcements in ospf or link state path vector lsp packets . embodiments include : storing type - length - value descriptions in a link state database , and performing constraint based calculations based on these parameters embodiments of the invention include a type - length - value format referred to herein as a “ wireless mesh routing tlv ”. non - limiting examples of type - length - value ( tlv ) descriptions used in embodiments of this invention are shown in fig4 in the form of 802 . 11 information elements ( or “ ie ( s )”). the information element has a 1 byte type field , followed by a 1 byte length field . 1 . routing category tlv ( 410 )— this routing category tlv allows the routing protocol type and version that initially provided the routing information to be exchanged between mesh points . this field indicator is used as either part of an existing link - state or link - state path vector protocol or part of the hello protocol . this field contains the following information a . path calculation control protocol ( 411 )— gives the path calculation protocol such as , by way of non - limiting example , link - state ospf , link - state isis , hybrid link - state path vector . b . version of the path vector protocol ( 412 ) c . routing packet type : by way of non - limiting examples , these may be hello , link state update , or database request or database update ( 413 ) d . sequence number of transmitted tlv formed 2 . the database lsas ie — this provides a tlv that further groups a set of tlvs to form an update message . the database ie contains : header information for this database , followed by a sequence of link - state - announcement ( lsa ) information elements ( tlv groups ). the database lsa ie ( tlv ) header field ( 420 ) contains : a . total length of the grouping of tlvs ( 421 ) b . topology database identification number ( 422 ) c . routing metric type ( 423 )— this contains the radio aware metric type , the topology aware type , and the preference between radio and topology aware . d . routing capabilities ( 424 )— a flag byte indicating what capabilities this database includes e . routing sub - ies ( 425 )— flags bytes indicate what type of ies are contained within the lsa ies f . last database request sequence number ( 426 )— this field contains the sequence number for the last database update request . g . count of lsa ie ( 427 )— this contains the count of the lsas that follow 3 . in embodiments of the invention , each lsa ie contains lsa origination information ( 430 ). the origination information may include the originating mesh point ( mp )( 431 ), lsa sequence number ( 432 ) and the life time value ( 433 ). optionally it can contain also contain the following information element ( tlvs ): a . neighbor link information element ( ie )( 435 ) b . forwarding information element ( ie )( 440 ) c . qos information element ( ie )( 442 ) d . resource information element ( ie )( 444 ) e . power information element ( ie )( 446 ) f . non - group mac address information element ( le )( 450 ) g . group mac address information element ( ie )( 460 ) h . ack information element ( 455 ) i . neighbor &# 39 ; s neighbor ( 470 ) j . neighbor link ie ( 473 ) k . neighbor qos ie ( 480 ) l . neighbor resource ie ( 482 ) m . neighbor non - group mac m ( 484 ) n . neighbor group mac ie ( 488 ) in embodiments of the invention , the foregoing tlvs may occur one or more time . the information elements inside of lsa ie are : 1 . neighbor link ie ( 430 ) contains the following fields a . mac address of neighbor mesh point ( 436 ) b . mlid — logical id for link connecting to the remote neighbor ( 437 ) c . routing metric type — gives 3 field that indicate routing metric type , radio - aware metric , and topology aware metric 2 . forwarding element ( ie ) ( 440 )— contains a 1 byte field for forwarding flags . forwarding flags ( 441 ) include ( but are not limited to ) unicast , multicast , and power - aware . 3 . qos ie ( 442 )— qos ie contains a variable list of qos parameters . this qos ie info field is variable in length with the length specified in the tlv format . 4 . resource ie ( 443 )— the resource ie field contains a variable field that provides information on resources that include ( but are not limited to ) to rf resources ( channel , frequency or bandwidth ), cpu resources , or memory resources . 5 . power ie ( 446 )— in embodiments , the power ie field contains a variable size set of parameters about power usage or status . these parameters may contain , by way of example but not limitation , parameters about remaining battery life or current power utilization or total power available . 6 . non - group mac address ( 450 )— this ie contains a list of non - group mac addresses . this field has an id that identifies this grouping of mac addresses , followed by a count of unicast mac address , and a list of mac address ( 1 to n macs ) 7 . ack ie ( 455 )— this field has a list of ack , or “ acknowledgement ” messages for different lsa sequence numbers . the fields in this ie are length of the ack value ( 2 bytes by default ), range of sequence numbers ack ( 457 ) contain start and end , followed by a list of ack sequence values . 8 . group mac address ie ( 460 )— this field has an id ( 461 ), followed by a count of group mac addresses ( 462 ) followed by a list group - mac address - flag pairs . 9 . neighbor &# 39 ; s neighbor ie ( 470 )— is a ie that contains information about the neighbors of a mesh point &# 39 ; s neighbor . this field has a header followed by the inclusion of a nbr &# 39 ; s nbr link ie ( 473 ) or a nbr qos ie ( 480 ) or a nbr resource ie ( 482 ) or a nbr non - group mac ( 484 ) or a nbr group mac address ( 490 ). the header information contains the total length of the full neighbor field ( 471 ) plus a count of the neighbors of the neighbor . 10 . nbr nbr link ie ( 473 )— contains a neighbor linked to this neighbor ( 474 ), the link the neighbor &# 39 ; s neighbor is connected over , the routing metric associated with the link , the sequence number of the last hello received by this neighbor ( 477 ), and the last lsa sequence number from the neighbor &# 39 ; s neighbor . 11 . nbr qos ie ( 480 )— the qos ie field from the nbr is forwarded in this tlv . 12 . nbr resource ie ( 482 )— the neighbor &# 39 ; s resource ie is forwarded in this tlv . 13 . nbr non - group mac ie ( 484 )— the neighbor &# 39 ; s non - group mac field is forwarded in this tlv . the ie field contains a id field that allows the mac addresses to be grouped . 14 . nbr group mac ie ( 490 )— the neighbor &# 39 ; s group mac field is passed in this tlv . in embodiments of the invention , the link state databases are expanded to include the information passed in these topologies . constraint based calculations can specify any of these in calculating a best network path through the mesh network . a te calculation runs both the basic spf to determine links without constraints and then re - runs the spf calculations with constraints . in embodiments of the invention , the spf calculation includes the following steps : step 0 — initializing the tent and path structures step 1 — examine the zero length link state topology packet and process step 2 — if the tent is empty , then stop . else iterate to add additional links in some embodiments , the foregoing algorithm is modified for constraints to be : pre - select out nodes by : removing all nodes and links that do not support constraint based routing and remove all nodes that do not meet the constraints run spf calculation above with this limited set of nodes run reduced flooding calculations to minimize the flooding of new information . embodiments of this invention exchange information in the tlvs regarding unieast mac addresses and group mac addresses associated with a mesh point . in embodiments , the group mac addresses are passed in the group mac ie ( 460 ) or the neighbor group mac ( 490 ) as shown in fig4 . the calculation of multicast forwarding trees utilizes either a link state or link state path vector protocols to pass information about the mesh point topology , pass information regarding group mac addresses and ( source , group ) mac addresses associated with each mesh point , pass weighting information to allow multiple equal - cost paths to be turned to a single path , and use link state topologies to calculate forwarding path rooted at a mesh node for a set of group mac addresses . the light weight routing protocol (“ ra - hello ”), which is , used for a 1 - hop to 2 - hop protocol , uses : the information is passed in a type - length - value ( tlv ) fields as described in previous section on path calculation ( group mac addresses or neighbor &# 39 ; s group mac addresses ). embodiments of this invention calculate multicast forwarding paths between mesh points sending to a multicast group and those receiving from a multicast group . a single tree rooted at a mesh point is calculated to all other mesh points receiving the mesh point . in embodiments of the invention , the foregoing calculation is performed by the following steps : remove all nodes that will not forward multicast ( denoted in the forwarding element ie field as unicast only ), for each group mac address sourcing data from this node : remove as end mesh nodes all nodes those except those reporting the multicast group mac address , create group - mac entry with : group mac address , list of mesh points that includes this mac address check to see if this group - mac entry matches an existing group - mac table entry . if so , add this group mac as secondary mac to this entry . if no match , add a new entry calculate the shortest path tree from each for each group entry in the tree . check to see if the multicast path contains an equal - coast multi - path ( ecmp ) from this node if no ecmp , finished with this step . if ecmp from this node , select a main path based on user policy , or lowest mesh point id / mesh point link id tuple . update a tlv with a different metric for this link and distribute with next link state update to neighbors . fig5 shows an illustrative , non - limiting example of the addition of one node ( node n ) sending traffic to several receivers ( denoted by the shaded nodes ). diagram 501 in fig5 shows node n flooding the group mac ie via the link - state packets to potential forwarders ( pf ) and to final receivers ( shaded nodes ). in stage 2 shown as element 502 in the figure , a shortest path calculation from node n is calculated to all receiving nodes . in stage 3 shown as fig5 , the algorithm selects a single path from this node to the distribution tree from the original node and then sends out an updated metric in the flag associated with the group mac from that node . in stage shown as fig5 , the forwarding table entries have been updated to select a single path . this multicast path calculation occurs after a normal shortest - path link - state algorithm calculates distances and shortest pathways to mesh points . as shall be apparent to those skilled in the art , if a group mac or a node &# 39 ; s announcement of group mac is removed , the next link state calculation runs and updates the link state database , the group mac address will no longer exist in the database . at this point , the multicast algorithm above will remove the tree rooted on that source node . fig6 shows , as a illustrative , non - limiting example , a mesh with node a being removed ( 601 ) and the resulting removal from the multicast forwarding path ( 602 ). should a tree link break , each node re - calculates the shortest path to all mesh points having the group mac associated using the algorithm above . fig7 provides a step by step indication of how this algorithm works with a broken link . item 701 shows how a link breaks in the middle of the network . item 702 shows how the recalculation selects a new forwarder ( based on link state spf and multicast algorithm running ). item 703 show how shortest path routes an alternate path between a and b . item 704 shows the forwarding path being calculated . item 705 show the repaired tree with new forwarding state . link state database exchange algorithms that minimize the exchange of database information transmitted on limited bandwidth broadcast media transmission of link state announcements by multiple nodes encrypted by group multicast key from a wireless mesh node to its neighbors . the originating node waits for ack from neighbors prior to re - transmitting to a specific neighbor the link state database update . a two stage update process that queries link - state announcement sequence numbers before updating the link state database . in the transmission of link state announcements , multiple nodes send back an ack for the set of received lsa ies . the “ ack ie field ” ( item 454 , fig4 ) gives the ack that can be sent from a particular field upon receipt . the algorithm for transmitting is : 1 . transmit link state announcements from a node to a local layer 2 multicast group appropriate for the link state protocol ( which may be , by way of non - limiting example , ospf , isis , or lspv ) using the node &# 39 ; s group key 2 . wait for a locally configured time to receive a wi - mesh routing ie with a db lsa ie with ack ies with the sequence number . 3 . if the time expires prior to receiving the acks , go back to step 1 until all nodes have ack the lsa database update . for a two stage update process , embodiments of the invention include additional information passed in the appropriate link state messages . this information is a set of tlvs denoted as the “ db request / response ” shown in fig8 . the tlvs included are : 1 . wireless mesh routing ie for a db packet type ( 801 ) which includes : a . type denoted wireless mesh routing ie b . length of the field c . control protocol ( 4 bits )— link state or hybrid link state d . version ( 4 bits ) e . packet type — db request / response f . sequence of tlvs — 2 bytes of sequence number for ordering of these tlvs g . routing metric type — 3 bytes : type flags , radio - aware metric , topology aware h . capability ie — flags for the types of capabilities supported by this node a . type — database ie b . length of ie c . topology db id # [ 811 ]— id number used to identify the topology in multiple topology overlays d . mpid of requestor [ 812 ] — mac address of mesh point requesting update e . last db request sequence # [ 813 ]— sequence number of last database request f . sequence number of request [ 814 ] — sequence number for this request g . request / response flags ( 1 byte ) [ 815 ] i . flags : ( xxx sptr ) ii . r = request ( 1 ), 0 — reply iii . t — transmit lsa in response ( 1 = transmit , 0 = response ) iv . p — partial sequence number response v . s — sequence number list follows i . type — sequence number ie ii . length — length of ie iii . starting of lsa sequence number ( 4 bytes ) iv . end ( last ) lsa sequence number ( 4 bytes ) v . count of lifetime ie that follow ( may be zero ) i . lifetime ie ( one or more may follow ) [ 830 , 840 ] i . lifetime value ii . count of lsas at lifetime iii . lsa id list fig9 shows an illustrative , non - limiting example of a database request sequence . fig1 illustrates a non - limiting example of a down loaded lsa . the database request sequence in fig9 undergoes the following steps : topology db id = 0 ( default ) requestor — mpid3 last request : 0 — no earlier request request : # 1 — first request flags : s = 0 — sn ie included — so give all lsas r = 1 — request for information on this node p = 0 — not a partial request t = 0 — transmit step ( b ) mp2 responds to the db request with list of lsas topology db id = 0 ( default ) requestor : mpid3 last request : 0 — no earlier request request : 1 flags : s = 1 — sn le included r = 0 — response to request of db request p = 0 — not a partial request t = 0 — echo of transmit flag start lsa sequence # 1 — start of lsa sequence # end lsa sequence # 2 — end of sequence # lifecnt — count of lifetime blocks topology db id = 0 ( default ) requestor — mpid2 last request : 0 — no earlier request request : # 1 — first request flags : s = 0 — sn ie included — so give all lsas r = 1 — request for information on this node p = 0 — not a partial request t = 0 — transmit step ( d ) mp3 responds to the db request with list of lsas topology db id = 0 ( default ) requestor : mpid2 last request : 0 — no earlier request request : 1 flags : s = 1 — sn ie included r = 0 — response to request of db request p = 0 — not a partial request t = 0 — echo of transmit flag sn ie start lsa sequence # 1 — start of lsa sequence # end lsa sequence # 2 — end of sequence # lifecnt — count of lifetime blocks life - time ie time — 100 counts cnt 3 lsas : 1 , 2 , 3 fig1 illustrates the downloading of the link state database with steps e through step h of the process . these steps are : step ( e ) mp 3 requests the db from mp 2 with the following tlvs : topology db id = 0 ( default ) requestor — mpid3 last request : 1 — no earlier request request : # 2 — second request flags : step ( f ) mp3 responds to the db request with list of lsas db request : # 2 topology db id requestor : mpid2 last request ( 1 ), current request ( 2 ) flags : sn ie — start with lsa4 , end with lsa4 ( g - 2 ) ack ie : db # 0 , last - req ( 2 ), ack ( 1 - 3 ) steps ( h ) mp2 responds with the list of lsa in a topology message ( lsdb ) fig1 illustrates , by way of non - limiting example , multiple nodes interacting to update each link state databases . mesh point 1 , 2 , 3 and 4 interact to bring the database up . embodiments of this invention allows a database update based on a full or a partial list of lsa sequence numbers . for the database transmission , the database request message determines the side that will transmit the database . if the requests come in simultaneously , the tie breaking goes to the lowest mesh point node id ( mac address ). in embodiments of the invention , the mac address grouping id provides scalable mac address that may be added or deleted in large groups . mac addressees may be added or delete from the large group id . embodiments of this invention include a “ ra - hello ” protocol that can provide 1 - hop to 2 - hop connectivity in a wireless mesh network based on inclusion of fields in the beacon message for wireless . such embodiments include tlvs that can be used in the beacon message , rules for interacting with the beacon , and hello process rules ( inbound and outbound .) this ra - hello protocol provides a quick start topology knowledge that can stabilize a network while the wireless mesh routing protocols exchange databases . fig1 shows the tlvs that can be supported in as part of the “ ra - hello ”. most of these tlvs are also used on the tlvs passed in the extensions to the link state update . the new tlvs are as follows : hello timers — a type - length - value that includes : hello interval time and dead router interval time . traffic engineering metric — contains a constraint map that indicates the use of the node weight and link weight . the ra hello can be carried in 802 . 11 beacon , probe responses and mesh reports . the implied information in the frame is the neighbor ( from the source mac address ) and the time stamp . the minimal set of information is the wi - mesh protocol field . other fields that may be included in the routing ie include : mpid of neighbor &# 39 ; s neighbor , routing - aware metric , topology - aware metric , mlid routing capability — bit per routing m fields forwarding ie ( in embodiments , default unicast and / or power may be supported ) traffic engineering ie ( optional ) hello timers unicast mac ee ( optional ) multicast mac ie ( optional , none ) environmental ie — qos m — impacts links & amp ; nodes resource ie parameters as & amp ; captive portal weighted per node resource functions may impact node or link calculations embodiments of the invention include the following method for processing inbound ra - hello messages : 1 . process beacon headers & amp ; sanity check routing information . if illegal , drop packet . 2 . process the security sections of the routing header to see if md5 hash is present . if so , compare the md5 hash field with the calculated md5 . if no match , drop packet . 3 . if encrypted , decrypt the packet . 4 . get packet , and reset dead link timer . process hello information for neighbor as adjacency information , but flag with current security level ( none , md5 , or encrypted ) 5 . if security association needs to be established or changed , go through security association process . if secure association fails , drop the mesh link that this hello came in on . if secure association is valid , set the adjacency to secure . 6 . start the topology update request process ( by requesting database update ) & amp ; processing update information embodiments of the invention include the following method for processing out - bound ra hello messages : 1 . upon initializing , discover the links that are valid 2 . determine the security parameters for each link & amp ; configured neighbors such as md5 authentication , as priority , rsn ie information , pmk ( announce , mic or shared key ) 3 . schedule sending first hello with beacon information based on beacon set - ups 4 . upon receiving 1st neighbors hello , go through hello process a . if there is data received from wsta , keep trying to establish b . if no data , back - off the hello interval . fig1 provides an overview of a multi - node use of the “ ack ” field in the hello message . the hello tlvs are sent with a sequence number . this sequence number is echoed in the neighbor &# 39 ; s hello in the neighbor information . the ack list in the link state database also gives the sequence number for the last received hello . this sequence number allows updates based on hello message information to be tracked in the exchanges . thus if the database is out of date because it hasn &# 39 ; t processed link state updates or hello updates , it will be reflected in the hello message . this check allows quick debugging of slowed processing due to cpu or memory overloads . embodiments of the invention support on - demand group keys based on a mac address or group of mac address via additions to the flag for passing group mac addresses to indicate that : flag1 : on - demand group key for these mac addresses are to be obtain from the security process ( either as a pre - shared key ) or as a result from an 802 . 1x exchange with the appropriate authentication service , flag 2 : on - demand node group key has been obtain for this mac address , and flag 3 : a flag that group encryption and forwarding has been established for this node . these flags are carried as part of the group mac address with the “ flag ” world per group address . if flag 1 is on , the mesh point will , in embodiments of the invention , insert “ hints ” into an expanded rsn ie ( denoted here as an m - rsn ie ) via 802 . 11i to initiate the 802 . 1x authentication . if flag 1 goes off , then the mesh point no longer needs the on - demand group key . if flag 2 is on , the link state topology update mechanisms or the ra - hello topology mechanism , can start to calculate a path between all nodes transmitting to a group address or listening to a group mac data stream . flag 3 , indicates that the path calculations has completed at this time . an additional embodiment of this invention enables the securing of multicast keys to a group leader per multicast group ( elected by a combination of policy and mesh point id ). in some such embodiments , the multicast key group leader is located with good connectivity to an authentication server . the embodiments and examples provided herein are for example purposes only . many alternatives , variants , and equivalents shall be readily apparent to those skilled in the art .