<?xml version="1.0" encoding="UTF-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1" version="1.1">
  <file original="NoName" source-language="en" datatype="plaintext" target-language="en">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="69fa50db94aa0bf9" weblate-flags="read-only">
        <source>Datalink layer technologies</source>
        <target state="translated">Datalink layer technologies</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/lan.rst</context>
          <context context-type="linenumber">6</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="64e14421be3e40c2" weblate-flags="read-only">
        <source>In this section, we review the key characteristics of several datalink layer technologies. We discuss in more detail the technologies that are widely used today. A detailed survey of all datalink layer technologies would be outside the scope of this book.</source>
        <target state="translated">In this section, we review the key characteristics of several datalink layer technologies. We discuss in more detail the technologies that are widely used today. A detailed survey of all datalink layer technologies would be outside the scope of this book.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/lan.rst</context>
          <context context-type="linenumber">8</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="653655da7ccdf5ca" weblate-flags="read-only">
        <source>The Point-to-Point Protocol</source>
        <target state="translated">The Point-to-Point Protocol</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">7</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6b8cf977dc261428" weblate-flags="read-only">
        <source>Many point-to-point datalink layers [#flapb]_ have been developed, starting in the 1960s. In this section, we focus on the protocols that are often used to transport IP packets between hosts or routers that are directly connected by a point-to-point link. This link can be a dedicated physical cable, a leased line through the telephone network or a dial-up connection with modems on the two communicating hosts.</source>
        <target state="translated">Many point-to-point datalink layers [#flapb]_ have been developed, starting in the 1960s. In this section, we focus on the protocols that are often used to transport IP packets between hosts or routers that are directly connected by a point-to-point link. This link can be a dedicated physical cable, a leased line through the telephone network or a dial-up connection with modems on the two communicating hosts.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">9</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="12c5a49b2b63ead5" weblate-flags="read-only">
        <source>The first solution to transport IP packets over a serial line was proposed in :rfc:`1055` and is known as `Serial Line IP` (SLIP). SLIP is a simple character stuffing technique applied to IP packets. SLIP defines two special characters : `END` (decimal 192) and `ESC` (decimal 219). `END` appears at the beginning and at the end of each transmitted IP packet and the sender adds `ESC` before each `END` character inside each transmitted IP packet. SLIP only supports the transmission of IP packets and it assumes that the two communicating hosts/routers have been manually configured with each other's IP address. SLIP was mainly used over links offering bandwidth of often less than 20 Kbps.  On such a low bandwidth link, sending 20 bytes of IP header followed by 20 bytes of TCP header for each TCP segment takes a lot of time. This initiated the development of a family of compression techniques to efficiently compress the TCP/IP headers. The first header compression technique proposed in :rfc:`1144` was designed to exploit the redundancy between several consecutive segments that belong to the same TCP connection. In all these segments, the IP addresses and port numbers are always the same. Furthermore, fields such as the sequence and acknowledgment numbers do not change in a random way. :rfc:`1144` defined simple techniques to reduce the redundancy found in successive segments. The development of header compression techniques continued and there are still improvements being developed now :rfc:`5795`.</source>
        <target state="translated">The first solution to transport IP packets over a serial line was proposed in :rfc:`1055` and is known as `Serial Line IP` (SLIP). SLIP is a simple character stuffing technique applied to IP packets. SLIP defines two special characters : `END` (decimal 192) and `ESC` (decimal 219). `END` appears at the beginning and at the end of each transmitted IP packet and the sender adds `ESC` before each `END` character inside each transmitted IP packet. SLIP only supports the transmission of IP packets and it assumes that the two communicating hosts/routers have been manually configured with each other's IP address. SLIP was mainly used over links offering bandwidth of often less than 20 Kbps.  On such a low bandwidth link, sending 20 bytes of IP header followed by 20 bytes of TCP header for each TCP segment takes a lot of time. This initiated the development of a family of compression techniques to efficiently compress the TCP/IP headers. The first header compression technique proposed in :rfc:`1144` was designed to exploit the redundancy between several consecutive segments that belong to the same TCP connection. In all these segments, the IP addresses and port numbers are always the same. Furthermore, fields such as the sequence and acknowledgment numbers do not change in a random way. :rfc:`1144` defined simple techniques to reduce the redundancy found in successive segments. The development of header compression techniques continued and there are still improvements being developed now :rfc:`5795`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">13</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4b45af35ec68ae41" weblate-flags="read-only">
        <source>While SLIP was implemented and used in some environments, it had several limitations discussed in :rfc:`1055`. The `Point-to-Point Protocol` (PPP) was designed shortly after and is specified in :rfc:`1548`. PPP aims to support IP and other network layer protocols over various types of serial lines. PPP is in fact a family of three protocols that are used together :</source>
        <target state="translated">While SLIP was implemented and used in some environments, it had several limitations discussed in :rfc:`1055`. The `Point-to-Point Protocol` (PPP) was designed shortly after and is specified in :rfc:`1548`. PPP aims to support IP and other network layer protocols over various types of serial lines. PPP is in fact a family of three protocols that are used together :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">15</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3561d3af55d9ebf5" weblate-flags="read-only">
        <source>The `Point-to-Point Protocol` defines the framing technique to transport network layer packets.</source>
        <target state="translated">The `Point-to-Point Protocol` defines the framing technique to transport network layer packets.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">17</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7e3fe6b8021e2a8f" weblate-flags="read-only">
        <source>The `Link Control Protocol` that is used to negotiate options and authenticate the session by using username and password or other types of credentials</source>
        <target state="translated">The `Link Control Protocol` that is used to negotiate options and authenticate the session by using username and password or other types of credentials</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">18</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="83a8af0236f482a0" weblate-flags="read-only">
        <source>The `Network Control Protocol` that is specific for each network layer protocol. It is used to negotiate options that are specific for each protocol. For example, IPv4's NCP :rfc:`1548` can negotiate the IPv4 address to be used, the IPv4 address of the DNS resolver. IPv6's NCP is defined in :rfc:`5072`.</source>
        <target state="translated">The `Network Control Protocol` that is specific for each network layer protocol. It is used to negotiate options that are specific for each protocol. For example, IPv4's NCP :rfc:`1548` can negotiate the IPv4 address to be used, the IPv4 address of the DNS resolver. IPv6's NCP is defined in :rfc:`5072`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">19</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="49ef13356396da54" weblate-flags="read-only">
        <source>The PPP framing :rfc:`1662` was inspired by the datalink layer protocols standardized by ITU-T and ISO. A typical PPP frame is composed of the fields shown in the figure below. A PPP frame starts with a one byte flag containing `01111110`. PPP can use bit stuffing or character stuffing depending on the environment where the protocol is used. The address and control fields are present for backward compatibility reasons. The 16 bit Protocol field contains the identifier [#fpppid]_ of the network layer protocol that is carried in the PPP frame. `0x002d` is used for an IPv4 packet compressed with :rfc:`1144` while `0x002f` is used for an uncompressed IPv4 packet. `0xc021` is used by the Link Control Protocol, `0xc023` is used by the Password Authentication Protocol (PAP). `0x0057` is used for IPv6 packets. PPP supports variable length packets, but LCP can negotiate a maximum packet length. The PPP frame ends with a Frame Check Sequence. The default is a 16 bits CRC, but some implementations can negotiate a 32 bits CRC. The frame ends with the `01111110` flag.</source>
        <target state="translated">The PPP framing :rfc:`1662` was inspired by the datalink layer protocols standardized by ITU-T and ISO. A typical PPP frame is composed of the fields shown in the figure below. A PPP frame starts with a one byte flag containing `01111110`. PPP can use bit stuffing or character stuffing depending on the environment where the protocol is used. The address and control fields are present for backward compatibility reasons. The 16 bit Protocol field contains the identifier [#fpppid]_ of the network layer protocol that is carried in the PPP frame. `0x002d` is used for an IPv4 packet compressed with :rfc:`1144` while `0x002f` is used for an uncompressed IPv4 packet. `0xc021` is used by the Link Control Protocol, `0xc023` is used by the Password Authentication Protocol (PAP). `0x0057` is used for IPv6 packets. PPP supports variable length packets, but LCP can negotiate a maximum packet length. The PPP frame ends with a Frame Check Sequence. The default is a 16 bits CRC, but some implementations can negotiate a 32 bits CRC. The frame ends with the `01111110` flag.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">21</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5232cb21df16b2d8" weblate-flags="read-only">
        <source>PPP frame format</source>
        <target state="translated">PPP frame format</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">27</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="594d8e541b849c3f" weblate-flags="read-only">
        <source>PPP played a key role in allowing Internet Service Providers to provide dial-up access over modems in the late 1990s and early 2000s. ISPs operated modem banks connected to the telephone network. For these ISPs, a key issue was to authenticate each user connected through the telephone network. This authentication was performed by using the `Extensible Authentication Protocol` (EAP) defined in :rfc:`3748`. EAP is a simple, but extensible protocol that was initially used by access routers to authenticate the users connected through dial-up lines. Several authentication methods, starting from the simple username/password pairs to more complex schemes have been defined and implemented. When ISPs started to upgrade their physical infrastructure to provide Internet access over `Asymmetric Digital Subscriber Lines` (ADSL), they tried to reuse their existing authentication (and billing) systems. To meet these requirements, the IETF developed specifications to allow PPP frames to be transported over other networks than the point-to-point links for which PPP was designed. Nowadays, most ADSL deployments use PPP over either ATM :rfc:`2364` or Ethernet :rfc:`2516`.</source>
        <target state="translated">PPP played a key role in allowing Internet Service Providers to provide dial-up access over modems in the late 1990s and early 2000s. ISPs operated modem banks connected to the telephone network. For these ISPs, a key issue was to authenticate each user connected through the telephone network. This authentication was performed by using the `Extensible Authentication Protocol` (EAP) defined in :rfc:`3748`. EAP is a simple, but extensible protocol that was initially used by access routers to authenticate the users connected through dial-up lines. Several authentication methods, starting from the simple username/password pairs to more complex schemes have been defined and implemented. When ISPs started to upgrade their physical infrastructure to provide Internet access over `Asymmetric Digital Subscriber Lines` (ADSL), they tried to reuse their existing authentication (and billing) systems. To meet these requirements, the IETF developed specifications to allow PPP frames to be transported over other networks than the point-to-point links for which PPP was designed. Nowadays, most ADSL deployments use PPP over either ATM :rfc:`2364` or Ethernet :rfc:`2516`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">31</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c463aea6549199a2" weblate-flags="read-only">
        <source>Footnotes</source>
        <target state="translated">Footnotes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">34</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">192</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">308</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">157</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8c81cf3037d4e08d" weblate-flags="read-only">
        <source>`LAPB &lt;http://en.wikipedia.org/wiki/LAPB&gt;`_ and `HDLC &lt;http://en.wikipedia.org/wiki/HDLC&gt;`_ were widely used datalink layer protocols.</source>
        <target state="translated">`LAPB &lt;http://en.wikipedia.org/wiki/LAPB&gt;`_ and `HDLC &lt;http://en.wikipedia.org/wiki/HDLC&gt;`_ were widely used datalink layer protocols.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">35</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="36bc4f0244004224" weblate-flags="read-only">
        <source>The IANA maintains the registry of all assigned PPP protocol fields at : http://www.iana.org/assignments/ppp-numbers</source>
        <target state="translated">The IANA maintains the registry of all assigned PPP protocol fields at : http://www.iana.org/assignments/ppp-numbers</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ppp.rst</context>
          <context context-type="linenumber">37</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f02a9d72d0eaf293" weblate-flags="read-only">
        <source>Ethernet</source>
        <target state="translated">Ethernet</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">5</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4a176ad49d11bb26" weblate-flags="read-only">
        <source>Ethernet was designed in the 1970s at the Palo Alto Research Center [Metcalfe1976]_. The first prototype [#fethernethistory]_ used a coaxial cable as the shared medium and 3 Mbps of bandwidth. Ethernet was improved during the late 1970s and in the 1980s, Digital Equipment, Intel and Xerox published the first official Ethernet specification [DIX]_. This specification defines several important parameters for Ethernet networks. The first decision was to standardize the commercial Ethernet at 10 Mbps. The second decision was the duration of the `slot time`. In Ethernet, a long `slot time` enables networks to span a long distance but forces the host to use a larger minimum frame size. The compromise was a `slot time` of 51.2 microseconds, which corresponds to a minimum frame size of 64 bytes.</source>
        <target state="translated">Ethernet was designed in the 1970s at the Palo Alto Research Center [Metcalfe1976]_. The first prototype [#fethernethistory]_ used a coaxial cable as the shared medium and 3 Mbps of bandwidth. Ethernet was improved during the late 1970s and in the 1980s, Digital Equipment, Intel and Xerox published the first official Ethernet specification [DIX]_. This specification defines several important parameters for Ethernet networks. The first decision was to standardize the commercial Ethernet at 10 Mbps. The second decision was the duration of the `slot time`. In Ethernet, a long `slot time` enables networks to span a long distance but forces the host to use a larger minimum frame size. The compromise was a `slot time` of 51.2 microseconds, which corresponds to a minimum frame size of 64 bytes.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">12</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e4daa5770d5aeb00" weblate-flags="read-only">
        <source>The third decision was the frame format. The experimental 3 Mbps Ethernet network built at Xerox used short frames containing 8 bit source and destination addresses fields, a 16 bit type indication, up to 554 bytes of payload and a 16 bit CRC. Using 8 bit addresses was suitable for an experimental network, but it was clearly too small for commercial deployments. Although the initial Ethernet specification [DIX]_ only allowed up to 1024 hosts on an Ethernet network, it also recommended three important changes compared to the networking technologies that were available at that time. The first change was to require each host attached to an Ethernet network to have a globally unique datalink layer address. Until then, datalink layer addresses were manually configured on each host. [DP1981]_ went against that state of the art and noted "`Suitable installation-specific administrative procedures are also needed for assigning numbers to hosts on a network. If a host is moved from one network to another it may be necessary to change its host  number if its former number is in use on the new network. This is easier said than done, as each network must have an administrator who must record the continuously changing state of the system (often on a piece of paper tacked to the wall !). It is anticipated that in future office environments, hosts locations will change as often as telephones are changed in present-day offices.`" The second change introduced by Ethernet was to encode each address as a 48 bits field [DP1981]_. 48 bit addresses were huge compared to the networking technologies available in the 1980s, but the huge address space had several advantages [DP1981]_ including the ability to allocate large blocks of addresses to manufacturers. Eventually, other LAN technologies opted for 48 bits addresses as well [IEEE802]_ . The third change introduced by Ethernet was the definition of `broadcast` and `multicast` addresses. The need for `multicast` Ethernet was foreseen in [DP1981]_ and thanks to the size of the addressing space it was possible to reserve a large block of multicast addresses for each manufacturer.</source>
        <target state="translated">The third decision was the frame format. The experimental 3 Mbps Ethernet network built at Xerox used short frames containing 8 bit source and destination addresses fields, a 16 bit type indication, up to 554 bytes of payload and a 16 bit CRC. Using 8 bit addresses was suitable for an experimental network, but it was clearly too small for commercial deployments. Although the initial Ethernet specification [DIX]_ only allowed up to 1024 hosts on an Ethernet network, it also recommended three important changes compared to the networking technologies that were available at that time. The first change was to require each host attached to an Ethernet network to have a globally unique datalink layer address. Until then, datalink layer addresses were manually configured on each host. [DP1981]_ went against that state of the art and noted "`Suitable installation-specific administrative procedures are also needed for assigning numbers to hosts on a network. If a host is moved from one network to another it may be necessary to change its host  number if its former number is in use on the new network. This is easier said than done, as each network must have an administrator who must record the continuously changing state of the system (often on a piece of paper tacked to the wall !). It is anticipated that in future office environments, hosts locations will change as often as telephones are changed in present-day offices.`" The second change introduced by Ethernet was to encode each address as a 48 bits field [DP1981]_. 48 bit addresses were huge compared to the networking technologies available in the 1980s, but the huge address space had several advantages [DP1981]_ including the ability to allocate large blocks of addresses to manufacturers. Eventually, other LAN technologies opted for 48 bits addresses as well [IEEE802]_ . The third change introduced by Ethernet was the definition of `broadcast` and `multicast` addresses. The need for `multicast` Ethernet was foreseen in [DP1981]_ and thanks to the size of the addressing space it was possible to reserve a large block of multicast addresses for each manufacturer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">14</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="08dcaf4f042959e7" weblate-flags="read-only">
        <source>The datalink layer addresses used in Ethernet networks are often called MAC addresses. They are structured as shown in the figure below. The first bit of the address indicates whether the address identifies a network adapter or a multicast group. The upper 24 bits are used to encode an Organization Unique Identifier (OUI). This OUI identifies a block of addresses that has been allocated by the secretariat [#foui]_ that is responsible for the uniqueness of Ethernet addresses to a manufacturer. Once a manufacturer has received an OUI, it can build and sell products with one of the 16 million addresses in this block.</source>
        <target state="translated">The datalink layer addresses used in Ethernet networks are often called MAC addresses. They are structured as shown in the figure below. The first bit of the address indicates whether the address identifies a network adapter or a multicast group. The upper 24 bits are used to encode an Organization Unique Identifier (OUI). This OUI identifies a block of addresses that has been allocated by the secretariat [#foui]_ that is responsible for the uniqueness of Ethernet addresses to a manufacturer. Once a manufacturer has received an OUI, it can build and sell products with one of the 16 million addresses in this block.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">19</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9b095b310530e1cf" weblate-flags="read-only">
        <source>The original 10 Mbps Ethernet specification [DIX]_ defined a simple frame format where each frame is composed of five fields. The Ethernet frame starts with a preamble (not shown in the figure below) that is used by the physical layer of the receiver to synchronize its clock with the sender's clock. The first field of the frame is the destination address. As this address is placed at the beginning of the frame, an Ethernet interface can quickly verify whether it is the frame recipient and if not, cancel the processing of the arriving frame. The second field is the source address. While the destination address can be either a unicast or a multicast/broadcast address, the source address must always be a unicast address. The third field is a 16 bits integer that indicates which type of network layer packet is carried inside the frame. This field is often called the `EtherType`. Frequently used `EtherType` values [#fethertype]_ include `0x0800` for IPv4, `0x86DD` for IPv6 [#fipv6ether]_ and `0x806` for the Address Resolution Protocol (ARP).</source>
        <target state="translated">The original 10 Mbps Ethernet specification [DIX]_ defined a simple frame format where each frame is composed of five fields. The Ethernet frame starts with a preamble (not shown in the figure below) that is used by the physical layer of the receiver to synchronize its clock with the sender's clock. The first field of the frame is the destination address. As this address is placed at the beginning of the frame, an Ethernet interface can quickly verify whether it is the frame recipient and if not, cancel the processing of the arriving frame. The second field is the source address. While the destination address can be either a unicast or a multicast/broadcast address, the source address must always be a unicast address. The third field is a 16 bits integer that indicates which type of network layer packet is carried inside the frame. This field is often called the `EtherType`. Frequently used `EtherType` values [#fethertype]_ include `0x0800` for IPv4, `0x86DD` for IPv6 [#fipv6ether]_ and `0x806` for the Address Resolution Protocol (ARP).</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">47</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2248e4969c1de1af" weblate-flags="read-only">
        <source>The fourth part of the Ethernet frame is the payload. The minimum length of the payload is 46 bytes to ensure a minimum frame size, including the header of 512 bits. The Ethernet payload cannot be longer than 1500 bytes. This size was found reasonable when the first Ethernet specification was written. At that time, Xerox had been using its experimental 3 Mbps Ethernet that offered 554 bytes of payload and :rfc:`1122` required a minimum MTU of 572 bytes for IPv4. 1500 bytes was large enough to support these needs without forcing the network adapters to contain overly large memories. Furthermore, simulations and measurement studies performed in Ethernet networks revealed that CSMA/CD was able to achieve a very high utilization. This is illustrated in the figure below based on [SH1980]_, which shows the channel utilization achieved in Ethernet networks containing different numbers of hosts that are sending frames of different sizes.</source>
        <target state="translated">The fourth part of the Ethernet frame is the payload. The minimum length of the payload is 46 bytes to ensure a minimum frame size, including the header of 512 bits. The Ethernet payload cannot be longer than 1500 bytes. This size was found reasonable when the first Ethernet specification was written. At that time, Xerox had been using its experimental 3 Mbps Ethernet that offered 554 bytes of payload and :rfc:`1122` required a minimum MTU of 572 bytes for IPv4. 1500 bytes was large enough to support these needs without forcing the network adapters to contain overly large memories. Furthermore, simulations and measurement studies performed in Ethernet networks revealed that CSMA/CD was able to achieve a very high utilization. This is illustrated in the figure below based on [SH1980]_, which shows the channel utilization achieved in Ethernet networks containing different numbers of hosts that are sending frames of different sizes.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">49</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="20bb687caceb501d" weblate-flags="read-only">
        <source>Impact of the frame length on the maximum channel utilisation [SH1980]_</source>
        <target state="translated">Impact of the frame length on the maximum channel utilisation [SH1980]_</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">56</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8d79dbd470d85e13" weblate-flags="read-only">
        <source>The last field of the Ethernet frame is a 32 bit Cyclical Redundancy Check (CRC). This CRC is able to catch a much larger number of transmission errors than the Internet checksum used by IP, UDP and TCP [SGP98]_. The format of the Ethernet frame is shown below.</source>
        <target state="translated">The last field of the Ethernet frame is a 32 bit Cyclical Redundancy Check (CRC). This CRC is able to catch a much larger number of transmission errors than the Internet checksum used by IP, UDP and TCP [SGP98]_. The format of the Ethernet frame is shown below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">59</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="62c996cfca4c2e53" weblate-flags="read-only">
        <source>Ethernet DIX frame format</source>
        <target state="translated">Ethernet DIX frame format</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">68</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cfa08abbf953d418" weblate-flags="read-only">
        <source>Where should the CRC be located in a frame ?</source>
        <target state="translated">Where should the CRC be located in a frame ?</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">70</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="650b163b0d3e6190" weblate-flags="read-only">
        <source>The transport and datalink layers usually chose different strategies to place their CRCs or checksums. Transport layer protocols usually place their CRCs or checksums in the segment header. Datalink layer protocols sometimes place their CRC in the frame header, but often in a trailer at the end of the frame. This choice reflects implementation assumptions, but also influences performance :rfc:`893`. When the CRC is placed in the trailer, as in Ethernet, the datalink layer can compute it while transmitting the frame and insert it at the end of the transmission. All Ethernet interfaces use this optimization today. When the checksum is placed in the header, as in a TCP segment, it is impossible for the network interface to compute it while transmitting the segment. Some network interfaces provide hardware assistance to compute the TCP checksum, but this is more complex than if the TCP checksum were placed in the trailer [#ftso]_.</source>
        <target state="translated">The transport and datalink layers usually chose different strategies to place their CRCs or checksums. Transport layer protocols usually place their CRCs or checksums in the segment header. Datalink layer protocols sometimes place their CRC in the frame header, but often in a trailer at the end of the frame. This choice reflects implementation assumptions, but also influences performance :rfc:`893`. When the CRC is placed in the trailer, as in Ethernet, the datalink layer can compute it while transmitting the frame and insert it at the end of the transmission. All Ethernet interfaces use this optimization today. When the checksum is placed in the header, as in a TCP segment, it is impossible for the network interface to compute it while transmitting the segment. Some network interfaces provide hardware assistance to compute the TCP checksum, but this is more complex than if the TCP checksum were placed in the trailer [#ftso]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">72</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="87d8ac8e2e182e0e" weblate-flags="read-only">
        <source>The Ethernet frame format shown above is specified in [DIX]_. This is the format used to send both IPv4 :rfc:`894` and IPv6 packets :rfc:`2464`. After the publication of [DIX]_, the Institute of Electrical and Electronic Engineers (IEEE) began to standardize several Local Area Network technologies. IEEE worked on several LAN technologies, starting with Ethernet, Token Ring and Token Bus. These three technologies were completely different, but they all agreed to use the 48 bits MAC addresses specified initially for Ethernet [IEEE802]_ . While developing its Ethernet standard [IEEE802.3]_, the IEEE 802.3 working group was confronted with a problem. Ethernet mandated a minimum payload size of 46 bytes, while some companies were looking for a LAN technology that could transparently transport short frames containing only a few bytes of payload. Such a frame can be sent by an Ethernet host by padding it to ensure that the payload is at least 46 bytes long. However since the Ethernet header [DIX]_ does not contain a length field, it is impossible for the receiver to determine how many useful bytes were placed inside the payload field. To solve this problem, the IEEE decided to replace the `Type` field of the Ethernet [DIX]_ header with a length field [#ftypelen]_. This `Length` field contains the number of useful bytes in the frame payload. The payload must still contain at least 46 bytes, but padding bytes are added by the sender and removed by the receiver. In order to add the `Length` field without significantly changing the frame format, IEEE had to remove the `Type` field. Without this field, it is impossible for a receiving host to identify the type of network layer packet inside a received frame. To solve this new problem, IEEE developed a completely new sublayer called the Logical Link Control [IEEE802.2]_. Several protocols were defined in this sublayer. One of them provided a slightly different version of the `Type` field of the original Ethernet frame format. Another contained acknowledgments and retransmissions to provide a reliable service... In practice, [IEEE802.2]_ is never used to support IP in Ethernet networks. The figure below shows the official [IEEE802.3]_ frame format.</source>
        <target state="translated">The Ethernet frame format shown above is specified in [DIX]_. This is the format used to send both IPv4 :rfc:`894` and IPv6 packets :rfc:`2464`. After the publication of [DIX]_, the Institute of Electrical and Electronic Engineers (IEEE) began to standardize several Local Area Network technologies. IEEE worked on several LAN technologies, starting with Ethernet, Token Ring and Token Bus. These three technologies were completely different, but they all agreed to use the 48 bits MAC addresses specified initially for Ethernet [IEEE802]_ . While developing its Ethernet standard [IEEE802.3]_, the IEEE 802.3 working group was confronted with a problem. Ethernet mandated a minimum payload size of 46 bytes, while some companies were looking for a LAN technology that could transparently transport short frames containing only a few bytes of payload. Such a frame can be sent by an Ethernet host by padding it to ensure that the payload is at least 46 bytes long. However since the Ethernet header [DIX]_ does not contain a length field, it is impossible for the receiver to determine how many useful bytes were placed inside the payload field. To solve this problem, the IEEE decided to replace the `Type` field of the Ethernet [DIX]_ header with a length field [#ftypelen]_. This `Length` field contains the number of useful bytes in the frame payload. The payload must still contain at least 46 bytes, but padding bytes are added by the sender and removed by the receiver. In order to add the `Length` field without significantly changing the frame format, IEEE had to remove the `Type` field. Without this field, it is impossible for a receiving host to identify the type of network layer packet inside a received frame. To solve this new problem, IEEE developed a completely new sublayer called the Logical Link Control [IEEE802.2]_. Several protocols were defined in this sublayer. One of them provided a slightly different version of the `Type` field of the original Ethernet frame format. Another contained acknowledgments and retransmissions to provide a reliable service... In practice, [IEEE802.2]_ is never used to support IP in Ethernet networks. The figure below shows the official [IEEE802.3]_ frame format.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">81</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b5d1c638d8dc9dd8" weblate-flags="read-only">
        <source>Ethernet 802.3 frame format</source>
        <target state="translated">Ethernet 802.3 frame format</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">89</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0edbfe149ba5464f" weblate-flags="read-only">
        <source>What is the Ethernet service ?</source>
        <target state="translated">What is the Ethernet service ?</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">92</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3a2f2d29c2439b14" weblate-flags="read-only">
        <source>An Ethernet network provides an unreliable connectionless service. It supports three different transmission modes : `unicast`, `multicast` and `broadcast`. While the Ethernet service is unreliable in theory, a good Ethernet network should, in practice, provide a service that:</source>
        <target state="translated">An Ethernet network provides an unreliable connectionless service. It supports three different transmission modes : `unicast`, `multicast` and `broadcast`. While the Ethernet service is unreliable in theory, a good Ethernet network should, in practice, provide a service that:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">94</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="03721b1b1ca83519" weblate-flags="read-only">
        <source>delivers frames to their destination with a very high probability of successful delivery</source>
        <target state="translated">delivers frames to their destination with a very high probability of successful delivery</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">96</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7f2d9d339b07d684" weblate-flags="read-only">
        <source>does not reorder the transmitted frames</source>
        <target state="translated">does not reorder the transmitted frames</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">97</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8f60210c8ec09078" weblate-flags="read-only">
        <source>The first property is a consequence of the utilization of CSMA/CD. The second property is a consequence of the physical organization of the Ethernet network as a shared bus. These two properties are important and all revisions to the Ethernet technology have preserved them.</source>
        <target state="translated">The first property is a consequence of the utilization of CSMA/CD. The second property is a consequence of the physical organization of the Ethernet network as a shared bus. These two properties are important and all revisions to the Ethernet technology have preserved them.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">99</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ce0c0af55023d900" weblate-flags="read-only">
        <source>Several physical layers have been defined for Ethernet networks. The first physical layer, usually called 10Base5, provided 10 Mbps over a thick coaxial cable. The characteristics of the cable and the transceivers that were used then enabled the utilization of 500 meter long segments. A 10Base5 network can also include repeaters between segments.</source>
        <target state="translated">Several physical layers have been defined for Ethernet networks. The first physical layer, usually called 10Base5, provided 10 Mbps over a thick coaxial cable. The characteristics of the cable and the transceivers that were used then enabled the utilization of 500 meter long segments. A 10Base5 network can also include repeaters between segments.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">109</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="66ae619df15e6e6c" weblate-flags="read-only">
        <source>The second physical layer was 10Base2. This physical layer used a thin coaxial cable that was easier to install than the 10Base5 cable, but could not be longer than 185 meters. A 10BaseF physical layer was also defined to transport Ethernet over point-to-point optical links. The major change to the physical layer was the support of twisted pairs in the 10BaseT specification. Twisted pair cables are traditionally used to support the telephone service in office buildings. Most office buildings today are equipped with structured cabling. Several twisted pair cables are installed between any room and a central telecom closet per building or per floor in large buildings. These telecom closets act as concentration points for the telephone service but also for LANs.</source>
        <target state="translated">The second physical layer was 10Base2. This physical layer used a thin coaxial cable that was easier to install than the 10Base5 cable, but could not be longer than 185 meters. A 10BaseF physical layer was also defined to transport Ethernet over point-to-point optical links. The major change to the physical layer was the support of twisted pairs in the 10BaseT specification. Twisted pair cables are traditionally used to support the telephone service in office buildings. Most office buildings today are equipped with structured cabling. Several twisted pair cables are installed between any room and a central telecom closet per building or per floor in large buildings. These telecom closets act as concentration points for the telephone service but also for LANs.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">113</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="96a0d261f0400112" weblate-flags="read-only">
        <source>The introduction of the twisted pairs led to two major changes to Ethernet. The first change concerns the physical topology of the network. 10Base2 and 10Base5 networks are shared buses, the coaxial cable typically passes through each room that contains a connected computer. A 10BaseT network is a star-shaped network. All the devices connected to the network are attached to a twisted pair cable that ends in the telecom closet. From a maintenance perspective, this is a major improvement. The cable is a weak point in 10Base2 and 10Base5 networks. Any physical damage on the cable broke the entire network and when such a failure occurred, the network administrator had to manually check the entire cable to detect where it was damaged. With 10BaseT, when one twisted pair is damaged, only the device connected to this twisted pair is affected and this does not affect the other devices. The second major change introduced by 10BaseT was that is was impossible to build a 10BaseT network by simply connecting all the twisted pairs together. All the twisted pairs must be connected to a relay that operates in the physical layer. This relay is called an `Ethernet hub`. A `hub` is thus a physical layer relay that receives an electrical signal on one of its interfaces, regenerates the signal and transmits it over all its other interfaces. Some `hubs` are also able to convert the electrical signal from one physical layer to another (e.g. 10BaseT to 10Base2 conversion).</source>
        <target state="translated">The introduction of the twisted pairs led to two major changes to Ethernet. The first change concerns the physical topology of the network. 10Base2 and 10Base5 networks are shared buses, the coaxial cable typically passes through each room that contains a connected computer. A 10BaseT network is a star-shaped network. All the devices connected to the network are attached to a twisted pair cable that ends in the telecom closet. From a maintenance perspective, this is a major improvement. The cable is a weak point in 10Base2 and 10Base5 networks. Any physical damage on the cable broke the entire network and when such a failure occurred, the network administrator had to manually check the entire cable to detect where it was damaged. With 10BaseT, when one twisted pair is damaged, only the device connected to this twisted pair is affected and this does not affect the other devices. The second major change introduced by 10BaseT was that is was impossible to build a 10BaseT network by simply connecting all the twisted pairs together. All the twisted pairs must be connected to a relay that operates in the physical layer. This relay is called an `Ethernet hub`. A `hub` is thus a physical layer relay that receives an electrical signal on one of its interfaces, regenerates the signal and transmits it over all its other interfaces. Some `hubs` are also able to convert the electrical signal from one physical layer to another (e.g. 10BaseT to 10Base2 conversion).</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">118</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1c79e00e0407661e" weblate-flags="read-only">
        <source>Computers can directly be attached to Ethernet hubs. Ethernet hubs themselves can be attached to other Ethernet hubs to build a larger network. However, some important guidelines must be followed when building a complex network with hubs. First, the network topology must be a tree. As hubs are relays in the physical layer, adding a link between `Hub2` and `Hub3` in the network below would create an electrical shortcut that would completely disrupt the network. This implies that there cannot be any redundancy in a hub-based network. A failure of a hub or of a link between two hubs would partition the network into two isolated networks. Second, as hubs are relays in the physical layer, collisions can happen and must be handled by CSMA/CD as in a 10Base5 network. This implies that the maximum delay between any pair of devices in the network cannot be longer than the 51.2 microseconds `slot time`. If the delay is longer, collisions between short frames may not be correctly detected. This constraint limits the geographical spread of 10BaseT networks containing hubs.</source>
        <target state="translated">Computers can directly be attached to Ethernet hubs. Ethernet hubs themselves can be attached to other Ethernet hubs to build a larger network. However, some important guidelines must be followed when building a complex network with hubs. First, the network topology must be a tree. As hubs are relays in the physical layer, adding a link between `Hub2` and `Hub3` in the network below would create an electrical shortcut that would completely disrupt the network. This implies that there cannot be any redundancy in a hub-based network. A failure of a hub or of a link between two hubs would partition the network into two isolated networks. Second, as hubs are relays in the physical layer, collisions can happen and must be handled by CSMA/CD as in a 10Base5 network. This implies that the maximum delay between any pair of devices in the network cannot be longer than the 51.2 microseconds `slot time`. If the delay is longer, collisions between short frames may not be correctly detected. This constraint limits the geographical spread of 10BaseT networks containing hubs.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">149</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9a0777a908af3c21" weblate-flags="read-only">
        <source>A hierarchical Ethernet network composed of hubs</source>
        <target state="translated">A hierarchical Ethernet network composed of hubs</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">156</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="da3a1416e6855838" weblate-flags="read-only">
        <source>In the late 1980s, 10 Mbps became too slow for some applications and network manufacturers developed several LAN technologies that offered higher bandwidth, such as the 100 Mbps FDDI LAN that used optical fibers. As the development of 10Base5, 10Base2 and 10BaseT had shown that Ethernet could be adapted to different physical layers, several manufacturers started to work on 100 Mbps Ethernet and convinced IEEE to standardize this new technology that was initially called `Fast Ethernet`. `Fast Ethernet` was designed under two constraints. First, `Fast Ethernet` had to support twisted pairs. Although it was easier from a physical layer perspective to support higher bandwidth on coaxial cables than on twisted pairs, coaxial cables were a nightmare from deployment and maintenance perspectives. Second, `Fast Ethernet` had to be perfectly compatible with the existing 10 Mbps Ethernet to allow `Fast Ethernet` technology to be used initially as a backbone technology to interconnect 10 Mbps Ethernet networks. This forced `Fast Ethernet` to use exactly the same frame format as 10 Mbps Ethernet. This implied that the minimum `Fast Ethernet` frame size remained at 512 bits. To preserve CSMA/CD with this minimum frame size and 100 Mbps instead of 10 Mbps, the duration of the `slot time` was decreased to 5.12 microseconds.</source>
        <target state="translated">In the late 1980s, 10 Mbps became too slow for some applications and network manufacturers developed several LAN technologies that offered higher bandwidth, such as the 100 Mbps FDDI LAN that used optical fibers. As the development of 10Base5, 10Base2 and 10BaseT had shown that Ethernet could be adapted to different physical layers, several manufacturers started to work on 100 Mbps Ethernet and convinced IEEE to standardize this new technology that was initially called `Fast Ethernet`. `Fast Ethernet` was designed under two constraints. First, `Fast Ethernet` had to support twisted pairs. Although it was easier from a physical layer perspective to support higher bandwidth on coaxial cables than on twisted pairs, coaxial cables were a nightmare from deployment and maintenance perspectives. Second, `Fast Ethernet` had to be perfectly compatible with the existing 10 Mbps Ethernet to allow `Fast Ethernet` technology to be used initially as a backbone technology to interconnect 10 Mbps Ethernet networks. This forced `Fast Ethernet` to use exactly the same frame format as 10 Mbps Ethernet. This implied that the minimum `Fast Ethernet` frame size remained at 512 bits. To preserve CSMA/CD with this minimum frame size and 100 Mbps instead of 10 Mbps, the duration of the `slot time` was decreased to 5.12 microseconds.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">162</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="50802e6886e0530d" weblate-flags="read-only">
        <source>The evolution of Ethernet did not stop. In 1998, the IEEE published a first standard to provide Gigabit Ethernet over optical fibers. Several other types of physical layers were added afterwards. The `10 Gigabit Ethernet &lt;http://en.wikipedia.org/wiki/10_gigabit_Ethernet&gt;`_ standard appeared in 2002. Work is ongoing to develop `standards &lt;http://www.ieee802.org/3/ba/public/index.html&gt;`_ for 40 Gigabit and 100 Gigabit Ethernet and some are thinking about `Terabit Ethernet &lt;http://www.networkworld.com/news/2009/042009-terabit-ethernet.html&gt;`_. The table below lists the main Ethernet standards. A more detailed list may be found at http://en.wikipedia.org/wiki/Ethernet_physical_layer.</source>
        <target state="translated">The evolution of Ethernet did not stop. In 1998, the IEEE published a first standard to provide Gigabit Ethernet over optical fibers. Several other types of physical layers were added afterwards. The `10 Gigabit Ethernet &lt;http://en.wikipedia.org/wiki/10_gigabit_Ethernet&gt;`_ standard appeared in 2002. Work is ongoing to develop `standards &lt;http://www.ieee802.org/3/ba/public/index.html&gt;`_ for 40 Gigabit and 100 Gigabit Ethernet and some are thinking about `Terabit Ethernet &lt;http://www.networkworld.com/news/2009/042009-terabit-ethernet.html&gt;`_. The table below lists the main Ethernet standards. A more detailed list may be found at http://en.wikipedia.org/wiki/Ethernet_physical_layer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">164</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="097dd7c16ffba21b" weblate-flags="read-only">
        <source>Standard</source>
        <target state="translated">Standard</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">169</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">19</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2aff35f1f38a6c15" weblate-flags="read-only">
        <source>Comments</source>
        <target state="translated">Comments</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">169</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6605d5240abcd040" weblate-flags="read-only">
        <source>10Base5</source>
        <target state="translated">10Base5</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">171</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d6924e19a9b76d05" weblate-flags="read-only">
        <source>Thick coaxial cable, 500m</source>
        <target state="translated">Thick coaxial cable, 500m</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">171</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6446be49e0a71cb8" weblate-flags="read-only">
        <source>10Base2</source>
        <target state="translated">10Base2</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">172</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6ea55c053c2f4c44" weblate-flags="read-only">
        <source>Thin coaxial cable, 185m</source>
        <target state="translated">Thin coaxial cable, 185m</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">172</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3996c9ba85c6cc6e" weblate-flags="read-only">
        <source>10BaseT</source>
        <target state="translated">10BaseT</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">173</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="39bafb95f660e369" weblate-flags="read-only">
        <source>Two pairs of category 3+ UTP</source>
        <target state="translated">Two pairs of category 3+ UTP</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">173</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a093677f9b287581" weblate-flags="read-only">
        <source>10Base-F</source>
        <target state="translated">10Base-F</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">174</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="34ac46a5a48c7e9f" weblate-flags="read-only">
        <source>10 Mb/s over optical fiber</source>
        <target state="translated">10 Mb/s over optical fiber</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">174</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="00631329edd5d81c" weblate-flags="read-only">
        <source>100Base-Tx</source>
        <target state="translated">100Base-Tx</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">175</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d9141e07f1639859" weblate-flags="read-only">
        <source>Category 5 UTP or STP, 100 m maximum</source>
        <target state="translated">Category 5 UTP or STP, 100 m maximum</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">175</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b45a088ee98e5c39" weblate-flags="read-only">
        <source>100Base-FX</source>
        <target state="translated">100Base-FX</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">176</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1dcfbfae6ac9e5fe" weblate-flags="read-only">
        <source>Two multi-mode optical fiber, 2 km maximum</source>
        <target state="translated">Two multi-mode optical fiber, 2 km maximum</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">176</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9a62487f1d241ef3" weblate-flags="read-only">
        <source>1000Base-CX</source>
        <target state="translated">1000Base-CX</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">177</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1175145e3019c75b" weblate-flags="read-only">
        <source>Two pairs shielded twisted pair, 25m maximum</source>
        <target state="translated">Two pairs shielded twisted pair, 25m maximum</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">177</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="22fbe3c851e3544d" weblate-flags="read-only">
        <source>1000Base-SX</source>
        <target state="translated">1000Base-SX</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">178</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2fcd8ee022609951" weblate-flags="read-only">
        <source>Two multi-mode or single mode optical fibers with lasers</source>
        <target state="translated">Two multi-mode or single mode optical fibers with lasers</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">178</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ebc86d169ab4a418" weblate-flags="read-only">
        <source>10 Gbps</source>
        <target state="translated">10 Gbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">179</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">358</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ee92ad6e128b2eac" weblate-flags="read-only">
        <source>Optical fiber but also Category 6 UTP</source>
        <target state="translated">Optical fiber but also Category 6 UTP</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">179</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="dfa5e197b5891042" weblate-flags="read-only">
        <source>40-100 Gbps</source>
        <target state="translated">40-100 Gbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">180</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3164a784c1a547a0" weblate-flags="read-only">
        <source>Optical fiber (experiences are performed with copper)</source>
        <target state="translated">Optical fiber (experiences are performed with copper)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">180</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="49241d2d9061e394" weblate-flags="read-only">
        <source>Additional information about the history of the Ethernet technology may be found at http://ethernethistory.typepad.com/</source>
        <target state="translated">Additional information about the history of the Ethernet technology may be found at http://ethernethistory.typepad.com/</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">193</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5286d333f8ae0159" weblate-flags="read-only">
        <source>Initially, the OUIs were allocated by Xerox [DP1981]_. However, once Ethernet became an IEEE and later an ISO standard, the allocation of the OUIs moved to IEEE. The list of all OUI allocations may be found at http://standards.ieee.org/regauth/oui/index.shtml</source>
        <target state="translated">Initially, the OUIs were allocated by Xerox [DP1981]_. However, once Ethernet became an IEEE and later an ISO standard, the allocation of the OUIs moved to IEEE. The list of all OUI allocations may be found at http://standards.ieee.org/regauth/oui/index.shtml</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">195</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7c6e78b5bc1fe576" weblate-flags="read-only">
        <source>The official list of all assigned Ethernet type values is available from http://standards.ieee.org/regauth/ethertype/eth.txt</source>
        <target state="translated">The official list of all assigned Ethernet type values is available from http://standards.ieee.org/regauth/ethertype/eth.txt</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">197</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="69a920a1ec224c50" weblate-flags="read-only">
        <source>The attentive reader may question the need for different `EtherTypes` for IPv4 and IPv6 while the IP header already contains a version field that can be used to distinguish between IPv4 and IPv6 packets. Theoretically, IPv4 and IPv6 could have used the same `EtherType`. Unfortunately, developers of the early IPv6 implementations found that some devices did not check the version field of the IPv4 packets that they received and parsed frames whose `EtherType` was set to `0x0800` as IPv4 packets. Sending IPv6 packets to such devices would have caused disruptions. To avoid this problem, the IETF decided to apply for a distinct `EtherType` value for IPv6. Such a choice is now mandated by :rfc:`6274` (section 3.1), although we can find a funny counter-example in :rfc:`6214`.</source>
        <target state="translated">The attentive reader may question the need for different `EtherTypes` for IPv4 and IPv6 while the IP header already contains a version field that can be used to distinguish between IPv4 and IPv6 packets. Theoretically, IPv4 and IPv6 could have used the same `EtherType`. Unfortunately, developers of the early IPv6 implementations found that some devices did not check the version field of the IPv4 packets that they received and parsed frames whose `EtherType` was set to `0x0800` as IPv4 packets. Sending IPv6 packets to such devices would have caused disruptions. To avoid this problem, the IETF decided to apply for a distinct `EtherType` value for IPv6. Such a choice is now mandated by :rfc:`6274` (section 3.1), although we can find a funny counter-example in :rfc:`6214`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">199</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fc01f88318975637" weblate-flags="read-only">
        <source>These network interfaces compute the TCP checksum while a segment is transferred from the host memory to the network interface [SH2004]_.</source>
        <target state="translated">These network interfaces compute the TCP checksum while a segment is transferred from the host memory to the network interface [SH2004]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">201</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="78b6e89a70e64bd3" weblate-flags="read-only">
        <source>Fortunately, IEEE was able to define the [IEEE802.3]_ frame format while maintaining backward compatibility with the Ethernet [DIX]_ frame format. The trick was to only assign values above 1500 as `EtherType` values. When a host receives a frame, it can determine whether the frame's format by checking its `EtherType/Length` field. A value lower smaller than `1501` is clearly a length indicator and thus an [IEEE802.3]_ frame. A value larger than `1501` can only be type and thus a [DIX]_ frame.</source>
        <target state="translated">Fortunately, IEEE was able to define the [IEEE802.3]_ frame format while maintaining backward compatibility with the Ethernet [DIX]_ frame format. The trick was to only assign values above 1500 as `EtherType` values. When a host receives a frame, it can determine whether the frame's format by checking its `EtherType/Length` field. A value lower smaller than `1501` is clearly a length indicator and thus an [IEEE802.3]_ frame. A value larger than `1501` can only be type and thus a [DIX]_ frame.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">203</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a8a3900354faec28" weblate-flags="read-only">
        <source>Ethernet Switches</source>
        <target state="translated">Ethernet Switches</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">207</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="71a9a9cdb9012862" weblate-flags="read-only">
        <source>Increasing the physical layer bandwidth as in `Fast Ethernet` was only one of the solutions to improve the performance of Ethernet LANs. A second solution was to replace the hubs with more intelligent devices. As `Ethernet hubs` operate in the physical layer, they can only regenerate the electrical signal to extend the geographical reach of the network. From a performance perspective, it would be more interesting to have devices that operate in the datalink layer and can analyze the destination address of each frame and forward the frames selectively on the link that leads to the destination. Such devices are usually called `Ethernet switches` [#fbridges]_.  An `Ethernet switch` is a relay that operates in the datalink layer as is illustrated in the figure below.</source>
        <target state="translated">Increasing the physical layer bandwidth as in `Fast Ethernet` was only one of the solutions to improve the performance of Ethernet LANs. A second solution was to replace the hubs with more intelligent devices. As `Ethernet hubs` operate in the physical layer, they can only regenerate the electrical signal to extend the geographical reach of the network. From a performance perspective, it would be more interesting to have devices that operate in the datalink layer and can analyze the destination address of each frame and forward the frames selectively on the link that leads to the destination. Such devices are usually called `Ethernet switches` [#fbridges]_.  An `Ethernet switch` is a relay that operates in the datalink layer as is illustrated in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">211</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cf73564bfd654907" weblate-flags="read-only">
        <source>An `Ethernet switch` understands the format of the Ethernet frames and can selectively forward frames over each interface. For this, each `Ethernet switch` maintains a `MAC address table`. This table contains, for each MAC address known by the switch, the identifier of the switch's port over which a frame sent towards this address must be forwarded to reach its destination. This is illustrated below with the `MAC address table` of the bottom switch. When the switch receives a frame destined to address `B`, it forwards the frame on its South port. If it receives a frame destined to address `D`, it forwards it only on its North port.</source>
        <target state="translated">An `Ethernet switch` understands the format of the Ethernet frames and can selectively forward frames over each interface. For this, each `Ethernet switch` maintains a `MAC address table`. This table contains, for each MAC address known by the switch, the identifier of the switch's port over which a frame sent towards this address must be forwarded to reach its destination. This is illustrated below with the `MAC address table` of the bottom switch. When the switch receives a frame destined to address `B`, it forwards the frame on its South port. If it receives a frame destined to address `D`, it forwards it only on its North port.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">248</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1642bd1dfe1576fb" weblate-flags="read-only">
        <source>Operation of Ethernet switches</source>
        <target state="translated">Operation of Ethernet switches</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">255</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4b28c5ad369b17d1" weblate-flags="read-only">
        <source>One of the selling points of Ethernet networks is that, thanks to the utilization of 48 bits MAC addresses, an Ethernet LAN is plug and play at the datalink layer. When two hosts are attached to the same Ethernet segment or hub, they can immediately exchange Ethernet frames without requiring any configuration. It is important to retain this plug and play capability for Ethernet switches as well. This implies that Ethernet switches must be able to build their MAC address table automatically without requiring any manual configuration. This automatic configuration is performed by the `MAC address learning` algorithm that runs on each Ethernet switch. This algorithm extracts the source address of the received frames and remembers the port over which a frame from each source Ethernet address has been received. This information is inserted into the MAC address table that the switch uses to forward frames. This allows the switch to automatically learn the ports that it can use to reach each destination address, provided that this host has previously sent at least one frame. This is not a problem since most upper layer protocols use acknowledgments at some layer and thus even an Ethernet printer sends Ethernet frames as well.</source>
        <target state="translated">One of the selling points of Ethernet networks is that, thanks to the utilization of 48 bits MAC addresses, an Ethernet LAN is plug and play at the datalink layer. When two hosts are attached to the same Ethernet segment or hub, they can immediately exchange Ethernet frames without requiring any configuration. It is important to retain this plug and play capability for Ethernet switches as well. This implies that Ethernet switches must be able to build their MAC address table automatically without requiring any manual configuration. This automatic configuration is performed by the `MAC address learning` algorithm that runs on each Ethernet switch. This algorithm extracts the source address of the received frames and remembers the port over which a frame from each source Ethernet address has been received. This information is inserted into the MAC address table that the switch uses to forward frames. This allows the switch to automatically learn the ports that it can use to reach each destination address, provided that this host has previously sent at least one frame. This is not a problem since most upper layer protocols use acknowledgments at some layer and thus even an Ethernet printer sends Ethernet frames as well.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">261</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="09ae78e43c0161a1" weblate-flags="read-only">
        <source>The pseudo-code below details how an Ethernet switch forwards Ethernet frames. It first updates its `MAC address table` with the source address of the frame. The `MAC address table` used by some switches also contains a timestamp that is updated each time a frame is received from each known source address. This timestamp is used to remove from the `MAC address table` entries that have not been active during the last `n` minutes. This limits the growth of the `MAC address table`, but also allows hosts to move from one port to another. The switch uses its `MAC address table` to forward the received unicast frame. If there is an entry for the frame's destination address in the `MAC address table`, the frame is forwarded selectively on the port listed in this entry. Otherwise, the switch does not know how to reach the destination address and it must forward the frame on all its ports except the port from which the frame has been received. This ensures that the frame will reach its destination, at the expense of some unnecessary transmissions. These unnecessary transmissions will only last until the destination has sent its first frame. Multicast and Broadcast frames are also forwarded in a similar way.</source>
        <target state="translated">The pseudo-code below details how an Ethernet switch forwards Ethernet frames. It first updates its `MAC address table` with the source address of the frame. The `MAC address table` used by some switches also contains a timestamp that is updated each time a frame is received from each known source address. This timestamp is used to remove from the `MAC address table` entries that have not been active during the last `n` minutes. This limits the growth of the `MAC address table`, but also allows hosts to move from one port to another. The switch uses its `MAC address table` to forward the received unicast frame. If there is an entry for the frame's destination address in the `MAC address table`, the frame is forwarded selectively on the port listed in this entry. Otherwise, the switch does not know how to reach the destination address and it must forward the frame on all its ports except the port from which the frame has been received. This ensures that the frame will reach its destination, at the expense of some unnecessary transmissions. These unnecessary transmissions will only last until the destination has sent its first frame. Multicast and Broadcast frames are also forwarded in a similar way.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">263</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2cd35fa69712d469" weblate-flags="read-only">
        <source>Security issues with Ethernet hubs and switches</source>
        <target state="translated">Security issues with Ethernet hubs and switches</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">287</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e9995818298b779a" weblate-flags="read-only">
        <source>From a security perspective, Ethernet hubs have the same drawbacks as the older coaxial cable. A host attached to a hub will be able to capture all the frames exchanged between any pair of hosts attached to the same hub. Ethernet switches are much better from this perspective thanks to the selective forwarding, a host will usually only receive the frames destined to itself as well as the multicast, broadcast and unknown frames. However, this does not imply that switches are completely secure. There are, unfortunately, attacks against Ethernet switches. From a security perspective, the `MAC address table` is one of the fragile elements of an Ethernet switch. This table has a fixed size. Some low-end switches can store a few tens or a few hundreds of addresses while higher-end switches can store tens of thousands of addresses or more. From a security point of view, a limited resource can be the target of Denial of Service attacks. Unfortunately, such attacks are also possible on Ethernet switches. A malicious host could overflow the `MAC address table` of the switch by generating thousands of frames with random source addresses. Once the `MAC address table` is full, the switch needs to broadcast all the frames that it receives. At this point, an attacker will receive unicast frames that are not destined to its address. The ARP attack discussed in the previous chapter could also occur with Ethernet switches [Vyncke2007]_. Recent switches implement several types of defenses against these attacks, but they need to be carefully configured by the network administrator. See [Vyncke2007]_ for a detailed discussion on security issues with Ethernet switches.</source>
        <target state="translated">From a security perspective, Ethernet hubs have the same drawbacks as the older coaxial cable. A host attached to a hub will be able to capture all the frames exchanged between any pair of hosts attached to the same hub. Ethernet switches are much better from this perspective thanks to the selective forwarding, a host will usually only receive the frames destined to itself as well as the multicast, broadcast and unknown frames. However, this does not imply that switches are completely secure. There are, unfortunately, attacks against Ethernet switches. From a security perspective, the `MAC address table` is one of the fragile elements of an Ethernet switch. This table has a fixed size. Some low-end switches can store a few tens or a few hundreds of addresses while higher-end switches can store tens of thousands of addresses or more. From a security point of view, a limited resource can be the target of Denial of Service attacks. Unfortunately, such attacks are also possible on Ethernet switches. A malicious host could overflow the `MAC address table` of the switch by generating thousands of frames with random source addresses. Once the `MAC address table` is full, the switch needs to broadcast all the frames that it receives. At this point, an attacker will receive unicast frames that are not destined to its address. The ARP attack discussed in the previous chapter could also occur with Ethernet switches [Vyncke2007]_. Recent switches implement several types of defenses against these attacks, but they need to be carefully configured by the network administrator. See [Vyncke2007]_ for a detailed discussion on security issues with Ethernet switches.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">289</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b26c41bba8ef65cd" weblate-flags="read-only">
        <source>The `MAC address learning` algorithm combined with the forwarding algorithm work well in a tree-shaped network such as the one shown above. However, to deal with link and switch failures, network administrators often add redundant links to ensure that their network remains connected even after a failure. Let us consider what happens in the Ethernet network shown in the figure below.</source>
        <target state="translated">The `MAC address learning` algorithm combined with the forwarding algorithm work well in a tree-shaped network such as the one shown above. However, to deal with link and switch failures, network administrators often add redundant links to ensure that their network remains connected even after a failure. Let us consider what happens in the Ethernet network shown in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">293</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6c6c6b6de6b7f499" weblate-flags="read-only">
        <source>Ethernet switches in a loop</source>
        <target state="translated">Ethernet switches in a loop</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">300</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3d6f3e866e880e60" weblate-flags="read-only">
        <source>When all switches boot, their `MAC address table` is empty. Assume that host `A` sends a frame towards host `C`. Upon reception of this frame, switch1 updates its `MAC address table` to remember that address `A` is reachable via its West port. As there is no entry for address `C` in switch1's `MAC address table`, the frame is forwarded to both switch2 and switch3. When switch2 receives the frame, its updates its `MAC address table` for address `A` and forwards the frame to host `C` as well as to switch3. switch3 has thus received two copies of the same frame. As switch3 does not know how to reach the destination address, it forwards the frame received from switch1 to switch2 and the frame received from switch2 to switch1... The single frame sent by host `A` will be continuously duplicated by the switches until their `MAC address table` contains an entry for address `C`. Quickly, all the available link bandwidth will be used to forward all the copies of this frame. As Ethernet does not contain any `TTL` or `HopLimit`, this loop will never stop.</source>
        <target state="translated">When all switches boot, their `MAC address table` is empty. Assume that host `A` sends a frame towards host `C`. Upon reception of this frame, switch1 updates its `MAC address table` to remember that address `A` is reachable via its West port. As there is no entry for address `C` in switch1's `MAC address table`, the frame is forwarded to both switch2 and switch3. When switch2 receives the frame, its updates its `MAC address table` for address `A` and forwards the frame to host `C` as well as to switch3. switch3 has thus received two copies of the same frame. As switch3 does not know how to reach the destination address, it forwards the frame received from switch1 to switch2 and the frame received from switch2 to switch1... The single frame sent by host `A` will be continuously duplicated by the switches until their `MAC address table` contains an entry for address `C`. Quickly, all the available link bandwidth will be used to forward all the copies of this frame. As Ethernet does not contain any `TTL` or `HopLimit`, this loop will never stop.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">303</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="830c29edd96d97ed" weblate-flags="read-only">
        <source>The `MAC address learning` algorithm allows switches to be plug-and-play. Unfortunately, the loops that arise when the network topology is not a tree are a severe problem. Forcing the switches to only be used in tree-shaped networks as hubs would be a severe limitation. To solve this problem, the inventors of Ethernet switches have developed the `Spanning Tree Protocol`. This protocol allows switches to automatically disable ports on Ethernet switches to ensure that the network does not contain any cycle that could cause frames to loop forever.</source>
        <target state="translated">The `MAC address learning` algorithm allows switches to be plug-and-play. Unfortunately, the loops that arise when the network topology is not a tree are a severe problem. Forcing the switches to only be used in tree-shaped networks as hubs would be a severe limitation. To solve this problem, the inventors of Ethernet switches have developed the `Spanning Tree Protocol`. This protocol allows switches to automatically disable ports on Ethernet switches to ensure that the network does not contain any cycle that could cause frames to loop forever.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">305</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5c3d5569f737b794" weblate-flags="read-only">
        <source>The first Ethernet relays that operated in the datalink layers were called `bridges`. In practice, the main difference between switches and bridges is that bridges were usually implemented in software while switches are hardware-based devices. Throughout this text, we always use `switch` when referring to a relay in the datalink layer, but you might still see the word `bridge`.</source>
        <target state="translated">The first Ethernet relays that operated in the datalink layers were called `bridges`. In practice, the main difference between switches and bridges is that bridges were usually implemented in software while switches are hardware-based devices. Throughout this text, we always use `switch` when referring to a relay in the datalink layer, but you might still see the word `bridge`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">309</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c825f1d1d864af84" weblate-flags="read-only">
        <source>The Spanning Tree Protocol (802.1d)</source>
        <target state="translated">The Spanning Tree Protocol (802.1d)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">314</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f2fefe54369ab04b" weblate-flags="read-only">
        <source>The `Spanning Tree Protocol` (STP), proposed in [Perlman1985]_, is a distributed protocol that is used by switches to reduce the network topology to a spanning tree, so that there are no cycles in the topology. For example, consider the network shown in the figure below. In this figure, each bold line corresponds to an Ethernet to which two Ethernet switches are attached. This network contains several cycles that must be broken to allow Ethernet switches, using the MAC address learning algorithm, to exchange frames.</source>
        <target state="translated">The `Spanning Tree Protocol` (STP), proposed in [Perlman1985]_, is a distributed protocol that is used by switches to reduce the network topology to a spanning tree, so that there are no cycles in the topology. For example, consider the network shown in the figure below. In this figure, each bold line corresponds to an Ethernet to which two Ethernet switches are attached. This network contains several cycles that must be broken to allow Ethernet switches, using the MAC address learning algorithm, to exchange frames.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">316</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5816c84aed527e7f" weblate-flags="read-only">
        <source>Spanning tree computed in a switched Ethernet network</source>
        <target state="translated">Spanning tree computed in a switched Ethernet network</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">324</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cc332880083f61d8" weblate-flags="read-only">
        <source>In this network, the STP will compute the following spanning tree. `Switch1` will be the root of the tree. All the interfaces of `Switch1`, `Switch2` and `Switch7` are part of the spanning tree. Only the interface connected to `LAN B` will be active on `Switch9`. `LAN H` will only be served by `Switch7` and the port of `Switch44` on `LAN G` will be disabled. A frame originating on `LAN B` and destined for `LAN A` will be forwarded by `Switch7` on `LAN C`, then by `Switch1` on `LAN E`, then by `Switch44` on `LAN F` and eventually by `Switch2` on `LAN A`.</source>
        <target state="translated">In this network, the STP will compute the following spanning tree. `Switch1` will be the root of the tree. All the interfaces of `Switch1`, `Switch2` and `Switch7` are part of the spanning tree. Only the interface connected to `LAN B` will be active on `Switch9`. `LAN H` will only be served by `Switch7` and the port of `Switch44` on `LAN G` will be disabled. A frame originating on `LAN B` and destined for `LAN A` will be forwarded by `Switch7` on `LAN C`, then by `Switch1` on `LAN E`, then by `Switch44` on `LAN F` and eventually by `Switch2` on `LAN A`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">327</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="63ed0b4e590b6d27" weblate-flags="read-only">
        <source>Switches running the `Spanning Tree Protocol` exchange `BPDUs`. These `BPDUs` are always sent as frames with destination MAC address as the `ALL_BRIDGES` reserved multicast MAC address. Each switch has a unique 64 bit `identifier`. To ensure uniqueness, the lower 48 bits of the identifier are set to the unique MAC address allocated to the switch by its manufacturer. The high order 16 bits of the switch identifier can be configured by the network administrator to influence the topology of the spanning tree. The default value for these high order bits is 32768.</source>
        <target state="translated">Switches running the `Spanning Tree Protocol` exchange `BPDUs`. These `BPDUs` are always sent as frames with destination MAC address as the `ALL_BRIDGES` reserved multicast MAC address. Each switch has a unique 64 bit `identifier`. To ensure uniqueness, the lower 48 bits of the identifier are set to the unique MAC address allocated to the switch by its manufacturer. The high order 16 bits of the switch identifier can be configured by the network administrator to influence the topology of the spanning tree. The default value for these high order bits is 32768.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">329</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6363426bbe329427" weblate-flags="read-only">
        <source>The switches exchange `BPDUs` to build the spanning tree. Intuitively, the spanning tree is built by first selecting the switch with the smallest `identifier` as the root of the tree. The branches of the spanning tree are then composed of the shortest paths that allow all of the switches that compose the network to be reached. The `BPDUs` exchanged by the switches contain the following information :</source>
        <target state="translated">The switches exchange `BPDUs` to build the spanning tree. Intuitively, the spanning tree is built by first selecting the switch with the smallest `identifier` as the root of the tree. The branches of the spanning tree are then composed of the shortest paths that allow all of the switches that compose the network to be reached. The `BPDUs` exchanged by the switches contain the following information :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">331</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0c6ab257dd8912e5" weblate-flags="read-only">
        <source>the `identifier` of the root switch (`R`)</source>
        <target state="translated">the `identifier` of the root switch (`R`)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">334</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ae35aacad5537489" weblate-flags="read-only">
        <source>the `cost` of the shortest path between the switch that sent the `BPDU` and the root switch (`c`)</source>
        <target state="translated">the `cost` of the shortest path between the switch that sent the `BPDU` and the root switch (`c`)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">335</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0170654a1e9844ff" weblate-flags="read-only">
        <source>the `identifier` of the switch that sent the `BPDU` (`T`)</source>
        <target state="translated">the `identifier` of the switch that sent the `BPDU` (`T`)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">336</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1e2139b1346ca100" weblate-flags="read-only">
        <source>the number of the switch port over which the `BPDU` was sent (`p`)</source>
        <target state="translated">the number of the switch port over which the `BPDU` was sent (`p`)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">337</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="77e51f881903e064" weblate-flags="read-only">
        <source>We will use the notation `&lt;R,c,T,p&gt;` to represent a `BPDU` whose `root identifier` is `R`, `cost` is `c` and that was sent from the port `p` of switch `T`.  The construction of the spanning tree depends on an ordering relationship among the `BPDUs`. This ordering relationship could be implemented by the Python function below.</source>
        <target state="translated">We will use the notation `&lt;R,c,T,p&gt;` to represent a `BPDU` whose `root identifier` is `R`, `cost` is `c` and that was sent from the port `p` of switch `T`.  The construction of the spanning tree depends on an ordering relationship among the `BPDUs`. This ordering relationship could be implemented by the Python function below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">339</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8bc61a092e6694b4" weblate-flags="read-only">
        <source>In addition to the `identifier` discussed above, the network administrator can also configure a `cost` to be associated to each switch port. Usually, the `cost` of a port depends on its bandwidth and the [IEEE802.1d]_ standard recommends the values below. Of course, the network administrator may choose other values. We will use the notation `cost[p]` to indicate the cost associated to port `p` in this section.</source>
        <target state="translated">In addition to the `identifier` discussed above, the network administrator can also configure a `cost` to be associated to each switch port. Usually, the `cost` of a port depends on its bandwidth and the [IEEE802.1d]_ standard recommends the values below. Of course, the network administrator may choose other values. We will use the notation `cost[p]` to indicate the cost associated to port `p` in this section.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">350</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cb227a34cdf5cc20" weblate-flags="read-only">
        <source>Bandwidth</source>
        <target state="translated">Bandwidth</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">353</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9ecd57f59d78d2cd" weblate-flags="read-only">
        <source>Cost</source>
        <target state="translated">Cost</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">353</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5f3e79e95d581ef6" weblate-flags="read-only">
        <source>10 Mbps</source>
        <target state="translated">10 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">355</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a069035b8e166058" weblate-flags="read-only">
        <source>2000000</source>
        <target state="translated">2000000</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">355</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="91dec8bf95f5b485" weblate-flags="read-only">
        <source>100 Mbps</source>
        <target state="translated">100 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">356</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ddeb278dd11627f7" weblate-flags="read-only">
        <source>200000</source>
        <target state="translated">200000</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">356</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6eaaf97d666f9119" weblate-flags="read-only">
        <source>1 Gbps</source>
        <target state="translated">1 Gbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">357</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8c1d3c8ced8625e3" weblate-flags="read-only">
        <source>20000</source>
        <target state="translated">20000</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">357</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f7478bd1e89cf21c" weblate-flags="read-only">
        <source>2000</source>
        <target state="translated">2000</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">358</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e3fc883641a2d585" weblate-flags="read-only">
        <source>100 Gbps</source>
        <target state="translated">100 Gbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">359</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="72e280cb32f6bab3" weblate-flags="read-only">
        <source>200</source>
        <target state="translated">200</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">359</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="88fe0aec68bd1d12" weblate-flags="read-only">
        <source>The `Spanning Tree Protocol` uses its own terminology that we illustrate in the figure above. A switch port can be in three different states : `Root`, `Designated` and `Blocked`. All the ports of the `root` switch are in the `Designated` state. The state of the ports on the other switches is determined based on the `BPDU` received on each port.</source>
        <target state="translated">The `Spanning Tree Protocol` uses its own terminology that we illustrate in the figure above. A switch port can be in three different states : `Root`, `Designated` and `Blocked`. All the ports of the `root` switch are in the `Designated` state. The state of the ports on the other switches is determined based on the `BPDU` received on each port.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">362</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="aba564fa9aed6122" weblate-flags="read-only">
        <source>The `Spanning Tree Protocol` uses the ordering relationship to build the spanning tree. Each switch listens to `BPDUs` on its ports. When `BPDU = &lt;R,c,T,p&gt;` is received on port `q`, the switch computes the port's `root priority vector`: `V[q] = &lt;R,c+cost[q],T,p,q&gt;` , where `cost[q]` is the cost associated to the port over which the `BPDU` was received. The switch stores in a table the last `root priority vector` received on each port. The switch then compares its own `identifier` with the smallest `root identifier` stored in this table. If its own `identifier` is smaller, then the switch is the root of the spanning tree and is, by definition, at a distance `0` of the root. The `BPDU` of the switch is then `&lt;R,0,R,p&gt;`, where `R` is the switch `identifier` and `p` will be set to the port number over which the `BPDU` is sent.</source>
        <target state="translated">The `Spanning Tree Protocol` uses the ordering relationship to build the spanning tree. Each switch listens to `BPDUs` on its ports. When `BPDU = &lt;R,c,T,p&gt;` is received on port `q`, the switch computes the port's `root priority vector`: `V[q] = &lt;R,c+cost[q],T,p,q&gt;` , where `cost[q]` is the cost associated to the port over which the `BPDU` was received. The switch stores in a table the last `root priority vector` received on each port. The switch then compares its own `identifier` with the smallest `root identifier` stored in this table. If its own `identifier` is smaller, then the switch is the root of the spanning tree and is, by definition, at a distance `0` of the root. The `BPDU` of the switch is then `&lt;R,0,R,p&gt;`, where `R` is the switch `identifier` and `p` will be set to the port number over which the `BPDU` is sent.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">364</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2f7c3f9ed16d7d07" weblate-flags="read-only">
        <source>Otherwise, the switch chooses the best priority vector from its table, `bv = &lt;R,c+cost[q'],T,p,q'&gt;`. The port `q'`, over which this best root priority vector was learned, is the switch port that is closest to the `root` switch. This port becomes the `Root` port of the switch. There is only one `Root` port per switch (except for the `Root` switches whose ports are all `Designated`). The switch can then compute its own `BPDU` as `BPDU = &lt;R,c',S,p&gt;` , where `R` is the `root identifier`, `c'` the cost of the best root priority vector, `S` the identifier of the switch and `p` will be replaced by the number of the port over which the `BPDU` will be sent.</source>
        <target state="translated">Otherwise, the switch chooses the best priority vector from its table, `bv = &lt;R,c+cost[q'],T,p,q'&gt;`. The port `q'`, over which this best root priority vector was learned, is the switch port that is closest to the `root` switch. This port becomes the `Root` port of the switch. There is only one `Root` port per switch (except for the `Root` switches whose ports are all `Designated`). The switch can then compute its own `BPDU` as `BPDU = &lt;R,c',S,p&gt;` , where `R` is the `root identifier`, `c'` the cost of the best root priority vector, `S` the identifier of the switch and `p` will be replaced by the number of the port over which the `BPDU` will be sent.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">366</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e1eed6766e2e6ea8" weblate-flags="read-only">
        <source>To determine the state of its other ports, the switch compares its own `BPDU` with the last `BPDU` received on each port. Note that the comparison is done by using the `BPDUs` and not the `root priority vectors`. If the switch's `BPDU` is better than the last `BPDU` of this port, the port becomes a `Designated` port. Otherwise, the port becomes a `Blocked` port.</source>
        <target state="translated">To determine the state of its other ports, the switch compares its own `BPDU` with the last `BPDU` received on each port. Note that the comparison is done by using the `BPDUs` and not the `root priority vectors`. If the switch's `BPDU` is better than the last `BPDU` of this port, the port becomes a `Designated` port. Otherwise, the port becomes a `Blocked` port.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">368</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="29830460a093486c" weblate-flags="read-only">
        <source>The state of each port is important when considering the transmission of `BPDUs`. The root switch regularly sends its own `BPDU` over all of its (`Designated`) ports. This `BPDU` is received on the `Root` port of all the switches that are directly connected to the `root switch`. Each of these switches computes its own `BPDU` and sends this `BPDU` over all its `Designated` ports. These `BPDUs` are then received on the `Root` port of downstream switches, which then compute their own `BPDU`, etc. When the network topology is stable, switches send their own `BPDU` on all their `Designated` ports, once they receive a `BPDU` on their `Root` port. No `BPDU` is sent on a `Blocked` port. Switches listen for `BPDUs` on their `Blocked` and `Designated` ports, but no `BPDU` should be received over these ports when the topology is stable. The utilization of the ports for both `BPDUs` and data frames is summarized in the table below.</source>
        <target state="translated">The state of each port is important when considering the transmission of `BPDUs`. The root switch regularly sends its own `BPDU` over all of its (`Designated`) ports. This `BPDU` is received on the `Root` port of all the switches that are directly connected to the `root switch`. Each of these switches computes its own `BPDU` and sends this `BPDU` over all its `Designated` ports. These `BPDUs` are then received on the `Root` port of downstream switches, which then compute their own `BPDU`, etc. When the network topology is stable, switches send their own `BPDU` on all their `Designated` ports, once they receive a `BPDU` on their `Root` port. No `BPDU` is sent on a `Blocked` port. Switches listen for `BPDUs` on their `Blocked` and `Designated` ports, but no `BPDU` should be received over these ports when the topology is stable. The utilization of the ports for both `BPDUs` and data frames is summarized in the table below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">370</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="40b5c3baa5996599" weblate-flags="read-only">
        <source>Port state</source>
        <target state="translated">Port state</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">373</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d84ad4b2f62f49c3" weblate-flags="read-only">
        <source>Receives BPDUs</source>
        <target state="translated">Receives BPDUs</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">373</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f8c8f2aab064fb3a" weblate-flags="read-only">
        <source>Sends BPDU</source>
        <target state="translated">Sends BPDU</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">373</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9a9a2ca667aa6d36" weblate-flags="read-only">
        <source>Handles data frames</source>
        <target state="translated">Handles data frames</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">373</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2fb7bea33629e2da" weblate-flags="read-only">
        <source>Blocked</source>
        <target state="translated">Blocked</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">375</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5eb3ef91c0519544" weblate-flags="read-only">
        <source>yes</source>
        <target state="translated">yes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">375</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">376</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">376</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">377</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">377</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">377</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3a469e4a9d76f823" weblate-flags="read-only">
        <source>no</source>
        <target state="translated">no</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">375</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">375</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">376</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7a7795905455338c" weblate-flags="read-only">
        <source>Root</source>
        <target state="translated">Root</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">376</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8699479e3718e37a" weblate-flags="read-only">
        <source>Designated</source>
        <target state="translated">Designated</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">377</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1d0ad9668f253e29" weblate-flags="read-only">
        <source>To illustrate the operation of the `Spanning Tree Protocol`, let us consider the simple network topology in the figure below.</source>
        <target state="translated">To illustrate the operation of the `Spanning Tree Protocol`, let us consider the simple network topology in the figure below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">382</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9c44186d2ef19bda" weblate-flags="read-only">
        <source>A simple Spanning tree computed in a switched Ethernet network</source>
        <target state="translated">A simple Spanning tree computed in a switched Ethernet network</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">389</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="330c9e4edbc138ae" weblate-flags="read-only">
        <source>Assume that `Switch4` is the first to boot. It sends its own `BPDU = &lt;4,0,4,1&gt;` (resp. `BPDU = &lt;4,0,4,2&gt;`) on port 1 (resp. port 2). When `Switch1` boots, it sends `BPDU = &lt;1,0,1,1&gt;`. This `BPDU` is received by `Switch4`, which updates its `BPDU` and root priority vector tables and computes a new `BPDU = &lt;1,3,4,1&gt;` (resp. `BPDU = &lt;1,3,4,2&gt;`) on port 1 (resp. port 2). Indeed, there is only one root priority vector and hence, it is the best one. Port 1 of `Switch4` becomes the `Root` port while its second port is still in the `Designated` state.</source>
        <target state="translated">Assume that `Switch4` is the first to boot. It sends its own `BPDU = &lt;4,0,4,1&gt;` (resp. `BPDU = &lt;4,0,4,2&gt;`) on port 1 (resp. port 2). When `Switch1` boots, it sends `BPDU = &lt;1,0,1,1&gt;`. This `BPDU` is received by `Switch4`, which updates its `BPDU` and root priority vector tables and computes a new `BPDU = &lt;1,3,4,1&gt;` (resp. `BPDU = &lt;1,3,4,2&gt;`) on port 1 (resp. port 2). Indeed, there is only one root priority vector and hence, it is the best one. Port 1 of `Switch4` becomes the `Root` port while its second port is still in the `Designated` state.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">391</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4d55d1d87df98a07" weblate-flags="read-only">
        <source>Assume now that `Switch9` boots and immediately receives `Switch1` 's `BPDU` on port 1. `Switch9` computes its own `BPDU = &lt;1,1,9,1&gt;` (resp. `BPDU = &lt;1,1,9,2&gt;`) on port 1 (resp. port 2) and port 1 becomes the `Root` port of this switch. The `BPDU` is sent on port 2 of `Switch9` and reaches `Switch4`. `Switch4` compares the priority vectors. It notices that the last computed vector (i.e., `V[2] = &lt;1,2,9,2,2&gt;`) is better than `V[1] = &lt;1,3,1,1,1&gt;`. Thus, `Switch4`'s `BPDU` is recomputed and port 2 becomes the `Root` port of `Switch4`. `Switch4` compares its new `BPDU = &lt;1,2,4,p&gt;` with the last `BPDU` received on each port (except for the `Root` port). Port 1 becomes a `Blocked` port on `Switch4` because the `BPDU=&lt;1,0,1,1&gt;` received on this port is better.</source>
        <target state="translated">Assume now that `Switch9` boots and immediately receives `Switch1` 's `BPDU` on port 1. `Switch9` computes its own `BPDU = &lt;1,1,9,1&gt;` (resp. `BPDU = &lt;1,1,9,2&gt;`) on port 1 (resp. port 2) and port 1 becomes the `Root` port of this switch. The `BPDU` is sent on port 2 of `Switch9` and reaches `Switch4`. `Switch4` compares the priority vectors. It notices that the last computed vector (i.e., `V[2] = &lt;1,2,9,2,2&gt;`) is better than `V[1] = &lt;1,3,1,1,1&gt;`. Thus, `Switch4`'s `BPDU` is recomputed and port 2 becomes the `Root` port of `Switch4`. `Switch4` compares its new `BPDU = &lt;1,2,4,p&gt;` with the last `BPDU` received on each port (except for the `Root` port). Port 1 becomes a `Blocked` port on `Switch4` because the `BPDU=&lt;1,0,1,1&gt;` received on this port is better.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">393</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fc9d1846e1e2fab8" weblate-flags="read-only">
        <source>During the computation of the spanning tree, switches discard all received data frames, as at that time the network topology is not guaranteed to be loop-free. Once that topology has been stable for some time, the switches again start to use the MAC learning algorithm to forward data frames. Only the `Root` and `Designated` ports are used to forward data frames. Switches discard all the data frames received on their `Blocked` ports and never forward frames on these ports.</source>
        <target state="translated">During the computation of the spanning tree, switches discard all received data frames, as at that time the network topology is not guaranteed to be loop-free. Once that topology has been stable for some time, the switches again start to use the MAC learning algorithm to forward data frames. Only the `Root` and `Designated` ports are used to forward data frames. Switches discard all the data frames received on their `Blocked` ports and never forward frames on these ports.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">395</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="659eb583733a4a82" weblate-flags="read-only">
        <source>Switches, ports and links can fail in a switched Ethernet network. When a failure occurs, the switches must be able to recompute the spanning tree to recover from the failure. The `Spanning Tree Protocol` relies on regular transmissions of the `BPDUs` to detect these failures. A `BPDU` contains two additional fields : the `Age` of the `BPDU` and the `Maximum Age`. The `Age` contains the amount of time that has passed since the root switch initially originated the `BPDU`. The root switch sends its `BPDU` with an `Age` of zero and each switch that computes its own `BPDU` increments its `Age` by one. The `Age` of the `BPDUs` stored on a switch's table is also incremented every second. A `BPDU` expires when its `Age` reaches the `Maximum Age`. When the network is stable, this does not happen as `BPDU` s are regularly sent by the `root` switch and downstream switches. However, if the `root` fails or the network becomes partitioned, `BPDU` will expire and switches will recompute their own `BPDU` and restart the `Spanning Tree Protocol`. Once a topology change has been detected, the forwarding of the data frames stops as the topology is not guaranteed to be loop-free. Additional details about the reaction to failures may be found in [IEEE802.1d]_.</source>
        <target state="translated">Switches, ports and links can fail in a switched Ethernet network. When a failure occurs, the switches must be able to recompute the spanning tree to recover from the failure. The `Spanning Tree Protocol` relies on regular transmissions of the `BPDUs` to detect these failures. A `BPDU` contains two additional fields : the `Age` of the `BPDU` and the `Maximum Age`. The `Age` contains the amount of time that has passed since the root switch initially originated the `BPDU`. The root switch sends its `BPDU` with an `Age` of zero and each switch that computes its own `BPDU` increments its `Age` by one. The `Age` of the `BPDUs` stored on a switch's table is also incremented every second. A `BPDU` expires when its `Age` reaches the `Maximum Age`. When the network is stable, this does not happen as `BPDU` s are regularly sent by the `root` switch and downstream switches. However, if the `root` fails or the network becomes partitioned, `BPDU` will expire and switches will recompute their own `BPDU` and restart the `Spanning Tree Protocol`. Once a topology change has been detected, the forwarding of the data frames stops as the topology is not guaranteed to be loop-free. Additional details about the reaction to failures may be found in [IEEE802.1d]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">397</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="494eac3bd87440dd" weblate-flags="read-only">
        <source>Virtual LANs</source>
        <target state="translated">Virtual LANs</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">402</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a68e293c5d781bca" weblate-flags="read-only">
        <source>Another important advantage of Ethernet switches is the ability to create Virtual Local Area Networks (VLANs). A virtual LAN can be defined as a `set of ports attached to one or more Ethernet switches`. A switch can support several VLANs and it runs one MAC learning algorithm for each Virtual LAN. When a switch receives a frame with an unknown or a multicast destination, it forwards it over all the ports that belong to the same Virtual LAN but not over the ports that belong to other Virtual LANs. Similarly, when a switch learns a source address on a port, it associates it to the Virtual LAN of this port and uses this information only when forwarding frames on this Virtual LAN.</source>
        <target state="translated">Another important advantage of Ethernet switches is the ability to create Virtual Local Area Networks (VLANs). A virtual LAN can be defined as a `set of ports attached to one or more Ethernet switches`. A switch can support several VLANs and it runs one MAC learning algorithm for each Virtual LAN. When a switch receives a frame with an unknown or a multicast destination, it forwards it over all the ports that belong to the same Virtual LAN but not over the ports that belong to other Virtual LANs. Similarly, when a switch learns a source address on a port, it associates it to the Virtual LAN of this port and uses this information only when forwarding frames on this Virtual LAN.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">404</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e7b4069939355b9e" weblate-flags="read-only">
        <source>The figure below illustrates a switched Ethernet network with three Virtual LANs. `VLAN2` and `VLAN3` only require a local configuration of switch `S1`. Host `C` can exchange frames with host `D`, but not with hosts that are outside of its VLAN. `VLAN1` is more complex as there are ports of this VLAN on several switches. To support such VLANs, local configuration is not sufficient anymore. When a switch receives a frame from another switch, it must be able to determine the VLAN in which the frame originated to use the correct MAC table to forward the frame. This is done by assigning an identifier to each Virtual LAN and placing this identifier inside the headers of the frames that are exchanged between switches.</source>
        <target state="translated">The figure below illustrates a switched Ethernet network with three Virtual LANs. `VLAN2` and `VLAN3` only require a local configuration of switch `S1`. Host `C` can exchange frames with host `D`, but not with hosts that are outside of its VLAN. `VLAN1` is more complex as there are ports of this VLAN on several switches. To support such VLANs, local configuration is not sufficient anymore. When a switch receives a frame from another switch, it must be able to determine the VLAN in which the frame originated to use the correct MAC table to forward the frame. This is done by assigning an identifier to each Virtual LAN and placing this identifier inside the headers of the frames that are exchanged between switches.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">406</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2f4896f2f1fdbaf8" weblate-flags="read-only">
        <source>Virtual Local Area Networks in a switched Ethernet network</source>
        <target state="translated">Virtual Local Area Networks in a switched Ethernet network</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">413</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2e3a2eaaf2c6d2c3" weblate-flags="read-only">
        <source>IEEE defined in the [IEEE802.1q]_ standard a special header to encode the VLAN identifiers. This 32 bit header includes a 12 bit VLAN field that contains the VLAN identifier of each frame. The format of the [IEEE802.1q]_ header is described below.</source>
        <target state="translated">IEEE defined in the [IEEE802.1q]_ standard a special header to encode the VLAN identifiers. This 32 bit header includes a 12 bit VLAN field that contains the VLAN identifier of each frame. The format of the [IEEE802.1q]_ header is described below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">415</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9526a5751d39b906" weblate-flags="read-only">
        <source>Format of the 802.1q header</source>
        <target state="translated">Format of the 802.1q header</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">421</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="922fa9ffac670636" weblate-flags="read-only">
        <source>The [IEEE802.1q]_ header is inserted immediately after the source MAC address in the Ethernet frame (i.e. before the EtherType field). The maximum frame size is increased by 4 bytes. It is encoded in 32 bits and contains four fields. The Tag Protocol Identifier is set to `0x8100` to allow the receiver to detect the presence of this additional header. The `Priority Code Point` (PCP) is a three bit field that is used to support different transmission priorities for the frame. Value `0` is the lowest priority and value `7` the highest. Frames with a higher priority can expect to be forwarded earlier than frames having a lower priority. The `C` bit is used for compatibility between Ethernet and Token Ring networks. The last 12 bits of the 802.1q header contain the VLAN identifier. Value `0` indicates that the frame does not belong to any VLAN while value `0xFFF` is reserved. This implies that 4094 different VLAN identifiers can be used in an Ethernet network.</source>
        <target state="translated">The [IEEE802.1q]_ header is inserted immediately after the source MAC address in the Ethernet frame (i.e. before the EtherType field). The maximum frame size is increased by 4 bytes. It is encoded in 32 bits and contains four fields. The Tag Protocol Identifier is set to `0x8100` to allow the receiver to detect the presence of this additional header. The `Priority Code Point` (PCP) is a three bit field that is used to support different transmission priorities for the frame. Value `0` is the lowest priority and value `7` the highest. Frames with a higher priority can expect to be forwarded earlier than frames having a lower priority. The `C` bit is used for compatibility between Ethernet and Token Ring networks. The last 12 bits of the 802.1q header contain the VLAN identifier. Value `0` indicates that the frame does not belong to any VLAN while value `0xFFF` is reserved. This implies that 4094 different VLAN identifiers can be used in an Ethernet network.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/ethernet.rst</context>
          <context context-type="linenumber">423</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="edc38b22b49c7a38" weblate-flags="read-only">
        <source>802.11 wireless networks</source>
        <target state="translated">802.11 wireless networks</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">5</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c11148b9ac6c3fd2" weblate-flags="read-only">
        <source>The radio spectrum is a limited resource that must be shared by everyone. During most of the twentieth century, governments and international organizations have regulated most of the radio spectrum. This regulation controls the utilization of the radio spectrum, in order to prevent interference among different users. A company that wants to use a frequency range in a given region must apply for a license from the regulator. Most regulators charge a fee for the utilization of the radio spectrum and some governments have encouraged competition among companies bidding for the same frequency to increase the license fees.</source>
        <target state="translated">The radio spectrum is a limited resource that must be shared by everyone. During most of the twentieth century, governments and international organizations have regulated most of the radio spectrum. This regulation controls the utilization of the radio spectrum, in order to prevent interference among different users. A company that wants to use a frequency range in a given region must apply for a license from the regulator. Most regulators charge a fee for the utilization of the radio spectrum and some governments have encouraged competition among companies bidding for the same frequency to increase the license fees.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">7</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="79958703d11b21e7" weblate-flags="read-only">
        <source>In the 1970s, after the first experiments with ALOHANet, interest in wireless networks grew. Many experiments were done on and outside the ARPANet. One of these experiments was the `first mobile phone &lt;http://news.bbc.co.uk/2/hi/programmes/click_online/8639590.stm&gt;`_ , which was developed and tested in 1973. This experimental mobile phone was the starting point for the first generation analog mobile phones. Given the growing demand for mobile phones, it was clear that the analog mobile phone technology was not sufficient to support a large number of users.  To support more users and new services, researchers in several countries worked on the development of digital mobile telephones. In 1987, several European countries decided to develop the standards for a common cellular telephone system across Europe : the `Global System for Mobile Communications` (GSM). Since then, the standards have evolved and more than three billion users are connected to GSM networks today.</source>
        <target state="translated">In the 1970s, after the first experiments with ALOHANet, interest in wireless networks grew. Many experiments were done on and outside the ARPANet. One of these experiments was the `first mobile phone &lt;http://news.bbc.co.uk/2/hi/programmes/click_online/8639590.stm&gt;`_ , which was developed and tested in 1973. This experimental mobile phone was the starting point for the first generation analog mobile phones. Given the growing demand for mobile phones, it was clear that the analog mobile phone technology was not sufficient to support a large number of users.  To support more users and new services, researchers in several countries worked on the development of digital mobile telephones. In 1987, several European countries decided to develop the standards for a common cellular telephone system across Europe : the `Global System for Mobile Communications` (GSM). Since then, the standards have evolved and more than three billion users are connected to GSM networks today.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">9</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="01e6020acbb38760" weblate-flags="read-only">
        <source>While most of the frequency ranges of the radio spectrum are reserved for specific applications and require a special license, there are a few exceptions. These exceptions are known as the `Industrial, Scientific and Medical &lt;http://en.wikipedia.org/wiki/ISM_band&gt;`_ (ISM) radio bands. These bands can be used for industrial, scientific and medical applications without requiring a license from the regulator. For example, some radio-controlled models use the 27 MHz ISM band and some cordless telephones operate in the 915 MHz ISM. In 1985, the 2.400-2.500 GHz band was added to the list of ISM bands. This frequency range corresponds to the frequencies that are emitted by microwave ovens. Sharing this band with licensed applications would have likely caused interference, given the large number of microwave ovens that are used. Despite the risk of interference with microwave ovens, the opening of the 2.400-2.500 GHz allowed the networking industry to develop several wireless network techniques to allow computers to exchange data without using cables. In this section, we discuss in more detail the most popular one, i.e. the WiFi [IEEE802.11]_ family of wireless networks. Other wireless networking techniques such as `BlueTooth &lt;http://en.wikipedia.org/wiki/BlueTooth&gt;`_ or `HiperLAN &lt;http://en.wikipedia.org/wiki/HiperLAN&gt;`_ use the same frequency range.</source>
        <target state="translated">While most of the frequency ranges of the radio spectrum are reserved for specific applications and require a special license, there are a few exceptions. These exceptions are known as the `Industrial, Scientific and Medical &lt;http://en.wikipedia.org/wiki/ISM_band&gt;`_ (ISM) radio bands. These bands can be used for industrial, scientific and medical applications without requiring a license from the regulator. For example, some radio-controlled models use the 27 MHz ISM band and some cordless telephones operate in the 915 MHz ISM. In 1985, the 2.400-2.500 GHz band was added to the list of ISM bands. This frequency range corresponds to the frequencies that are emitted by microwave ovens. Sharing this band with licensed applications would have likely caused interference, given the large number of microwave ovens that are used. Despite the risk of interference with microwave ovens, the opening of the 2.400-2.500 GHz allowed the networking industry to develop several wireless network techniques to allow computers to exchange data without using cables. In this section, we discuss in more detail the most popular one, i.e. the WiFi [IEEE802.11]_ family of wireless networks. Other wireless networking techniques such as `BlueTooth &lt;http://en.wikipedia.org/wiki/BlueTooth&gt;`_ or `HiperLAN &lt;http://en.wikipedia.org/wiki/HiperLAN&gt;`_ use the same frequency range.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">13</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1ef15722fb89f189" weblate-flags="read-only">
        <source>Today, WiFi is a very popular wireless networking technology. There are more than several hundreds of millions of WiFi devices. The development of this technology started in the late 1980s with the `WaveLAN &lt;http://en.wikipedia.org/wiki/WaveLAN&gt;`_ proprietary wireless network. WaveLAN operated at 2 Mbps and used different frequency bands in different regions of the world. In the early 1990s, the IEEE_ created the `802.11 working group &lt;http://www.ieee802.org/11/&gt;`_ to standardize a family of wireless network technologies. This working group was very prolific and produced several wireless networking standards that use different frequency ranges and different physical layers. The table below provides a summary of the main 802.11 standards.</source>
        <target state="translated">Today, WiFi is a very popular wireless networking technology. There are more than several hundreds of millions of WiFi devices. The development of this technology started in the late 1980s with the `WaveLAN &lt;http://en.wikipedia.org/wiki/WaveLAN&gt;`_ proprietary wireless network. WaveLAN operated at 2 Mbps and used different frequency bands in different regions of the world. In the early 1990s, the IEEE_ created the `802.11 working group &lt;http://www.ieee802.org/11/&gt;`_ to standardize a family of wireless network technologies. This working group was very prolific and produced several wireless networking standards that use different frequency ranges and different physical layers. The table below provides a summary of the main 802.11 standards.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">15</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="610c8557e506f9d8" weblate-flags="read-only">
        <source>Frequency</source>
        <target state="translated">Frequency</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">19</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2b831cf2c124f324" weblate-flags="read-only">
        <source>Typical throughput</source>
        <target state="translated">Typical throughput</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">19</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8d170ad6869d7f6e" weblate-flags="read-only">
        <source>Max bandwidth</source>
        <target state="translated">Max bandwidth</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">19</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eb7927d2deefe588" weblate-flags="read-only">
        <source>Range (m) indoor/outdoor</source>
        <target state="translated">Range (m) indoor/outdoor</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">19</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b08a897a279d5e06" weblate-flags="read-only">
        <source>802.11</source>
        <target state="translated">802.11</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">22</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="59803a7076969e61" weblate-flags="read-only">
        <source>2.4 GHz</source>
        <target state="translated">2.4 GHz</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">22</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">24</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">25</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="96383daac82f34c0" weblate-flags="read-only">
        <source>0.9 Mbps</source>
        <target state="translated">0.9 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">22</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3fd79cab698256ac" weblate-flags="read-only">
        <source>2 Mbps</source>
        <target state="translated">2 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">22</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2be6fd16aa8d8c0f" weblate-flags="read-only">
        <source>20/100</source>
        <target state="translated">20/100</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">22</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f413b4ba04847763" weblate-flags="read-only">
        <source>802.11a</source>
        <target state="translated">802.11a</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">23</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="969371b605af5b61" weblate-flags="read-only">
        <source>5 GHz</source>
        <target state="translated">5 GHz</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">23</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9908266c0143528b" weblate-flags="read-only">
        <source>23 Mbps</source>
        <target state="translated">23 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">23</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b13896cc2c7bbce1" weblate-flags="read-only">
        <source>54 Mbps</source>
        <target state="translated">54 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">23</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">25</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="87fbc90f2fc4a3f9" weblate-flags="read-only">
        <source>35/120</source>
        <target state="translated">35/120</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">23</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="91668756ae3a809d" weblate-flags="read-only">
        <source>802.11b</source>
        <target state="translated">802.11b</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">24</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9aa990a4287eff1f" weblate-flags="read-only">
        <source>4.3 Mbps</source>
        <target state="translated">4.3 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">24</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0f54a8c240e99c58" weblate-flags="read-only">
        <source>11 Mbps</source>
        <target state="translated">11 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">24</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4a913287004edd91" weblate-flags="read-only">
        <source>38/140</source>
        <target state="translated">38/140</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">24</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">25</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b15c56f499d66fbb" weblate-flags="read-only">
        <source>802.11g</source>
        <target state="translated">802.11g</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">25</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3b8004e6ff36d651" weblate-flags="read-only">
        <source>19 Mbps</source>
        <target state="translated">19 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">25</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b0507c9ebc1583bc" weblate-flags="read-only">
        <source>802.11n</source>
        <target state="translated">802.11n</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">26</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5d1377d5cf392ab8" weblate-flags="read-only">
        <source>2.4/5 GHz</source>
        <target state="translated">2.4/5 GHz</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">26</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a1685b2ed2d0e375" weblate-flags="read-only">
        <source>74 Mbps</source>
        <target state="translated">74 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">26</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="795eadc99f536919" weblate-flags="read-only">
        <source>150 Mbps</source>
        <target state="translated">150 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">26</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="69f2a8f44169206c" weblate-flags="read-only">
        <source>70/250</source>
        <target state="translated">70/250</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">26</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8763d857e3da8d29" weblate-flags="read-only">
        <source>When developing its family of standards, the `IEEE 802.11 working group &lt;http://www.ieee802.org/11/&gt;`_ took a similar approach as the `IEEE 802.3 working group &lt;http://www.ieee802.org/3/&gt;`_ that developed various types of physical layers for Ethernet networks. 802.11 networks use the CSMA/CA Medium Access Control technique described earlier and they all assume the same architecture and use the same frame format.</source>
        <target state="translated">When developing its family of standards, the `IEEE 802.11 working group &lt;http://www.ieee802.org/11/&gt;`_ took a similar approach as the `IEEE 802.3 working group &lt;http://www.ieee802.org/3/&gt;`_ that developed various types of physical layers for Ethernet networks. 802.11 networks use the CSMA/CA Medium Access Control technique described earlier and they all assume the same architecture and use the same frame format.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">29</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="556ad1bfc7b3daa6" weblate-flags="read-only">
        <source>The architecture of WiFi networks is slightly different from the Local Area Networks that we have discussed until now. There are, in practice, two main types of WiFi networks : `independent` or `adhoc` networks  and `infrastructure` networks [#fBSS]_. An `independent` or `adhoc` network is composed of a set of devices that communicate with each other. These devices play the same role and the `adhoc` network is usually not connected to the global Internet. `Adhoc` networks are used when for example a few laptops need to exchange information or to connect a computer with a WiFi printer.</source>
        <target state="translated">The architecture of WiFi networks is slightly different from the Local Area Networks that we have discussed until now. There are, in practice, two main types of WiFi networks : `independent` or `adhoc` networks  and `infrastructure` networks [#fBSS]_. An `independent` or `adhoc` network is composed of a set of devices that communicate with each other. These devices play the same role and the `adhoc` network is usually not connected to the global Internet. `Adhoc` networks are used when for example a few laptops need to exchange information or to connect a computer with a WiFi printer.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">35</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="71c7a5613ee629b2" weblate-flags="read-only">
        <source>An 802.11 independent or adhoc network</source>
        <target state="translated">An 802.11 independent or adhoc network</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">42</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="553862831de38553" weblate-flags="read-only">
        <source>Most WiFi networks are `infrastructure` networks. An `infrastructure` network contains one or more `access points` that are attached to a fixed Local Area Network (usually an Ethernet network) that is connected to other networks such as the Internet. The figure below shows such a network with two access points and four WiFi devices. Each WiFi device is associated to one access point and uses this access point as a relay to exchange frames with the devices that are associated to another access point or reachable through the LAN.</source>
        <target state="translated">Most WiFi networks are `infrastructure` networks. An `infrastructure` network contains one or more `access points` that are attached to a fixed Local Area Network (usually an Ethernet network) that is connected to other networks such as the Internet. The figure below shows such a network with two access points and four WiFi devices. Each WiFi device is associated to one access point and uses this access point as a relay to exchange frames with the devices that are associated to another access point or reachable through the LAN.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">47</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0434020b8d52774a" weblate-flags="read-only">
        <source>An 802.11 infrastructure network</source>
        <target state="translated">An 802.11 infrastructure network</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">54</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="451da06d64fedbf1" weblate-flags="read-only">
        <source>An 802.11 access point is a relay that operates in the datalink layer like switches. The figure below represents the layers of the reference model that are involved when a WiFi host communicates with a host attached to an Ethernet network through an access point.</source>
        <target state="translated">An 802.11 access point is a relay that operates in the datalink layer like switches. The figure below represents the layers of the reference model that are involved when a WiFi host communicates with a host attached to an Ethernet network through an access point.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">56</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6a3877642c45e520" weblate-flags="read-only">
        <source>802.11 devices exchange variable length frames, which have a slightly different structure than the simple frame format used in Ethernet LANs. We review the key parts of the 802.11 frames. Additional details may be found in [IEEE802.11]_ and [Gast2002]_ . An 802.11 frame contains a fixed length header, a variable length payload that may contain up 2324 bytes of user data and a 32 bits CRC. Although the payload can contain up to 2324 bytes, most 802.11 deployments use a maximum payload size of 1500 bytes as they are used in `infrastructure` networks attached to Ethernet LANs. An 802.11 data frame is shown below.</source>
        <target state="translated">802.11 devices exchange variable length frames, which have a slightly different structure than the simple frame format used in Ethernet LANs. We review the key parts of the 802.11 frames. Additional details may be found in [IEEE802.11]_ and [Gast2002]_ . An 802.11 frame contains a fixed length header, a variable length payload that may contain up 2324 bytes of user data and a 32 bits CRC. Although the payload can contain up to 2324 bytes, most 802.11 deployments use a maximum payload size of 1500 bytes as they are used in `infrastructure` networks attached to Ethernet LANs. An 802.11 data frame is shown below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">93</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="97bcaaf9cb86f373" weblate-flags="read-only">
        <source>802.11 data frame format</source>
        <target state="translated">802.11 data frame format</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">99</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4264b3e0fd401f52" weblate-flags="read-only">
        <source>The first part of the 802.11 header is the 16 bit `Frame Control` field. This field contains flags that indicate the type of frame (data frame, RTS/CTS, acknowledgment, management frames, etc), whether the frame is sent to or from a fixed LAN, etc [IEEE802.11]_. The `Duration` is a 16 bit field that is used to reserve the transmission channel. In data frames, the `Duration` field is usually set to the time required to transmit one acknowledgment frame after a SIFS delay. Note that the `Duration` field must be set to zero in multicast and broadcast frames. As these frames are not acknowledged, there is no need to reserve the transmission channel after their transmission. The `Sequence control` field contains a 12 bits sequence number that is incremented for each data frame and a 4 bits fragment number.</source>
        <target state="translated">The first part of the 802.11 header is the 16 bit `Frame Control` field. This field contains flags that indicate the type of frame (data frame, RTS/CTS, acknowledgment, management frames, etc), whether the frame is sent to or from a fixed LAN, etc [IEEE802.11]_. The `Duration` is a 16 bit field that is used to reserve the transmission channel. In data frames, the `Duration` field is usually set to the time required to transmit one acknowledgment frame after a SIFS delay. Note that the `Duration` field must be set to zero in multicast and broadcast frames. As these frames are not acknowledged, there is no need to reserve the transmission channel after their transmission. The `Sequence control` field contains a 12 bits sequence number that is incremented for each data frame and a 4 bits fragment number.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">102</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="05f56cddfb693c59" weblate-flags="read-only">
        <source>The astute reader may have noticed that the 802.11 data frames contain three 48-bits address fields [#f4addresses]_ . This is surprising compared to other protocols in the network and datalink layers whose headers only contain a source and a destination address. The need for a third address in the 802.11 header comes from the `infrastructure` networks. In such a network, frames are usually exchanged between routers and servers attached to the LAN and WiFi devices attached to one of the access points. The role of the three address fields is specified by bit flags in the `Frame Control` field.</source>
        <target state="translated">The astute reader may have noticed that the 802.11 data frames contain three 48-bits address fields [#f4addresses]_ . This is surprising compared to other protocols in the network and datalink layers whose headers only contain a source and a destination address. The need for a third address in the 802.11 header comes from the `infrastructure` networks. In such a network, frames are usually exchanged between routers and servers attached to the LAN and WiFi devices attached to one of the access points. The role of the three address fields is specified by bit flags in the `Frame Control` field.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">105</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9d4b979ee34f58b6" weblate-flags="read-only">
        <source>When a frame is sent from a WiFi device to a server attached to the same LAN as the access point, the first address of the frame is set to the MAC address of the access point, the second address is set to the MAC address of the source WiFi device and the third address is the address of the final destination on the LAN. When the server replies, it sends an Ethernet frame whose source address is its MAC address and the destination address is the MAC address of the WiFi device. This frame is captured by the access point that converts the Ethernet header into an 802.11 frame header. The 802.11 frame sent by the access point contains three addresses : the first address is the MAC address of the destination WiFi device, the second address is the MAC address of the access point and the third address the MAC address of the server that sent the frame.</source>
        <target state="translated">When a frame is sent from a WiFi device to a server attached to the same LAN as the access point, the first address of the frame is set to the MAC address of the access point, the second address is set to the MAC address of the source WiFi device and the third address is the address of the final destination on the LAN. When the server replies, it sends an Ethernet frame whose source address is its MAC address and the destination address is the MAC address of the WiFi device. This frame is captured by the access point that converts the Ethernet header into an 802.11 frame header. The 802.11 frame sent by the access point contains three addresses : the first address is the MAC address of the destination WiFi device, the second address is the MAC address of the access point and the third address the MAC address of the server that sent the frame.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">107</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5cb8f9ad576f00e0" weblate-flags="read-only">
        <source>802.11 control frames are simpler than data frames. They contain a `Frame Control`, a `Duration` field and one or two addresses. The acknowledgment frames are very small. They only contain the address of the destination of the acknowledgment. There is no source address and no `Sequence Control` field in the acknowledgment frames. This is because the acknowledgment frame can easily be associated to the previous frame that it acknowledges. Indeed, each unicast data frame contains a `Duration` field that is used to reserve the transmission channel to ensure that no collision will affect the acknowledgment frame. The `Sequence Control` field is mainly used by the receiver to remove duplicate frames. Duplicate frames are detected as follows. Each data frame contains a 12 bits sequence number in the `Sequence Control` field and the `Frame Control` field contains the `Retry` bit flag that is set when a frame is transmitted.  Each 802.11 receiver stores the most recent sequence number received from each source address in frames whose `Retry` bit is reset. Upon reception of a frame with the `Retry` bit set, the receiver verifies its sequence number to determine whether it is a duplicated frame or not.</source>
        <target state="translated">802.11 control frames are simpler than data frames. They contain a `Frame Control`, a `Duration` field and one or two addresses. The acknowledgment frames are very small. They only contain the address of the destination of the acknowledgment. There is no source address and no `Sequence Control` field in the acknowledgment frames. This is because the acknowledgment frame can easily be associated to the previous frame that it acknowledges. Indeed, each unicast data frame contains a `Duration` field that is used to reserve the transmission channel to ensure that no collision will affect the acknowledgment frame. The `Sequence Control` field is mainly used by the receiver to remove duplicate frames. Duplicate frames are detected as follows. Each data frame contains a 12 bits sequence number in the `Sequence Control` field and the `Frame Control` field contains the `Retry` bit flag that is set when a frame is transmitted.  Each 802.11 receiver stores the most recent sequence number received from each source address in frames whose `Retry` bit is reset. Upon reception of a frame with the `Retry` bit set, the receiver verifies its sequence number to determine whether it is a duplicated frame or not.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">109</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bc86baac36ac3c21" weblate-flags="read-only">
        <source>IEEE 802.11 ACK and CTS frames</source>
        <target state="translated">IEEE 802.11 ACK and CTS frames</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">115</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7c1d5c258be6c7b8" weblate-flags="read-only">
        <source>802.11 RTS/CTS frames are used to reserve the transmission channel, in order to transmit one data frame and its acknowledgment. The RTS frames contain a `Duration` and the transmitter and receiver addresses. The `Duration` field of the RTS frame indicates the duration of the entire reservation (i.e. the time required to transmit the CTS, the data frame, the acknowledgments and the required SIFS delays). The CTS frame has the same format as the acknowledgment frame.</source>
        <target state="translated">802.11 RTS/CTS frames are used to reserve the transmission channel, in order to transmit one data frame and its acknowledgment. The RTS frames contain a `Duration` and the transmitter and receiver addresses. The `Duration` field of the RTS frame indicates the duration of the entire reservation (i.e. the time required to transmit the CTS, the data frame, the acknowledgments and the required SIFS delays). The CTS frame has the same format as the acknowledgment frame.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">120</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="087c2244277739a6" weblate-flags="read-only">
        <source>IEEE 802.11 RTS frame format</source>
        <target state="translated">IEEE 802.11 RTS frame format</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">126</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="700965a93261cfd7" weblate-flags="read-only">
        <source>The 802.11 service</source>
        <target state="translated">The 802.11 service</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">129</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e7fccebd69001960" weblate-flags="read-only">
        <source>Despite the utilization of acknowledgments, the 802.11 layer only provides an unreliable connectionless service like Ethernet networks that do not use acknowledgments. The 802.11 acknowledgments are used to minimize the probability of frame duplication. They do not guarantee that all frames will be correctly received by their recipients. Like Ethernet, 802.11 networks provide a high probability of successful delivery of the frames, not a guarantee. Furthermore, it should be noted that 802.11 networks do not use acknowledgments for multicast and broadcast frames. This implies that in practice such frames are more likely to suffer from transmission errors than unicast frames.</source>
        <target state="translated">Despite the utilization of acknowledgments, the 802.11 layer only provides an unreliable connectionless service like Ethernet networks that do not use acknowledgments. The 802.11 acknowledgments are used to minimize the probability of frame duplication. They do not guarantee that all frames will be correctly received by their recipients. Like Ethernet, 802.11 networks provide a high probability of successful delivery of the frames, not a guarantee. Furthermore, it should be noted that 802.11 networks do not use acknowledgments for multicast and broadcast frames. This implies that in practice such frames are more likely to suffer from transmission errors than unicast frames.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">131</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="66600e4bc34d65b0" weblate-flags="read-only">
        <source>In addition to the data and control frames that we have briefly described above, 802.11 networks use several types of management frames. These management frames are used for various purposes. We briefly describe some of these frames below. A detailed discussion may be found in [IEEE802.11]_ and [Gast2002]_.</source>
        <target state="translated">In addition to the data and control frames that we have briefly described above, 802.11 networks use several types of management frames. These management frames are used for various purposes. We briefly describe some of these frames below. A detailed discussion may be found in [IEEE802.11]_ and [Gast2002]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">135</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="62e57f96ad618e24" weblate-flags="read-only">
        <source>A first type of management frames are the `beacon` frames. These frames are broadcasted regularly by access points. Each `beacon frame` contains information about the capabilities of the access point (e.g. the supported 802.11 transmission rates) and a `Service Set Identity` (SSID). The SSID is a null-terminated ASCII string that can contain up to 32 characters. An access point may support several SSIDs and announce them in beacon frames. An access point may also choose to remain silent and not advertise beacon frames. In this case, WiFi stations may send `Probe request` frames to force the available access points to return a `Probe response` frame.</source>
        <target state="translated">A first type of management frames are the `beacon` frames. These frames are broadcasted regularly by access points. Each `beacon frame` contains information about the capabilities of the access point (e.g. the supported 802.11 transmission rates) and a `Service Set Identity` (SSID). The SSID is a null-terminated ASCII string that can contain up to 32 characters. An access point may support several SSIDs and announce them in beacon frames. An access point may also choose to remain silent and not advertise beacon frames. In this case, WiFi stations may send `Probe request` frames to force the available access points to return a `Probe response` frame.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">141</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="507a4bccda13c035" weblate-flags="read-only">
        <source>IP over 802.11</source>
        <target state="translated">IP over 802.11</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">144</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="088c65d87a75549c" weblate-flags="read-only">
        <source>Two types of encapsulation schemes were defined to support IP in Ethernet networks : the original encapsulation scheme, built above the Ethernet DIX format is defined in :rfc:`894` and a second encapsulation :rfc:`1042` scheme, built above the LLC/SNAP protocol [IEEE802.2]_. In 802.11 networks, the situation is simpler and only the :rfc:`1042` encapsulation is used. In practice, this encapsulation adds 6 bytes to the 802.11 header. The first four bytes correspond to the LLC/SNAP header. They are followed by the two bytes Ethernet Type field (`0x800` for IP and `0x806` for ARP). The figure below shows an IP packet encapsulated in an 802.11 frame.</source>
        <target state="translated">Two types of encapsulation schemes were defined to support IP in Ethernet networks : the original encapsulation scheme, built above the Ethernet DIX format is defined in :rfc:`894` and a second encapsulation :rfc:`1042` scheme, built above the LLC/SNAP protocol [IEEE802.2]_. In 802.11 networks, the situation is simpler and only the :rfc:`1042` encapsulation is used. In practice, this encapsulation adds 6 bytes to the 802.11 header. The first four bytes correspond to the LLC/SNAP header. They are followed by the two bytes Ethernet Type field (`0x800` for IP and `0x806` for ARP). The figure below shows an IP packet encapsulated in an 802.11 frame.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">146</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="86c02611ce64fde5" weblate-flags="read-only">
        <source>IP over IEEE 802.11</source>
        <target state="translated">IP over IEEE 802.11</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">152</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="35ccfa1b86d85a90" weblate-flags="read-only">
        <source>The second important utilization of the management frames is to allow a WiFi station to be associated with an access point. When a WiFi station starts, it listens to beacon frames to find the available SSIDs. To be allowed to send and receive frames via an access point, a WiFi station must be associated to this access point. If the access point does not use any security mechanism to secure the wireless transmission, the WiFi station simply sends an `Association request` frame to its preferred access point (usually the access point that it receives with the strongest radio signal). This frame contains some parameters chosen by the WiFi station and the SSID that it requests to join. The access point replies with an `Association response frame` if it accepts the WiFI station.</source>
        <target state="translated">The second important utilization of the management frames is to allow a WiFi station to be associated with an access point. When a WiFi station starts, it listens to beacon frames to find the available SSIDs. To be allowed to send and receive frames via an access point, a WiFi station must be associated to this access point. If the access point does not use any security mechanism to secure the wireless transmission, the WiFi station simply sends an `Association request` frame to its preferred access point (usually the access point that it receives with the strongest radio signal). This frame contains some parameters chosen by the WiFi station and the SSID that it requests to join. The access point replies with an `Association response frame` if it accepts the WiFI station.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">154</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d4febaf642f12973" weblate-flags="read-only">
        <source>The 802.11 working group defined the `basic service set (BSS)` as a group of devices that communicate with each other. We continue to use `network` when referring to a set of devices that communicate.</source>
        <target state="translated">The 802.11 working group defined the `basic service set (BSS)` as a group of devices that communicate with each other. We continue to use `network` when referring to a set of devices that communicate.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">158</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c3507618f1b9ef0d" weblate-flags="read-only">
        <source>In fact, the [IEEE802.11]_ frame format contains a fourth optional address field. This fourth address is only used when an 802.11 wireless network is used to interconnect bridges attached to two classical LAN networks.</source>
        <target state="translated">In fact, the [IEEE802.11]_ frame format contains a fourth optional address field. This fourth address is only used when an 802.11 wireless network is used to interconnect bridges attached to two classical LAN networks.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/wifi.rst</context>
          <context context-type="linenumber">160</context>
        </context-group>
      </trans-unit>
    </body>
  </file>
</xliff>
