A Routing Architecture and Multicasting for Mesh Networks

Document Sample
A Routing Architecture and Multicasting for Mesh Networks Powered By Docstoc
					June 2005                                                                                                                 doc.: IEEE 802.11-05/0572r1

       A Routing Architecture and Multicasting
                 for Mesh Networks
                                                                        Date: 2005-06-14
Authors:
Name                                  Company                            Address                                    Phone                           email
Jeffrey (Zhifeng) Polytechnic                                            6 Metrotech Center, 917-977-0908                                           jefftao@photon.poly.edu
Tao               University                                             Brooklyn, NY,
                                                                         11201
Shivendra S.                          Polytechnic                        6 Metrotech Center, 718-260-3740                                           panwar@catt.poly.edu
Panwar                                University                         Brooklyn, NY,
                                                                         11201


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
<stuart.kerry@philips.com> 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 <patcom@ieee.org>.


Submission                                                                                 Slide 1                          J. Z. Tao, S. S. Panwar, Polytechnic University
June 2005                                      doc.: IEEE 802.11-05/0572r1




        A Routing Architecture and Multicasting for
                     Mesh Networks

                           Jeffrey (Zhifeng) Tao
                           Shivendra S. Panwar

             Department of Electrical and Computer Engineering
                          Polytechnic University
                               Brooklyn, NY




Submission                         Slide 2     J. Z. Tao, S. S. Panwar, Polytechnic University
June 2005                         doc.: IEEE 802.11-05/0572r1

                     Outline

  • Mesh Routing Architecture
  • Mesh Broadcast
  • Mesh Multicast




Submission              Slide 3   J. Z. Tao, S. S. Panwar, Polytechnic University
June 2005                                        doc.: IEEE 802.11-05/0572r1

               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




Submission                           Slide 4      J. Z. Tao, S. S. Panwar, Polytechnic University
June 2005                                                             doc.: IEEE 802.11-05/0572r1

                         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
Submission                                              Slide 5        J. Z. Tao, S. S. Panwar, Polytechnic University
June 2005                                                doc.: IEEE 802.11-05/0572r1

                             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.




Submission                                 Slide 6           J. Z. Tao, S. S. Panwar, Polytechnic University
June 2005                                              doc.: IEEE 802.11-05/0572r1

                               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




Submission                                   Slide 7   J. Z. Tao, S. S. Panwar, Polytechnic University
June 2005                                                             doc.: IEEE 802.11-05/0572r1

                      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.


Submission                                            Slide 8          J. Z. Tao, S. S. Panwar, Polytechnic University
    June 2005                                                            doc.: IEEE 802.11-05/0572r1

                           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.




    Submission                                          Slide 9           J. Z. Tao, S. S. Panwar, Polytechnic University
 June 2005                                      doc.: IEEE 802.11-05/0572r1

                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.




 Submission                         Slide 10     J. Z. Tao, S. S. Panwar, Polytechnic University
June 2005                                 doc.: IEEE 802.11-05/0572r1

               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.




Submission                     Slide 11   J. Z. Tao, S. S. Panwar, Polytechnic University
    June 2005                                                                  doc.: IEEE 802.11-05/0572r1

             Mobility Support and Loop Avoidance
•     Due to mobility or node failure,                                               RP
      “JOIN_ACK” and                                                                        MP2
      “JOIN_REQ” may traverse
      through different paths. The                                       MP1
                                                                                                      MP3
      activation of forwarding state
                                                                                                                MAP5
      upon the reception of a                                     MAP4                    STA
      “JOIN_ACK” allows the tree to
                                                                                                                    BSS 2
      use the most up-to-date route.
                                                               BSS 1

•     Loop avoidance                                                                  Legend
        – Problem (an example)                                               JOIN_REQ                         JOIN_ACK
                 • MAP5 sends a “JOIN_REQ”                                   Multicast tree                   Loop
                 • 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”

    Submission                                             Slide 12            J. Z. Tao, S. S. Panwar, Polytechnic University
    June 2005                                                    doc.: IEEE 802.11-05/0572r1

                 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                                             RP
      significance
        – Every multicast frame traverses each MP/MAP on the tree
                                                                                    MP1                 MP2
          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
                                                                                    MP29                MP30
      load distribution.

•     An extreme example                                                                                 MP31
        – 32 MP/MAPs
        – Instead of directly sending to MP29, MP31 has to traverse
          through the entire tree via RP/Core to deliver its multicast                       Legend
          packet to MP29.                                                                          Optimal path
        – The real delay could be approximately 31 times of the                                  Multicast tree
          minimum delay.

    Submission                                   Slide 13         J. Z. Tao, S. S. Panwar, Polytechnic University
June 2005                                                              doc.: IEEE 802.11-05/0572r1

                                    Per-Source Tree
                                                                                                    RP
•   To address the problem of imbalanced tree,
    receivers that meet the certain requirements can
    initiate a switch-over to a per-source tree multicast                                 MP1
                                                                                                Y        Z   MP2
    approach.                                                                                        X

•   Switch-over criteria                                                            MP3             MP4             MP5

     – If (Y+Z) >> X
             • The hop count from source (MAP6) to receiver (MAP7)
               via the RP/Core is greater than the direct distance between
                                                                                   MAP6                             MAP7
               the source and receiver by a certain threshold
                                                                                                                   Receiver
     – If Z >> X                                                                 Source
             • The direct distance between RP/Core and receiver (MAP7)
               is greater than the direct distance between the source and                           Legend
               the receiver by a certain threshold                                                  Distance between
     – If the multicast MAC data frame is of either AC_VO                                           two end points
       (voice) or AC_VI (video).                                                                  Multicast tree
                                                                                                  The new
                                                                                                  optimal path



Submission                                           Slide 14          J. Z. Tao, S. S. Panwar, Polytechnic University
June 2005                                                         doc.: IEEE 802.11-05/0572r1

                                 Per-Source Tree
                                                                                              RP
 •    Switch-over procedure
       – The receiver (MAP7) sends a source specific                                  MP1             MP2
         “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                           MP3           MP4            MP5
         “JOIN_ACK”
       – The MP/MAPs along the new path
             • Sends back a “JOIN_ACK” to its downstream
                                                                              MAP6                            MAP7
               MP/MAP, and
             • Activates the corresponding forwarding state.                  Source                        Receiver
       – The receiver (MAP7) sends a “DEPART_REQ” to
         its previous upstream MP/MAP (e.g., MP5) for                                         Legend
         pruning.                                                                              JOIN_REQ
       – The previous upstream MP/MAP (e.g., MP5)                                              JOIN_ACK
             • Replies with a “DEPART_ACK”, and                                                DEPART_REQ
             • Sends a “DEPART_REQ”, if it has no downstream                                   DEPART_ACK
               MP/MAPs subscribe to that particular multicast group                            Multicast tree
               any longer.


Submission                                       Slide 15             J. Z. Tao, S. S. Panwar, Polytechnic University
June 2005                                            doc.: IEEE 802.11-05/0572r1

                           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.




Submission                             Slide 16       J. Z. Tao, S. S. Panwar, Polytechnic University
June 2005                                               doc.: IEEE 802.11-05/0572r1

             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.




Submission                                Slide 17       J. Z. Tao, S. S. Panwar, Polytechnic University
June 2005                                                   doc.: IEEE 802.11-05/0572r1

                                    Reference
  [1] D. Eastlake 3 rd, 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




Submission                                   Slide 18        J. Z. Tao, S. S. Panwar, Polytechnic University