Geneva, Switzerland, 13 July 2013

802.1AX-REV – Link Aggregation Revision

Panagiotis Saltsidis,Senior Specialist, Ericsson

Joint IEEE-SA and ITU Workshop on Ethernet

Geneva, Switzerland, 2 13 July 2013 2

Link aggregation

Link Aggregation was originally standardized in 802.3ad-2000 (it has been later incorporated in 802.3 as clause 43 of 802.3-2005).Since 2000 there has been a growing demand that Link Aggregation should not be specific to an individual MAC technology, and that the maintenance work should be done in 802.1.In 2008 Link Aggregation was removed from the 802.3-2008 revision and published as IEEE Std 802.1AX-2008.A limitation of the current IEEE802.1AX is that all physical ports in the link aggregation group must reside on the same switch which in most scenarios will leave a single point of failure when the physical switch to which all links are connected goes offline. Proprietary solutions that address dual homed scenarios exist

Original 802.1AX Goals

Increased bandwidthLinearly incremental bandwidthIncreased availabilityLoad sharingAutomatic configurationRapid configuration and reconfigurationDeterministic behaviorLow risk of duplication or misorderingSupport of existing MAC ClientsBackwards compatibility with aggregation-unaware devicesAccommodation of differing capabilities and constraintsNo change to frame formatsNetwork management supportDissimilar MACs

Geneva, Switzerland,13 July 2013 3

Link Aggregation Sublayer

Geneva, Switzerland,13 July 2013 4

AggregatorParser/Mult iplexer

AggregatorParser/Mult iplexer

AggregatorParser/Multiplexer• • •

MarkerResponder

FrameCollector

Frame Collection

Marker Generator/Receiver (optional)

FrameDistributor

Frame Distribution

Aggregator

ControlParser/Multiplexer

ControlParser/Multiplexer

ControlParser/Multiplexer• • •

Link AggregationControl Protocol

Aggregation Control

Link AggregationControl shared state variables

Link Aggregationsublayer

ControlframesInternal Sublayer Service Interface(s)

MAC MAC MAC

Internal Sublayer Service Interfaces

Aggregator Client

Internal Sublayer Service Interface

Agg: M_UNITDATA ( )

CtrlMuxN: M_UNITDATA ( ) and

MacN: M_UNITDATA ( )

Internal Sublayer

AggMuxN:

Aggregator Client andMarker frames

MarkerFrames

MAC

FramesClient

MAC

FramesClient

MarkerFrames

Service Interface(s)

M_UNITDATA ( )

DataMuxN: M_UNITDATA()CtrlMux CtrlMux

DataMuxDataMux

IEEE802.1AX-REV - DRNI

Link Aggregation—DRNI provides benefits of Link AggregationPortals—Connections between two cooperating sets of Systems (two Portals) are supported, in contrast to Link Aggregation defined by previous versions of the standard, so that connectivity between two networks can be maintained despite the failure of an entire System (and its connected links) belonging to a Portal.Compatibility—A multi-System Portal can connect to a single-System Portal or to an Aggregation System compliant with previous versions of this Standard.Administrative isolation—A DRNI Link Aggregation Group can connect Portals in networks that are under separate administration, running different fault recovery protocols.Administrative independence—The specification of DRNI to interconnect separate networks does not introduce new requirements on either networks’ existing control protocols.

Geneva, Switzerland,13 July 2013 5

IEEE802.1AX-REV - DRNI

Inter-network fault isolation—The failure or recovery of a link or node in one network, requiring a reaction by that network’s control protocols, can be hidden by DRNI from the second network’s control protocols. Thus, super-networks can be created out of separate networks interconnected via DRNI, without propagating one network’s fault and recovery events throughout the super-network.Network-DRNI fault isolation—The failure or recovery of a link between two Portals can be hidden by DRNI from both networks’ control protocols.Rapid fault recovery—Means for the Systems in a Portal to communicate are provided so that they can cooperate to respond rapidly to failure or recovery events, typically on the order of milliseconds for link down events and 1 second or less for link up events.Extended faults—Optional elements of DRNI can support three Systems in a Portal, so that fault redundancy can be provided even while a System is added or removed from a Portal.Distribution independence—The frame distribution algorithm used to satisfy network requirements can be different from the algorithm used to assign frames to the Aggregation Ports of a Link Aggregation Group.

Geneva, Switzerland,13 July 2013 6

DRNI

DRNI is created by using a Distributed Relay to interconnect two or three Systems, each running Link Aggregation, to create a Portal. Each System in the Portal (i.e., each Portal System) runs Link Aggregation with a single Aggregator. The Distributed Relay enables the Portal Systems to jointly terminate a Link Aggregation Group. To all other Systems to which the Portal is connected, the Link Aggregation Group appears to terminate in a separate emulated System created by the Portal Systems

Geneva, Switzerland,13 July 2013 7

Systems in a Portal

Systems A and B each is characterized by performing a “Function 1,” which is presumably some kind of packet relay function, e.g., a router or a bridge. “Function 1” could just as well be a file server operation, in which case the outside two “ports” on each System would likely not be present. Each system runs a single instance of a Link Aggregation sublayer.

Geneva, Switzerland,13 July 2013 8

Funct ion 1 Funct ion 1

possibleother

possibleother

port

networklinks

networklinks

port

System A System B

possible network linkMAC q MAC r

Link Aggregat ionportport

MAC p

Link Aggregat ion

MAC s MAC t

Distributed Relay

There appears to exist a third emulated System C, connected to the original Portal Systems by a link that has been inserted between Function 1 and Link Aggregation.

Portal Systems A and B conspire to behave, insofar as any other Systems to which they are connected can discern, as if emulated System C actually exists

The Distributed Relay supports:The necessary protocols and procedures for up to three Portal Systems.Link Aggregation functions, each subsuming one or more MACsConnections among the Portal Systems of the Distributed Relay.The Distributed Relay in the emulated System C is an (N+1)-port relay for N Portal Systems, with N Gateway Ports connected to the Portal Systems, and a single Emulated Link Aggregation sublayer associated with the original Portal Systems.The Aggregation Ports (MACs) have been moved to the emulated System, and thus appear, to all other Systems, to be equally distant from the real Portal Systems comprising the Distributed Relay.

Geneva, Switzerland,13 July 2013 9

Gateway

Portal System A Portal System B

Emulated System C

Link Aggregat ionGateway MAC

MAC

MAC q MAC r

MAC

MAC

MAC s

Funct ion 1 Function 1

possible network link

portport

possibleother

possibleother

port

networklinks

networklinks

port

Distributed Relay

MAC p MAC t

View from Systems A and B

In each System A and B, the ports that are to be associated with System C are moved to a position below the DR Function’s Link Aggregation sublayer.A virtual link and its terminating virtual MACs, called a “Gateway”, is constructed to connect each DR Function to its Function 1.Between each pair of DR Functions in the Portal there is constructed an Intra-Portal Link (IPL), terminated at each end by an Intra-Portal Port (IPP). There is a “Gateway algorithm” that decides through which Gateway a frame can pass into or out of the emulated Distributed Relay.Similarly, a “Port algorithm” decides through which Portal System’s Aggregation Ports a frame can pass into or out of the emulated Distributed Relay.The DR Functions, work together to move frames between the Gateways, the IPLs, and the Link Aggregation sublayers.

Geneva, Switzerland,13 July 2013 10

Portal System A Portal System B

Function 1 Function 1

possible network link

portport

possibleother

possibleother

port

networklinks

networklinks

port

Gateway Gateway

DR Function DR Function

IPP IPP

IPLMAC rMAC q

Emulated System C

MAC p MAC tMAC s

MAC

MAC

MAC

MACLink AggregationLink Aggregat ion

Not an example of a DRNI Portal

IEEE802.1AX-REV will not define the alternate model shown in Figure above, in which the entirety of Systems A and B simulate a single System D, but neither will it prevent the use of DRNI in such a model

Geneva, Switzerland,13 July 2013 11

port

possibleotherlinks

MAC

Link Aggregation Group

port

possibleotherlinks …

MAC

Distributed Forwarding and/or Upper Layers

Link Aggregation

System D = A + B

MAC

Portal Systems Topology

The mechanisms specified in IEEE802.1AX-REV support certain topologies of Portal Systems interconnected by IPLs.

The trivial case of a single-System Portal, which of course has no IPL.A Portal with two Systems, connected by an IPL. A ring of three Systems, connected by three IPLs.Three Portal Systems in a linear topology with two IPLs. Note that this topology may arise by design or by failure of an IPL in a ring of three Portal Systems.

Geneva, Switzerland,13 July 2013 12

Intra-Portal Link

An Intra-Portal Link can be supported by physical (e.g., an 802.3 Ethernet LAN) or logical (e.g., a PBB tunnel or an IETF pseudowire) links. DRNI supports a number of methods by which the systems can distinguish frames on a network link from frames on a particular Intra-Portal Link:

Physical. A separate physical link can be used for any particular network link or Intra-Portal Link.Aggregated. A separate Aggregation can be used for an IPL.Time-shared. A network link and one or more IPLs can use the same physical link (or Aggregator Port), but at different times. This requires that the Systems disable the use of the network link when the IPL is required for connectivity, or else that the use of the Aggregation Links and the selection of Gateways be adjusted to eliminate the need for using the IPL when the network link is required.Tag-shared. If Per-service frame distribution is employed, and if the number of services required to support the network link, plus the number of services required to support one or more Intra-Portal Links, is less that the number of services supplied by the frame format used (e.g., 4094 S-VLAN IDs), then VID translation can be used to separate the frames on the different logical links. Encapsulated. The frames on the network link and the IPL(s) can be encapsulated.

A system implementing the DRNI shall support using separate physical links for IPLs and network links, and may support any of the other methods.

Geneva, Switzerland,13 July 2013 13

Distributed Relay Control Protocol

The purpose of the Distributed Relay Control Protocol (DRCP) is to:

Establish communication between Portal Systems across an Intra-Portal Link;Verify the consistent configuration of Portal Systems;Determine the identity to be used for the emulated System;Distribute the current states of the Portal Systems and their Aggregation Ports among each other;Compute the resultant path of any frame required to pass through each IPL, and exchange the information with adjacent Portal Systems as required to ensure against forwarding loops and duplicate frame delivery.

Geneva, Switzerland,13 July 2013 14

Establishing the Portal and Distributed Relay

802.1AX-REV will not specify the creation of Portals automatically. DRCP compares the network administrator’s intentions, as defined by managed objects, to the physical topology of the configured Systems, and if the connected Systems’ configurations are compatible, DRCP establishes and enables the operation of the Portal.

In order to establish a Distributed Relay across a Portal, a network administrator will configure the following managed objects

Which systems are to participate in a Portal. Which point-to-point links are to be assigned as Intra-Portal Links. Which Aggregator in each Portal System is to be assigned to its DR Function The methods to be used by the DR Functions to assign frames to Gateway Conversation IDs and Port Conversation IDs The prioritized list of assignments of Conversation IDs to Gateways and Aggregation Ports to cover failure modes

Geneva, Switzerland,13 July 2013 15

Current Status – Schedule

The 6th Task Group Ballot will be discussed during this meetingThe aim is have new drafts and associated ballots per IEEE802.1 meetingThe goal is to have an approved and published standard during the first half of 2014

Geneva, Switzerland,13 July 2013 17