802 Architecture Group - PowerPoint PPT Presentation

Loading...

PPT – 802 Architecture Group PowerPoint presentation | free to download - id: 64a3e3-NGY2Y



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

802 Architecture Group

Description:

IEEE Architecture Group 802.3 Issues ... management within the system 802 Architecture issues Power ... the issue for 802.11? Is this an architecture ... – PowerPoint PPT presentation

Number of Views:41
Avg rating:3.0/5.0
Slides: 61
Provided by: TonyJe4
Learn more at: http://www.ieee802.org
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com