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)
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.
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.
3
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 IntraPortal 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 interconnected 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
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.
11
Thank You
.
12