Skip to main content

Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1
draft-shah-extreme-eaps-03

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 3619.
Authors M Yip , S Shah
Last updated 2015-10-14 (Latest revision 2003-05-16)
RFC stream Independent Submission
Intended RFC status Informational
Formats
Stream ISE state (None)
Consensus boilerplate Unknown
Document shepherd (None)
IESG IESG state Became RFC 3619 (Informational)
Action Holders
(None)
Telechat date (None)
Responsible AD Dr. Thomas Narten
Send notices to <my@extremenetworks.com>
draft-shah-extreme-eaps-03
Network Working Group                                   S. Shah & M. Yip
Internet Draft                                          Extreme Networks
draft-shah-extreme-eaps-03.txt                             24 April 2003

                           Extreme Networks'
            Ethernet Automatic Protection Switching (EAPS),
                               Version 1

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions of
   Section 10 of RFC2026 except that the right to produce derivative
   works is not granted.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that other
   groups may also distribute working documents as Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at:
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at:
   http://www.ietf.org/shadow.html

   This document provides information for members of the networking
   community.  Distribution of this memo is unlimited.

ABSTRACT

        This document describes 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.

Shah & Yip                                                      [Page 1]
Internet-Draft                                             24 April 2003

1. INTRODUCTION

        Many Metropolitan Area Networks (MANs) and some Local Area
   Networks (LANs) have a ring topology, as the fibre runs.  The Ethernet
   Automatic Protection Switching technology described here works well in
   ring topologies for MANs or LANs.

        Also, most MAN operators want to minimise the recovery time in
   the event a fibre cut occurs.  The Spanning Tree Protocol can take as
   long as 40 seconds to converge in the event of a topology change.  The
   newer Rapid Spanning Tree Protocol is considerably faster. However, its
   convergence time is still dependent upon the number of nodes in the ring.
   Both STP and RSTP limit the number of nodes 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 nodes in the ring, and the
   convergence time is independent of the number of nodes.

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 node on
   that ring is referred to as a "transit node".

        Of course, each node 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.

        EAPS uses both a polling mechanism, described in detail below,
   and an alert mechanism, also described below, to verify the

Shah & Yip                                                      [Page 2]
Internet-Draft                                             24 April 2003

   connectivity of the ring and to quickly detect any faults.

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 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 to the ring-fault
   state and unblocks its secondary port.  The master node also flushes
   its bridging table.  The master node also sends a control frame to
   all other ring nodes instructing them to flush their bridging tables.
   Immediately after flushing its bridging table, each node starts
   learning the new topology.

2.2 RING POLLING

        The master node sends a health-check frame 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 frame, the master node resets its
   fail-period timer and continues normal operation.

        If the master node does not receive the health-check frame
   before the fail-period timer expires, the master node moves from the
   normal state to the "ring-fault" state and unblocks its secondary
   port.  The master node also flushes its bridging table.  The master
   node also sends a control frame to all other nodes instructing them to
   also flush their bridging tables.  Immediately after flushing its
   bridge table, each node starts learning the new topology.  This ring
   polling mechanism provides a backup in the event the Link Down Alert
   frame should get lost for some unforeseen reason.

2.3 RING RESTORATION

        The master node continues sending periodic health-check
   frames out its primary port even when operating in the
   ring-fault state.  Once the ring is restored, the very next
   health-check frame will be received on the master node's
   secondary port.  This will cause the master node to transition

Shah & Yip                                                      [Page 3]
Internet-Draft                                             24 April 2003

   back to the normal state, logically block non-control frames
   on the secondary port, flush its own bridge table, and send
   a control frame 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 "pre-forwarding" state.  When the transit node in
   the "pre-forwarding" state receives a control frame 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" state.

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.

EAPS FRAME FORMAT

        0         1          2          3          4        4
        12345678 90123456 78901234 56789012 34567890 12345678
       +--------+--------+--------+--------+--------+--------+
       |         Destination MAC Address (6 bytes)           |
       +--------+--------+--------+--------+--------+--------+
       |         Source MAC Address (6 bytes)                |
       +--------+--------+--------+--------+--------+--------+
       |    EtherType    |PRI | VLAN ID    |  Frame Length   |
       +--------+--------+--------+--------+--------+--------+
       |    DSAP/SSAP    | CONTROL|     OUI = 0x00E02B       |

Shah & Yip                                                      [Page 4]
Internet-Draft                                             24 April 2003

       +--------+--------+--------+--------+--------+--------+
       |     0x00bb      |  0x99  |  0x0b  |  EAPS_LENGTH    |
       +--------+--------+--------+--------+--------+--------+
       |EAPS_VER|EAPSTYPE|  CTRL_VLAN_ID   |    0x0000       |
       +--------+--------+--------+--------+--------+--------+
       |  0x0000         |    SYSTEM_MAC_ADDR (6 bytes)      |
       +--------+--------+--------+--------+--------+--------+
       |                 |   HELLO_TIMER   |    FAIL_TIMER   |
       +--------+--------+--------+--------+--------+--------+
       | STATE  | 0x00   |   HELLO_SEQ     |     0x0000      |
       +--------+--------+--------+--------+--------+--------+
       |                 RESERVED (0x000000000000)           |
       +--------+--------+--------+--------+--------+--------+
       |                 RESERVED (0x000000000000)           |
       +--------+--------+--------+--------+--------+--------+
       |                 RESERVED (0x000000000000)           |
       +--------+--------+--------+--------+--------+--------+
       |                 RESERVED (0x000000000000)           |
       +--------+--------+--------+--------+--------+--------+
       |                 RESERVED (0x000000000000)           |
       +--------+--------+--------+--------+--------+--------+
       |                 RESERVED (0x000000000000)           |
       +--------+--------+--------+--------+--------+--------+

      Where:

          Destination MAC Address is always 0x00e02b000004.
          PRI contains 3 bits of priority, with 1 other bit reserved.
          EtherType is always 0x8100.
          DSAP/SSAP is always 0xAAAA.
          CONTROL is always 0x03.
          EAPS_LENGTH is 0x40.
          EAPS_VERS is 0x0001.
          CTRL_VLAN_ID is the VLAN ID for the Control VLAN in use.
          SYSTEM_MAC_ADDR is the System MAC Address of the sending node.
          HELLO_TIMER is the value set by the Master Node.
          FAIL_TIMER is the value set by the Master Node.
          HELLO_SEQ is the sequence number of the Hello Frame.

      EAPS Type (EAPSTYPE) values:
          HEALTH              = 5
          RING-UP-FLUSH-FDB   = 6
          RING-DOWN-FLUSH-FDB = 7
          LINK-DOWN           = 8
          All other values are reserved.

      STATE values:

Shah & Yip                                                      [Page 5]
Internet-Draft                                             24 April 2003

          IDLE           = 0
          COMPLETE       = 1
          FAILED         = 2
          LINKS-UP       = 3
          LINK-DOWN      = 4
          PRE-FORWARDING = 5
          All other values are reserved.

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.  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.

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.

ACKNOWLEDGEMENT

   This document was edited together and put into RFC format by R.J. Atkinson
   from internal documents created by the authors below.  The Editor is
   solely responsible for any errors made during redaction.

Shah & Yip                                                      [Page 6]
Internet-Draft                                             24 April 2003

EDITOR'S ADDRESS:

   R. Atkinson
   Extreme Networks
   3585 Monroe Street
   Santa Clara, CA, 95051 USA

   Telephone: +1 (408)579-2800
   Email: rja@extremenetworks.com

AUTHOR'S ADDRESS:
   S. Shah
   Extreme Networks
   3585 Monroe Street
   Santa Clara, CA, 95051
   Email: sshah@extremenetworks.com
   Phone: +1 (408)579-2800

   M. Yip
   Extreme Networks
   3585 Monroe Street
   Santa Clara, CA, 95051

   Email: my@extremenetworks.com
   Phone: +1 (408)579-2800

Shah & Yip                                                      [Page 7]