802 Architecture Group

Website:

http://www.ieee802.org/1/files/public/802_architecture_group/

Joining the Email exploder:http://www.ieee802.org/1/email-pages/joining.html

Intent

• Improve alignment between WG projects and existing 802 architecture by:– Identifying current problems, omissions, conflicts,

ramifications, and their potential resolution– Identifying potential refinements or changes to the

architecture– Providing a regular forum in which such discussion can

take place, in a lower pressure environment than is possible during the core Plenary cycle.

Mechanism

• A meeting per Plenary cycle– Chaired by 802.1 Chair– Time slot: 2-5 PM Sunday prior to Plenary– Participants: Initially, WG Chairs plus one (or more)

“architects” or “technical leads”; long term, whoever the Chair determines is appropriate/willing

– Meeting Topic: Architectural issues known to each WG & how they might be resolved

• First meeting: July 2004

Purpose

• To actually have a recurring discussion on architectural issues

• To improve cross-WG discussion/understanding

• To promote a common view

Outputs

• Not detail document oriented• Consensus, frame of mind, consciousness raising• Maybe slideware if appropriate• Topics/thoughts for the focus of the next

discussion• Encouragement to WGs to fix identified problems

in appropriate ways• Simple architecture• Preservation of layering

Actions

• SEC to formally establish the activity as a SEC standing committee.

• WG Chairs to appoint max 2 nominated participants per WG– Qualifications for participants: Capable of generating a

durable architecture. Capable of knowing the difference between an architecture, a product, and a standard. Respected within their WG as subject matter experts.

• Report to SEC on status at each meeting.

Known issues – 802.1• MAC Service definition (currently a revision PAR in place)• QoS – could be better expressed• Security expressed as a set of procedures after network entry• Management – scope and interface

– Commonality of MAC/PHY management interfaces (managed object definitions)

• MIB definition for service discovery• Where work gets done – 802.1 vs 802.X• Process – ensuring due diligence• Max frame size• Position/location awareness

Known issues – 802.3• QoS/class of service

– Timing, synchronous, guaranteed bandwidth, low jitter/latency, congestion management…– Need a consistent architecture for QOS across 802 so we can switch between port types.– Many questions coming from many new projects across the MAC groups.

• Ethernet/TCP-IP interdependence– Do we care about anything non-TCP?– Yes, we care. Telecomunications, backplane, a lot of entertainment is UDP, SCTP– Definitately need strong non-TCP support, Harder to say something other than IP is needed.

• Security/link agg– This should be generalized to above MAC layer 2 protocols over link agg. – With 2 port bridge/media converter, can you run link agg on two parallel links with this in

each?– Do we need a new link agg in the future.

• Dual homing/resilience/robustness – Low priority - no advocates currently pushing specifics– layer 3 solutions exist– backplane might want it at some point. If so, it seems most appropriate for 802.1 so it could

work across MAC types.• MAC Service definition

– No indication MAC to MAC client of readiness for another request. Thus commit to a request is ambiguous. When can you replace a low priority request with a low priority request?

– Would help QOS.– Should we have a MA data request acknowledge?

802.11 was “allocated” issues by the other WGs• Other group allocated

802.11 some issues– “Bridging compatibility”– “Security”– “QoS/class of service”– “Protocol definition vs scope” – “LLC”– “Mesh”– “What is the future .11

architecture”– “Power/channel management”

– Added: Additional issues or comments

•The “allocated” issues are unclear to some 802.11 members– Additional slides are attached that

reflect the ongoing discussion that has occurred over the last four months via email and at the previous interim meeting held in May 2005 as compiled from 802.11-05/0407r2. The slides are an attempt to represent comments without specific author endorsement. As such the authors of this document to do necessarily share these views. This forum and this document was designed to facilitate discussion.

Do we need a standard bridge table updating mechanism• What is the situation?

– STA roaming to a new AP is a normal part of 802.11 operation

– Ideally, it should be achieved without disruption to QoS on the STA

– This requires frames destined to the STA to be redirected to the new AP

• What is the problem?– A network using 802.1D

bridges, will not update the forwarding tables until a frame is sent in the opposite direction

• What should we do about it?– We need a standard method

for updating the bridge forwarding tables when a STA roams that will take effect within the sort of timescales needed to maintain QoS (5 to 30ms)

– Mike Moreton believes, “properly designed network should be capable of updating its own forwarding tables without help from external devices.”

Mike Moreton asks whether we need a standard bridge table

updating mechanism– This issue was

documented in a recent liaison to 802.1 (05/0185r2)

• It is under consideration already?

– 802.11F represents an effort to solve this problem

• There is contention about whether 802.11F will survive

– A more general architectural concept of updating location may be needed

• 802.1D is not the only way to construct a DS

We need to explore the “Bridging compatibility” architecture issue

– ? Is this issue related to forward and backward compatibility between 48 b address versus 64 b address?

• ----------– The “Bridging compatibility

– handling of multicasts” issue was allocated to 802.11

– It is not clear what the issue is?

– ? Is this issue related to multicasts with security enabled?

• Questions– What is the issue?– Is this an architecture

issue?– Is it relevant to

802.11?– What should be done?

Mike Moreton asks whether 802.1X needs to be modified to

reflect realities of broadcast media• What is the situation?

– 802.1X was designed for situations where there was one end station per port

• What is the problem?– 802.11i can have multiple end-

stations per port because its a broadcast medium

– 802.11i overcomes the problem using virtual ports by having each STA's data encrypted with a different pair-wise key

• … and you thought that was to stop eavesdropping

• See last part of 04/1191r5

– However, there are still some aspects of 802.1X that are limited to the physical port

• eg authenticating through one port (we're talking an AP working on different channels here) shouldn't allow you to send data via a different port, because the keys may well not have been programmed in on that port.

• What should we do about it?– 802.1 need to have some

reflection in 802.1X of how it works with broadcast media where traffic is segmented by separate keys.

Mike Moreton asks whether 802.1X needs to be modified to

reflect realities of broadcast media– This issue was

documented in a recent liaison to 802.1 (05/0185r2)

• Is it under consideration already?

– It was noted that 802.1X does not recognise or take advantage of the fact that STAs often move from port to port

• Does the port a mobile STA moves to need to be blocked or can it be pre-unblocked?

• Can an STA have multiple virtual ports open at once

We need to explore the “security” architecture issue

• Background– The “security” issue

was allocated to 802.11– It is not clear what the

issue is relative to 802.11?

• Questions– What is the issue?– Is this an architecture

issue?– Is it relevant to

802.11?– What should be done?

Some have said “Time is an important dimension in wireless

networks but not wired networks”

• 802 is traditionally based on static concepts– “big fat ugly pipe”– Wired networks were

originally based on completely static nodes

– Over time slow portability of network connections was taken into account, eg STP

– Connections are mostly binary

• ie simply up or down– Network performance is

more predictable

• Wireless networks are very dynamic– “nasty thin network”– STAs move often and by

choice– Network conditions change

rapidly and massively• Interference• Contention

– Connections in wireless are “analog”

• ie 0-100%– Network performance tends to

vary significantly over time• eg delay, jitter, loss etc

Dynamic Wireless networks have particular needs that need to be

recognised by the 802 architecture– Wireless networks need

more than just link up/down to enable sensible operation

• We need an in-between status that changes often

– Wireless networks may increasingly use soft handover and need an appropriate infrastructure to support it

• This leads to the possibility of two connections to a STA are active at one time

– Network management needs to recognise that applications are sometimes in a better position to optimally use the network

• eg Skype does not need a management application providing constant QoS

• In some applications, it does not matter that 90% of packets are lost

We need to explore the “QoS/class of service”

architecture issue– One option was that we

carefully map QoS from 802.11 to 802.x

– However, it was noted that the QoS capability changes rapidly and massively in wireless networks

– This might lead to the conclusion that any effort to define a formal QoS mapping is a waste of time

– Maybe the best approach is to allow people to independently do what they think is best at the time – a one size fits all approach may not make sense or be possible

We need to explore the “QoS/class of service”

architecture issue• Background

– The “QoS/class of service” issue was allocated to 802.11

– It has been interpreted to mean, “How do you map QoS between different networks?”

• Questions– Is the issue

interpretation correct and complete?

– Is this an architecture issue?

– Is it relevant to 802.11?

– What should be done?

We need to explore the “Protocol definition vs scope” architecture

issue– It was not clear what

the issue was– Some hypothesised

that this issue resulted from some thinking that 802.11 has defined features above L2 too often in the past

– When is it appropriate for 802.11 to define L2+ features?

• When the features are unique to 802.11?

• When 802.1 will not undertake the definition task?

• When non-802.11 (eg IETF) technologies are involved?

We need to explore the “LLC” architecture issue

• Background– The “LLC” issue was

allocated to 802.11– The issue has been

interpreted as meaning:• The LLC provides no

mechanism for passing additional parameters

• This means that it is difficult to up set up a QoS connection across multiple radio links

• Questions– What is the issue?– Is this an architecture

issue?– Is it relevant to

802.11?– What should be done?

We need to explore the “MESH” architecture issue

• Background– The “MESH” issue was

allocated to 802.11– The issue has been

interpreted as meaning:• The ongoing 802.11s

task groups discussion regarding modifying: discovery, spanning tree and routing/bridging should be happening elsewhere.

• Questions– What is the issue?– Is this an architecture

issue?– Is it relevant to

802.11?– What should be done?

We need to explore the Signal Power/ Channel Management

architecture issue• Background

– 802.11k is addressing common measurement some misunderstood or confused management with measurement

– 802.11v is considering this effort to be within its scope

• What is the problem– Multiple working groups are

presently or have already defined this issue using different definitions, semantics and formulas only for themselves

• Questions– What is the issue for

802.11?– Is this an architecture

issue for 802?– What should 802.11

do?

May 2005 Andrew Myles, Cisco 24

Are there any additional issues or comments?

– Some people would like a “common language” and “dictionary” to talk about wireless networks – but other’s want something “not too detailed”

– Should 802.11 undertake network discovery (eg TGu, TGs) or should there be a more common approach across 802?

– Maybe we “need to create a focused wireless architecture group because wired is so different?”

– Maybe “this effort belongs under co-existence?”

– Maybe we “need to change the 802 architecture moving this work away from 802.1 and to a wireless TAG” that would allow each participant to maintain their membership in their respective primary working group?

– “Maybe we need a wireless task group inside 802.1?”

• A group inside 802.1 may divide wireless expertise drawing it away from the wireless groups

Dot15 802 Architecture Group Update

Tom SiepCambridge Silicon Radio

802.15 Liaison to 802 Architecture Committee

NOTE: Changes made as a result of 13-Mar-05 802 Architecture Group meeting are in BLUE

Prioritized issues – 802.15• Issues

1. LLC – acts as a block to passing additional (e.g., QoS) parameters2. QoS3. (Signal) Power/channel management4. 64bit to 48 bit address mapping for bridging (new topic)5. Smaller than 100 octets allowed for minimum packet size6. Bridging compatibility – handling of multicasts, no clause 6 section

for .1D• Non-Issues

– Are PANs different from WLANs?– Security– Mesh (work TBD)– Architectural consistency across three MACs

Not architectural issues

Management Issues

{Not addressed at Sunday meeting

}

Other Groups Affected• LLC – acts as a block 802.1 and 802.2• QoS 802.1 and 802.2• (Signal) Power/channel management 802.1

and 802.2• 64bit to 48 bit address mapping for bridging

802.1 and 802.2• Smaller than 100 octet packets 802.1 and

802.2• Bridging compatibility – internal problem being

worked

Work to be done by 802.15

• Form plans to solve issues• Determine feasibility of plans• Study proposal to use IETF model for QoS

– will it work for .15 TGs?• Characterize management function needs• Can’t do bridging 64 to 48 bit addresses –

are we OK with this?

LLC – acts as a block to passing additional (e.g., QoS) parameters

• All 3 MAC need LLC support to requests to create/modify/terminate streams based on QoS parameters

• Data needs to be able to be associated with a stream at the MAC SAP

• QoS changes need to be communicated to the higher layers

• Need to be able to inquire QoS characteristics of remote nodes

Backup Slides

Known issues – 802.15 (as presented at Sunday meeting in

San Antonio)• Are PANs different from WLANs?

– We hope the answer is “No” (wrt the MAC service)• Security

– What functionality is needed– Who does what aspect

• Bridging compatibility – handling of multicasts, no clause 6 section for .1D

• LLC – acts as a block to passing additional (e.g., QoS) parameters• Mesh (not the same as the .11 issue though)• QoS• Architectural consistency across three MACs• (Signal) Power/channel management

QoS

• Block asynchronous data– Need block size to plan and allocate resources

(Signal) Power/channel management

• Need a way to pass (up and down) information that is important to wireless, for example– Transmit power– Regulatory domain– Signal quality– Coexistence information– Other

• Must be extensible

Bridging compatibility – handling of multicasts, no clause 6 section

for .1D• Compatibility with .1D

– 15.1a – Bridging is handled in BNEP, which maps to Ethernet.

– 15.3 – Annex A (normative) specifies compatibility– 15.4 – Annex A (normative) specifies compatibility

• Multicasts– 15.1a – does not do multicast– 15.3 – Had multicast, being revised in current work– 15.4 – Had broadcast, being revised to include

multicast in current work

Known issues – 802.16• Security

– has to roll its own EAP transport as .1X/AF– is above the LLC– No PKI model in .1X/AF– MBS – breaks security model– Should schedule a joint meeting with 802.1

• QoS– See .21

• Bridging compatibility – handling of multicasts, no clause 6 section for .1D

• . MTU discovery– Look at 802.1AD LLDP?

Known issues – 802.17

• Frame size– Not dissimilar problem to dot-3 – will take their

lead• CoS/QoS

– Look at intsrv/diffsrv• Security

– We have layering issues.

Known issues – 802.20• Needs to support handoff – not clear how to deal with L2

handoff in current architecture• QoS

– No standard way to pass upper layer QoS requirements through to MAC level QoS parameters

– LLC acts as a block– Relation to IntSrv/DifSrv mechanisms

• Security– has to roll its own EAP transport as .1X/AF– is above the LLC– No PKI model in .1X/AF

• Compatibility between 802.20 frame and LLC frame

.21 : Action items from 3/2005

– Groups that have QOS on list to look at IETF intsrv/difsrv documents & identify specific things that would allow their MAC to better support these services

– Groups that have listed security issues to detail specific questions/issues regarding security

– Tutorial on service interface vs API (was this Tony’s action?)

.21 : QoS Intserv && Diffserv

– .21 not specifying a MAC directly– Working with Intserv model

• Seems to be main model IETF & industry is following• New work in NSIS though

– Several abstractions / categories in 802• Grouping of traffic into a link• Identifying SDUs by

– Connections– Priorities– VLAN– Traffic class

.21 : Security IssuesCurrently most security issues out of scope

for .21• Having multiple associations at once (MBB)

– Otherwise need fast (re) establishment of SA• Authentication mechanisms – different

mechanisms across 802• Enabling handover policy to consider

security attributes of potential network attachment points

802.21 issues in priority• QoS mapping across heterogeneous

interfaces• Authentication mechanisms – different

mechanisms in different technologies• Security – how do you re-establish the

security context during/after transition• Service discovery• Neighborhood service differs per technology• Power/channel management

Known issues – 802.22

• Goal to avoid all of the above

Known issues – Broadband over Power lines (external project)

• Will this be Bridgeable or will it only be routable (to 802 technologies)?

• In order for the technology to be Bridgeable, then they should participate in this architecture group

• Make liaison with 802 a requirement of the PAR• They should address coexistence (with other

technologies)• Entity balloting would tend to disenfranchise a

significant body of technical expertise from the balloting process. LMSC join as an entity?

Action items– Groups that have QOS on list to look at IETF

intsrv/difsrv documents & identify specific things that would allow their MAC to better support these services

• Need some work done on this. WG representatives to identify people interested in studying this area of work & feeding back to the group.

• If there is no movement on this by next meeting we will drop the item from the action list.

– Groups that have listed security issues to detail specific questions/issues regarding security

– Tutorial on service interface vs API• Tony, Mick do something for next meeting

Agenda for next meeting,Sunday Nov 13 2005, 2-5pm

• Continue (.3 through .1) refinement and prioritisation of current issues list based on WG input (homework items from previous slide)

• Report back from “Wireless Architecture Sub-Group”• Tutorial on service interface vs API• Report back on issues that are currently being addressed• Proposals for resolution of high priority issues that are not

currently being addressed• Spend more time on QoS, especially support of

intsrv/diffsrv by 802 MACs