idnits 2.17.1 draft-shah-extreme-eaps-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 17 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 April 2003) is 7644 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Shah & M. Yip 3 Internet Draft Extreme Networks 4 draft-shah-extreme-eaps-03.txt 24 April 2003 6 Extreme Networks' 7 Ethernet Automatic Protection Switching (EAPS), 8 Version 1 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions of 13 Section 10 of RFC2026 except that the right to produce derivative 14 works is not granted. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at: 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at: 29 http://www.ietf.org/shadow.html 31 This document provides information for members of the networking 32 community. Distribution of this memo is unlimited. 34 ABSTRACT 36 This document describes the Ethernet Automatic Protection 37 Switching (EAPS) (TM) technology invented by Extreme Networks to 38 increase the availability and robustness of Ethernet rings. An 39 Ethernet ring built using EAPS can have resilience comparable to 40 that provided by SONET rings, at lower cost and without some of 41 the constraints (e.g. ring size) of SONET. 43 1. INTRODUCTION 45 Many Metropolitan Area Networks (MANs) and some Local Area 46 Networks (LANs) have a ring topology, as the fibre runs. The Ethernet 47 Automatic Protection Switching technology described here works well in 48 ring topologies for MANs or LANs. 50 Also, most MAN operators want to minimise the recovery time in 51 the event a fibre cut occurs. The Spanning Tree Protocol can take as 52 long as 40 seconds to converge in the event of a topology change. The 53 newer Rapid Spanning Tree Protocol is considerably faster. However, its 54 convergence time is still dependent upon the number of nodes in the ring. 55 Both STP and RSTP limit the number of nodes in the ring. The Ethernet 56 Automatic Protection Switching (EAPS) technology described here 57 converges in less than one second, often in less than 100 milliseconds. 58 EAPS technology does not limit the number of nodes in the ring, and the 59 convergence time is independent of the number of nodes. 61 2. CONCEPT OF OPERATION 63 An EAPS Domain exists on a single Ethernet ring. Any Ethernet 64 Virtual Local Area Network (VLAN) that is to be protected is 65 configured on all ports in the ring for the given EAPS Domain. Each 66 EAPS Domain has a single designated "master node". Each other node on 67 that ring is referred to as a "transit node". 69 Of course, each node on the ring will have 2 ports connected to 70 the ring. One port of the master node is designated to be the 71 "primary port" to the ring for the master node. The other port 72 is designated as the "secondary port". 74 In normal operation, the master node blocks the secondary port 75 for all non-control Ethernet frames belonging to the given EAPS 76 Domain, thereby avoiding a loop in the ring. Existing Ethernet 77 switching and learning mechanisms operate per existing standards on 78 this ring. This is possible because the master node makes the ring 79 appear not to have a loop, from the perspective of the Ethernet 80 standard algorithms used for switching and learning. If the master 81 node detects a ring fault, it unblocks its secondary port and allows 82 Ethernet data frames to pass through that port. There is a special 83 "Control VLAN" that can always pass through all ports in the EAPS 84 Domain, including the secondary port of the master node. 86 EAPS uses both a polling mechanism, described in detail below, 87 and an alert mechanism, also described below, to verify the 88 connectivity of the ring and to quickly detect any faults. 90 2.1 LINK DOWN ALERT 92 When any transit node detects a link-down on any of 93 its ports in the EAPS Domain, that transit node immediately 94 sends a "link down" control frame on the Control VLAN 95 to the master node. 97 When the master node receives this "link down" control 98 frame, the master node moves from the "normal" state to the ring-fault 99 state and unblocks its secondary port. The master node also flushes 100 its bridging table. The master node also sends a control frame to 101 all other ring nodes instructing them to flush their bridging tables. 102 Immediately after flushing its bridging table, each node starts 103 learning the new topology. 105 2.2 RING POLLING 107 The master node sends a health-check frame on the 108 Control VLAN at a user-configurable interval. If the ring is 109 complete, this will be received on its secondary port. Upon 110 receipt of the health-check frame, the master node resets its 111 fail-period timer and continues normal operation. 113 If the master node does not receive the health-check frame 114 before the fail-period timer expires, the master node moves from the 115 normal state to the "ring-fault" state and unblocks its secondary 116 port. The master node also flushes its bridging table. The master 117 node also sends a control frame to all other nodes instructing them to 118 also flush their bridging tables. Immediately after flushing its 119 bridge table, each node starts learning the new topology. This ring 120 polling mechanism provides a backup in the event the Link Down Alert 121 frame should get lost for some unforeseen reason. 123 2.3 RING RESTORATION 125 The master node continues sending periodic health-check 126 frames out its primary port even when operating in the 127 ring-fault state. Once the ring is restored, the very next 128 health-check frame will be received on the master node's 129 secondary port. This will cause the master node to transition 130 back to the normal state, logically block non-control frames 131 on the secondary port, flush its own bridge table, and send 132 a control frame to the transit nodes instructing them to flush 133 their bridging tables and re-learn the topology. 135 During the time between the transit node detecting that its 136 link is restored and the master node detecting that the ring is 137 restored, the secondary port of the master node is still open -- 138 creating the possibility of a temporary loop in the topology. To 139 prevent any temporary loop, the transit node will put all the 140 protected VLANs transiting the newly restored port into a temporary 141 blocked state, remember which port has been temporarily blocked, and 142 transition into the "pre-forwarding" state. When the transit node in 143 the "pre-forwarding" state receives a control frame instructing it to 144 flush its bridging table, it will flush the bridging table, unblock 145 the previously blocked protected VLANs on the newly restored port, and 146 transition to the "normal" state. 148 3. MULTIPLE EAPS DOMAINS 150 An EAPS-enabled switch can be part of more than one ring. 151 Hence, an EAPS-enabled switch can belong to more than one EAPS Domain 152 at the same time. Each EAPS Domain on a switch requires a separate 153 instance of the EAPS protocol on that same switch, one instance 154 per EAPS-protected ring. 156 One can also have more than one EAPS domain running on 157 the same ring at the same time. Each EAPS Domain has its own 158 different master node and each EAPS Domain has its own set of 159 protected VLANs. This facilitates spatial reuse of the ring's 160 bandwidth. 162 EAPS FRAME FORMAT 164 0 1 2 3 4 4 165 12345678 90123456 78901234 56789012 34567890 12345678 166 +--------+--------+--------+--------+--------+--------+ 167 | Destination MAC Address (6 bytes) | 168 +--------+--------+--------+--------+--------+--------+ 169 | Source MAC Address (6 bytes) | 170 +--------+--------+--------+--------+--------+--------+ 171 | EtherType |PRI | VLAN ID | Frame Length | 172 +--------+--------+--------+--------+--------+--------+ 173 | DSAP/SSAP | CONTROL| OUI = 0x00E02B | 174 +--------+--------+--------+--------+--------+--------+ 175 | 0x00bb | 0x99 | 0x0b | EAPS_LENGTH | 176 +--------+--------+--------+--------+--------+--------+ 177 |EAPS_VER|EAPSTYPE| CTRL_VLAN_ID | 0x0000 | 178 +--------+--------+--------+--------+--------+--------+ 179 | 0x0000 | SYSTEM_MAC_ADDR (6 bytes) | 180 +--------+--------+--------+--------+--------+--------+ 181 | | HELLO_TIMER | FAIL_TIMER | 182 +--------+--------+--------+--------+--------+--------+ 183 | STATE | 0x00 | HELLO_SEQ | 0x0000 | 184 +--------+--------+--------+--------+--------+--------+ 185 | RESERVED (0x000000000000) | 186 +--------+--------+--------+--------+--------+--------+ 187 | RESERVED (0x000000000000) | 188 +--------+--------+--------+--------+--------+--------+ 189 | RESERVED (0x000000000000) | 190 +--------+--------+--------+--------+--------+--------+ 191 | RESERVED (0x000000000000) | 192 +--------+--------+--------+--------+--------+--------+ 193 | RESERVED (0x000000000000) | 194 +--------+--------+--------+--------+--------+--------+ 195 | RESERVED (0x000000000000) | 196 +--------+--------+--------+--------+--------+--------+ 198 Where: 200 Destination MAC Address is always 0x00e02b000004. 201 PRI contains 3 bits of priority, with 1 other bit reserved. 202 EtherType is always 0x8100. 203 DSAP/SSAP is always 0xAAAA. 204 CONTROL is always 0x03. 205 EAPS_LENGTH is 0x40. 206 EAPS_VERS is 0x0001. 207 CTRL_VLAN_ID is the VLAN ID for the Control VLAN in use. 208 SYSTEM_MAC_ADDR is the System MAC Address of the sending node. 209 HELLO_TIMER is the value set by the Master Node. 210 FAIL_TIMER is the value set by the Master Node. 211 HELLO_SEQ is the sequence number of the Hello Frame. 213 EAPS Type (EAPSTYPE) values: 214 HEALTH = 5 215 RING-UP-FLUSH-FDB = 6 216 RING-DOWN-FLUSH-FDB = 7 217 LINK-DOWN = 8 218 All other values are reserved. 220 STATE values: 222 IDLE = 0 223 COMPLETE = 1 224 FAILED = 2 225 LINKS-UP = 3 226 LINK-DOWN = 4 227 PRE-FORWARDING = 5 228 All other values are reserved. 230 SECURITY CONSIDERATIONS 232 Anyone with physical access to the physical layer connections 233 could forge any sort of Ethernet frame they wished, including but not 234 limited to Bridge frames or EAPS frames. Such forgeries could be used 235 to disrupt an Ethernet network in various ways, including methods that 236 are specific to EAPS or other unrelated methods such as forged 237 Ethernet bridge frames. 239 As such, it is recommended that users not deploy Ethernet 240 without some form of encryption in environments where such active 241 attacks are considered a significant operational risk. IEEE standards 242 already exist for link-layer encryption. Those IEEE standards could 243 be used to protect an Ethernet's links. Alternately, upper-layer 244 security mechanisms could be used if more appropriate to the local 245 threat model. 247 INTELLECTUAL PROPERTY 249 The IETF has been notified of intellectual property rights 250 claimed in regard to some or all of the specification 251 contained in this document. For more information, consult 252 the online list of claimed rights. 254 ACKNOWLEDGEMENT 256 This document was edited together and put into RFC format by R.J. Atkinson 257 from internal documents created by the authors below. The Editor is 258 solely responsible for any errors made during redaction. 260 EDITOR'S ADDRESS: 262 R. Atkinson 263 Extreme Networks 264 3585 Monroe Street 265 Santa Clara, CA, 95051 USA 267 Telephone: +1 (408)579-2800 268 Email: rja@extremenetworks.com 270 AUTHOR'S ADDRESS: 271 S. Shah 272 Extreme Networks 273 3585 Monroe Street 274 Santa Clara, CA, 95051 275 Email: sshah@extremenetworks.com 276 Phone: +1 (408)579-2800 278 M. Yip 279 Extreme Networks 280 3585 Monroe Street 281 Santa Clara, CA, 95051 283 Email: my@extremenetworks.com 284 Phone: +1 (408)579-2800