


Individual Submission                                        A. Lim, Ed.
Internet-Draft                                             S. Blake, Ed.
Intended status: Informational                          Extreme Networks
Expires: January 7, 2012                                         S. Shah
                                                                Ericsson
                                                            July 6, 2011


                           Extreme Networks'
            Ethernet Automatic Protection Switching (EAPS),
                              Version 1.3
                    draft-shah-extreme-rfc3619bis-02

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 January 7, 2012.

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 January 7, 2012                [Page 1]

Internet-Draft     Extreme Networks' EAPS Version 1.3          July 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 When Using the Ring-Polling
           Method . . . . . . . . . . . . . . . . . . . . . . . . . .  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 January 7, 2012                [Page 2]

Internet-Draft     Extreme Networks' EAPS Version 1.3          July 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.  Each EAPS Domain uses a special Control
   VLAN which only carries EAPS control PDUs.  This Control VLAN must
   not be blocked, so EAPS control PDUs must be consumed by the Master
   node and NOT forwarded.



Lim, et al.              Expires January 7, 2012                [Page 3]

Internet-Draft     Extreme Networks' EAPS Version 1.3          July 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) out of
   its primary port 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 will perform one of two
   operations based on the Fail-timer-expiry action configured.  If the
   Fail-timer-expiry action is set to "Send-Alert", the Master node will
   send a QUERY-LINK-STATUS-PDU out of both ring ports to determine
   whether any Transit nodes have link failures.  Transit nodes with a
   link failure will reply back to the Master node with a LINK-DOWN-PDU,
   which will cause the Master node to move from normal state to the
   "ring-fault" state (FAILED) and unblock its secondary port.  If the
   Fail-timer-expiry action is set to "Open Secondary Port" the Master
   will NOT send a QUERY-LINK-STATUS-PDU, but will move directly from
   normal state to the "ring-fault" state (FAILED) and unblock its
   secondary port.  When entering FAILED state, the Master node will
   flush its bridging table.  The Master node will also send a control



Lim, et al.              Expires January 7, 2012                [Page 4]

Internet-Draft     Extreme Networks' EAPS Version 1.3          July 2011


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

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 When Using the Ring-Polling Method

   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.



Lim, et al.              Expires January 7, 2012                [Page 5]

Internet-Draft     Extreme Networks' EAPS Version 1.3          July 2011


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



Lim, et al.              Expires January 7, 2012                [Page 6]

Internet-Draft     Extreme Networks' EAPS Version 1.3          July 2011


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



Lim, et al.              Expires January 7, 2012                [Page 7]

Internet-Draft     Extreme Networks' EAPS Version 1.3          July 2011


   hello-interval field in the PDU, then multiplies this value by 3, and
   adds 3 to it.


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



Lim, et al.              Expires January 7, 2012                [Page 8]

Internet-Draft     Extreme Networks' EAPS Version 1.3          July 2011


       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"
       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 January 7, 2012                [Page 9]

Internet-Draft     Extreme Networks' EAPS Version 1.3          July 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 January 7, 2012               [Page 10]

Internet-Draft     Extreme Networks' EAPS Version 1.3          July 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 January 7, 2012               [Page 11]

Internet-Draft     Extreme Networks' EAPS Version 1.3          July 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 January 7, 2012               [Page 12]

Internet-Draft     Extreme Networks' EAPS Version 1.3          July 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 January 7, 2012               [Page 13]

Internet-Draft     Extreme Networks' EAPS Version 1.3          July 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 January 7, 2012               [Page 14]

Internet-Draft     Extreme Networks' EAPS Version 1.3          July 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 January 7, 2012               [Page 15]

