802 Architecture Group

1
802 Architecture Group

• Website
• http//www.ieee802.org/1/files/public/802_architec
  ture_group/
• Joining the Email exploder
• http//www.ieee802.org/1/email-pages/joining.html

2
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.

3
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

4
Purpose

• To actually have a recurring discussion on
  architectural issues
• To improve cross-WG discussion/understanding
• To promote a common view

5
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

6
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.

7
IEEE Architecture Group802.3 Issues13 November
2005

• Pat ThalerBob Grow

8
IEEE 802.3 Issues

• QOS architecture
• Link aggregation
• Ethernet IP interdependence
• Dual homing/resilience/robustness
• Power Management

9
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.

10
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.

11
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

12
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

13
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

14
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)

15
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

16
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

17
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

18
Network based alternatives

• Wake-on-LAN
• Directed packet
• Link speed change
• Proxies

19
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

20
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

21
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

22
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

23
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

24
802.11 was allocated issues by the other WGs

• 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.

• 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

25
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.

26
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

27
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?

28
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.

29
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

30
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?

31
Some have said Time is an important dimension in
wireless networks but not wired networks

• 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

• 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

32
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

33
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

34
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?

35
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?

36
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?

37
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?

38
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?

39
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 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

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

• Tom Siep
• Cambridge Silicon Radio
• 802.15 Liaison to 802 Architecture Committee

41
Prioritized issues 802.15
Management Issues

• Issues
• LLC acts as a block to passing additional
  (e.g., QoS) parameters
• QoS
• (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
• Non-Issues
• Are PANs different from WLANs?
• Security
• Mesh (work TBD)
• Architectural consistency across three MACs

Not architectural issues

Not addressed at Sunday meeting
42
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

43
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?

44
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

45
Backup Slides
46
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

47
QoS

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

48
(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

49
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

50
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?

51
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.

52
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

53
.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?)

54
.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

55
.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

56
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

57
Known issues 802.22

• Goal to avoid all of the above

58
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?

59
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

60
Agenda for next meeting,Sunday Mar 5 2006, 2-5pm

• Continue (.1, then) 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