doc.: ieee 802.11-05/0572r1 submission june 2005 j. z. tao, s. s. panwar, polytechnic...

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


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


Slide 3

doc.: IEEE 802.11-05/0572r1

Submission

Outline

• Mesh Routing Architecture• Mesh Broadcast• Mesh Multicast

June 2005


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

doc.: ieee 802.11-05/0572r1 submission june 2005 j. z. tao, s. s. panwar, polytechnic...

Documents