idnits 2.17.1 draft-ietf-tsvwg-gre-in-udp-encap-01.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 (February 13, 2014) is 3719 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) == Missing Reference: 'RFC0768' is mentioned on line 82, but not defined == Missing Reference: 'TBD' is mentioned on line 318, but not defined == Unused Reference: 'RFC791' is defined on line 412, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'RFC4884' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'RFC6790' is defined on line 469, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2983 ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- No information found for draft-bonica-intara-gre-mtu - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Crabbe, Ed. 2 Internet-Draft Google 3 Intended status: Standard Track L. Yong, Ed. 4 Huawei USA 5 X. Xu, Ed. 6 Huawei Technologies 8 Expires: September 2014 February 13, 2014 10 Generic UDP Encapsulation for IP Tunneling 11 draft-ietf-tsvwg-gre-in-udp-encap-01 13 Abstract 15 This document describes a method of encapsulating arbitrary 16 protocols within GRE and UDP headers. In this encapsulation, the 17 source UDP port may be used as an entropy field for purposes of load 18 balancing while the payload protocol may be identified by the GRE 19 Protocol Type. 21 Status of This Document 23 This Internet-Draft is submitted 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). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 13, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction...................................................3 56 1.1. Applicability Statements..................................3 57 2. Terminology....................................................4 58 2.1. Requirements Language.....................................4 59 3. Procedures.....................................................4 60 4. Encapsulation Considerations...................................8 61 5. Backward Compatibility.........................................9 62 6. IANA Considerations............................................9 63 7. Security Considerations.......................................10 64 7.1. Vulnerability............................................10 65 8. Acknowledgements..............................................10 66 9. Contributors..................................................10 67 10. References...................................................11 68 10.1. Normative References....................................11 69 10.2. Informative References..................................12 70 11. Authors' Addresses...........................................13 72 1. Introduction 74 Load balancing, or more specifically, statistical multiplexing of 75 traffic using Equal Cost Multi-Path (ECMP) and/or Link Aggregation 76 Groups (LAGs) in IP networks is a widely used technique for creating 77 higher capacity networks out of lower capacity links. Most existing 78 routers in IP networks are already capable of distributing IP 79 traffic flows over ECMP paths and/or LAGs on the basis of a hash 80 function performed on flow invariant fields in IP packet headers and 81 their payload protocol headers. Specifically, when the IP payload is 82 a User Datagram Protocol (UDP)[RFC0768] or Transmission Control 83 Protocol (TCP) packet, router hash functions frequently operate on 84 the five-tuple of the source IP address, the destination IP address, 85 the source port, the destination port, and the protocol/next-header 87 Several tunneling techniques are in common use in IP networks, such 88 as Generic Routing Encapsulation (GRE) [RFC2784], MPLS [RFC4023] and 89 L2TPv3 [RFC3931]. GRE is an increasingly popular encapsulation 90 choice, especially in environments where MPLS is unavailable or 91 unnecessary. Unfortunately, use of common GRE endpoints may reduce 92 the entropy available for use in load balancing, especially in 93 environments where the GRE Key field [RFC2890] is not readily 94 available for use as entropy in forwarding decisions. 96 This document defines a generic GRE-in-UDP encapsulation for 97 tunneling arbitrary network protocol payloads across an IP network 98 environment where ECMP or LAGs are used. The GRE header provides 99 payload protocol de-multiplexing by way of it's protocol type field 100 [RFC2784] while the UDP header provides additional entropy by way of 101 it's source port. 103 This encapsulation method requires no changes to the transit IP 104 network. Hash functions in most existing IP routers may utilize and 105 benefit from the use of a GRE-in-UDP tunnel is without needing any 106 change or upgrade to their ECMP implementation. The encapsulation 107 mechanism is applicable to a variety of IP networks including Data 108 Center and wide area networks. 110 1.1. Applicability Statements 112 It is recommended to use the GRE-in-UDP encapsulation technology in 113 a Service Provider (SP) network and/or DC network where the 114 congestion control is not a concern, rather than over the Internet 115 where the congestion control is a must. Furthermore, packet filters 116 should be added so as to prevent GRE-in-UDP packets from escaping 117 from the service provider networks due to mis-configuration or 118 packet errors. 120 2. Terminology 122 The terms defined in [RFC768] are used in this document. 124 2.1. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 3. Procedures 132 When a tunnel ingress device conforming to this document receives a 133 packet, the ingress MUST encapsulate the packet in UDP and GRE 134 headers and set the destination port of the UDP header to [TBD] 135 Section 6. The ingress device must also insert the payload protocol 136 type in the GRE Protocol Type field. The ingress device SHOULD set 137 the UDP source port based on flow invariant fields from the payload 138 header, otherwise it should be set to a randomly selected constant 139 value, e.g. zero, to avoid packet flow reordering. How a tunnel 140 ingress generates entropy from the payload is outside the scope of 141 this document. The tunnel ingress MUST encode its own IP address as 142 the source IP address and the egress tunnel endpoint IP address. 143 The TTL field in the IP header must be set to a value appropriate 144 for delivery of the encapsulated packet to the tunnel egress 145 endpoint. 147 When the tunnel egress receives a packet, it must remove the outer 148 UDP and GRE headers. Section 5 describes the error handling when 149 this entity is not instantiated at the tunnel egress. 151 To simplify packet processing at the tunnel egress, packets destined 152 to this assigned UDP destination port [TBD] MAY have their UDP 153 checksum set to zero. In the environment where the UDP packets may 154 be mis-delivered [RFC5405], UDP checksum SHOULD be used. Upon 155 receiving a packet with a non-zero checksum, tunnel egress MUST 156 perform the UDP checksum verification. For an IPv6 network, UDP 157 checksum SHOULD be used; if the checksum needs to be disabled for 158 performance or implementation concerns, the considerations described 159 in [RFC6935][RFC6936] MUST be examined. The Sequence flags MUST set 160 to zero. 162 The tunnel ingress may set the GRE Key Present, Sequence Number 163 Present, and Checksum Present bits and associated fields in the GRE 164 header defined by [RFC2784] and [RFC2890]. 166 In addition IPv6 nodes MUST conform to the following: 168 1. the IPv6 tunnel ingress and egress SHOULD follow the node 169 requirements specified in Section 4 of [RFC6936] and the usage 170 requirements specified in Section 5 of [RFC6936]. 172 2. IPv6 transit nodes SHOULD follow the requirements 9, 10, 11 173 specified in Section 5 of [RFC6936]. 175 The tunnel ingress may set the GRE Key Present, Sequence Number 176 Present, and Checksum Present bits and associated fields in the GRE 177 header defined by [RFC2784] and [RFC2890]. 178 The format of the GRE-in-UDP encapsulation for both IPv4 and IPv6 179 outer headers is shown in the following figures: 181 0 1 2 3 182 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 184 IPv4 Header: 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 |Version| IHL |Type of Service| Total Length | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Identification |Flags| Fragment Offset | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Time to Live |Protcol=17(UDP)| Header Checksum | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Source IPv4 Address | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Destination IPv4 Address | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 UDP Header: 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Source Port = XXXX | Dest Port = TBD | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | UDP Length | UDP Checksum | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 GRE Header: 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 |C| |K|S| Reserved0 | Ver | Protocol Type | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Checksum (optional) | Reserved1 (Optional) | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Key (optional) | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Sequence Number (Optional) | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 1 UDP+GRE IPv4 headers 217 0 1 2 3 218 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 220 IPv6 Header: 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 |Version| Traffic Class | Flow Label | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 227 + + 228 | | 229 + Outer Source IPv6 Address + 230 | | 231 + + 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | | 235 + + 236 | | 237 + Outer Destination IPv6 Address + 238 | | 239 + + 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 UDP Header: 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Source Port = XXXX | Dest Port = TBD | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | UDP Length | UDP Checksum | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 GRE Header: 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 |C| |K|S| Reserved0 | Ver | Protocol Type | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Checksum (optional) | Reserved1 (Optional) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Key (optional) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Sequence Number (Optional) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Figure 2 UDP+GRE IPv6 headers 263 The total overhead increase for a UDP+GRE tunnel without use of 264 optional GRE fields, representing the lowest total overhead increase, 265 is 32 bytes in the case of IPv4 and 52 bytes in the case of IPv6. 266 The total overhead increase for a UDP+GRE tunnel with use of GRE Key, 267 Sequence and Checksum Fields, representing the highest total 268 overhead increase, is 44 bytes in the case of IPv4 and 64 bytes in 269 the case of IPv6. 271 4. Encapsulation Considerations 273 GRE-in-UDP encapsulation allows the tunneled traffic to be unicast, 274 broadcast, or multicast traffic. Entropy may be generated from the 275 header of tunneled unicast or broadcast/multicast packets at tunnel 276 ingress. The mapping mechanism between the tunneled multicast 277 traffic and the multicast capability in the IP network is 278 transparent and independent to the encapsulation and is outside the 279 scope of this document. 281 If tunnel ingress must perform the fragmentation [GREMTU] on a 282 packet before encapsulation, it MUST use the same source UDP port 283 for all packet fragments. This ensures that the transit routers 284 will forward the packet fragments on the same path. GRE-in-UDP 285 encapsulation introduces some overhead as mentioned in section 3, 286 which reduces the effective Maximum Transmission Unit (MTU) size. 287 An operator should factor in this addition overhead bytes when 288 considering an MTU size for the payload to reduce the likelihood of 289 fragmentation. 291 To ensure the tunneled traffic gets the same treatment over the IP 292 network, prior to the encapsulation process, tunnel ingress should 293 process the payload to get the proper parameters to fill into the IP 294 header such as DiffServ [RFC2983]. Tunnel end points that support 295 ECN MUST use the method described in [RFC6040] for ECN marking 296 propagation. This process is outside of the scope of this document. 298 Note that the IPv6 header [RFC2460] contains a flow label field that 299 may be used for load balancing in an IPv6 network [RFC6438]. Thus 300 in an IPv6 network, either GRE-in-UDP or flow labels may be used for 301 improving load balancing performance. Use of GRE-in-UDP 302 encapsulation provides a unified hardware implementation for load 303 balancing in an IP network independent of the IP version(s) in use. 304 However, if UDP checksum has to be used in the environment, a flow 305 label based load balancing is advantage in performance and 306 implementation. 308 5. Backward Compatibility 310 It is assumed that tunnel ingress routers must be upgraded in order 311 to support the encapsulations described in this document. 313 No change is required at transit routers to support forwarding of 314 the encapsulation described in this document. 316 If a router that is intended for use as a tunnel egress does not 317 support the GRE-in-UDP encapsulation described in this document, it 318 will not be listening on destination port [TBD]. In these cases, 319 the router will conform to normal UDP processing and respond to the 320 tunnel ingress with an ICMP message indicating "port unreachable" 321 according to [RFC792]. Upon receiving this ICMP message, the tunnel 322 ingress MUST NOT continue to use GRE-in-UDP encapsulation toward 323 this tunnel egress without management intervention. 325 6. IANA Considerations 327 IANA is requested to make the following allocation: 329 Service Name: GRE-in-UDP 330 Transport Protocol(s): UDP 331 Assignee: IESG 332 Contact: IETF Chair 333 Description: GRE-in-UDP Encapsulation 334 Reference: [This.I-D] 335 Port Number: TBD 336 Service Code: N/A 337 Known Unauthorized Uses: N/A 338 Assignment Notes: N/A 340 7. Security Considerations 342 7.1. Vulnerability 344 Neither UDP nor GRE encapsulation effects security for the payload 345 protocol. When using GRE-in-UDP, Network Security in a network is 346 the same as that of a network using GRE. 348 Use of ICMP for signaling of the GRE-in-UDP encapsulation capability 349 adds a security concern. Tunnel ingress devices may want to 350 validate the origin of ICMP Port Unreachable messages before taking 351 action. The mechanism for performing this validation is out of the 352 scope of this document. 354 In an instance where the UDP src port is not set based on the flow 355 invariant fields from the payload header, a random port SHOULD be 356 selected in order to minimize the vulnerability to off-path attacks. 357 [RFC6056] How the src port randomization occurs is outside scope of 358 this document. 360 Using one standardized value in UDP destination port for an 361 encapsulation indication may increase the vulnerability of off-path 362 attack. To overcome this, tunnel egress may request tunnel ingress 363 using a different and specific value [RFC6056] in UDP destination 364 port for the GRE-in-UDP encapsulation indication. How the tunnel end 365 points communicate the value is outside scope of this document. 367 8. Acknowledgements 369 Authors like to thank Vivek Kumar, Ron Bonica, Joe Touch, Ruediger 370 Geib, Gorry Fairhurst, David Black, Lar Edds, Lloyd, and many others 371 for their review and valuable input on this draft. 373 9. Contributors 375 The following people all contributed significantly to this document 376 and are listed below in alphabetical order: 378 John E. Drake 379 Juniper Networks 380 Email: jdrake@juniper.net 382 Adrian Farrel 383 Juniper Networks 385 Email: adrian@olddog.co.uk 387 Vishwas Manral 388 Hewlett-Packard Corp. 389 3000 Hanover St, Palo Alto. 391 Email: vishwas.manral@hp.com 393 Carlos Pignataro 394 Cisco Systems 395 7200-12 Kit Creek Road 396 Research Triangle Park, NC 27709 USA 398 EMail: cpignata@cisco.com 400 Yongbing Fan 401 China Telecom 402 Guangzhou, China. 403 Phone: +86 20 38639121 405 10. References 407 10.1. Normative References 409 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 410 August 1980. 412 [RFC791] DARPA, "Internet Protocol", RFC791, September 1981 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC2119, March 1997. 417 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 418 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 419 March 2000. 421 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 422 RFC2890, September 2000. 424 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC2983, 425 October 2000. 427 [RFC5405] Eggert, L., "Unicast UDP Usage Guideline for Application 428 Designers", RFC5405, November 2008. 430 [RFC6040] Briscoe, B., "Tunneling of Explicit Congestion 431 Notification", RFC6040, November 2010 433 [RFC6438] Carpenter, B., Amante, S., "Using the IPv6 Flow Label for 434 Equal Cost Multipath Routing and Linda Aggregation in 435 tunnels", RFC6438, November, 2011 437 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 438 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 440 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 441 for the Use of IPv6 UDP Datagrams with Zero Checksums", 442 RFC 6936, April 2013. 444 10.2. Informative References 446 [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 447 792, September 1981. 449 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 450 (IPv6) Specification", RFC 2460, December 1998. 452 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 453 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 455 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 456 MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 457 4023, March 2005. 459 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 460 Networks (VPNs)", RFC 4364, February 2006. 462 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 463 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 464 April 2007. 466 [RFC6056] Larsen, M. and Gont, F., "Recommendations for Transport- 467 Protocol Port Randomization", RFC6056, January 2011 469 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 470 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 471 RFC 6790, November 2012. 473 [GREMTU] Bonica, R., "A Fragmentation Strategy for Generic Routing 474 Encapsulation (GRE)", draft-bonica-intara-gre-mtu, work in 475 progress 477 11. Authors' Addresses 479 Edward Crabbe (editor) 480 Google 481 1600 Amphitheatre Parkway 482 Mountain View, CA 94102 483 US 485 Lucy Yong (editor) 486 Huawei Technologies, USA 488 Email: lucy.yong@huawei.com 490 Xiaohu Xu (editor) 491 Huawei Technologies, 492 Beijing, China 494 Email: xuxiaohu@huawei.com