2. cnp3-ebook
3. principles/sharing
4. English
5. Zen

106 ../../principles/sharing.rst:661
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The figure below shows the basic operation of CSMA/CA devices. Before transmitting, host `A` verifies that the channel is empty for a long enough period. Then, its sends its data frame. After checking the validity of the received frame, the recipient sends an acknowledgment frame after a short SIFS delay. Host `C`, which does not participate in the frame exchange, senses the channel to be busy at the beginning of the data frame. Host `C` can use this information to determine how long the channel will be busy for. Note that as :math:`SIFS<DIFS<EIFS`, even a device that would start to sense the channel immediately after the last bit of the data frame could not decide to transmit its own frame during the transmission of the acknowledgment frame. 752/10000 · 752
107 ../../principles/sharing.rst:668
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Operation of a CSMA/CA device 29/10000 · 29
108 ../../principles/sharing.rst:674
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The main difficulty with CSMA/CA is when two or more devices transmit at the same time and cause collisions. This is illustrated in the figure below, assuming a fixed timeout after the transmission of a data frame. With CSMA/CA, the timeout after the transmission of a data frame is very small, since it corresponds to the SIFS plus the time required to transmit the acknowledgment frame. 388/10000 · 388
109 ../../principles/sharing.rst:680
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Collisions with CSMA/CA 23/10000 · 23
110 ../../principles/sharing.rst:686
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To deal with this problem, CSMA/CA relies on a backoff timer. This backoff timer is a random delay that is chosen by each device in a range that depends on the number of retransmissions for the current frame. The range grows exponentially with the retransmissions as in CSMA/CD. The minimum range for the backoff timer is :math:`[0,7*slotTime]` where the `slotTime` is a parameter that depends on the underlying physical layer. Compared to CSMA/CD's exponential backoff, there are two important differences to notice. First, the initial range for the backoff timer is seven times larger. This is because it is impossible in CSMA/CA to detect collisions as they happen. With CSMA/CA, a collision may affect the entire frame while with CSMA/CD it can only affect the beginning of the frame. Second, a CSMA/CA device must regularly sense the transmission channel during its back off timer. If the channel becomes busy (i.e. because another device is transmitting), then the back off timer must be frozen until the channel becomes free again. Once the channel becomes free, the back off timer is restarted. This is in contrast with CSMA/CD where the back off is recomputed after each collision. This is illustrated in the figure below. Host `A` chooses a smaller backoff than host `C`. When `C` senses the channel to be busy, it freezes its backoff timer and only restarts it once the channel is free again. 1403/10000 · 1403
111 ../../principles/sharing.rst:693
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Detailed example with CSMA/CA 29/10000 · 29
112 ../../principles/sharing.rst:696
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The pseudo-code below summarizes the operation of a CSMA/CA device. The values of the SIFS, DIFS, EIFS and :math:`slotTime` depend on the underlying physical layer technology [IEEE802.11]_ 188/10000 · 188
113 ../../principles/sharing.rst:725
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Another problem faced by wireless networks is often called the `hidden station problem`. In a wireless network, radio signals are not always propagated same way in all directions. For example, two devices separated by a wall may not be able to receive each other's signal while they could both be receiving the signal produced by a third host. This is illustrated in the figure below, but it can happen in other environments. For example, two devices that are on different sides of a hill may not be able to receive each other's signal while they are both able to receive the signal sent by a station at the top of the hill. Furthermore, the radio propagation conditions may change with time. For example, a truck may temporarily block the communication between two nearby devices. 781/10000 · 781
114 ../../principles/sharing.rst:732
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The hidden station problem 26/10000 · 26
115 ../../principles/sharing.rst:738
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To avoid collisions in these situations, CSMA/CA allows devices to reserve the transmission channel for some time. This is done by using two control frames : `Request To Send` (RTS) and `Clear To Send` (CTS). Both are very short frames to minimize the risk of collisions. To reserve the transmission channel, a device sends a RTS frame to the intended recipient of the data frame. The RTS frame contains the duration of the requested reservation. The recipient replies, after a SIFS delay, with a CTS frame which also contains the duration of the reservation. As the duration of the reservation has been sent in both RTS and CTS, all hosts that could collide with either the sender or the reception of the data frame are informed of the reservation. They can compute the total duration of the transmission and defer their access to the transmission channel until then. This is illustrated in the figure below where host `A` reserves the transmission channel to send a data frame to host `B`. Host `C` notices the reservation and defers its transmission. 1053/10000 · 1053
116 ../../principles/sharing.rst:744
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Reservations with CSMA/CA 25/10000 · 25
117 ../../principles/sharing.rst:746
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The utilization of the reservations with CSMA/CA is an optimization that is useful when collisions are frequent. If there are few collisions, the time required to transmit the RTS and CTS frames can become significant and in particular when short frames are exchanged. Some devices only turn on RTS/CTS after transmission errors. 329/10000 · 329
118 ../../principles/sharing.rst:750
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Deterministic Medium Access Control algorithms 46/10000 · 46
119 ../../principles/sharing.rst:752
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — During the 1970s and 1980s, there were huge debates in the networking community about the best suited Medium Access Control algorithms for Local Area Networks. The optimistic algorithms that we have described until now were relatively easy to implement when they were designed. From a performance perspective, mathematical models and simulations showed the ability of these optimistic techniques to sustain load. However, none of the optimistic techniques are able to guarantee that a frame will be delivered within a given delay bound and some applications require predictable transmission delays. The deterministic MAC algorithms were considered by a fraction of the networking community as the best solution to fulfill the needs of Local Area Networks. 755/10000 · 755
120 ../../principles/sharing.rst:754
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Both the proponents of the deterministic and the opportunistic techniques lobbied to develop standards for Local Area networks that would incorporate their solution. Instead of trying to find an impossible compromise between these diverging views, the IEEE 802 committee that was chartered to develop Local Area Network standards chose to work in parallel on three different LAN technologies and created three working groups. The `IEEE 802.3 working group <http://www.ieee802.org/3/>`_ became responsible for CSMA/CD. The proponents of deterministic MAC algorithms agreed on the basic principle of exchanging special frames called tokens between devices to regulate the access to the transmission medium. However, they did not agree on the most suitable physical layout for the network. IBM argued in favor of Ring-shaped networks while the manufacturing industry, led by General Motors, argued in favor of a bus-shaped network. This led to the creation of the `IEEE 802.4 working group <http://www.ieee802.org/4/>`_ to standardize Token Bus networks and the `IEEE 802.5 working group <http://www.ieee802.org/5/>`_ to standardize Token Ring networks. Although these techniques are not widely used anymore today, the principles behind a token-based protocol are still important. 1277/10000 · 1277
121 ../../principles/sharing.rst:756
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The IEEE 802.5 Token Ring technology is defined in [IEEE802.5]_. We use Token Ring as an example to explain the principles of the token-based MAC algorithms in ring-shaped networks. Other ring-shaped networks include the defunct FDDI [Ross1989]_ or Resilient Pack Ring [DYGU2004]_ . A good survey of the early token ring networks may be found in [Bux1989]_ . 358/10000 · 358
122 ../../principles/sharing.rst:759
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A Token Ring network is composed of a set of stations that are attached to a unidirectional ring. The basic principle of the Token Ring MAC algorithm is that two types of frames travel on the ring : tokens and data frames. When the Token Ring starts, one of the stations sends the token. The token is a small frame that represents the authorization to transmit data frames on the ring. To transmit a data frame on the ring, a station must first capture the token by removing it from the ring. As only one station can capture the token at a time, the station that owns the token can safely transmit a data frame on the ring without risking collisions. After having transmitted its frame, the station must remove it from the ring and resend the token so that other stations can transmit their own frames. 802/10000 · 802
123 ../../principles/sharing.rst:767
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A Token Ring network 20/10000 · 20
124 ../../principles/sharing.rst:771
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — While the basic principles of the Token Ring are simple, there are several subtle implementation details that add complexity to Token Ring networks. To understand these details let us analyze the operation of a Token Ring interface on a station. A Token Ring interface serves three different purposes. Like other LAN interfaces, it must be able to send and receive frames. In addition, a Token Ring interface is part of the ring, and as such, it must be able to forward the electrical signal that passes on the ring even when its station is powered off. 553/10000 · 553
125 ../../principles/sharing.rst:773
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When powered-on, Token Ring interfaces operate in two different modes : `listen` and `transmit`. When operating in `listen` mode, a Token Ring interface receives an electrical signal from its upstream neighbor on the ring, introduces a delay equal to the transmission time of one bit on the ring and regenerates the signal before sending it to its downstream neighbor on the ring. 380/10000 · 380