One document matched: draft-shah-extreme-rfc3619bis-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3619 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3619.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most
I-Ds might want to use. (Here they are set differently than their
defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="no" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-shah-extreme-rfc3619bis-01" ipr="noModificationTrust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3978, noModification3978, noDerivatives3978
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only
necessary if the full title is longer than 39 characters -->
<title abbrev="Extreme Networks' EAPS Version 1.3">Extreme Networks' Ethernet Automatic Protection Switching (EAPS), Version 1.3</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Arnel Lim" initials="A" surname="Lim" role="editor">
<organization>Extreme Networks</organization>
<address>
<postal>
<street>3585 Monroe Street</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>USA</country>
</postal>
<phone>+1 408-579-2688</phone>
<email>alim@extremenetworks.com</email>
</address>
</author>
<author fullname="Steven Blake" initials="S" surname="Blake" role="editor">
<organization>Extreme Networks</organization>
<address>
<postal>
<street>Pamlico Building One, Suite 100</street>
<street>3306/08 E. NC Hwy 54</street>
<city>RTP</city>
<region>NC</region>
<code>27709</code>
<country>USA</country>
</postal>
<phone>+1 919-884-3211</phone>
<email>sblake@extremenetworks.com</email>
</address>
</author>
<author fullname="Sunil Shah" initials="S" surname="Shah">
<organization>Ericsson</organization>
<address>
<postal>
<street>300 Holger Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408-750-8523</phone>
<email>sunil.shah@ericsson.com</email>
</address>
</author>
<date year="2011" month="June" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Individual Submission</workgroup>
<!-- WG name at the upperleft corner of the doc, IETF is fine for
individual submissions. If this element is not present, the default
is "Network Working Group", which is used by the RFC Editor as a nod
to the history of the IETF. -->
<keyword>EAPS</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
This document describes version 1.3 of the Ethernet Automatic
Protection Switching (EAPS) (TM) technology invented by Extreme
Networks to increase the availability and robustness of Ethernet rings.
An Ethernet ring built using EAPS can have resilience comparable to
that provided by SONET rings, at lower cost and without some of the
constraints (e.g. ring size) of SONET.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Many Metropolitan Area Networks (MANs) and some Local Area
Networks (LANs) have a ring topology, as the fiber runs. The Ethernet
Automatic Protection Switching technology described here works well in
ring topologies for MANs or LANs.
</t>
<t>
Also, most MAN operators want to minimize the recovery time in
the event a fiber cut occurs. The Spanning Tree Protocol
<xref target="IEEE802.1D-1998">STP</xref> can take as
long as 40 seconds to converge in the event of a topology change. The
newer Rapid Spanning Tree Protocol
<xref target="IEEE802.1D-2004">RSTP</xref>
is considerably faster. However, its convergence time is still dependent
upon the number of switching nodes in the ring. Both STP and RSTP
limit the number of switches in the ring. The Ethernet Automatic
Protection Switching (EAPS) technology described here converges in
less than one second, often in less than 100 milliseconds. EAPS
technology does not limit the number of switches in the ring, and the
convergence time is independent of the number of switches. </t>
<t>
EAPS version 1 is specified in
<xref target="RFC3619"></xref>.
</t>
</section>
<section title="Concept of Operation">
<t>
An EAPS Domain exists on a single Ethernet ring. Any Ethernet
Virtual Local Area Network (VLAN) that is to be protected is
configured on all ports in the ring for the given EAPS Domain. Each
EAPS Domain has a single designated "Master node". Each other switch
on that ring is referred to as a "Transit node".
</t>
<t>
Of course, each switch on the ring will have 2 ports connected to
the ring. One port of the Master node is designated to be the
"primary port" to the ring for the Master node. The other port
is designated as the "secondary port".
</t>
<t>
In normal operation, the Master node blocks the secondary port
for all non-control Ethernet frames belonging to the given EAPS
Domain, thereby avoiding a loop in the ring. Existing Ethernet
switching and learning mechanisms operate per existing standards on
this ring. This is possible because the Master node makes the ring
appear not to have a loop, from the perspective of the Ethernet
standard algorithms used for switching and learning. If the Master
node detects a ring fault, it unblocks its secondary port and allows
Ethernet data frames to pass through that port. There is a special
"Control VLAN" that can always pass through all ports in the EAPS
Domain, including the secondary port of the Master node.
</t>
<t>
EAPS uses both a polling mechanism, described in detail below,
and an alert mechanism, also described below, to verify the
connectivity of the ring and to quickly detect any faults.
</t>
<t>
EAPS frames are encoded using the Extreme Networks' Encapsulation
Protocol. The EAPS frame format is defined in
<xref target="Sec-EAPS_Frame_Format" />. All EAPS frames use a source
MAC address of 00-E0-2B-00-00-01 (assigned out of an Extreme
Networks OUI). All EAPS frames use a destination MAC address
of 00-E0-2B-00-00-04 (with the exception of FLUSH-FDB-PDU,
described in <xref target="Sec-EAPS_SHARED-PORTS" />).
</t>
<section title="Link Down Alert">
<t>
When any Transit node detects a link-down on any of
its ports in the EAPS Domain, that Transit node immediately
sends a "link down" control frame (LINK-DOWN-PDU) on the Control
VLAN to the Master node.
</t>
<t>
When the Master node receives this "link down" control
frame, the Master node moves from the "normal" state (COMPLETE) to
the ring-fault state (FAILED) and unblocks its secondary port. The
Master node also flushes its bridging table. The Master node also
sends a control frame (RING-DOWN-FLUSH-FDB) to all other ring switches
instructing them to flush their bridging tables. Immediately after
flushing its bridging table, each switch starts learning the new
topology.
</t>
</section>
<section title="Ring Polling">
<t>
The Master node sends a health-check frame (HEALTH-CHECK-PDU) on
the Control VLAN at a user-configurable interval. If the ring is
complete, this will be received on its secondary port. Upon
receipt of the HEALTH-CHECK-PDU, the Master node resets its
Fail-period timer and continues normal operation.
</t>
<t>
If the Master node does not receive the HEALTH-CHECK-PDU
before the Fail-period timer expires, the Master node moves from the
normal state to the "ring-fault" state (FAILED) and unblocks its
secondary port. The Master node also flushes its bridging table. The
Master node also sends a control frame (RING-DOWN-FLUSH-FDB) to all
other switches instructing them to also flush their bridging tables.
Immediately after flushing its bridge table, each switch starts
learning the new topology. This ring polling mechanism provides a
backup in the event the Link Down Alert frame (LINK-DOWN-PDU) should
get lost for some unforeseen reason.
</t>
</section>
<section title="Ring Restoration">
<t>
The Master node continues sending periodic HEALTH-CHECK-PDUs
out its primary port even when operating in the
ring-fault (FAILED) state. Once the ring is restored, the very next
HEALTH-CHECK-PDU sent will be received on the Master node's
secondary port. This will cause the Master node to transition
back to the normal (COMPLETE) state, logically block non-control frames
on the secondary port, flush its own bridge table, and send
a control frame (RING-UP-FLUSH-FDB-PDU) to the Transit nodes
instructing them to flush their bridging tables and re-learn the
topology.
</t>
<t>
During the time between the Transit node detecting that its
link is restored and the Master node detecting that the ring is
restored, the secondary port of the Master node is still open --
creating the possibility of a temporary loop in the topology. To
prevent any temporary loop, the Transit node will put all the
protected VLANs transiting the newly restored port into a temporary
blocked state, remember which port has been temporarily blocked, and
transition into the "PREFORWARDING" state. When the Transit node in
the PREFORWARDING state receives a RING-UP-FLUSH-FDB-PDU
instructing it to flush its bridging table, it
will flush the bridging table, unblock the previously blocked
protected VLANs on the newly restored port, and transition to the
"normal" (LINKS-UP) state.
</t>
</section>
<section title="Preventing False Failures">
<t>
One of the biggest drawbacks of using the ring-polling mechanism in
detecting failures is when the EAPS HEALTH-CHECK-PDUs do not return to
the Master node, even though the ring itself is complete. This could
happen due to a number of reasons such as the Control VLAN not being
configured correctly on all switches in the ring; or bad hardware
dropping control PDUs; or too much traffic on the ring causing control
PDUs to get dropped or delayed; or the Master node's CPU being too
busy, and not getting a chance to process a HEALTH-CHECK-PDU thereby
causing its Fail-period timer to expire.
</t>
<t>
When the EAPS Master node enters into FAILED state due to its
Fail-period timer expiring, and unblocks its secondary port, it
may inadvertently cause a loop in the network if the ring is
actually complete.
</t>
<t>
The EAPS Master node can be configured to take one of two actions
when its Fail-period timer expires:
</t>
<t>
<list style="letters">
<t>
Open the secondary port - This is the earlier behavior, and can
still be used if the EAPS network has a non-EAPS switch not capable
of sending a LINK-DOWN-PDU when its link goes down. In such a
network, we would still need to use the polling mechanism to detect
failures in the ring. In these cases, when the Fail-period timer
expires, forwarding on the the secondary port needs to be enabled.
</t>
<t>
Send alert - This is the preferred configuration and should be the
default setting. In this mode, if the Fail-period timer expires, and
the Master node has not received a LINK-DOWN-PDU, or an event
indicating a local link failure, it keeps its secondary-port in
blocking state, and sends an alert message to the network
administrator. A "Failed flag" is set to let the user know that the
Fail-period timer expired without any legitimate reason such as
a local link going down or receiving a LINK-DOWN-PDU.
</t>
</list>
</t>
<t>
To handle the situation where a LINK-DOWN-PDU may been missed or
dropped, a new PDU type has been introduced - QUERY-LINK-STATUS-PDU.
When the Master node's Fail-period timer expires while being
configured for send-alert, it's Failed flag gets set. The Master node
also sends the QUERY-LINK-STATUS-PDU out both its ring-ports. If any
Transit node in the ring has one of its links down, it will respond
with its regular LINK-DOWN-PDU. This way, if there is a legitimate
failure in the ring, the Master node will get a chance to learn about
it and transition to the regular FAILED state and unblock its
secondary-port.
</t>
</section>
<section title="Enhancements to Aid in Trouble-Shooting">
<t>
A couple of enhancements have been added to the EAPS protocol since
<xref target="RFC3619"></xref> to help in trouble-shooting an EAPS
network.
</t>
<t>
<list style="letters">
<t>
INIT state - This state was introduced to differentiate it from the
Master node's COMPLETE state. When the EAPS Master node is coming
up for the first time, and detects that both of its ring-ports are
up, it still doesn't know if the ring itself is complete or not.
It takes the safe approach and blocks its secondary-port to prevent
a possible loop in the network. The Master node will transition
into the COMPLETE state when it receives its HEALTH-CHECK-PDU.
<vspace blankLines="1" />
If say a switch had a misconfigured Control VLAN, the
HEALTH-CHECK-PDU would not make it back to the Master node, and
it would remain in INIT state. This would be a clue to the network
administrator that there is an apparent problem in the EAPS
network, while at the same time, the secondary port would remain
blocked, preventing a loop in the network.
</t>
<t>
LINK-UP-PDU - When a link comes up on a Transit node, it will send a
LINK-UP-PDU to the Master node, which would get logged in its
logging database. The timestamp of this log message could be used
in trouble-shooting an EAPS network if for example it never
transitioned to COMPLETE state.
</t>
</list>
</t>
</section>
<section title="PREFORWARDING State on Transit">
<t>
On a Transit node, when one ring-port is already up, and the other
one transitions from down to up, this Transit node's state will
change from LINK-DOWN to PREFORWARDING. This is a state to prevent a
temporary loop in the network.
</t>
<t>
Without this state, a Transit node which already had one port up,
and had the other one coming up would have transitioned from LINK-DOWN
state to LINKS-UP state where both ports are forwarding. At that moment
the Master node is still in FAILED state where both of its ports are
forwarding. We would have a temporary loop in the network until the
Master node detected the ring is complete and blocked its secondary
port.
</t>
<t>
When a port comes up on the Transit node, it checks the status of its
other ring-port. If the other port is also up, it enters into
PREFORWARDING state, and keeps the port that just came up in blocking
state, while starting its Preforwarding timer. It now waits to receive
the RING-UP-FLUSH-FDB-PDU from the Master node. The Master node sends
this PDU when it enters into COMPLETE state and has blocked its
secondary-port.
</t>
<t>
When the Transit node sees the RING-UP-FLUSH-FDB-PDU message, it
knows that the ring has been blocked by the Master node, so it
transitions from PREFORWARDING state into the LINKS-UP state, enables
forwarding on its previously blocked port, and flushes its FDB. The
Transit node also stops the Preforwarding timer.
</t>
<t>
The role of the Preforwarding timer is to deal with a lost
RING-UP-FLUSH-FDB-PDU. It is also used in the case of another break in
the ring, in which case the Transit node would not receive a
RING-UP-FLUSH-FDB-PDU from the Master node. Without a Preforwarding
timer, the Transit node would remain in PREFORWARDING state with
its port in blocked state indefinitely, thereby causing a
disconnected network.
</t>
<t>
The value of the Preforwarding timer is derived from the
HEALTH-CHECK-PDU sent by the Master node. The Transit node looks up
the hello-interval field in the PDU, then multiplies this value by
3, and adds 3 to it.
</t>
</section>
</section>
<section title="Multiple EAPS Domains">
<t>
An EAPS-enabled switch can be part of more than one ring.
Hence, an EAPS-enabled switch can belong to more than one EAPS Domain
at the same time. Each EAPS Domain on a switch requires a separate
instance of the EAPS protocol on that same switch, one instance
per EAPS-protected ring.
</t>
<t>
One can also have more than one EAPS Domain running on
the same ring at the same time. Each EAPS Domain has its own
different Master node and each EAPS Domain has its own set of
protected VLANs. This facilitates spatial reuse of the ring's
bandwidth.
</t>
</section>
<section title="Inter-operation with EAPS SHARED-PORTS"
anchor="Sec-EAPS_SHARED-PORTS">
<t>
EAPS Shared-Ports is the technology used with EAPS to break a
loop when multiple EAPS Domains have a common-link between them.
</t>
<t>
Without EAPS Shared-Ports there would be a loop in the network
if the common-link between them went down, and there were VLANs
spanning two or more domains.
</t>
<t>
EAPS Shared-Ports is a proprietary protocol run in addition to
EAPS on those switches that have one end of the common-link between the
domains. One switch is configured to be the CONTROLLER, which does the
blocking when the common-link goes down. Its peer is running on the
other end of the common-link, and is configured to be the PARTNER.
Both switches work together to prevent a loop in the network when the
common-link between them goes down.
</t>
<t>
Describing the operation of EAPS Shared-Ports is beyond the scope
of this document. Here, we will describe the additional changes that
have to be made to an EAPS switch which is participating in such a
network, but not running the EAPS Shared-Ports protocol itself. In fact,
it does not even have to know that there is EAPS Shared-Ports configured
on other switches in its network.
</t>
<t>
<list style="numbers">
<t>
Processing and Forwarding of FLUSH-FDB-PDU: This PDU is sent by
a switch running EAPS Shared-Ports when a section of the network needs
to have its FDB flushed.
<vspace blankLines="1" />
It is sent with a special destination MAC address 00-E0-2B-00-00-07.
The EAPS PDU type is FLUSH-FDB-PDU whose value is 0x0D.
<vspace blankLines="1" />
When a Transit or Master node receives this PDU, it should flush
its own bridging table, and forward this PDU out the "other"
ring-port via slow-path.
</t>
<t>
A switch running EAPS Shared-Ports may send a QUERY-LINK-STATUS-PDU to
determine if there is a failure in a particular segment. These PDUs
would need to be forwarded out the "other" ring-port to ensure they
reach the EAPS Shared-Ports sender's peer switch. A Transit node
should always forward a QUERY-LINK-STATUS-PDU when it is in LINKS-UP
state. A Master node only forwards a QUERY-LINK-STATUS-PDU when
it is in FAILED state.
</t>
<t>
A switch that receives a LINK-DOWN-PDU needs to forward this PDU out
the "other" ring-port so that it reaches the EAPS Shared-Ports switch
at the end of this segment. A Transit node should always forward
a LINK-DOWN-PDU when possible (when in LINKS-UP state), while a
Master node should forward a LINK-DOWN-PDU only while in FAILED state.
</t>
</list>
</t>
</section>
<?rfc needLines="35" ?> <!-- Pagebreak -->
<section title="EAPS Frame Format" anchor="Sec-EAPS_Frame_Format">
<figure align="left" title="EAPS Frame Format" anchor="EAPS_Frame_Format">
<artwork align="left"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source MAC address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EtherType (2 bytes) | Pri | VLAN Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame length [0x005C] | DSAP [0xAA] | SSAP [0xAA] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control [0x03]| OUI [0x00] | OUI [0xE0] | OUI [0x2B] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type [0x00BB] |EEP Ver [0x01] |EEP Resv[0x00] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EEP Len [0x0054] | EEP Checksum (2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EEP Sequence Num (2 bytes) | Device Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (8 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Marker [0x99]| EEP Type[0x0B] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAPS length [0x0040] |EAPS Ver [0x01]| EAPS PDU Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|EAPS Control VLAN Id (2 bytes) | EAPS Reserved [0x0000] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [0x0000] | System MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAPS Hello Timer (2 bytes) | EAPS Fail Timer (2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|EAPS State | [0x00] | EAPS Sequence Num (2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAPS Reserved (38 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Marker [0x99] | EEP Type[0x00]|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EEP NULL TLV Len [0x04] | Ethernet Frame... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Checksum (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<figure align="left">
<artwork align="left"><![CDATA[
Where:
Dest MAC (6 bytes) = 0x00 E0 2B 00 00 04
Source MAC (6 bytes) = 0x00 E0 2B 00 00 01
EtherType (2 bytes) = 0x81 00 (for IEEE 802.1Q tagged packets)
Pri (4 bits) = 3 bits Priority + 1 bit reserved
VLAN Id (12 bits) = VLAN Id for Control VLAN in use
Frame Len (2 bytes) = 0x005C (Ethernet frame data length)
DSAP (1 byte) = 0xAA
SSAP (1 byte) = 0xAA
Control (1 byte) = 0x03
OUI (3 bytes) = 0x00 E0 2B (Extreme Networks OUI)
Type (2 bytes) = 0x00 BB
EEP Ver (1 byte) = 0x01 (Extreme's Encapsulation Protocol
version)
EEP Resv (1 byte) = 0x00
EEP Len (2 bytes) = 0x0054 (Length of EEP data + EEP header)
EEP Checksum (2 bytes) = Calculated checksum. (Described below)
EEP Seq Num (2 bytes) = The first EEP packet has a value of 1.
This value is incremented by 1 for each
subsequent EEP packet sent out. (This
field is only used for debugging
purposes.)
Device Id (8 bytes) = System MAC. The 2 MSBs of Device Id set
to 0.
Marker (1 byte) = 0x99 (EEP's Start of a new TLV marker.
This is the beginning of the EAPS
TLV)
EEP Type (1 byte) = 0x0B (EAPS PDU TLV)
EAPS Length (2 bytes) = 0x0040 (Length of EAPS TLV including
header)
EAPS Ver (1 byte) = 0x01 (EAPS Ver 1)
EAPS PDU Type (1 byte) = Identifies the type of EAPS PDU
(Values given below)
EAPS VLAN Id (2 bytes) = VLAN Id for Control VLAN being used to
send and receive EAPS PDUs
EAPS Reserved (4 bytes) = 0x00 00 00 00
System MAC (6 bytes) = System MAC of node issuing the EAPS
packet
EAPS Hello (2 bytes) = 0x04. Even though this is meant to
convey the EAPS Hello Interval, it is
hard-coded to 4. This is so that the
Transits can derive their preforwarding
interval to be 15 seconds.
EAPS Fail (2 bytes) = EAPS Fail Timer interval set by Master
EAPS State (1 byte) = EAPS node's state (Values given below)
EAPS Reserved (1 byte) = 0x00
EAPS Seq Num (2 bytes) = For debug, sequence number of
Health-PDUs in ascending order
EAPS Reserved (38 bytes) = All bytes are 0 for now
Marker (1 byte) = 0x99 (EEP's Start of a new TLV marker.
This is the beginning of the NULL
TLV)
EEP Type (1 byte) = 0x00 (EEP NULL TLV)
NULL TLV Len (2 bytes) = 0x04 (including header)
Checksum (4 bytes) = Ethernet Frame's checksum
]]></artwork>
</figure>
<figure>
<artwork align="left"><![CDATA[
EAPS PDU Type values:
HEALTH-CHECK-PDU = 0x05
RING-UP-FLUSH-FDB-PDU = 0x06
RING-DOWN-FLUSH-FDB-PDU = 0x07
LINK-DOWN-PDU = 0x08
FLUSH-FDB-PDU = 0x0D
QUERY-LINK-STATUS-PDU = 0x0F
LINK-UP-PDU = 0x10
All other values are reserved
]]></artwork>
</figure>
<figure>
<artwork align="left"><![CDATA[
EAPS State values:
IDLE = 0x00 (EAPS Domain (Master/Transit) still not
running)
COMPLETE = 0x01 (Master in Complete State)
FAILED = 0x02 (Master in Failed State)
LINKS-UP = 0x03 (Transit in Links-Up State. Both ring-ports
are up)
LINK-DOWN = 0x04 (Transit in Link-Down State. One or both
ring-ports are down)
PREFORWARDING = 0x05 (Transit in Preforwarding State)
INIT = 0x06 (Master in Init State)
All other values are reserved
]]></artwork>
</figure>
<figure>
<artwork align="left"><![CDATA[
EEP Checksum:
This is 16 bits wide and is calculated as follows:
o First set "EEP Checksum" field to 0.
o Calculate the checksum using the algorithm below starting from
"EEP Ver" field through "EEP NULL TLV Len" field.
o This size is the same value that is set in "EEP Len" field.
// Algorithm for EEP checksum calculation
int checksum (uint16_t *addr, int len)
{
int sum = 0;
o Using a 32 bit accumulator 'sum'
o In a while-loop, go on adding sequential 16 bit words
from 'addr' to accumulator 'sum'
o If there is an odd byte left at the end, add it to
accumulator 'sum'
o Add high 16 bits of 'sum' to low 16 bits of 'sum'
o If there is a carry bit, add it back to 'sum'
o Truncate to 16 bits, and return this as a 16 bit word.
}
]]></artwork>
</figure>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This memo includes no request to IANA.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
Anyone with physical access to the physical layer connections
could forge any sort of Ethernet frame they wished, including but not
limited to Bridge frames or EAPS frames. Such forgeries could be used
to disrupt an Ethernet network in various ways, including methods that
are specific to EAPS or other unrelated methods such as forged
Ethernet bridge frames.
</t>
<t>
As such, it is recommended that users not deploy Ethernet
without some form of encryption in environments where such active
attacks are considered a significant operational risk. IEEE standards
already exist for
<xref target="IEEE802.1AE-2006">link-layer encryption</xref>.
Those IEEE standards could be used to protect an Ethernet's links.
Alternately, upper-layer security mechanisms could be used if more
appropriate to the local threat model.
</t>
</section>
<section anchor="IPR" title="Intellectual Property">
<t>
The IETF has been notified of intellectual property rights
claimed in regard to some or all of the specification
contained in this document. For more information, consult
the online list of claimed rights.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
<xref target="RFC3619"></xref> was edited and put into RFC
format by R.J. Atkinson from internal documents created by the authors
of that document. This version of the EAPS specification is derived
from <xref target="RFC3619"></xref>. Arnel Lim and Steven Blake edited
this document based on a draft prepared by Sunil Shah.
</t>
<t>
This document was produced using the xml2rfc tool
<xref target="RFC2629" />.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation
libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629;
here (as shown)
2. simply use a PI "less than character"?rfc
include="reference.RFC.2119.xml"?> here (for I-Ds:
include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find
included files in the same directory as the including file. You can
also define the XML_LIBRARY environment variable with a value
containing a set of directories to search. These can be either in
the local filing system or remote ones accessed by
http (http://domain/dir/... ). -->
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<reference anchor="IEEE802.1D-1998">
<front>
<title>IEEE 802.1D Standard for Local and Metropolitan Area Networks:
Media Access Control (MAC) Bridges</title>
<author>
<organization>IEEE LAN/MAN Standards Committee</organization>
</author>
<date year="1998" />
</front>
</reference>
<reference anchor="IEEE802.1D-2004">
<front>
<title>IEEE 802.1D Standard for Local and Metropolitan Area Networks:
Media Access Control (MAC) Bridges</title>
<author>
<organization>IEEE LAN/MAN Standards Committee</organization>
</author>
<date year="2004" />
</front>
</reference>
&RFC3619;
<reference anchor="IEEE802.1AE-2006">
<front>
<title>IEEE 802.1AE Standard for Local and Metropolitan Area Networks:
Media Access Control (MAC) Security</title>
<author>
<organization>IEEE LAN/MAN Standards Committee</organization>
</author>
<date year="2006" />
</front>
</reference>
&RFC2629;
</references>
</back>
</rfc>
<!-- Change Log
00 2008-10-02 Converted to xml2rfc format.
03 2008-10-08 (Hopefully) final edits for -00.
04 2011-05-31 Submitted -01
-->
| PAFTECH AB 2003-2026 | 2026-04-19 18:54:40 |