Rough Outline for a Intra-Portal Protocol

Version 03

Stephen Haddock

September 12, 2012

1

New in this version (v03)

• Updated to reflect recent split-brain discussions– In particular this version is intended to be compatible with

http://ieee802.org/1/files/public/docs2012/axrev-farkas-split-brain-handling-0912-v01.pdf

– Major changes:• Emulated System ID is configured to be the same in each Portal System.

• All Portal Ports always use Emulated System ID in LACPDUs, even when the Intra-Portal Link(s) are down.

• The only parameter that changes in Portal Port LACP when the Intra-Portal Links are up or down is the Key.

• Intended to support Portals with more than two systems– In particular the topologies in http://ieee802.org/1/files/public/docs2012/axrev-farkas-split-brain-handling-0912-v01.pdf

2

Intra-Portal Topologies (from Finn)

3

Protocol discussed in this presentation will support these and detect cases where there are more than three stations in a chain or ring with active Intra-Portal Links. May not be able to detect large chains or rings that are segmented by inactive Intra-Portal Links.

Protocol discussed in this presentation could support these for some defined maximum number of Portal Systems in the star. Could conceivably support partial meshes of Portal Systems provided only one system has more than two Intra-Portal Links, but may not be able to detect violations of that rule.

Objectives of the Intra-Portal Protocol

1. Establish communication between Portal Systems across an Intra-Portal Link.

2. Verify consistent configuration of Portal Systems that would allow formation of an Emulated System and a DRNI.

3. Select the Emulated System parameters to be advertised in LACPDUs on the Portal Ports.

4. Provide a vehicle for exchanging TLVs between Portal Systems that contain other information that needs to be coordinated between Portal Systems.

– E.g. MEP-IDs, Conversation-ID-to-Gateway relationships, etc.

– State machines or algorithms that negotiate, or take action upon, the information in these TLVs are not considered part of the basic Intra-Portal Protocol.

4

Configuring the Portal

• Configure a Portal Identifier for each Portal– Needs to be the same in all systems in a portal.

– Needs to be unique within each system of a portal.

– Could be the same as the System ID for the Emulated System • But Emulated System ID has additional uniqueness requirements.

– Used to detect mis-connections of Intra-Portal Links

– In systems with multiple Portals, used to assure Portal Ports and Intra-Portal Ports get associated with the correct Portal.

• Designate the Intra-Portal Port(s) for each Portal– Could be physical or virtual ports.

• Designate the Portal Port(s) for each Portal– These are the ports on each system that will become ports on the

Emulated System for the Portal.

5

Emulated System LACP Parameters -1

• System ID for Emulated System of each Portal– Needs to be “globally” unique (i.e. unique across all inter-connected

networks).

– Configured to be the same in each Portal System.• Intra-Portal Protocol will verify that each Portal System is configured with the

same value.

• If the value is not the same, then the resulting aggregation will not be distributed between the Portal Systems (details to follow).

• Previous versions of this presentation proposed each Portal System be configured with a different candidate Emulated System ID, and the protocol agree on which to use. The change to configure the same Emulated System ID in each system substantially weakens the argument for having Portal ID separate from Emulated System ID.

– Concatenation of a 16 bit priority value and a 48 bit MAC address.• This MAC address will be used as the MAC address of the Aggregated Port.

• The MAC address may be the same as the MAC address of one of the Portal Ports of the Emulated system, with the caveat that this can complicate swapping hardware components in real deployments.

6

Emulated System LACP Parameters - 2

• LACP Key– Each Portal System has an Administrative Key and an Operational

Key for the Emulated System.• The Administrative Key is configured and must be different for each Portal

System. Specifically the two MSBs must be different in each Portal System. (This allows up to three systems in the portal with the value of the MSBs being 01, 10, or 11. Would need more bits for the “star” topology from Norm Finn’s port selection presentation.) The lower 14 bits may be any value, do not need to be the same in each Portal System, and have a default of zero.

• The Operational Key takes the value of the Administrative Key when the Portal Systems are not in synchronization, and the value of the numerically lowest Administrative Key of all systems in the Portal when the Portal Systems are in synchronization.

7

Emulated System LACP Parameters - 3

• Portal Port Identifiers– Need to be unique within an Emulated System.

• Propose that each Portal System configure Port IDs such that the lower 14 bits are unique within the Portal System and the two MSBs have the same value of the two MSBs of the Administrative Key.

8

Intra-Portal Protocol Operation

• Modeled after LACP operation.• Each Portal System maintains Portal Information for itself

(Portal Actor) and for its Portal Partner(s).– Portal Information consists of the Portal Identifier, Emulated System

ID, Emulated System Administrative Key, and Portal State.• Specifics of Portal State to be defined later, but will include the synchronization

state with each Portal Partner.

– Portal Partner Information set to zero on initialization, when the Intra-Portal Link is down, and on a protocol timeout.

• Each Portal System sends advertisement PDUs on each Intra-Portal Link– PDUs contain Portal Actor Information, Portal Partner Information

(for Partner on this Intra-Portal Link), and Other Portal Partner Information (for Partner on the other Intra-Portal Link).

• Abbreviate as PA-Info, PP-Info, and OPP-Info

9

Intra-Portal Protocol Operation (cont.)

• Upon receiving an advertisement PDU on an Intra-Portal Link, the protocol:– Records the received PA-Info as this Portal System’s PP-Info for this

Intra-Portal Link, and

– Compares the received PP-Info to this Portal System’s PA-Info, and

– Compares the received OPP-Info to this Portal System’s PP-Info for the other Intra-Portal Link.

• Portal System is in synchronization with a Portal Partner when:– The Portal Identifier and Emulated System ID are the same for each

system in the Portal, and

– The Administrative Key is different for each system in the Portal, and– The received PP-Info matches this Portal System’s PA-Info.

10

Intra-Portal Protocol

11

Re-use the LACP structure for controlling the Intra-Portal Protocol on each Intra-Portal Link• Rx, Periodic, and Tx state machines

• Adapt to control the exchange of IPPDUs on each Intra-Portal Link.

• Selection Logic • Replace with logic or state machine that

verifies compatibility of the Intra-Portal Links and selects an Operational Key value to be used by LACP on the Portal Ports.

• Mux state Machine• Controls the synchronization state of the

Intra-Portal Link.

• When IN-SYNC, the Intra-Portal Link may be used to forward data frames between the Portal Systems.

Thank You

.

12