1. TBR Centralized Routing Extension
May 2006
doc.: IEEE /0630r0
May 2006
TBR Centralized Routing Extension
Date:
Authors:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Youiti Kado, et.al.
Youiti Kado, et.al.

2. Motivations Approach Proposing an extension of TBR
May 2006
Motivations
Eliminate the intra-mesh RREQ flooding and reduce routing overhead.
Disperse the intra-mesh traffics and balance the traffics towards the Root.
Notice: We consider the network topology to support the legacy STAs deployment in traffic management, for providing real-time voice services in offices, campuses and cities.
Approach
Proposing an extension of TBR
Collecting topology information in order to enable the Root to calculate an appropriate path for source-destination pair.
This approach can be simply applied to the TBR by setting an administration mode.
When the administration mode flag is set,
Each MP may piggyback the neighbor list information and the corresponding link metrics into gratuitous RREP destined to Root
Root may notify the appropriate path for the SRC-DST pair to the SRC/DST/BOTH
Youiti Kado, et.al.

3. TBR’s Administration Mode
May 2006
TBR’s Administration Mode
Example: MP3 wants to communicate with MP5 X 4 5 7 8 2 6 3 1 9
Message
(unicast)
SRC (MP3) may unicast message destined to DST (MP5) via Root as a normal function of TBR.
When Root determines an appropriate route from SRC to DST, Root may generate a RSET and unicasts it to DST.
Upon receiving RSET, DST generates a RNTF and forwards the RNTF to MP7.
Upon receiving RNTF, MP7 updates its routing table and forwards the RNTF destined to SRC via MP4.
After receiving RNTF, SRC updates its route table and starts transmission along the updated route.
Note: Root also can send the RSET destined to SRC/BOTH. X 1 2
RSET
(unicast)
DST 3 4
DST 5
SRC
SRC 6 7 8 9 X X 1 1 2 2
DST
DST 3 4
RNTF
(unicast) 3 4
Message
(unicast)
SRC 5
SRC 5 6 7 8 6 7 8 9 9
Youiti Kado, et.al.

4. Compatibility (AODV + TBR-A) Route Entry Maintenance May 2006 1 2 3 4X
TBR-A path 1 2
AODV path 3 4
TBR-A’s MP 5 6 7 8 9
In TBR-A, the route entry is maintained based on the same rule as that in AODV.
When the route maintenance of AODV and TBR-A co-exist in the same mesh network, the AODV’s entry has a higher priority than the TBR-A’s entry.
MP7 creates/maintains/updates its route entry based on the control messages of AODV
Youiti Kado, et.al.

5. Compatibility (AODV + TBR-A) Sequence Number Synchronization May 2006
doc.: IEEE /0630r0
May 2006
Compatibility
(AODV + TBR-A)
Sequence Number Synchronization
RNTF (TBR-A path)
Periodical
RREQ
(broadcast) 4 5 7 8 2 6 3 1 9
RREP (AODV path)
RREP
(unicast) 1 2
RSET (unicast) 3 4 5
RNTF
(unicast) 6 7 8 9
In TBR, when a destination MP originates a RNTF in response to a RSET, the destination MP MUST increase its own sequence number of most up-to-date sequence number in either RREP or RNTF for the purpose of synchronization.
Youiti Kado, et.al.
Youiti Kado, et.al.

6. RERR Processing for Link Break
May 2006
RERR Processing for Link Break
When MP7 detects a link break for the link between MP7 and MP5, then it
unicasts a Gratuitous RREP to Root immediately
generates a RERR and sends it along the notified route in reserving way.
invalidates the route entry of the unreachable destination.
Upon receiving the RERR, MPs along the notified route invalidate their route entry corresponding to the unreachable destination.
Link Break
RERR
(unicast) X 4 5 7 8 2 6 3 1 9
Gratuitous RREP
Youiti Kado, et.al.

7. Benefits of Eliminating RREQ Flooding & Reducing Routing Overhead
May 2006
Benefits of Eliminating RREQ Flooding & Reducing Routing Overhead
Route Discovery
Route Maintenance
Root
1-hop link
Root X
TBR-A’s RSET 1
AODV’s RREQ 2 1 2
TBR tree-path 3 4 5 3 4 5 6 7 8 20 20 6 7 8 21 9 10 22 9 21 22 10 11 23 24 25 12 25 23 12 24 11 13 28 14 15 26 27 28 26 27 14 15 16 17 29 18 17 29 18
When MPs exist densely in the situation of offices or cities, AODV couldn’t build a route soon due to the RREQ broadcast storm. Then, the traffics concentrate on the Root. TBR-A can solve this problem by quick route recommendation from Root.
In order to maintain the route from MP6 to MP22, TBR-A has no need to flood the RREQ periodically and route maintenance is performed only when it is necessary in TBR-A.
Youiti Kado, et.al.

8. Benefits of Centralized Load Balancing
May 2006
Benefits of Centralized Load Balancing
Traffics towards the Root
Intra-mesh Traffics
Root
Root X X
AODV path 1
TBR-A path 1 2 2
TBR path 3 4 3 4 5
TBR tree-path 5 20
Congested area 20 6 7 8 6 7 8 9 21 22 9 21 22 10 10 25 25 23 23 12 24 12 24 11 11 28 28 26 27 26 27 14 15 14 15 17 29 17 29 18 18
Based on the topology map that computed by the Root, MP12 is recommended to select a new parent MP (e.g. MP10). As a result, the traffic load can be well-balanced on the tree-path from MP12 and as well as MP24 towards to the Root.
When MP6 wants to communicate with MP22, Root can recommend MP6 to select a route via the intermediate MPs that are not in the congested area.
Youiti Kado, et.al.

9. Changes in RANN Element Format
May 2006
Changes in RANN Element Format
Octets: 1 1 6 4 ID
Length
Flag
Mesh Portal Bridge ID
Priority
Number of Mesh Portals
Mesh Portal Address
Root Sequence Number 4 1 6
Lifetime
Root Metric
Topology Maintenance Policy
Connected Mesh Portal IDs #1 …
Connected Mesh Portal IDs #N
Flag Field
Reserved
Bit #0 #1 #2 #3 #4 #5 #6 #7
Administration Mode
(0=Disabled; 1=Enabled)
Announcement Type
(0=Portal; 1=Root)
HWMP Registration
(0=Disabled; 1=Enabled)
Youiti Kado, et.al.

10. Changes in RREP Element Format
May 2006
Changes in RREP Element Format
Octets: 1 1 6 4 ID
Length
Mode Flag
Source Count
Destination Address
Destination Sequence Number
Lifetime
Metric 6 4
Source Address #1
Source Sequence Number #1 …
Source Address #N
Source Sequence Number #N 1 6 4
Number of Neighbor Nodes
Neighbor Node Address #1
Neighbor Node Link Metric #1 …
Neighbor Node Address #N
Neighbor Node Link Metric #N
Youiti Kado, et.al.

11. RSET Element Format RNTF Element Format
May 2006
RSET Element Format
Octets: 1 1 6 4 ID
Length
Flag
RSET ID
Root Address
Root Sequence Number
Lifetime 1 6
Number of Nodes
Node Address #1
(Notifying Node) …
Node Address #N
(Route Source)
RNTF Element Format
Octets: 1 1 6 4 ID
Length
Flag
RNTF ID
Notifying Node Address
Notifying Node Sequence Number
Lifetime 6 4 1
Root Address
Root Sequence Number
Cumulative
Link Metric
Number of Nodes
Node Address #1
(Notifying Node) …
Node Address #N
(Route Source)
Youiti Kado, et.al.

12. … … May 2006 11A.4.3.1.3.1 TBR Topology maintenance (optional)
In HWMP, a tree topology is built when the root enabled the HWMP-Registration flag in the root announcement message. By using the same message, the root also can provide a centralized scheme by enabling the HWMP-Administration flag in order to provide high efficiency and manageability of the whole network topology. Based on the centralized scheme, wireless mesh network can provide a wide range of benefits, such as emergency services, load balancing, multi-channel operations, and etc. If the HWMP-Administration flag is set in the announcement message, MPs upload the route reply message with the list of neighbor information. The root uses a path selection algorithm (the algorithm is out of scope for this specification) for selecting the valid paths for a destination and then choosing the best-metric among the valid paths. Based on these information, the root can build a whole network topology in addition to the tree topology and also able to provide the best-metric route for each source-destination pair. For a source MP wants to send a message, the root notifies a destination MP and the corresponding intermediate MPs about the route information by using a route set message to the destination MP. Then, the destination MP notifies the intermediate MPs along the route with a route notification message. With this new set of communication rules, the centralized scheme in corresponding to traffic, QoS, channel and etc is feasible. …
Youiti Kado, et.al.

13. May 2006 …
Whenever an MP chooses a new parent in the tree, it checks the HWMP-Administration flag in the root announcement message. If this flag is set, it sends a gratuitous RREP with a list of neighbor interface information to the root. Each intermediate MPs hearing the gratuitous RREP adds the MP address contained in the message to its forwarding table. These gratuitous RREP messages are needed by the Root in order to compute the whole network topology. As the MPs move to the "Forwarding" state only after completing topology administration with Root. …
Youiti Kado, et.al.

14. May 2006
Backup Slides
Youiti Kado, et.al.

15. Benefits Quickly Dispersing Root Traffic May 2006 Outside Mesh
120% load
Overloaded
80% load
Root
Outside Mesh X 1 2 3 4
40% load 5 6 7 8
Portal 9
When MP2 wants to send its traffic to outside mesh network, Root can disperse MP2’s traffic via MP8 in order to avoid the overloaded condition.
Youiti Kado, et.al.