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
–
–
–
•
Ethernet/TCP-IP interdependence
–
–
–
•
–
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
–
–
–
•
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
–
–
•
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.
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•TheWGs
“allocated” issues are
• 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
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
mechanism
• What is theupdating
situation?
• What should we do about
– 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
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• Wireless
not wired
networks are
• 802 is traditionally based
very dynamic
on static concepts networks”
– “nasty thin network”
– “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
– 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
– Wireless networks need
– Network management
architecture
more than just link up/down
needs to recognise that
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
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
– Maybe the best
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
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
– When is it appropriate
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
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
24
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
– 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