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)
No work done on the draft so far
ISS and 802.3 MAC service have converged
Stripped out spurious elements that were of historical significance (.5 etc.)
Current ISS, EISS in 802.1Q-REV (2005)
QoS could be better expressed
This is a potentially non-terminating discussion
Currently working in AV Bridging on using the existing mechanisms to
achieve specific qoS goals
Security expressed as a set of procedures after network entry?
LAN is a connectivity association (CA) of service access points
Shim operating over the LAN constructs a Secure CA (SCA)
Insecure SAP is the Uncontrolled Port
Secure SAP is the Controlled Port (.1X, .1af)
See AE Fig 10.2., Fig 11-7, Fig 11-10

Known issues 802.1
Management scope and interface
Commonality of MAC/PHY management interfaces (managed object definitions)?
Some sentiment in the room that it is a desirable goal, although implementation would be challenging.
Action item on this for WG reps to look at what possibilities might exist
MIB definition for service discovery
Potential need for a common approach to providing service discovery information (type of MAC,
speed,.etc.)
Where work gets done 802.1 vs 802.X
This one will run and run
Process ensuring due diligence
This has been aired recently
Assumption is that dot groups will be held accountable for how they meet their PAR obligations
Max frame size
Ongoing 802.3 project to adjust frame size for additional headers
Hits certain aspects of QoS vs certain aspects of efficiency how to make this trade-off?
Not clear that there is a universal answer here.
Position/location awareness
May be a need for a common approach to providing LAN-specific data that could assist with determining
physical location.
IEEE Architecture Group
802.3 Issues
13 November 2005
Pat Thaler
Bob Grow
 IEEE 802.3 Issues
QOS architecture
Link aggregation
Ethernet IP interdependence
Dual homing/resilience/robustness
Power Management
 QOS architecture (1)
MAC Service interface
Commit point when can MAC client change
the MA Data Request?
Clear and consistent definition of where queues
reside for 802.3 above interface but for other 802
below interface.
Acknowledgement of transmission to MAC client?
Link status higher layers dont know if
transmission will leave DTE.
 QOS architecture (2)
Clock synchronization
Residential and industrial Ethernet applications
May have implications within IEEE 1073 applications
(healthcare)
Work on this will probably be moving to.1, but may
need .3 hooks (e.g. service interface or mgmt)
Rate control
P802.3ar now has a proposed draft
802.1 projects proposed to use that capability
802.3s direction here is in process; other groups may
want to look at what we are doing and give feedback.
 QOS architecture (3)
Congestion management
Latency and latency jitter
Data center Ethernet applications
Residential applications
Expect this will be moving to 802.1; any
open 802.3 issues will come under the
MAC service interface item
 Link aggregation
Layering
It is an 802.3 sublayer but it has to go above 802.1x
802.1 current plan on media converters
Media converters will be transparent to link ag i.e. a physical link
with a media converter in it can be aggregated.
Issue: no way for management above link ag to address
management frames to a media converter in an aggregated link
Do we need additional capabilities such as ability to co-
operate to keep both directions of a flow on the same link?
Decision: not at this time. closed
 Miscellaneous
Ethernet IP interdependence - closed
Ethernet is used with protocols other than IP
Mostly just an issue of awareness, not architecture
Dual homing/resilience/robustness - closed
Low priority
Link Aggregation and Fast Spanning Tree help
Conclusion: not currently an 802.3 issue based on 802.1
projects
 New item: Power
Management
Something new since we created the original 802 issues
list
Multifaceted challenge
Cooling components and systems
Effects on data center equipment density
Total cost of operation because of energy consumption
Energy policy and environmental impact
Tutorial topic in July
Some possible work for 802.3 proposed
Not just a problem for 802.3 though
Has architectural implications related to some previous listed
issues (e.g., link availability)
Layers of power management
Not 802 Architecture
Device efficiency
Active chip power management
Power management within the system
802 Architecture issues
Power management of the network
Power management via the network
 PC energy use
Consumption is driven by
on-time, not by usage
To be on the network, PCs
must be on
Energy Star is now
targeting network
connectivity in sleep
mode
Classes of power
consumption
 Current energy star
Use an inactivity timer to power down
Power down monitor, disks, and eventually the
entire system
Sleep (Windows standby) and hibernate
Resume where left-off on detection of activity
Mouse wiggle or key stroke to wake-up
Possible networking additions
Adaptable speed
Protocol enhancements
 Network based alternatives
Wake-on-LAN
Directed packet
Link speed change
Proxies
 Wake-on-LAN
A special (non-standard) MAC frame
Repeat MAC address 16 times in data field
Common in 802.3 NICs
Also in some 802.11 NICs
Assumes limited mobility of device
Applications and protocols do not support WOL
Cant route to target device when timeout causes
discard of ARP cache entry
TCP connection starts with a SYN
 Directed packet wake-up
Recognition of interesting packets
Programmable packet filtering
Wake-on-LAN
IP protocol packets
Limitations
Wakes up on junk
Doesnt always wake-up when desired
Needs to be managed/configured
No concept of state
Link speed power relationship
10/100 Mb/s use small number of gates, 1G/10G
use significantly more gates at high speed
Example NICs
No link = 135 mW
10BASE-T = 150 mW
1000BASE-T = 1.1 W
10GBASE-T = 13 W
Break Ethernet link and reestablishes at different
speed though autonegotiation
 Network connectivity trends
More PCs left active
Network protocols not designed power effects
Network applications assume always on
Permanent connections are becoming more common
Sleep is not a network state, but a device state
No way to know sleep state of remote device
Limited non-guaranteed wake-up capability
 Options for continued
evaluation
Network aware system sleep states
Uses of proxies
More reliable wake-up
Network becomes part of system power management
Power management as a network function
Bridge/switch would play an increased role
Reduce latency of link speed change
Probably a WG problem
802.11 was allocated issues by
the other WGs
Other group allocated The allocated issues are
802.11 some issues unclear to some 802.11
Bridging compatibility members
Security Additional slides are attached
that reflect the ongoing
QoS/class of service
discussion that has occurred
Protocol definition vs over the last four months via
scope email and at the previous interim
LLC meeting held in May 2005 as
Mesh compiled from 802.11-
What is the future .11 05/0407r2. The slides are an
architecture attempt to represent comments
without specific author
Power/channel endorsement. As such the
management authors of this document to do
necessarily share these views.
Added: Additional issues or This forum and this document
comments 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
This issue was
mechanism
A more general
documented in a recent architectural concept of
liaison to 802.1 updating location may
(05/0185r2) be needed
It is under consideration
already? 802.1D is not the only
way to construct a DS
802.11F represents an
effort to solve this
problem
There is contention
about whether 802.11F
will survive
We need to explore the Bridging
compatibility architecture issue
? Is this issue related to
forward and backward
Questions
compatibility between 48 b What is the issue?
address versus 64 b
address? Is this an architecture
---------- issue?
The Bridging Is it relevant to 802.11?
compatibility handling of
multicasts issue was What should be done?
allocated to 802.11
It is not clear what the issue
is?
? Is this issue related to
multicasts with security
enabled?
 Mike Moreton asks whether
802.1X needs to be modified to
reflect realities of broadcast
What is the situation? media However, there are still
802.1X was designed for some aspects of 802.1X that
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
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
 Mike Moreton asks whether
802.1X needs to be modified to
reflect realities of broadcast
This issue was media It802.1X
was noted that
documented in a recent
liaison to 802.1
(05/0185r2)
Is it under consideration
already?
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 Questions
The security issue What is the issue?
was allocated to 802.11 Is this an architecture
It is not clear what the issue?
issue is relative to Is it relevant to 802.11?
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 Network management
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
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 Questions
The QoS/class of Is the issue
service issue was interpretation correct
allocated to 802.11 and complete?
It has been interpreted Is this an architecture
to mean, How do you issue?
map QoS between Is it relevant to 802.11?
different networks? What should be done?
 We need to explore the Protocol
definition vs scope architecture issue
It was not clear what When is it appropriate
the issue was for 802.11 to define
Some hypothesised L2+ features?
that this issue resulted When the features are
from some thinking unique to 802.11?
that 802.11 has defined When 802.1 will not
undertake the definition
features above L2 too task?
often in the past When non-802.11 (eg
IETF) technologies are
involved?
 We need to explore the LLC
architecture issue
Background Questions
The LLC issue was What is the issue?
allocated to 802.11
Is this an architecture
The issue has been issue?
interpreted as meaning:
The LLC provides no Is it relevant to 802.11?
mechanism for passing What should be done?
additional parameters
This means that it is
difficult to up set up a
QoS connection across
multiple radio links
We need to explore the MESH
architecture issue
Background Questions
The MESH issue What is the issue?
was allocated to 802.11
Is this an architecture
The issue has been issue?
interpreted as meaning:
The ongoing 802.11s Is it relevant to 802.11?
task groups discussion What should be done?
regarding modifying:
discovery, spanning tree
and routing/bridging
should be happening
elsewhere.
 We need to explore the Signal Power/
Channel Management architecture issue
Background Questions
802.11k is addressing
common measurement What is the issue for
some misunderstood or 802.11?
confused management with
measurement Is this an architecture
802.11v is considering this issue for 802?
effort to be within its scope What should 802.11
What is the problem do?
Multiple working groups
are presently or have
already defined this issue
using different definitions,
semantics and formulas
only for themselves
Are there any additional issues or
comments?
Some people would like a
common language and
dictionary to talk about
wireless networks but others
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
Mayunder
2005 co-existence? Andrew Myles, Cisco
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
41
 NOTE: Changes made as a
result of 13-Mar-05 802
Architecture Group meeting
are in BLUE

Dot15 802 Architecture Group

Update
Tom Siep
Cambridge Silicon Radio

802.15 Liaison to 802 Architecture Committee

 Management Issues
Prioritized issues 802.15
Issues
LLC acts as a block to passing additional (e.g., QoS) parameters

{
1.
2. QoS
3. (Signal) Power/channel management
Not architectural issues
4.
5.
6.
64bit to 48 bit address mapping for bridging (new topic)
Smaller than 100 octets allowed for minimum packet size }
Bridging compatibility handling of multicasts, no clause 6 section for
.1D Not addressed at Sunday meeting
Non-Issues
Are PANs different from WLANs?
Security
Mesh (work TBD)
Architectural consistency across three MACs
 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
Cant 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 Tonys 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 Issues
Currently 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
WGs to give brief presentation on how they currently go about
defining management functionality for their standards.
Proposals needed for specific issues that we consider we can do
something about within this forum
Proposals needed for how commonality of managed object
definitions might be achieved
 Agenda for next meeting,
Sunday Nov 12 2006, 2-5pm
Report back from Wireless Architecture
Sub-Group
Presentations on candidates for known high
priority issues that we believe the
Architecture group should work on with a
view to encouraging their resolution
Report back on issues that are currently
being addressed
 Candidate topics
Consumer electronics anything that is on the critical path:
Service interface harmonisation across MACs
Time synchronization
Some aspects of QoS
Location awareness relevance to VoIP
Link aggregation - .3 or generic
Need to make sure that PHY Agg doesnt break Link Agg
Slow Protocol where should this live
Procedurally how does it get moved? (2 simultaneous PARs)
Energy (power) management
Probably not ready for this yet, but it will hit us hard at some point
Issues with respect to constant services (Time protocols, Spanning tree...)
802.3 are running a CFI on power management during 11/06 meeting
End station HILI
802.1 issue
48 vs 64-bit addressing
If it needs to be Bridged, then 48 bit is the only way
If it doesnt need to be Bridged (and therefore, is a New Application), then 64 bit will be strongly encouraged
by the RAC.
 Future of the Architecture group
The Wireless sub-group has been closed down and will no longer meet.
The view of the participants in the Architecture group is that this
activity is no longer useful in its current form. The regular Sunday
afternoon meeting series will therefore cease as of this meeting.
If there is a need for the group to meet in order to address a specific
and focussed problem then we will schedule an ad-hoc Architecture
group meeting for that purpose. The best placing for this would be to
use a Plenary tutorial slot, and therefore the minimum notice period
would be as for other tutorials.
The 802.1 Technical Plenary will still be available as a vehicle for
addressing specific technical problems across 802.