June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 1
doc.: IEEE 802.11-05/0572r1
Submission
A Routing Architecture and Multicasting for Mesh Networks
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <[email protected]> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <[email protected]>.
Date: 2005-06-14
Name Company Address Phone email Jeffrey (Zhifeng) Tao
Polytechnic University
6 Metrotech Center, Brooklyn, NY, 11201
917-977-0908 [email protected]
Shivendra S. Panwar
Polytechnic University
6 Metrotech Center, Brooklyn, NY, 11201
718-260-3740 [email protected]
Authors:
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 2
doc.: IEEE 802.11-05/0572r1
Submission
A Routing Architecture and Multicasting for Mesh Networks
Jeffrey (Zhifeng) TaoShivendra S. Panwar
Department of Electrical and Computer Engineering Polytechnic University
Brooklyn, NY
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 3
doc.: IEEE 802.11-05/0572r1
Submission
Outline
• Mesh Routing Architecture• Mesh Broadcast• Mesh Multicast
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 4
doc.: IEEE 802.11-05/0572r1
Submission
Mesh Routing Architecture
• Unicast– Select appropriate link state routing protocol to achieve the optimal
path for unicast traffic between any source and destination MP/MAP pair.
• Broadcast– Reverse path forwarding (RPF)
• Multicast– An adaptive tree-based approach
• Based upon the Rbridge architecture
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 5
doc.: IEEE 802.11-05/0572r1
Submission
Mesh Routing Architecture
• An MAP should– Learn the MAC addresses of all the STAs associated with it in its BSS– Distribute the learnt association/address information among the rest of the MPs/MAPs in
the link state protocol in a periodic manner
• Each MP/MAP should maintain two tables– STA association table
• Map destination STA MAC address to the destination MAP MAC address– Routing table
• Used to select the next MP/MAP to reach the destination MAP.
• Necessary change to the MAC frame format– Use “ToDS = 1, FromDS = 1” for the frames exchanged within the mesh to avoid
confusion with the traffic belonging to each BSS– The four-MAC-address format specified in 802.11 is sufficient.– A hop count field should be included in the MAC frame to avoid loops
• The hop count field is only inserted by MP/MAP into the frame exchanged among WDS.
Acronyms:
Mesh point: MP Mesh Access Point: MAP Station: STA
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 6
doc.: IEEE 802.11-05/0572r1
Submission
Mesh Broadcast
• Reverse path forwarding (RPF)– MP/MAP accepts broadcast MAC frame from source S via
neighbor N, only if N is the neighbor the MP/MAP would forward to in order to reach S.
– Thus, each broadcast frame is transmitted over each link only once.
• Significantly reduce the broadcast traffic.
– Under stationary or low mobility case, RPF achieves good performance in a simple manner.
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 7
doc.: IEEE 802.11-05/0572r1
Submission
Mesh Multicast
• Main features– A protocol based upon core-based tree (CBT) and simple multicast
(SM).
– Multicast based upon the MAC group address
– An adaptive tree structure, which can use shared tree approach or per-source tree approach, according to the traffic and topological condition• Bi-directional shared tree
– Low overhead, sufficient stability
• Per-source tree– Shortest end-to-end path
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 8
doc.: IEEE 802.11-05/0572r1
Submission
Bi-Directional Shared Tree• The bi-directional tree is rooted at a special node, known as “Rendezvous
Point” (RP) or “core”.– Naturally, the portal of a mesh backbone can be configured as the RP/Core for this
shared tree.– If there is no portal in the mesh network, then the RP/Core can be selected based upon
such considerations as mesh topology, load balancing, etc.• The simplest way is to let the MP/MAP which boots up first be the RP/Core.
• Tree graft– For each MP/MAP, which intends to join the multicast group, either by its own will, or
upon the request from the STA associated with it, it unicasts a “JOIN_REQ” message to the RP/Core.
– For the MP/MAP which receives a “JOIN_REQ” message, • If it has already joined the corresponding tree, it stops forwarding the “JOIN_REQ”, and
responds with a “JOIN_ACK”.• If it hasn’t join the tree yet, it forwards the “JOIN_REQ” to its next hop toward the RP/Core.
– For the MP/MAP which receives a “JOIN_ACK” message, • It activates the forwarding state for that group.
– Eventually, each MP/MAP, who is a member of the group, or whose affiliated STA is a member of the group, should be included in this tree.
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 9
doc.: IEEE 802.11-05/0572r1
Submission
Bi-Directional Shared Tree• Tree prune
– When an MP/MAP realizes that none of its downstream MP/MAP (or its associated STAs) subscribes to the multicast group any longer, it sends a “DEPART_REQ” to its upstream MP/MAP.
– The upstream MP/MAP replies with a “DEPART_ACK”.
• Tree repair– If an MP/MAP in the tree detects the unavailability of its upstream MP/MAP (due to
mobility or failure), or it realizes that its shortest path to the RP/Core changes• It sends another “JOIN_REQ” to the RP/Core• Goes through the tree graft procedure.• Prunes itself off from the old upstream MP/MAP, if necessary.
• Forwarding on the shared tree– If any group member MP/MAP sends data to the group, the data will be forwarded to its
upstream neighbor MP/MAP that is on the multicast tree.– Each MP/MAP that receives a frame forwards it to all of its neighbors that are on the tree
except the one where the frame came from.
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 10
doc.: IEEE 802.11-05/0572r1
Submission
Bi-Directional Shared Tree
• Tree maintenance– Each MP/MAP periodically sends a keep-alive message to its neighbors,
both upstream (closer to RP/Core) and downstream (further away from RP/Core).
– This can help in pruning or repairing the tree.– To reduce channel contention, the keep-alive messages can be
piggybacked with the regular link state messages.
• Information/states to keep at each MP/MAP– A multicast group ID– A list of adjacent upstream neighbors and downstream neighbors that are
on the tree for this group.
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 11
doc.: IEEE 802.11-05/0572r1
Submission
Bi-Directional Shared Tree
• Other advantages of the shared tree approach– The RP/Core can be co-located with AAA server to
control access and enforce security.
– The RP/Core can distribute policy list to all the MP/MAPs.
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 12
doc.: IEEE 802.11-05/0572r1
Submission
Mobility Support and Loop Avoidance
• Loop avoidance– Problem (an example)
• MAP5 sends a “JOIN_REQ”• STA moves from BSS 2 to BSS 1.• If the time it takes for “JOIN_REQ” to reach an MP/MAP on the multicast tree (e.g., MP2),
is longer than the total time it takes for MAP4 and MP1 to update the routing information related to STA
– MP2 replies with a “JOIN_ACK” to MP1, instead of to MP3• Thus, MP1, MP2 and RP may form a temporary loop.
– Solution• If an MP/MAP receives a “JOIN_ACK”, and the message is not from the MP/MAP’s
upstream MP/MAP, it should respond with a “DEPART_REQ”
LegendJOIN_REQ JOIN_ACKMulticast tree Loop
• Due to mobility or node failure, “JOIN_ACK” and “JOIN_REQ” may traverse through different paths. The activation of forwarding state upon the reception of a “JOIN_ACK” allows the tree to use the most up-to-date route.
MP1
MP2
RP
MAP5MAP4 STA
BSS 2BSS 1
MP3
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 13
doc.: IEEE 802.11-05/0572r1
Submission
Problem of Imbalanced Shared Tree• Once the shared tree is formed, the RP/Core is just
another node in the tree and has no special significance
– Every multicast frame traverses each MP/MAP on the tree only once.
• But an improperly placed/selected root may result in an imbalanced tree, which in turn may have intolerable adverse impact on delay performance or load distribution.
• An extreme example– 32 MP/MAPs– Instead of directly sending to MP29, MP31 has to traverse
through the entire tree via RP/Core to deliver its multicast packet to MP29.
– The real delay could be approximately 31 times of the minimum delay.
. . .
MP1 MP2
MP29 MP30
MP31
RP
Legend
Optimal path
Multicast tree
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 14
doc.: IEEE 802.11-05/0572r1
Submission
Per-Source Tree• To address the problem of imbalanced tree,
receivers that meet the certain requirements can initiate a switch-over to a per-source tree multicast approach.
• Switch-over criteria– If (Y+Z) >> X
• The hop count from source (MAP6) to receiver (MAP7) via the RP/Core is greater than the direct distance between the source and receiver by a certain threshold
– If Z >> X• The direct distance between RP/Core and receiver
(MAP7) is greater than the direct distance between the source and the receiver by a certain threshold
– If the multicast MAC data frame is of either AC_VO (voice) or AC_VI (video).
MP1 MP2
MP3 MP4 MP5
RP
MAP6 MAP7
Source Receiver
X
Y Z
Legend
Multicast tree
Distance between two end points
The new optimal path
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 15
doc.: IEEE 802.11-05/0572r1
Submission
Per-Source Tree• Switch-over procedure
– The receiver (MAP7) sends a source specific “JOIN_REQ” to the source (MAP6)
– The first MP/MAP along the path which belongs to the multicast group (i.e., MP3) sends back a “JOIN_ACK”
– The MP/MAPs along the new path• Sends back a “JOIN_ACK” to its downstream
MP/MAP, and
• Activates the corresponding forwarding state.
– The receiver (MAP7) sends a “DEPART_REQ” to its previous upstream MP/MAP (e.g., MP5) for pruning.
– The previous upstream MP/MAP (e.g., MP5)• Replies with a “DEPART_ACK”, and
• Sends a “DEPART_REQ”, if it has no downstream MP/MAPs subscribe to that particular multicast group any longer.
Source Receiver
MP1 MP2
MP3 MP4 MP5
RP
MAP6 MAP7
Legend
Multicast tree
JOIN_REQ
DEPART_REQ
JOIN_ACK
DEPART_ACK
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 16
doc.: IEEE 802.11-05/0572r1
Submission
Per-Source Tree• For certain applications, the intended receivers for the multicast
group may include most of the MP/MAPs, if not all.
• The source MP/MAP then can fall back to the RPF approach to reach all the destinations.– Specify the destination MAC address to be a special multicast address
recognized by all MP/MAPs as an indication for RPF.– Set the hop count properly so that all the intended receivers can be
included, with the minimum scope.– Thus, the overhead of tree construction and maintenance can be avoided.
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 17
doc.: IEEE 802.11-05/0572r1
Submission
Interaction with IP Layer Multicast
• IGMP is used to manage groups for IP layer multicast
• Most of the STAs associated with the MAP, if not all, run IP over 802.11 MAC.
• It is highly likely that an IP layer multicast session originated outside the mesh would have multiple receivers inside the mesh.
• Possible cross-layer interaction– IGMP snooping: The MP/MAP can look at the IGMP traffic (which is
encapsulated in IP packet) to assist itself to determine whether or not it should trigger the corresponding tree graft procedure at the MAC layer within the mesh.
June 2005
J. Z. Tao, S. S. Panwar, Polytechnic University
Slide 18
doc.: IEEE 802.11-05/0572r1
Submission
Reference
[1] D. Eastlake 3rd, R. Perlman, “Routing and Rbridges”, IEEE 802.11 TGs document, IEEE 802.11-04/1462r0
[2] R. Perlman, “Rbridges: Transparent routing”, IEEE INFOCOM 2004, Hong Kong, March 2004
[3] T. Ballardie, P. Francis, and J. Crowcroft, “Core based trees (CBT): an architecture for scalable inter-domain multicast routing”, ACM SIGCOMM, 1993
[4] Core based tree (CBT), IETF RFC 2189[5] T. Ballardie, R. Perlman, C. Lee and J. Crowcroft, “Simple Scalable Internet Multicast”,
UCL Research Note RN/99/21[6] Y. Dalal, “Broadcast Protocols in Packet Switched Computer Networks”, Digital System
Laboratory, Department of Electrical Engineering, Stanford University, 1977.[7] S. E. Deering and D. R. Cheriton, “Multicast routing in datagram internetworks and
extended LANs”, ACM Transactions on Computer Systems, 1990[8] Distance vector multicast routing protocol (DVMRP), IETF RFC 1075[9] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, A. Helmy and L. Wei, “Protocol
independent multicast version 2, dense mode specification”, IETF Internet draft, 1997[10] Protocol independent multicast, sparse mode, IETF RFC 2362