June 2005 Guido Hiertz, Philips, et al. Slide 1 doc.: IEEE 802.11-05/573r0 Submission Wi-Mesh Alliance Proposal for Wi-Mesh Alliance Proposal for 802.11 TGs 802.11 TGs Authors: Tyan-Shu Jou Accton 1362 Borregas Avenue, Sunnyvale CA, 94089, USA +1 (408) 747- 0994 [email protected]Ted Kuo Accton 1362 Borregas Avenue, Sunnyvale CA, 94089, USA +1 (408) 747- 0994 [email protected]Juan Carlos Zuniga InterDigital 1000 Sherbrooke W. 10th Floor, Montreal, QC, CANADA +1(514) 904 6251 juancarlos.zuniga@interdig ital.com Marian Rudolf InterDigital 1000 Sherbrooke W. 10th Floor, Montreal, QC, CANADA +1(514) 904 6258 marian.rudolf@interdigital .com Catherine Livet InterDigital 1000 Sherbrooke W. 10th Floor, Montreal, QC, CANADA +1(514) 904 6252 catherine.livet@interdigit al.com John Tomici InterDigital Two Huntington Quadrangle, 3rd Floor, Melville, NY 11747, USA +1(631) 622 4079 [email protected]om Vincent Roy InterDigital 1000 Sherbrooke W. 10th Floor, Montreal, QC, CANADA +1(514) 904 6263 [email protected]om Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < http:// ieee802.org/guides/bylaws/sb-bylaws.pdf >, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <[email protected]> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If
Transcript
June 2005
Guido Hiertz, Philips, et al.Slide 1
doc.: IEEE 802.11-05/573r0
Submission
Wi-Mesh Alliance Proposal for 802.11 TGsWi-Mesh Alliance Proposal for 802.11 TGsAuthors:
Tyan-Shu Jou Accton1362 Borregas Avenue, Sunnyvale CA,
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <[email protected]> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <[email protected]>.
June 2005
Guido Hiertz, Philips, et al.Slide 2
doc.: IEEE 802.11-05/573r0
Submission
Wi-Mesh Alliance Proposal for 802.11 TGsWi-Mesh Alliance Proposal for 802.11 TGs
Authors (cont.):
D. J. Shyy MITRE7515 Colshire Drive, McLean, VA 22102,
• Common view towards rapidly achieving a complete and robust WLAN Mesh standard– Trade-off between simplicity and performance
• Multi-national company profiles representing a wide range of markets perspectives, just like 802.11 WG– Consumer Electronics
– Public Access
– Office
– Public Safety & Military
June 2005
Guido Hiertz, Philips, et al.Slide 4
doc.: IEEE 802.11-05/573r0
Submission
Proposal Features (1/3) Complete solution addressing all 802.11s Usage Models Flexible & suitable for
• Simple / Robust implementations• Sophisticated / High Performance systems
Support for single & multi-radio configurations• Efficient channel usage for regulatory limited domains (e.g. Japan)• Leverages on all available RF resources (e.g. channels, radios,
etc.) Scalable solution with distributed control Efficient QoS support
• Simple extension from 802.11e to Mesh Robust interference mitigation & RF management Can be deployed as stand-alone (similarly to ad-hoc mode)
or in combination with an infrastructure network (i.e. BSS)
June 2005
Guido Hiertz, Philips, et al.Slide 5
doc.: IEEE 802.11-05/573r0
Submission
Proposal Features (2/3) Self-Configuring / Ease of manageability WDS four-addressing extension Extended mesh discovery Dynamic auto-configuration of MAC-layer data delivery
paths for unicast, multicast & broadcast Integrated BSS & WLAN mesh unicast data delivery, with
efficient broadcast/multicast transport Enable multiple routing algorithms for MAC address
based forwarding with a simple Hello QoS, radio & power-efficiency aware dynamic routing
support Secure routing information
June 2005
Guido Hiertz, Philips, et al.Slide 6
doc.: IEEE 802.11-05/573r0
Submission
Proposal Features (3/3) Flexible and secure key distribution Authentication and Key Management using 802.11i concepts
– Mesh Discovery, Mesh Association– Support for distributed or centralized models
Mesh extensions with multi-hop encryption of unicast/multicast data – Secure neighborhood association performed at Beacon or hello time– Multi-hop encryption hop-by-hop authentication with multicast and tunnel
support – Optional Knobs for re-keying and replay protection defined
Extensions to protect pre-associated traffic with Authentication – Operational flexibility to deploy networks with multi-vendor environment
Seamless routing and security integration Agnostic to radio types, wireless stations or applications
June 2005
Guido Hiertz, Philips, et al.Slide 7
doc.: IEEE 802.11-05/573r0
Submission
Outline
• WLAN Mesh Architecture and Frame Definitions• Mesh MAC Sublayer
– Dynamic Mode• Allows two MPs to schedule meeting points (time, channel and duration)• Enables high potential in terms of spatial and frequency reuse
– Shared Coordination Channel Mode• Basic signaling exchange over dedicated Coordination Channel• Quickly adapts to topology changes
• All MPs within the same WLAN Mesh should operate with the same scheduling mode
June 2005
Guido Hiertz, Philips, et al.Slide 20
doc.: IEEE 802.11-05/573r0
Submission
MTXOP Negotiation Overview
• The MTXOP negotiation can be performed into 2 different ways– During each MTXOP, next MTXOP is negotiated – can piggyback Mesh Control fields in
Data Frame– Expedites coordination, with dedicated Mesh Management messages in a dedicated
channel or Mesh beacon period
• Each MTXOP is defined by– Timing information: Starting Time, duration, re-occurrence– RF Resource information: defines the channel(s) on which the 2 MP will communicate
during the MTXOP– QoS information: what QOS is required to exchange data during the MTXOP.
• The MTXOP agreement is a min 2 and max of 4-handshake transmission coordination mechanism
– The Destination MP can either agree, reject or propose another next MTXOP
– An option is used to indicate if the given message requires ACK to confirm
Source MP Dest MP
Proposes a next MTXOP
Agree or Proposes Another next MTXOP
Agree or Disagreeon next MTXOP
Agree or Disgree
No need for ACKAs this is Implicit ACK
Ensure Dest MPrecognizes Confirmationon negotiatedMTXOP
Transmitter and Receiver negotiate MTXOP reservationvia beacons
Immediate transmission begin, no backoffNeighbors repeat reservation
information in own beacons
No immediate Acknowledgment(Imm. ACK)
June 2005
Guido Hiertz, Philips, et al.Slide 24
doc.: IEEE 802.11-05/573r0
Submission
MP1
MP3 MP4
MP2MP1
MP1 Schedule
MP3 Schedule
MCF SchedulingMCF Scheduling Example – Periodic Mode (Multi-radio)
Time
Time
TimeMP2 Schedule
Freq
Ch #1
Ch #3
Ch #2
Freq
Ch #1
Ch #3
Ch #2
Freq
Ch #1
Ch #3
Ch #2
MP2 MP2 MP2MP1 MP1
MP4 Schedule Time
Freq
Ch #1
Ch #3
Ch #2
- MP1-MP2, MP4-MP2 and MP3-MP4 communicate on a Periodic Mode
- They agree on the Periodic CFP the 1st time they met
-CP are used in-between to serve STAs (i.e. BSS)
Single or multi-radio Configuration- CFP highly efficient organised mesh communication- CP backwards compatible
CP CPCP
CP CPMP4 MP4
CP
CP CPMP2 MP2
MP4 MP4 MP4CP CPMP3MP3 MP3CP CP
June 2005
Guido Hiertz, Philips, et al.Slide 25
doc.: IEEE 802.11-05/573r0
Submission
Dynamic Mode Operation
• This mode allows 2 MPs to determine the characteristics of the Mesh TXOP (MTXOP) when they will be able to “meet” on their common ML
• The MCF dynamic scheduling is a fully distributed pair wise independent mechanism– MTXOP are independent time divisions that are coordinated
with neighbours
– Each MP keeps its own schedule for each of its ML
June 2005
Guido Hiertz, Philips, et al.Slide 26
doc.: IEEE 802.11-05/573r0
Submission
MP3 MP4
MP2MP1
MP1 Schedule
MP3 Schedule
MCF SchedulingMCF Scheduling Example – Dynamic Mode (Dual Radios)
MP2
Time
MP3
MP4
Time
MP1MP3
Time
MP2MP1 MP1
MP4 Schedule
MP1
TimeMP2 Schedule
Freq
Ch #1
Ch #3
Ch #2
Freq
Ch #1
Ch #3
Ch #2
Freq
Ch #1
Ch #3
Ch #2
Freq
Ch #1
Ch #3
Ch #2
MP3
MP1
MP2
MP4 MP4MP4 MP4
- The next MTXOP is negotiated between the 2 MP during the current TXOP
-MTXOP related information can be piggybacked in data frames
Concurrent TS allocations can be handled in two ways:(1) By using adaptive antennas which isolate MP1-MP2 from MP3-MP4 or (2) By relying on adaptive PCS techniques
Next TXOP negotiation
June 2005
Guido Hiertz, Philips, et al.Slide 27
doc.: IEEE 802.11-05/573r0
Submission
Shared Coordination Channel (SCC) Mode• The SCC is a logical channel used for exchange of control and
management frames by all MPs in a particular mesh domain– For instance, for negotiating channel access for pending mesh data frames– The use of the SCC option may be enabled during MP start-up or via
subsequent discovery/association procedures
• The SCC has the following characteristics:– The SCC (with MTXOP Req/MTXOP Rsp) provides a mechanism to
mitigate hidden node problems– Simplicity: Provides good performance with standard physical and virtual
carrier sensing– Power saving: Devices can decide to go into sleep state if no traffic is
destined for them– Robustness and performance: When SCC and traffic channel operate on
separate channels, an MP can receive measurement frames at any time. This allows for fast reaction to topology changes and power control adjustments
June 2005
Guido Hiertz, Philips, et al.Slide 28
doc.: IEEE 802.11-05/573r0
Submission
MP3 MP4
MP2MP1
MP3 Schedule
MCF SchedulingMCF Scheduling Example - SCC Mode (Dual Radios)
Time
TimeTimeMP4 Schedule
TimeMP2 Schedule
Freq
Ch #1
Freq
FreqFreq
One shared channel for control and management frames as well as resource coordination
Shared channel can be changed in a semi-static way
Other radio supports data traffic and adapts to interference by dynamically switching the channel
• Ch 1 is the shared channel• MTXOP Req/Rsp and MTXOP-ACK are transmitted on Ch 1
• Ch 2 and Ch 3 are dynamically scheduled• MP1 communicates with MP4• MP2 communicates with MP3
MP1 Schedule
Ch #2
Ch #3
Ch #1
Ch #2
Ch #3
Ch #1
Ch #2
Ch #3
Ch #1
Ch #2
Ch #3
MP4
MP3
MP1
MP2
MTXOP Req MTXOP Rsp MTXOP-ACK
June 2005
Guido Hiertz, Philips, et al.Slide 29
doc.: IEEE 802.11-05/573r0
Submission
MCF QoS Support • Re-use existing 802.11e to enable multi-priority
scheduling and transmission
• Adding Drop Precedence bit to WLAN Mesh
frames for each Access Category – Allows congestion management to prevent important
traffic from being dropped
• Coordinate the piggyback frame to have same Access Category and transmit priority
June 2005
Guido Hiertz, Philips, et al.Slide 30
doc.: IEEE 802.11-05/573r0
Submission
Mesh MAC Sub-LayerMesh RF Resource Management
Functions
June 2005
Guido Hiertz, Philips, et al.Slide 31
doc.: IEEE 802.11-05/573r0
Submission
RF Resource Management Highlights• RF resource management & arbitration to:
– Support satisfaction of regulatory requirements – Support maintenance of mesh link/path quality – Support the use of various types of radios and antennas
configurations in WLAN mesh – Aid STAs to operate within the WLAN Mesh, e.g., wireless
distribution system (WDS) capacity currently available for traffic forwarding.
– Support automatic channel selection within the WDS• to avoid “co-channel” interference• to avoid “adjacent channel” interference in the case of multi-
radio configuration • to distribute energy across the spectrum within a given
geographical area– Support automatic transmit power control to mitigate RF
interference – Support policy-based RF management
June 2005
Guido Hiertz, Philips, et al.Slide 33
doc.: IEEE 802.11-05/573r0
Submission
Mesh Transmit Power Control
• Motivation– Regulatory purposes
• Countries/bands have different regulatory Tx power allowances
– Radio Network Optimization purposes• Increases channel reuse -> increases capacity• Provides for Battery Savings
• Signaling– TPC capabilities/settings information
• Signaled through– Mesh beacon / probe response– Mesh association /authentication procedure– Special management frames
June 2005
Guido Hiertz, Philips, et al.Slide 34
doc.: IEEE 802.11-05/573r0
Submission
Auto-Configuration Mesh Link Maintenance Example
PHY
Neighbor Discovery, Topology Learning, Routing and Forwarding
Link Quality Assessment
Measurement Processing (Internal and External
Measurements)
MeasurementScheduling
Link ParameterModification
June 2005
Guido Hiertz, Philips, et al.Slide 35
doc.: IEEE 802.11-05/573r0
Submission
Mesh Measurements• The mesh measurement
request/report mechanism is built on 802.11k and can be used to improve mesh network operation– Auto-configuration
– Throughput efficiency
– QoS maintenance
• The mechanism supports single-hop and multi-hop requests and reports
• It allows exchanging metrics and statistics between MPs for functions such as:– Routing / Forwarding
Why Different Routing Protocols• Cost/Benefit trade-offs depend on applications running over the mesh
– Quick Access and quick adjustment to topology changes critical for VOIP– Efficient Multicast forwarding important for Video– 802.11 STA mobility
• On-demand Routing: discovers and maintains routes only when they are needed.– Pro: Route maintenance only when needed
– Reduce the effects of stale routes and overhead due to topology changes (mobility, mesh point failures or powerdown, etc.)
– No need to maintain unused routes
– Con: Extra route discovery delay and data buffer during route discovery
• Proactive Routing: each node maintains routes to all reachable destinations at all times, whether or not there is current need to deliver data to those destinations. – Pro: Little delay – Con: Routing overhead to keep the routing information current
– Especially when network topology changes frequently
June 2005
Guido Hiertz, Philips, et al.Slide 43
doc.: IEEE 802.11-05/573r0
Submission
Different Routing/Forwarding Algorithms for WLAN Mesh
• Differences between Wireless and Wired Forwarding – Forwarding a data frame out the same interface is normal
in Wireless– Wireless Stations may move and radio links may vary– Wireless nodes may need to detach to save power
• Basic Unicast Routing Algorithm Trade-off– Fast Detection of link and node up/downs and more
control traffic versus slower link and node up/downs and less routing traffic
June 2005
Guido Hiertz, Philips, et al.Slide 44
doc.: IEEE 802.11-05/573r0
Submission
Mechanisms for Wireless Multicast
LegendLegend
X – representing multicast data sourceX – representing multicast data source - MPR\- MPR\ - Non-MPR- Non-MPR
LegendLegend
X – representing multicast data sourceX – representing multicast data source - MPR\- MPR\ - Non-MPR- Non-MPR
• Differences in WLAN Mesh Multicast Forwarding
– Wired Multicast Forwarding (aka Classical Flooding) restricts flooding out interface data came in on
– Broadcasts on a Physical LAN can reach all via hardware
• Reduction Multicast & Broadcast repeat flooding of packets requires:
– Reduction of the Duplicate transmissions of a packet (Data or management) is sent to the MP
– Reduce the number of MP relay nodes
• Multicast Algorithms use: – Duplicate transmission of acks to reduce repeat
data transmission of data or management packets – Use MCDS (Minimum Connected Dominating
Set) based algorithms to reduce flooding nodes
• Multicast Routing Trade-off– Extra data flooding versus time delays for
retransmissions
June 2005
Guido Hiertz, Philips, et al.Slide 45
doc.: IEEE 802.11-05/573r0
Submission
Different Routing Solutions• Different blends of Routing protocols to attempt to maximize performance
– Hybrid 1: Start with link state and reduce overhead during changing topologies– Hybrid 2: Start with on-Demand Distance Vector (ADOV) and add pro-active route
establishment
• Hybrid 1: Link State with Extensions for:– Adhoc routing reduced flooding (based on MANET OSPF)– Support for efficient handling of Wireless Station changes via indirect forwarding – Broadcast/Multicast support via modified link state
• [algorithms based in research in IP protocols (Link-State Path Vector) and Multi-cast OSPF] – Allow weighting of nodes or links based on QoS, Radio, Resource, and Power aware metrics
• Hybrid 2: On-Demand Distance Vector with Extensions to selective Pro-active calculations
– On-Demand starts when data packet arrives• Unicast on-demand when Unicast packet arrives• Multicast on-demand when Multicast packet arrives
– Hybrid proactive route establishment • AODV with extensions to pro-actively create routes attached to Mesh Portal or AS
– Allow weighting of nodes or links based on QoS, Radio, Resource, and Power aware metrics
June 2005
Guido Hiertz, Philips, et al.Slide 46
doc.: IEEE 802.11-05/573r0
Submission
Hybrid Routing Algorithms for MAC address based Forwarding• Hybrid Link-state based
– Fast fail-over for fast routing convergence (aids voice) – Efficient link state routing information flooding (flooding reduction based
on multicast radio transmission) – Calculation of Multicast forwarding topology (on demand based) Based on well studied: – Adhoc MANET-OSPF modified for MAC based routing, Multicast OSPF
• Neighbor’s neighbor info, timers for neighbor down (hello timers), • Wireless station associated with MP (Unicast or Multicast MACs)• Forwarding Capabilities• Metrics for Resource Aware calculations
• Routing category in mesh report carries– Protocol specific messages on topology– Default metrics
• Resource-aware metric, topology metric– Each protocol can utilize “Resource aware” information in
– Multicast Group key (key per multicast group (MTKg)
– Neighbor multicast key (NTKn key per neighbor)
June 2005
Guido Hiertz, Philips, et al.Slide 55
doc.: IEEE 802.11-05/573r0
Submission
Security Algorithms• Security on Data
– Hop by Hop Security: Pair-Wise encryption keys between Neighbors– Tunnel Security: Pair-Wise keys between ends of tunnels– Broadcast Data – Group key used for all members of mesh– Locally Multicast data to neighbors
• Group key used as default • (optional) Neighbor key – can further reduce scope of keys
– Data sent to Multicast groups• Group key used as default• (optional) For applications requiring very tight security, one can create a per
Multicast group key
• Security of management frames with routing – Sequence number – Pair-Wise keys between peers for per-link basis for flooding – Group key between all peers for “multicast” functions of hello
June 2005
Guido Hiertz, Philips, et al.Slide 56
doc.: IEEE 802.11-05/573r0
Submission
m-SA key Establishment – PTK, GTK, NTK
Aspirant-MP Member-MP
Mesh Association
EAPOL AAAServer
M1 (Anonce)
M2 (Snonce, NTK-Aspirant)
M4 (Install)
M3 (NTK-Member, GTK)
PMKPTKNTK,GTK
PMK,PTKNTKGTK
PMKPMK,GTK
PMKPTK
• Just like 802.11i– MP PTK is derived
from MP PMK
– Keys derived or transferred in KDE (s) of EAPOL-Key Messages
June 2005
Guido Hiertz, Philips, et al.Slide 57
doc.: IEEE 802.11-05/573r0
Submission
Optional Secure Multicast Group Set-up • Multicast Group Data
– Encrypted/De-Encrypted at A,B,C only – Only A,B,C need to obtain the MTK– PF between A,B,C only forward encrypted multicast Data
• Secure Multicast Groups Detection– Pre-configured be secured prior to establishment– On-Demand securing based on detection Group MAC in frame
• Multicast group is detected on MP & secure flag is set on multicast group
– MAC address is included in Hello frame & distributed in routing protocol with flag that indicates the group is secure/pending
– Mesh members are detected without multicast data flowing (nodes A, B and C in example)
• Mesh association begins from each node – Multicast group leader initially secures the multicast group– Aspirant-MP sends MP association to the Group Leader– EAPOL occurs– M1, M2, M3, M4 steps occur to install (MMK) and MTK for this
group
• Mesh Group members are signaled– Mesh Group members are signaled that MP member has arrived
via the routing message in the Group MAC message
PF
A
Group LeaderC
PF
B
ASPF
PF
PFPF
PF
June 2005
Guido Hiertz, Philips, et al.Slide 58
doc.: IEEE 802.11-05/573r0
Submission
Optional Secure Multicast Group set-up Aspirant-MP Member-MP
Mesh Assocation (RSN ie, m-RSM ie)
EAPOL AAAServer
M1 (Anonce)
M2 (Snonce, NTK-Aspirant)
M4 (Install)
M3 (NTK-Member, GTK)
PMKPTKNTK,GTK
MMK,MTK
PMKMMK
PMK, MMK,GTK, MTK
PMKPTKMMKMTK
PMKPTKNTK,GTK
MMK,MTK
• Multicast group is detected on MP & secure flag is set on multicast group
– MAC address is included in Hello frame & distributed in routing protocol with flag that indicates the group is secure/pending
• Mesh members are detected without multicast data flowing
• Mesh association begins – Aspirant-MP sends MP association for
to Member MP – EAPOL occurs– M1, M2, M3, M4 steps occur to install
(MMK) and MTK for this group
• Mesh Group members are signaled– Mesh Group members are
June 2005
Guido Hiertz, Philips, et al.Slide 59
doc.: IEEE 802.11-05/573r0
Submission
Mesh Interworking
June 2005
Guido Hiertz, Philips, et al.Slide 60
doc.: IEEE 802.11-05/573r0
Submission
WLAN Mesh Interworking• Higher-Layer Support According to 802.1D
Ref: IEEE 802.1D-2004: 7.12.7Ref: IEEE 802.1D-2004: 7.12.7The functions provided by High-layer Entities can be categorized as requiring eitherThe functions provided by High-layer Entities can be categorized as requiring either
a)a) A single point of attachment to the Bridged Local Area Network, providing connectivity to stations attached to the A single point of attachment to the Bridged Local Area Network, providing connectivity to stations attached to the network at any point (subject to administrative control), as does Bridge Management, or network at any point (subject to administrative control), as does Bridge Management, or
b)b) A distinct point of attachment to each individual LAN attached by a Bridge Port, providing connectivity only to peer A distinct point of attachment to each individual LAN attached by a Bridge Port, providing connectivity only to peer entities connected directly to that LAN …entities connected directly to that LAN …
Ref: IEEE 802.1D-2004: 7.12.7Ref: IEEE 802.1D-2004: 7.12.7The functions provided by High-layer Entities can be categorized as requiring eitherThe functions provided by High-layer Entities can be categorized as requiring either
a)a) A single point of attachment to the Bridged Local Area Network, providing connectivity to stations attached to the A single point of attachment to the Bridged Local Area Network, providing connectivity to stations attached to the network at any point (subject to administrative control), as does Bridge Management, or network at any point (subject to administrative control), as does Bridge Management, or
b)b) A distinct point of attachment to each individual LAN attached by a Bridge Port, providing connectivity only to peer A distinct point of attachment to each individual LAN attached by a Bridge Port, providing connectivity only to peer entities connected directly to that LAN …entities connected directly to that LAN …
High Layer Entities High Layer Entities (Spanning Tree Protocol Entity, Bridge Management, etc.) (Spanning Tree Protocol Entity, Bridge Management, etc.)
