Doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 1 Tree Based...

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


Slide 2

doc.: IEEE 802.11-05/0641r1

Submission

Agenda

• Introduction

• Baseline for TGs: tree based routing

• Description

• Message formats

• Summary

July 2005


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


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


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


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


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


Slide 8

doc.: IEEE 802.11-05/0641r1

Submission

Optional Services

• ??

• ??

• ??

•??

• Connectivity

• Security

• QoS

• Management

Category Specifics

July 2005


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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



July 2005


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


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


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


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


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


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


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

Doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 1 Tree Based...

Documents

Transcript of Doc.: IEEE 802.11-05/0641r1 Submission July 2005 Jan Kruys, Shah Rahman.e.a, CiscoSlide 1 Tree Based...