Download IEEE Standard for Local and metropolitan area networks—Link Aggregation PDF

TitleIEEE Standard for Local and metropolitan area networks—Link Aggregation
File Size1.5 MB
Total Pages163
Table of Contents
                            IEEE Std 802.1AX-2008
Notice to users
	Laws and regulations
	Updating of IEEE documents
IEEE Standard for Local and metropolitan area networks—Link Aggregation
Important Notice
1. Overview
	1.1 Scope
	1.2 Purpose
2. Normative references
3. Definitions
4. Acronyms and abbreviations
5. Link Aggregation
	5.1 Overview
		5.1.1 State diagram conventions Actions inside state blocks State diagram variables State transitions Operators
		5.1.2 Goals and objectives
		5.1.3 Positioning of Link Aggregation within the IEEE 802.3 architecture
	5.2 Link Aggregation operation
		5.2.1 Principles of Link Aggregation
		5.2.2 Service interfaces
		5.2.3 Frame Collector Frame Collector state diagram Constants Variables Messages State diagram
		5.2.4 Frame Distributor Frame Distributor state diagram Variables Messages State diagram
		5.2.5 Marker Generator/Receiver (optional)
		5.2.6 Marker Responder
		5.2.7 Aggregator Parser/Multiplexer Aggregator Parser state diagram Constants Variables Messages
		5.2.8 Aggregator State diagram
		5.2.9 Control Parser/Multiplexer Control Parser state diagram Constants Variables Messages State diagram
		5.2.10 Addressing
	5.3 Link Aggregation Control
		5.3.1 Characteristics of Link Aggregation Control
		5.3.2 System identification
		5.3.3 Aggregator identification
		5.3.4 Port identification
		5.3.5 Capability identification
		5.3.6 Link Aggregation Group identification Construction of the Link Aggregation Group Identifier Representation of the Link Aggregation Group Identifier
		5.3.7 Selecting a Link Aggregation Group
		5.3.8 Agreeing on a Link Aggregation Group
		5.3.9 Attaching a link to an Aggregator
		5.3.10 Signaling readiness to transfer user data
		5.3.11 Enabling Collection and Distribution
		5.3.12 Monitoring the membership of a Link Aggregation Group
		5.3.13 Detaching a link from an Aggregator
		5.3.14 Configuration and administrative control of Link Aggregation
		5.3.15 Link Aggregation Control state information
	5.4 Link Aggregation Control Protocol (LACP)
		5.4.1 LACP design elements
		5.4.2 LACPDU structure and encoding Transmission and representation of octets LACPDU structure
		5.4.3 LACP state machine overview
		5.4.4 Constants
		5.4.5 Variables associated with the System
		5.4.6 Variables associated with each Aggregator
		5.4.7 Variables associated with each port
		5.4.8 Variables used for managing the operation of the state machines
		5.4.9 Functions
		5.4.10 Timers
		5.4.11 Messages
		5.4.12 Receive machine
		5.4.13 Periodic Transmission machine
		5.4.14 Selection Logic Selection Logic—Requirements Selection Logic—Recommended default operation
		5.4.15 Mux machine
		5.4.16 Transmit machine
		5.4.17 Churn Detection machines
	5.5 Marker protocol
		5.5.1 Introduction
		5.5.2 Sequence of operations
		5.5.3 Marker and Marker Response PDU structure and encoding Transmission and representation of octets Marker and Marker Response PDU structure
		5.5.4 Protocol definition Operation of the marker protocol Marker Responder state diagram Constants Variables Messages
	5.6 Configuration capabilities and restrictions
		5.6.1 Use of system and port priorities
		5.6.2 Dynamic allocation of operational Keys
		5.6.3 Link Aggregation on shared-medium links
		5.6.4 Selection Logic variants Reduced reconfiguration Limited Aggregator availability
	5.7 Protocol implementation conformance statement (PICS) proforma for Clause 5, Aggregation of Multiple Link Segments
		5.7.1 Introduction
		5.7.2 Abbreviations and special symbols
		5.7.3 Instructions for completing the PICS proforma
		5.7.4 Additional information
		5.7.5 Exceptional information
		5.7.6 Conditional items
		5.7.7 Identification Implementation identification Protocol summary
		5.7.8 Major capabilities/options
		5.7.9 Frame Collector
		5.7.10 Frame Distributor
		5.7.11 Marker protocol
		5.7.12 Aggregator Parser/Multiplexer
		5.7.13 Control Parser/Multiplexer
		5.7.14 System identification
		5.7.15 Aggregator identification
		5.7.16 Port identification
		5.7.17 Capability identification
		5.7.18 Link Aggregation Group identification
		5.7.19 Detaching a link from an Aggregator
		5.7.20 LACPDU structure
		5.7.21 State machine variables
		5.7.22 Receive machine
		5.7.23 Periodic Transmission machine
		5.7.24 Selection Logic
		5.7.25 Mux machine
		5.7.26 Transmit machine
		5.7.27 Churn Detection machines
		5.7.28 Marker protocol
		5.7.29 Configuration capabilities and restrictions
		5.7.30 Link Aggregation on shared-medium links
6. Management
	6.1 Overview
		6.1.1 Systems management overview
		6.1.2 Management model
	6.2 Managed objects
		6.2.1 Introduction
		6.2.2 Overview of managed objects Text description of managed objects
		6.2.3 Containment
		6.2.4 Naming
		6.2.5 Capabilities
	6.3 Management for Link Aggregation
		6.3.1 Aggregator managed object class Aggregator attributes aAggID aAggDescription aAggName aAggActorSystemID aAggActorSystemPriority aAggAggregateOrIndividual aAggActorAdminKey aAggActorOperKey aAggMACAddress aAggPartnerSystemID aAggPartnerSystemPriority aAggPartnerOperKey aAggAdminState aAggOperState aAggTimeOfLastOperChange aAggDataRate aAggOctetsTxOK aAggOctetsRxOK aAggFramesTxOK aAggFramesRxOK aAggMulticastFramesTxOK aAggMulticastFramesRxOK aAggBroadcastFramesTxOK aAggBroadcastFramesRxOK aAggFramesDiscardedOnTx aAggFramesDiscardedOnRx aAggFramesWithTxErrors aAggFramesWithRxErrors aAggUnknownProtocolFrames aAggPortList aAggLinkUpDownNotificationEnable aAggCollectorMaxDelay Aggregator Notifications nAggLinkUpNotification nAggLinkDownNotification
		6.3.2 Aggregation Port managed object class Aggregation Port Attributes aAggPortID aAggPortActorSystemPriority aAggPortActorSystemID aAggPortActorAdminKey aAggPortActorOperKey aAggPortPartnerAdminSystemPriority aAggPortPartnerOperSystemPriority aAggPortPartnerAdminSystemID aAggPortPartnerOperSystemID aAggPortPartnerAdminKey aAggPortPartnerOperKey aAggPortSelectedAggID aAggPortAttachedAggID aAggPortActorPort aAggPortActorPortPriority aAggPortPartnerAdminPort aAggPortPartnerOperPort aAggPortPartnerAdminPortPriority aAggPortPartnerOperPortPriority aAggPortActorAdminState aAggPortActorOperState aAggPortPartnerAdminState aAggPortPartnerOperState aAggPortAggregateOrIndividual
		6.3.3 Aggregation Port Statistics managed object class Aggregation Port Statistics attributes aAggPortStatsID aAggPortStatsLACPDUsRx aAggPortStatsMarkerPDUsRx aAggPortStatsMarkerResponsePDUsRx aAggPortStatsUnknownRx aAggPortStatsIllegalRx aAggPortStatsLACPDUsTx aAggPortStatsMarkerPDUsTx aAggPortStatsMarkerResponsePDUsTx
		6.3.4 Aggregation Port Debug Information managed object class Aggregation Port Debug Information attributes aAggPortDebugInformationID aAggPortDebugRxState aAggPortDebugLastRxTime aAggPortDebugMuxState aAggPortDebugMuxReason aAggPortDebugActorChurnState aAggPortDebugPartnerChurnState aAggPortDebugActorChurnCount aAggPortDebugPartnerChurnCount aAggPortDebugActorSyncTransitionCount aAggPortDebugPartnerSyncTransitionCount aAggPortDebugActorChangeCount aAggPortDebugPartnerChangeCount
Annex A (informative) Collection and Distribution functions
	A.1 Introduction
	A.2 Port selection
	A.3 Dynamic reallocation of conversations to different ports
	A.4 Topology considerations in the choice of distribution algorithm
Annex B (informative) LACP standby link selection and dynamic Key management
	B.1 Introduction
	B.2 Goals
	B.3 Standby link selection
	B.4 Dynamic Key management
	B.5 A dynamic Key management algorithm
	B.6 Example 1
	B.7 Example 2
Annex C (normative) SNMP MIB definitions for Link Aggregation
	C.1 Introduction
	C.2 The SNMP Management Framework
	C.3 Security considerations
	C.4 Structure of the MIB
		C.4.1 Relationship to the managed objects defined in Clause 6
		C.4.2 The Aggregator Group
		C.4.3 The Aggregator Port List Group
		C.4.4 The Aggregation Port Group
		C.4.5 The Aggregation Port Statistics Group
		C.4.6 The Aggregation Port Debug Group
	C.5 Relationship to other MIBs
		C.5.1 Relationship to the Interfaces MIB
		C.5.2 Layering model
		C.5.3 ifStackTable
		C.5.4 ifRcvAddressTable
	C.6 Definitions for Link Aggregation MIB
Document Text Contents
Page 1

IEEE Std 802.1AX™-2008

IEEE Standard for
Local and metropolitan area networks—

Link Aggregation

3 Park Avenue
New York, NY 10016-5997, USA

3 November 2008

IEEE Computer Society
Sponsored by the
LAN/MAN Standards Committee




Page 81

is only possible if it is also acceptable that only one Link Aggregation Group can be constructed from that
Key Group for a given {SK, TL}. In practice, this restriction can be somewhat alleviated by subdividing
Key Groups and allocating different operational Keys to each subdivision; however, this is, in general, only
useful if the form of the size restriction is closely bound to physical subdivisions in the implementation (e.g.,
it might be possible to aggregate only those links that are on the same interface card).

In Systems that have limited aggregation capability of this form, the following algorithm shall be used to
determine the subset of ports that will be aggregated together:

a) The System Aggregation Priority of each System is an eight octet binary number, formed by using
the Actor_System_Priority as the two most significant octets and the Actor’s System ID as the least
significant six octets. For a given Actor and Partner, the System with the numerically lower value of
System Aggregation Priority has the higher priority.

b) The Port Aggregation Priority of each port is a four octet binary number, formed by using the
Actor_Port_Priority as the two most significant octets and the port number as the two least
significant octets. For any given set of ports, the port with the numerically lower value of Port
Aggregation Priority has the higher priority.

c) Ports shall be selected for aggregation by each System based upon the Port Aggregation Priority
assigned by the System with the higher System Aggregation Priority, starting with the highest
priority port of the System with the higher priority, and working downward through the ordered list
of Port Aggregation Priority values for the N ports, applying the particular constraints imposed on
the System concerned.

d) For each link that a given System cannot include in the aggregation, the Selection Logic identifies
the Selection state of the corresponding port as STANDBY, preventing the link from becoming
active. The synchronization state signaled in transmitted LACPDUs for such links will be

e) The selection algorithm is reapplied upon changes in the membership of the Link Aggregation
Group (for example, if a link fails, or if a new link joins the group) and any consequent changes to
the set of active links are made accordingly.

A port that is selected as standby as a result of limitations on aggregation capability can be viewed as
providing a “hot standby” facility, as it will be able to take part in the aggregation upon failure of one of the
active links in the aggregation. The ability to hold links in a standby mode in this way provides the
possibility of using LACP even where the System is incapable of supporting distribution and collection with
more than one port. Parallel links could be automatically configured as standby links, and deployed to mask
link failures without any disruption to higher layer protocols.

5.6.2 Dynamic allocation of operational Keys

In some circumstances, the use of System and port priorities may prove to be insufficient to generate the
optimum aggregation among the set of links connecting a pair of Systems. A System may have a limited
aggregation capability that cannot be simply expressed as a limit on the total number of links in the
aggregation. The full description of its restrictions may be that it can only aggregate together particular
subsets of links, and the sizes of the subsets need not all be the same.

NOTE 1—An example would be an implementation organized such that, for a set of four links A through D, it would be
possible to operate with {A+B+C+D} as a single aggregation, or operate with {A+B} and {C+D} as two separate
aggregations, or operate as four individual links; however, all other aggregation possibilities (such as {A+C} and
{B+D}) would not be achievable by the implementation.

In such circumstances, it is permissible for the System with the higher System Aggregation Priority (i.e., the
numerically lower value) to dynamically modify the operational Key value associated with one or more of
the ports; the System with the lower priority shall not attempt to modify operational Key values for this
purpose. Operational Key changes made by the higher priority System should be consistent with
maintaining its highest priority port in the aggregate as an active link (i.e., in the IN_SYNC state).
Copyright © 2008 IEEE. All rights reserved. 63

Page 82

Successive operational Key changes, if they occur, should progressively reduce the number of ports in the
aggregation. The original operational Key value should be maintained for the highest priority port thought to
be aggregateable.

NOTE 2—Restricting operational Key changes in the manner described prevents the case where both Partner Systems
involved have limited capability and both attempt to make operational Key changes; this could be a non-converging
process, as a change by one participant can cause the other participant to make a change, which in turn causes the first
participant to make a change—and so on, ad infinitum.

This approach effectively gives the higher priority System permission to search the set of possible
configurations, in order to find the best combination of links given its own and its Partner’s configuration
constraints. The reaction of the Partner System to these changes can be determined by observing the changes
in the synchronization state of each link. A System performing operational Key changes should allow at
least 4 s for the Partner System to change an OUT_OF_SYNC state to an IN_SYNC state.

In the course of normal operation a port can dynamically change its operating characteristics (e.g., data rate,
full or half duplex operation). It is permissible (and appropriate) for the operational Key value associated
with such a port to change with the corresponding changes in the operating characteristics of the link, so that
the operational Key value always correctly reflects the aggregation capability of the link. Operational Key
changes that reflect such dynamic changes in the operating characteristics of a link may be made by either
System without restriction.

5.6.3 Link Aggregation on shared-medium links

The Link Aggregation Control Protocol cannot detect the presence of multiple Aggregation-aware devices
on the same link. Hence, shared-medium links shall be treated as Individual, with transmission/reception of
LACPDUs disabled on such ports.

5.6.4 Selection Logic variants

Two variants of the Selection Logic rules are described as follows:
a) The first accommodates implementations that may wish to operate in a manner that minimizes

disturbance of existing aggregates, at the expense of the deterministic characteristics of the logic
described in

b) The second accommodates implementations that may wish to limit the number of Aggregators that
are available for use to fewer than the number of ports supported. Reduced reconfiguration

By removing the constraint that the Aggregator chosen is always the lowest numbered Aggregator
associated with the set of ports in an aggregation, an implementation can minimize the degree to which
changes in the membership of a given aggregation result in changes of connectivity at higher layers. As
there would still be the same number of Aggregators and ports with a given operational Key value, any port
will still always be able to find an appropriate Aggregator to attach to, however the configuration achieved
over time (i.e., after a series of link disconnections, reconnections, or reconfigurations) with this relaxed set
of rules would not necessarily be the same as the configuration achieved if all Systems involved were reset,
given the rules stated in 5.4.15. Limited Aggregator availability

By removing the constraint that there are always as many Aggregators as ports, an implementation can limit
the number of MAC Client interfaces available to higher layers while maintaining the ability for each
Aggregator to serve multiple ports. This has the same effect as removing the assumption that Aggregators
and their associated ports have the same operational Key value; Aggregators can be effectively disabled (and
64 Copyright © 2008 IEEE. All rights reserved.

Page 162

STATUS current
“A collection of objects providing information about every
port in an aggregation.”
::= { dot3adAggGroups 4 }

dot3adAggPortDebugGroup OBJECT-GROUP
STATUS current
“A collection of objects providing debug information about
every aggregated port.”
::= { dot3adAggGroups 5 }

dot3adTablesLastChangedGroup OBJECT-GROUP
STATUS current
“A collection of objects providing information about the time
of changes to the configuration of aggregations and their ports.”
::= { dot3adAggGroup 6 }

-- -------------------------------------------------------------
-- compliance statements
-- -------------------------------------------------------------

dot3adAggCompliance MODULE-COMPLIANCE
STATUS current
“The compliance statement for device support of
Link Aggregation.”
144 Copyright © 2008 IEEE. All rights reserved.

Page 163


GROUP dot3adAggPortListGroup
“This group is optional.”

GROUP dot3adAggPortStatsGroup
“This group is optional.”

GROUP dot3adAggPortDebugGroup
“This group is optional.”

::= { dot3adAggCompliances 1 }

Copyright © 2008 IEEE. All rights reserved. 145

Similer Documents