Presentation is loading. Please wait.

Presentation is loading. Please wait.

802 Architecture Group Website : Joining the exploder:

Similar presentations

Presentation on theme: "802 Architecture Group Website : Joining the exploder:"— Presentation transcript:

1 802 Architecture Group Website : Joining the exploder:

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 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 Known issues – MAC Service definition (currently a revision PAR in place) –No work done on the draft so far –ISS and 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

8 Known issues – 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 – 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 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.

9 IEEE Architecture Group Issues 13 November 2005 Pat Thaler Bob Grow

10 IEEE Issues QOS architecture Link aggregation Ethernet IP interdependence Dual homing/resilience/robustness Power Management

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

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

13 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 issues will come under the MAC service interface item

14 Link aggregation Layering –It is an sublayer but it has to go above 802.1x 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

15 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 issue based on projects

16 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 proposed –Not just a problem for though –Has architectural implications related to some previous listed issues (e.g., link availability)

17 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

18 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

19 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

20 Network based alternatives Wake-on-LAN Directed packet Link speed change Proxies

21 Wake-on-LAN A special (non-standard) MAC frame –Repeat MAC address 16 times in data field –Common in NICs –Also in some 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

22 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

23 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

24 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

25 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

26 was allocated issues by the other WGs Other group allocated 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 members –Additional slides are attached that reflect the ongoing discussion that has occurred over the last four months via and at the previous interim meeting held in May 2005 as compiled from /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.

27 Do we need a standard bridge table updating mechanism What is the situation? –STA roaming to a new AP is a normal part of 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.

28 Mike Moreton asks whether we need a standard bridge table updating mechanism –This issue was documented in a recent liaison to (05/0185r2) It is under consideration already? –802.11F represents an effort to solve this problem There is contention about whether F will survive –A more general architectural concept of updating location may be needed 802.1D is not the only way to construct a DS

29 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 –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 ? –What should be done?

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

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

32 We need to explore the security architecture issue Background –The security issue was allocated to –It is not clear what the issue is relative to ? Questions –What is the issue? –Is this an architecture issue? –Is it relevant to ? –What should be done?

33 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

34 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

35 We need to explore the QoS/class of service architecture issue –One option was that we carefully map QoS from 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

36 We need to explore the QoS/class of service architecture issue Background –The QoS/class of service issue was allocated to –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 ? –What should be done?

37 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 has defined features above L2 too often in the past –When is it appropriate for to define L2+ features? When the features are unique to ? When will not undertake the definition task? When non (eg IETF) technologies are involved?

38 We need to explore the LLC architecture issue Background –The LLC issue was allocated to –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 ? –What should be done?

39 We need to explore the MESH architecture issue Background –The MESH issue was allocated to –The issue has been interpreted as meaning: The ongoing s 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 ? –What should be done?

40 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 ? –Is this an architecture issue for 802? –What should do?

41 May 2005Andrew Myles, Cisco41 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 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 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 may divide wireless expertise drawing it away from the wireless groups

42 Dot Architecture Group Update Tom Siep Cambridge Silicon Radio Liaison to 802 Architecture Committee NOTE: Changes made as a result of 13-Mar Architecture Group meeting are in BLUE

43 Prioritized issues – Issues 1.LLC – acts as a block to passing additional (e.g., QoS) parameters 2.QoS 3.(Signal) Power/channel management 4.64bit to 48 bit address mapping for bridging (new topic) 5.Smaller than 100 octets allowed for minimum packet size 6.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 Management Issues { Not addressed at Sunday meeting }

44 Other Groups Affected LLC – acts as a block and QoS and (Signal) Power/channel management and bit to 48 bit address mapping for bridging and Smaller than 100 octet packets and Bridging compatibility – internal problem being worked

45 Work to be done by 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?

46 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

47 Backup Slides

48 Known issues – (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

49 QoS Block asynchronous data –Need block size to plan and allocate resources

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

51 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

52 Known issues – 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 QoS –See.21 Bridging compatibility – handling of multicasts, no clause 6 section for.1D. MTU discovery –Look at 802.1AD LLDP?

53 Known issues – Frame size –Not dissimilar problem to dot-3 – will take their lead CoS/QoS –Look at intsrv/diffsrv Security –We have layering issues.

54 Known issues – 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 frame and LLC frame

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

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

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

58 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

59 Known issues – Goal to avoid all of the above

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

61 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

62 Agenda for next meeting, Sunday July , 2-5pm Report back from Wireless Architecture Sub- Group Presentation – Kevin Stanton on time synch for.11,.16 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

Download ppt "802 Architecture Group Website : Joining the exploder:"

Similar presentations

Ads by Google