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
–
–
•
MIB definition for service discovery
–
•
This has been aired recently
Assumption is that dot groups will be held accountable for how they meet their PAR obligations
Max frame size
–
–
–
•
This one will run and run
Process – ensuring due diligence
–
–
•
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
–
•
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
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 don’t 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.3’s 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 cooperate 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
– Can’t 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
Doesn’t 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
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.1105/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
– A more general
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
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
• What is the situation? media– However, there are still
some aspects of 802.1X that
– 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
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
was noted that
– This issue was
media– It802.1X
does not
documented in a recent
liaison to 802.1
(05/0185r2)
• Is it under consideration
already?
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?
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
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
{
1.
2.
3.
4.
5.
6.
•
LLC – acts as a block to passing additional (e.g., QoS) parameters
QoS
Not architectural issues
(Signal) Power/channel management
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
• 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 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 July 16 2006, 2-5pm
• Report back from “Wireless Architecture
Sub-Group”
• Discuss/select 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