One document matched: draft-shah-extreme-rfc3619bis-01.txt
Differences from draft-shah-extreme-rfc3619bis-00.txt
Individual Submission A. Lim, Ed.
Internet-Draft S. Blake, Ed.
Intended status: Informational Extreme Networks
Expires: December 4, 2011 S. Shah
Ericsson
June 2, 2011
Extreme Networks'
Ethernet Automatic Protection Switching (EAPS),
Version 1.3
draft-shah-extreme-rfc3619bis-01
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to format it
for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 4, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Lim, et al. Expires December 4, 2011 [Page 1]
Internet-Draft Extreme Networks' EAPS Version 1.3 June 2011
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Concept of Operation . . . . . . . . . . . . . . . . . . . . . 3
2.1. Link Down Alert . . . . . . . . . . . . . . . . . . . . . 4
2.2. Ring Polling . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Ring Restoration . . . . . . . . . . . . . . . . . . . . . 5
2.4. Preventing False Failures . . . . . . . . . . . . . . . . 5
2.5. Enhancements to Aid in Trouble-Shooting . . . . . . . . . 6
2.6. PREFORWARDING State on Transit . . . . . . . . . . . . . . 7
3. Multiple EAPS Domains . . . . . . . . . . . . . . . . . . . . 8
4. Inter-operation with EAPS SHARED-PORTS . . . . . . . . . . . . 8
5. EAPS Frame Format . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Intellectual Property . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Lim, et al. Expires December 4, 2011 [Page 2]
Internet-Draft Extreme Networks' EAPS Version 1.3 June 2011
1. Introduction
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.
Also, most MAN operators want to minimize the recovery time in the
event a fiber cut occurs. The Spanning Tree Protocol STP
[IEEE802.1D-1998] can take as long as 40 seconds to converge in the
event of a topology change. The newer Rapid Spanning Tree Protocol
RSTP [IEEE802.1D-2004] 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.
EAPS version 1 is specified in [RFC3619].
2. Concept of Operation
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".
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".
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.
Lim, et al. Expires December 4, 2011 [Page 3]
Internet-Draft Extreme Networks' EAPS Version 1.3 June 2011
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.
EAPS frames are encoded using the Extreme Networks' Encapsulation
Protocol. The EAPS frame format is defined in Section 5. 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 Section 4).
2.1. Link Down Alert
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.
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.
2.2. Ring Polling
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.
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.
Lim, et al. Expires December 4, 2011 [Page 4]
Internet-Draft Extreme Networks' EAPS Version 1.3 June 2011
2.3. Ring Restoration
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.
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.
2.4. Preventing False Failures
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.
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.
The EAPS Master node can be configured to take one of two actions
when its Fail-period timer expires:
a. 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
Lim, et al. Expires December 4, 2011 [Page 5]
Internet-Draft Extreme Networks' EAPS Version 1.3 June 2011
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.
b. 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.
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.
2.5. Enhancements to Aid in Trouble-Shooting
A couple of enhancements have been added to the EAPS protocol since
[RFC3619] to help in trouble-shooting an EAPS network.
a. 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.
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.
b. 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
Lim, et al. Expires December 4, 2011 [Page 6]
Internet-Draft Extreme Networks' EAPS Version 1.3 June 2011
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.
2.6. PREFORWARDING State on Transit
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.
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.
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.
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.
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.
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.
Lim, et al. Expires December 4, 2011 [Page 7]
Internet-Draft Extreme Networks' EAPS Version 1.3 June 2011
3. Multiple EAPS Domains
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.
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.
4. Inter-operation with EAPS SHARED-PORTS
EAPS Shared-Ports is the technology used with EAPS to break a loop
when multiple EAPS Domains have a common-link between them.
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.
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.
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.
1. 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.
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.
When a Transit or Master node receives this PDU, it should flush
its own bridging table, and forward this PDU out the "other"
Lim, et al. Expires December 4, 2011 [Page 8]
Internet-Draft Extreme Networks' EAPS Version 1.3 June 2011
ring-port via slow-path.
2. 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.
3. 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.
Lim, et al. Expires December 4, 2011 [Page 9]
Internet-Draft Extreme Networks' EAPS Version 1.3 June 2011
5. EAPS Frame Format
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lim, et al. Expires December 4, 2011 [Page 10]
Internet-Draft Extreme Networks' EAPS Version 1.3 June 2011
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Marker [0x99] | EEP Type[0x00]|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EEP NULL TLV Len [0x04] | Ethernet Frame... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Checksum (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: EAPS Frame Format
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
Lim, et al. Expires December 4, 2011 [Page 11]
Internet-Draft Extreme Networks' EAPS Version 1.3 June 2011
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
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
Lim, et al. Expires December 4, 2011 [Page 12]
Internet-Draft Extreme Networks' EAPS Version 1.3 June 2011
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
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.
}
6. IANA Considerations
This memo includes no request to IANA.
Lim, et al. Expires December 4, 2011 [Page 13]
Internet-Draft Extreme Networks' EAPS Version 1.3 June 2011
7. Security Considerations
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.
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 link-layer encryption [IEEE802.1AE-2006]. 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.
8. Intellectual Property
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.
9. Acknowledgements
[RFC3619] 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 [RFC3619]. Arnel
Lim and Steven Blake edited this document based on a draft prepared
by Sunil Shah.
This document was produced using the xml2rfc tool [RFC2629].
10. Informative References
[IEEE802.1D-1998]
IEEE LAN/MAN Standards Committee, "IEEE 802.1D Standard
for Local and Metropolitan Area Networks: Media Access
Control (MAC) Bridges", 1998.
[IEEE802.1D-2004]
IEEE LAN/MAN Standards Committee, "IEEE 802.1D Standard
for Local and Metropolitan Area Networks: Media Access
Control (MAC) Bridges", 2004.
Lim, et al. Expires December 4, 2011 [Page 14]
Internet-Draft Extreme Networks' EAPS Version 1.3 June 2011
[RFC3619] Shah, S. and M. Yip, "Extreme Networks' Ethernet Automatic
Protection Switching (EAPS) Version 1", RFC 3619,
October 2003.
[IEEE802.1AE-2006]
IEEE LAN/MAN Standards Committee, "IEEE 802.1AE Standard
for Local and Metropolitan Area Networks: Media Access
Control (MAC) Security", 2006.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
Authors' Addresses
Arnel Lim (editor)
Extreme Networks
3585 Monroe Street
Santa Clara, CA 95051
USA
Phone: +1 408-579-2688
Email: alim@extremenetworks.com
Steven Blake (editor)
Extreme Networks
Pamlico Building One, Suite 100
3306/08 E. NC Hwy 54
RTP, NC 27709
USA
Phone: +1 919-884-3211
Email: sblake@extremenetworks.com
Sunil Shah
Ericsson
300 Holger Way
San Jose, CA 95134
USA
Phone: +1 408-750-8523
Email: sunil.shah@ericsson.com
Lim, et al. Expires December 4, 2011 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-19 09:30:56 |