doc.: ieee 802.11-05/0641r1 submission july 2005 jan kruys, shah rahman.e.a, ciscoslide 1 tree based...
TRANSCRIPT
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 1
doc.: IEEE 802.11-05/0641r1
Submission
Tree Based Routing Protocol
2005-07-11
NOTE: this document replaces document 11-05-0607-00-000s wstp-mesh-presentation
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]>.
Name Company Address Phone E-mail
Shah Rahman Cisco
Systems +1 408 5251351 [email protected]
Jan Kruys Cisco
Systems Int’l + 31 20 357 2447 [email protected]
??
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 2
doc.: IEEE 802.11-05/0641r1
Submission
Agenda
• Introduction
• Baseline for TGs: tree based routing
• Description
• Message formats
• Summary
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 3
doc.: IEEE 802.11-05/0641r1
Submission
Introduction
• Mesh is way of putting networks together – not a technology
• IEEE standards are intended to have broad applicability
Taking a step back
• Networks are used for many purposes
• There is no single best “way”
• TGs has to address many ways of using mesh networks
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 4
doc.: IEEE 802.11-05/0641r1
Submission
Main dimensions of (mesh) networking
• These four dimensions are actually two pairs of opposing dimensions
• Having your cake and eating it does not go together
• We have to make choices or offer alternatives
• The users will decide whether we did the right thing
mobility
simplicity
functionality
Network size
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 5
doc.: IEEE 802.11-05/0641r1
Submission
The focus of this proposal
• Simplicity and the ability to handle large scale networks is a key to major market segments like municipal and enterprises networks
• Home and small business are implicitly supported
• (Mesh) functionality and mobility not maximized
mobility
simplicity
functionality
Network size
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 6
doc.: IEEE 802.11-05/0641r1
Submission
Basic Requirements
• Connectivity – hooking nodes together
• Security – protect data and the network
• QoS – to meet the needs of users
• Management – to control the network
• Discovery, binding and routing – new work
• 802.11i/w/r – with minimal adaptations
• 802.11e – possibly without adaptations
• 802.11 base + exten-sions for mesh services
What How
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 7
doc.: IEEE 802.11-05/0641r1
Submission
Basic Services
• Connectivity
• Security
• QoS
• Management
Category Specifics
Mesh Topology Discovery
Probing/Beaconing
Modes of binding
Data Routing/Forwarding
Interworking Support
Node Authentication
Intra-mesh Key Management
Traffic classes
Intra-Mesh Congestion Control
RF channels
Binding Criteria
Master Key and Credentials
QoS Management
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 8
doc.: IEEE 802.11-05/0641r1
Submission
Optional Services
• ??
• ??
• ??
•??
• Connectivity
• Security
• QoS
• Management
Category Specifics
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 9
doc.: IEEE 802.11-05/0641r1
Submission
Routing/Forwarding at Layer 2
• Todate, the wired world relies on STP – which is still developing and improving
• But STP is not “wireless aware”
• Changing that takes time
• Little experience with wireless Layer 2 routing
• Most work is concentrating on Layer 3 solutions
– Many products combine Layer 2 and Layer 3
— which improves flexibility
• “down porting” of Layer 3 solutions to Layer 2 risks mixing incompatible designs and functions
• Issues with IP and 802 LAN Interworking
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 10
doc.: IEEE 802.11-05/0641r1
Submission
Our proposal:
• Use a simplified version of STP as baseline
– Serves a broad range of wireless environments
• Rely on extensibility of the standard to allow
– A wireless version of STP to be incorporated as it is developed by 802.1
– Other, application specific routing protocols
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 11
doc.: IEEE 802.11-05/0641r1
Submission
Tree Based Routing
• Aimed at the typical access network: “fixed” installations • but that also works well for small, flat meshes
• Organises mesh points into tree structures rooted in major information sources/sinks:
– Portals to other (sub)networks - in any scenario– Local Servers - in the office– Screens, DVDs, PCs at home
• Applications with more demanding requirements are better served by routing schemes that focus on mobility and frequent configuration change
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 12
doc.: IEEE 802.11-05/0641r1
Submission
TBR Example: Home
6 devices from two simple trees with a number of back-up paths
CABLE
HDTV
PC3
PC2
PC1
ENT. Srvr
ENT.SVR
HDTV
PC1
CABLE
PC3
PC2
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 13
doc.: IEEE 802.11-05/0641r1
Submission
TBR Example: wireless LAN in an SMB
APs in the workshops and offices are connected by two trees, both rooted in the same fibre feedpoint
APFibre
feedpoint
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 14
doc.: IEEE 802.11-05/0641r1
Submission
active links
alternate/backup links
Root (Portal)Branch NodeLeaf Node
TBR Example: Hotspot/Municipal
Six trees of Access Points, all rooted in one portal
Any of the “cells” can be the root of a back-up tree
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 15
doc.: IEEE 802.11-05/0641r1
Submission
Tree Construction
Trees are easy to constructand maintain:
- N sends out a requestand gets responses- N learns the path to the root(distance vector, link metrics)- N picks the best and links up
Pre-conditions: - Roots announce themselves - Mesh points recognize roots (like STA’s recognize IBSS’ses
Root
N
4
7
5
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 16
doc.: IEEE 802.11-05/0641r1
Submission
State Machine (per tree)
Seek Potential Upstream neighbour
More candidates
All good neighbours associated
Associate
Monitor
Activate back-up in case a link fails
Lost path to root
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 17
doc.: IEEE 802.11-05/0641r1
Submission
Link Metrics
• The question is: “will my packet make it quickly to the root”
• Factors that play a role: net link rate, current load uplink and hop count to root
• Further (radio metric) detail data is overkill
• SNR is a good predictor of net link rate
• Going down link is easier: traffic fans out
• Routing metric data reported by neighbours: upstream SNR and load, hops
• Supports simple distributed congestion control
• Processing and decision making is a local matter and outside scope
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 18
doc.: IEEE 802.11-05/0641r1
Submission
Security and Maintenance Security:- node authentication per 802.11i with AAA server basedor PSK/certificate based
- data security by link level encryption
Maintenance:- regular neighbor status checks
Recovery:- re-do constructionbut only towards the root
Root
N
4
7
5
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 19
doc.: IEEE 802.11-05/0641r1
Submission
Internal Addressing
• Each root (portal, server, etc) has its own tree = its own subnet. It may have more than one.
• Each mesh access point advertises the subnets it is on to STAs (e.g. by different SSIDs)
• ARP broadcasts from STAs are sent on the subnet chosen by the STA
• Intermediate mesh points learn end mesh node addresses from unicasts
• Portals learn STA addresses and the path they are on – if the path changes, the portal updates the path
• Loops are prevented by ignoring downstream broadcasts that carry the own source address
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 20
doc.: IEEE 802.11-05/0641r1
Submission
Forwarding and Interworking
• Edge nodes encapsulate STA packets, add a “mesh” header and transmit the packet up the tree
• Mesh points that receive such a packet pass it on and update the “down path” if necessary
• A portal updates its local routing tables and passes the de-capsulated packet to the wire
• Unicast packets from the wire are encapsulated sent down the tree
- Portals may perform proxy ARP and proxy DHCP to avoid forwarding broadcasts between inside and outside
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 21
doc.: IEEE 802.11-05/0641r1
Submission
Multiple Trees Multiple portals =multiple roots
A root can beany node thatis a sourceor sink of information
One node can be on two trees:e.g. B9 has a pathto A and to B.
No coupling between trees at common nodes
Root A
A4
A9
A5
Root B
B3
B9
B5 B6B4A8
A7
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 22
doc.: IEEE 802.11-05/0641r1
Submission
QoS/Overlapping trees Basic QoS through use of 802.11e
More advanced QoS: use multiple trees formultiple service levels
Traffic classes aremapped to treesas required
No special protocol needed
Root A
A7
A5
Root B
B7
B5
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 23
doc.: IEEE 802.11-05/0641r1
Submission
MP and STA Mobility Mesh points:
Mesh point mobility is handled by hookingup to another node
802.11 STAs:
Mesh (access) points, and portals learn addresses and keep routing tables
Root A
A7
A5
STA
STA
A2
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 24
doc.: IEEE 802.11-05/0641r1
Submission
Scalability
Replication allows scaling to almost any size network
Root/Bridge
Mesh 1
Root/Bridge
Mesh 2
Root/Bridge
Mesh 4
Root/Bridge
Mesh 3
RSTP/MST
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 25
doc.: IEEE 802.11-05/0641r1
Submission
Other aspects
Quick to configure/recover (see next slide)
Transparent to the use of single or multiple radios
Compatible with any security scheme
Orthogonal to power save modes, lightweight binding, etc.
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 26
doc.: IEEE 802.11-05/0641r1
Submission
Configuration time - example
No Flooding: One hop Neighbour Requests drive the process
A node keeps “polling” until it finds a suitable path
Assuming a 50msec poll cycle, it takes 3 to 5 cycles to get the tree mapped
= < 250msec
The medium load is in the range of 84 to 140 packets
= <50msec or < 20%
8 Requests, 8 Responses
4 Requests, 4 Responses
2 Requests, 2 Responses
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 27
doc.: IEEE 802.11-05/0641r1
Submission
Message Formats- general
• Define new Type/Subtype for mesh specifics like topology functions
• Subtypes for control, data, management
• Minimize new message definitions – encapsulate existing ones
• Mesh header can provide additional context – if needed• Maximizes re-use of exiting functions• Would allow – but not require – transparent tunneling
within the mesh
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 28
doc.: IEEE 802.11-05/0641r1
Submission
Message Formats- topology discovery and maintenance
Neighbour Request (broadcast and unicast)
Neighbour Response (unicast, periodic broadcast optional)
MAC HDR(Mesh type)
Mesh ID
Request Code
Candidate Address
FCS
MAC HDR(Mesh Type)
Mesh ID
Response Code
MeshInfo
# of Uplinks
Per uplink
Root ID RootInfo
Path cost
FCS
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 29
doc.: IEEE 802.11-05/0641r1
Submission
Message Formats- binding
Binding Request (unicast)
Binding Response (unicast)
MAC HDR(Mesh type)
Mesh ID
Binding Request Code
Payload = 802.11 Ass. Req.
FCS
MAC HDR(Mesh type)
Mesh ID
BindingResponse Code
Payload = 802.11 Ass. Resp.
FCS
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 30
doc.: IEEE 802.11-05/0641r1
Submission
Message Formats- data transmission & management
MAC HDR(Mesh Type)
Mesh ID Data or Man’t encap
Flow control = up (down)
Payload (source packet)
FCS
Unicast
Broadcast
MAC HDR(Mesh Type)
Mesh ID Data or Man’t encap
Flow control= up (down)
Payload (source packet)
FCS
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 31
doc.: IEEE 802.11-05/0641r1
Submission
SummaryThe tree based routing protocol proposed here meets all basic requirements
• It is very simple to implement and effective in practical use
• It would serve nicely as a low cost baseline for the TGs standard
Tree based routing is an easy first step towards a full blown wireless bridging protocol that we can leave to 802.1 to develop
Other routing protocols that meet the specific needs of specific applications or market segments, can be detailed and specified separately – possibly as options in annexes to the standard or as open, published specifications
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 32
doc.: IEEE 802.11-05/0641r1
Submission
What the standard has to contain
• All information needed for baseline interoperability
• Message formats • Behaviour associated with message processing and
generation
• Baseline interoperability• Mesh discovery
– Including routing scheme resolution and optional feature detection/exchange
• Mesh binding – minimum subset– 802.11i based binding– Extension by options
• Data forwarding – by encapsulation– Extension by options
• Basic management functions– Extension by options
July 2005
Jan Kruys, Shah Rahman.e.a, Cisco
Slide 33
doc.: IEEE 802.11-05/0641r1
Submission
TGs Mesh Requirements covered
• MAC-based routing protocol and algorithm
• Dynamic auto-configuration
• At least one radio-aware routing metric
• Alternative path selection metrics and/or protocols
• Support unicast, broadcast, multicast
• Interworking as simple LAN sgment
• Transparent for existing 802.11 implementations
• Support for single or multiple radios on mesh points
• Scalable to 32 mesh points and beyond