idnits 2.17.1 draft-mme-trill-fcoe-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 7, 2012) is 4187 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group David Melman 2 Internet Draft Tal Mizrahi 3 Intended status: Informational Marvell 4 Expires: May 2013 Donald Eastlake 5 Huawei 6 November 7, 2012 8 FCoE over TRILL 9 draft-mme-trill-fcoe-05.txt 11 Abstract 13 Fibre Channel over Ethernet (FCoE) and TRILL are two emerging 14 standards in the data center environment. While these two protocols 15 are seemingly unrelated, they have a very similar behavior in the 16 forwarding plane, as both perform hop-by-hop forwarding over 17 Ethernet, modifying the packet's MAC addresses at each hop. This 18 document describes an architecture for the integrated deployment of 19 these two protocols. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on May 7, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction ................................................. 2 62 2. Abbreviations ................................................ 3 63 3. FCoE over TRILL .............................................. 4 64 3.1. FCoE over a TRILL Cloud ................................. 4 65 3.2. FCoE over RBridge ....................................... 6 66 3.2.1. FCRB ............................................... 6 67 3.2.2. Topology ........................................... 8 68 3.2.3. The FCRB Flow ..................................... 10 69 3.2.3.1. Example - ENode to ENode ..................... 10 70 3.2.3.1.1. Forwarding from A to C - Dense Mode ..... 10 71 3.2.3.1.2. Forwarding from A to C - Sparse Mode .... 11 72 3.2.3.2. Example - ENode to Native FC Node ............ 12 73 3.2.3.3. Example - ENode to ENode with non-FCRB EoR ... 12 74 3.2.3.4. Example - FCoE Control Traffic through an FCRB 13 75 4. Security Considerations ..................................... 14 76 5. IANA Considerations ......................................... 14 77 6. Acknowledgments ............................................. 14 78 7. References .................................................. 15 79 7.1. Normative References ................................... 15 80 7.2. Informative References ................................. 15 82 1. Introduction 84 Data center networks are rapidly evolving towards a consolidated 85 approach, where Ethernet is used as the common infrastructure for all 86 types of traffic. Storage traffic was traditionally dominated by the 87 Fibre Channel (FC) protocol suite. At the intersection between these 88 two technologies a new technology was born, Fibre Channel over 89 Ethernet (FCoE), where native Fibre Channel (FC) packets are 90 encapsulated with an FCoE encapsulation over an Ethernet header. FCoE 91 is specified in [FC-BB-5] (A future version of FCoE is under 92 development and is expected to be specified in a document to be 93 referred to as FC-BB-6; however, this is a work in progress and 94 beyond the scope of this document.) 95 Traffic between two FCoE end nodes (ENodes) is forwarded through one 96 or more FCoE Forwarders (FCF). An FCF takes a forwarding decision 97 based on the Fibre Channel destination ID (D_ID), and enforces 98 security policies between ENodes, also known as zoning. Once an FCF 99 takes a forwarding decision, it modifies the source and destination 100 MAC addresses of the packet, to reflect the path to the next hop FCF 101 or ENode. An FCoE virtual link is an Ethernet link between an ENode 102 and an FCF, or between two FCFs. An FCoE virtual link may traverse 103 one or more Layer 2 bridges. FCFs use a routing protocol called 104 Fabric Shortest Path First (FSPF) to find the optimal path to each 105 destination. An FCF typically has one or more native Fibre Channel 106 interfaces, allowing it to communicate with native Fibre Channel 107 devices, e.g., storage arrays. 109 TRILL [RFCTRILL] is a protocol for transparent least cost routing, 110 where RBridges forward traffic to their destination based on a least 111 cost route, using a TRILL encapsulation header. RBridges route TRILL- 112 encapsulated packets based on the Egress RBridge Nickname in the 113 TRILL header. An RBridge routes a TRILL-encapsulated packet after 114 modifying its MAC addresses to reflect the path to the next-hop 115 RBridge, and decrementing a Hop Count field. 117 TRILL and FCoE bear a strong resemblance in their forwarding planes. 118 Both protocols take a routing decision based on protocol addresses 119 above Layer 2, and modify the Ethernet MAC addresses on a per-hop 120 basis. Each of the protocols uses its own routing protocol rather 121 than using any type of bridging protocol such as spanning tree 122 protocol [802.1Q] or the Shortest Path Bridging protocol [802.1aq]. 124 FCoE and TRILL are both targeted at the data center environment, and 125 their concurrent deployment is self-evident. This document describes 126 an architecture for the integrated deployment of these two protocols. 128 2. Abbreviations 130 DCB Data Center Bridging 132 ENode FCoE Node such as server or storage array 134 EoR End of Row 136 FC Fibre Channel 138 FCF Fibre Channel Forwarder 140 FCoE Fibre Channel over Ethernet 141 FCRB Fibre Channel forwarder over RBridge 143 FIP FCoE Initialization Protocol 145 FSPF Fabric Shortest Path First 147 LAN Local Area Network 149 RBridge Routing Bridge 151 SAN Storage Area Network 153 ToR Top of Rack 155 TRILL Transparent Interconnection of Lots of Links 157 WAN Wide Area Network 159 3. FCoE over TRILL 161 3.1. FCoE over a TRILL Cloud 163 The simplest approach for running FCoE traffic over a TRILL network 164 is presented in Figure 1. The figure illustrates a TRILL-enabled 165 network, where FCoE traffic is transparently forwarded over the TRILL 166 cloud. The figure illustrates two ENodes, a Server and an FCoE 167 Storage Array, an FCF, and a native Fibre Channel SAN connected to 168 the FCF. 170 FCoE traffic between the two ENodes is sent from the first ENode over 171 the TRILL cloud to the FCF, and then back through the TRILL cloud to 172 the second ENode. 174 +---+ 175 | |_________ 176 | | \ ___ _ 177 +---+ \/ \_/ \__ _ __ 178 FCoE Storage _/ \ / \_/ \_ 179 Array / TRILL / +---+ \_ \ 180 (ENode A) \_ Cloud /________| |____/ SAN _/ 181 / \ | | \__ _/ 182 \__/\_ ___/ +---+ \_/ 183 +---+ / \_/ FCF 184 | |________/ 185 | | 186 +---+ 187 Server 188 (ENode B) 189 Figure 1 The "Separate Cloud" Approach 191 The configuration in Figure 1 separates the TRILL cloud(s) and the 192 FCoE cloud(s). The TRILL cloud routes FCoE traffic as standard 193 Ethernet traffic, and appears to the ENodes and FCF as an Ethernet 194 LAN. FCoE traffic routed over the TRILL cloud includes FCoE data 195 frames, as well as FCoE control traffic, including FCoE 196 Initialization Protocol (FIP) frames. To eliminate frame loss due to 197 queue overflow, the switches in any TRILL Cloud used with FCoE would 198 likely implement and use the relevant DCB protocols [TRILLDCB]. 200 The main drawback of the Separate Cloud approach is that RBridges and 201 FCFs are separate nodes in the network, resulting in more cabling and 202 boxes, and communication between ENodes usually requires two TRILL 203 cloud traversals with twice as many hops. As mentioned above, data 204 center networking is converging towards a consolidated and cost 205 effective approach, where the same infrastructure and equipment is 206 used for both data and storage traffic, and where high efficiency and 207 minimal number of hops are important factors when designing the 208 network topology. 210 The Separate Cloud approach is presented as a background and 211 motivation. The next section introduces an alternative approach with 212 a higher level of integration. 214 3.2. FCoE over RBridge 216 3.2.1. FCRB 218 Rather than the Separate Cloud approach discussed in the previous 219 subsection, an alternate approach is presented, where each switch 220 incorporates both an FCF entity and an RBridge entity. This 221 consolidated entity is referred to as FCoE-forwarder-over-RBridge 222 (FCRB). 224 Figure 2 illustrates an FCRB, and its main building blocks. An FCRB 225 can be functionally viewed as two independent entities: 227 o An FCoE Forwarder (FCF) entity. 229 o An RBridge entity. 231 The FCF entity is connected to one of the ports of the RBridge, and 232 appears to the RBridge as a native Ethernet host. A detailed 233 description of the interaction between the layers is presented in 234 Section 3.2.3. 236 Note: the term "FCF" is used in this document slightly differently 237 than defined in [FC-BB-5], to emphasize the concept that an FCRB is 238 logically similar to an RBridge cascaded to an FCF. In the [FC-BB-5] 239 terminology, an FCRB would be referred to as an FCF, and the "FCF" 240 building block in Figure 2 would be referred to as a FC switching 241 element. 243 +-------------------+ 244 |FCRB | 245 | +-----------+ | Native FC 246 | | FCF |------ Interface 247 | +-----+-----+ | 248 | | | 249 | +-----+-----+ | 250 | | RBridge | | 251 | +-+-+---+-+-+ | 252 | | | | | | 253 +-----|-|---|-|-----+ 254 FCoE/ / | | | 255 +---+ Ethernet / / | | FCoE / Ethernet 256 | |___________________/ / | | over TRILL ___ _ 257 | | / | | / \_/ \__ 258 +---+ / | \_____________ _/ \ 259 FCoE Storage / \_______________/ TRILL / 260 Array / \_ Cloud / 261 (ENode A) / / \ 262 / \__/\_ ___/ 263 +---+ / \_/ 264 | |______________/ 265 | | 266 +---+ 267 Server 268 (ENode B) 269 Figure 2 FCRB Entity in the Network 271 The FCRB entity maintains layer independence between the TRILL and 272 FCoE protocols, while enabling both protocols on the same network. 274 It is noted that FCoE traffic is always forwarded through an FCF, and 275 cannot be forwarded directly between two ENodes. Thus, FCoE traffic 276 between ENodes A and B in the topology in Figure 1 is forwarded 277 through the path 279 ENode A-->TRILL cloud-->FCF-->TRILL cloud-->ENode B 281 As opposed to the topology in Figure 1, the FCF in Figure 2 is 282 adjacent to ENodes A and B. In Figure 2 the FCRB is connected to 283 ENodes A and B, and functions as the edge RBridge that connects these 284 two nodes to the TRILL cloud, as well as the FCF that forwards 285 traffic between these two nodes. Thus, traffic between A and B in the 286 topology in Figure 2 is forwarded through the path 288 ENode A-->FCRB-->ENode B 290 Hence, the usage of FCRB entities allows TRILL and FCoE to use common 291 infrastructure and equipment, as opposed to the Separate Cloud 292 topology presented in Figure 1. 294 3.2.2. Topology 296 The network configuration illustrated in Figure 3 shows a typical 297 topology of a data center network. Servers are hierarchically 298 connected through Top-of-Rack (ToR) switches, also known as access 299 switches, and each set of racks is aggregated through an End-of-Row 300 (EoR) switch. The EoR switches are aggregated to the Core switches, 301 which may be connected to other clouds, such as an external WAN or a 302 native FC SAN. 304 _ __ _ __ 305 / \_/ \_ / \_/ \_ 306 \_ \ \_ \ .... 307 / SAN _/ / WAN _/ 308 \__ _/ \__ _/ 309 \_/ \_/ 310 | | 311 | | 312 | | 313 +------+ +------+ 314 Core | | | | 315 FCoE over | | | | 316 RBridge | | | | 317 (FCRB) +------+ +------+ 318 | \___ ___/ | 319 | \ / | 320 | \/ | 321 EoR +----+_______/\_______+----+ 322 FCoE over | | | | 323 RBridge | | | | 324 (FCRB) +----+ +----+ 325 / \ / \ 326 / \ / \ 327 ToR +---+ +---+ +---+ +---+ 328 FCoE over | | | | | | | | 329 RBridge | | | | | | | | 330 (FCRB) +---+ +---+ +---+ +---+ 331 / \ / \ / \ / \ 332 / \ / \ / \ / \ 333 +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ 334 Servers/ | | | | | | | | | | | | | | | | 335 ENodes +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ 336 A B C D E F G H 338 Figure 3 FCoE over RBridge Topology 340 Note that in the example in Figure 3 all the ToR, EoR and core 341 switches are FCRB entities, but it is also possible for some of the 342 network nodes to be pure RBridges, creating a topology where FCRBs 343 are interconnected through TRILL clouds. 345 3.2.3. The FCRB Flow 347 3.2.3.1. Example - ENode to ENode 349 FCoE traffic sent between two ENodes, A and B in Figure 3, is 350 transmitted through the ToR FCRB, since A and B are connected to the 351 same ToR. Traffic between A and C must be forwarded through the EoR 352 FCRB. 354 The FCoE jargon distinguishes between two deployment modes: 356 o Sparse mode: an FCoE packet sent between two FCFs may be forwarded 357 over several hops of a Layer 2 network, allowing the underlying 358 Layer 2 network to determine the path between the two FCFs. 360 o Dense mode: each node along the path between two FCFs is also an 361 FCF, and the network is configured such that the forwarding 362 decision at each hop is taken at the FCF layer, allowing the path 363 between the two FCFs to be based on the FSPF routing protocol. 365 Figure 4 illustrates the traffic between ENodes A and C that are not 366 connected to the same ToR. The following two subsections describe the 367 forwarding procedure in the Dense mode and in the Sparse mode, 368 respectively. 370 +--------+ +--------+ +--------+ +--------+ +--------+ 371 | FCoE |.....| FCF |.....| FCF |.....| FCF |.....| FCoE | 372 | ENode | +--------+ +--------+ +--------+ | ENode | 373 | | |RBridge |.....|RBridge |.....|RBridge | | | 374 +--------+ +--------+ +--------+ +--------+ +--------+ 375 |Ethernet|<===>|Ethernet|<===>|Ethernet|<===>|Ethernet|<===>|Ethernet| 376 +--------+ +--------+ +--------+ +--------+ +--------+ 377 Server ToR 1 EoR ToR 2 FCoE Storage 378 ENode A FCRB FCRB FCRB Array 379 ENode C 380 Figure 4 Traffic between two ENodes - Example 382 3.2.3.1.1. Forwarding from A to C - Dense Mode 384 o FCoE traffic from A is sent to the ToR over the Ethernet 385 interface. The destination MAC address is the address of the FCF 386 entity at the ToR. 388 o ToR 1: 390 o The packet is forwarded to the FCF entity at the ToR. Thus, 391 forwarding between A and the FCF at the ToR is analogous to 392 forwarding between two Ethernet hosts. 394 o The FCF entity at the ToR takes a forwarding decision based 395 on the FC addresses. This decision is based on the FSPF 396 routing protocol at the FCF layer, forwarding the packet to 397 the FCF entity in the EoR. 399 o The FCF then updates the destination MAC address of the 400 packet to the address of the EoR FCF. 402 o The packet is forwarded to the RBridge entity, where it is 403 encapsulated in a TRILL header, and sent to the RBridge at 404 the EoR over a single hop of the TRILL network. 406 o The RBridge entity in the EoR FCRB, acting as the egress RBridge, 407 decapsulates the TRILL header and forwards the FCoE packet to the 408 FCF entity. From this point the forwarding process is similar to 409 the one described above for the ToR. 411 o A similar forwarding process takes place at the next hop ToR FCRB, 412 where the FCRB finally forwards the FCoE packet to the target 413 ENode C. 415 3.2.3.1.2. Forwarding from A to C - Sparse Mode 417 o Traffic is forwarded to ToR 1, as described in Section 3.2.3.1.1. 419 o The FCF in ToR 1, based on an FSPF forwarding decision, forwards 420 the packet to the FCF in ToR 2. The destination MAC address of the 421 FCoE packet is updated, reflecting the FCF in ToR 2. The RBridge 422 entity in ToR 2 adds a TRILL encapsulation, with an egress RBridge 423 nickname representing ToR 2. 425 o The packet reaches the EoR. The RBridge entity in the EoR routes 426 the packet to the RBridge entity in ToR 2. 428 o The packet reaches ToR 2, and from this point on the process is 429 identical to the one described in Section 3.2.3.1.1. 431 3.2.3.2. Example - ENode to Native FC Node 433 +--------+ +--------+ +--------+ +---------+ +--------+ 434 | FCoE |.....| FCF |.....| FCF |.....| FCF |.....| FC | 435 | ENode | +--------+ +--------+ +----+----+ |protocol| 436 | | |RBridge |.....|RBridge |.....| RB | | | stack | 437 +--------+ +--------+ +--------+ +----+ FC | | | 438 |Ethernet|<===>|Ethernet|<===>|Ethernet|<===>|Eth | |<===>| | 439 +--------+ +--------+ +--------+ +----+----+ +--------+ 440 Server ToR EoR Core Native FC 441 ENode FCRB FCRB FCRB Storage Array 443 Figure 5 Example Traffic between ENode & Native FC Storage Array 445 Figure 5 illustrates a second example, where traffic is sent between 446 an ENode and an FC Storage Array, following the network topology in 447 Figure 3. 449 o FCoE traffic from the ENode is sent to the ToR over the Ethernet 450 interface. The forwarding process through the ToR FCRB and through 451 the EoR is similar to the corresponding steps in Section 3.2.3.1. 453 o When the packet reaches the core FCRB, the egress RBridge entity 454 decapsulates the TRILL header and forwards the FCoE packet to the 455 FCF entity. The packet is then forwarded as a native FC packet 456 through the FC interface to the native FC node. 458 3.2.3.3. Example - ENode to ENode with non-FCRB EoR 460 The example illustrated in Figure 6 is similar to the one shown in 461 Figure 4, except that the EoR is an RBridge rather than an FCRB. 463 +--------+ +--------+ +--------+ +--------+ 464 | FCoE |.....| FCF |....................| FCF |.....| FCoE | 465 | ENode | +--------+ +--------+ +--------+ | ENode | 466 | | |RBridge |.....|RBridge |.....|RBridge | | | 467 +--------+ +--------+ +--------+ +--------+ +--------+ 468 |Ethernet|<===>|Ethernet|<===>|Ethernet|<===>|Ethernet|<===>|Ethernet| 469 +--------+ +--------+ +--------+ +--------+ +--------+ 470 Server ToR 1 EoR ToR 2 FCoE Storage 471 ENode A FCRB FCRB FCRB Array 472 ENode C 473 Figure 6 Traffic between two ENodes - Example 475 An FCoE packet sent from A to C is forwarded as follows: 477 o The packet is sent to the FCF in ToR 1, as in the previous 478 example. 480 o The FCF in ToR 1 takes a forwarding decision based on the FC 481 addresses, and forwards the packet to the next hop FCF, which 482 resides in ToR 2. This forwarding decision is taken at the FCF 483 layer, and is based on the FSPF routing protocol. 485 o The packet is then forwarded to the RBridge entity in ToR 1, where 486 it is encapsulated in a TRILL encapsulation, and forwarded to the 487 RBridge at ToR 2. The packet is routed over the TRILL cloud 488 through the RBridge at the EoR. The path through the TRILL cloud 489 is determined by TRILL's IS-IS routing protocol. 491 o Once the packet reaches ToR 2, it is forwarded in a similar manner 492 to the description in Section 3.2.3.1. 494 This example demonstrates that it is possible to have a hybrid 495 network, where some of the nodes are FCRBs, and some of the nodes are 496 RBridges. The forwarding procedure in this example is somewhat 497 similar to the sparse-mode forwarding described in Section 3.2.3.1.2. 499 3.2.3.4. Example - FCoE Control Traffic through an FCRB 501 The previous subsections focused on the data plane, i.e., storage 502 data exchanges transported over an FCoE encapsulation. FCoE also 503 requires control and management traffic that is used for initializing 504 sessions (FIP), distributing routing information (FSPF), and fabric 505 administration and management. 507 The FCoE Initialization Protocol (FIP) uses Ethernet frames with a 508 dedicated Ethertype, allowing the FCF to distinguish it from other 509 traffic. FIP uses both unicast and multicast traffic. The following 510 example describes the forwarding scheme of a multicast FIP packet 511 sent through the network depicted in Figure 4: 513 o ENode A generates a multicast frame to a multicast MAC address 514 representing all the FCFs (All-FCF-MAC). 516 o The packet is forwarded to the ToR FCRB node. The RBridge entity 517 forwards a copy of the packet to its FCF entity, and also sends 518 the packet through the TRILL cloud as a multicast TRILL 519 encapsulated packet. 521 o Each of the FCRBs in turn receives the packet, forwards a copy to 522 its FCF entity, as well as forwarding the packet through the TRILL 523 network, allowing all the FCFs to receive the packet. 525 While FIP packets have a dedicated Ethertype and frame format, other 526 types of FCoE control and management frames use the same FCoE 527 encapsulation as FCoE data traffic. Thus, the forwarding scheme for 528 such control traffic is similar to the examples described in the 529 previous subsections, with the exception that these frames can be 530 sent between ENodes, between FCFs, or between ENodes and FCFs. 532 4. Security Considerations 534 For general TRILL Security Considerations see [RFCTRILL]. 536 For general FCoE Security Consideration see Annex D of [FC-BB-5]. 538 There are no additional security implications imposed by this 539 document. 541 5. IANA Considerations 543 There are no IANA actions required by this document. 545 RFC Editor: please delete this section before publication. 547 6. Acknowledgments 549 The authors gratefully acknowledge Ayandeh Siamack and David Black 550 for their helpful comments. The authors also thank the T11 committee 551 for reviewing the document, and in particular Pat Thaler and Joe 552 White for their useful inputs. 554 This document was prepared using 2-Word-v2.0.template.dot. 556 7. References 558 7.1. Normative References 560 [RFCTRILL] Perlman, R., Eastlake, D., Dutt, D., Gai, S., 561 Ghanwani, A., "Routing Bridges (RBridges): Base 562 Protocol Specification", RFC 6325, July 2011. 564 [FC-BB-5] ANSI INCITS 462: Information Technology - Fibre 565 Channel - Backbone - 5 (FC-BB-5). 567 7.2. Informative References 569 [802.1Q] "IEEE Standard for Local and metropolitan area 570 networks - Virtual Bridged Local Area Networks", IEEE 571 Std 802.1Q-2011, May 2011. 573 [802.1aq] "IEEE Standard for Local and metropolitan area 574 networks - Media Access Control (MAC) Bridges and 575 Virtual Bridged Local Area Networks - Shortest Path 576 Bridging", IEEE Std 802.1aq-2012, June 2012. 578 [TRILLDCB] Eastlake, D., Wadekar, M., Ghanwani, A., Agarwal, P., 579 Mizrahi, T., "TRILL: Support of IEEE 802.1Qbb, 580 802.1Qaz, and Congestion Notification", draft- 581 eastlake-trill-rbridge-dcb, work in progress, 2012. 583 Authors' Addresses 585 David Melman 586 Marvell 587 6 Hamada St. 588 Yokneam, 20692 Israel 590 Email: davidme@marvell.com 591 Tal Mizrahi 592 Marvell 593 6 Hamada St. 594 Yokneam, 20692 Israel 596 Email: talmi@marvell.com 598 Donald Eastlake 3rd 599 Huawei USA R&D 600 155 Beaver Street 601 Milford, MA 01757 USA 603 Phone: +1-508-333-2270 604 EMail: d3e3e3@gmail.com