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

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
126 ../../principles/sharing.rst:775
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first problem faced by a Token Ring network is that as the token represents the authorization to transmit, it must continuously travel on the ring when no data frame is being transmitted. Let us assume that a token has been produced and sent on the ring by one station. In Token Ring networks, the token is a 24 bits frame whose structure is shown below. 358/10000 · 358
127 ../../principles/sharing.rst:784
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 802.5 token format 18/10000 · 18
128 ../../principles/sharing.rst:789
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The token is composed of three fields. First, the `Starting Delimiter` is the marker that indicates the beginning of a frame. The first Token Ring networks used Manchester coding and the `Starting Delimiter` contained both symbols representing `0` and symbols that do not represent bits. The last field is the `Ending Delimiter` which marks the end of the token. The `Access Control` field is present in all frames, and contains several flags. The most important is the `Token` bit that is set in token frames and reset in other frames. 536/10000 · 536
129 ../../principles/sharing.rst:793
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Let us consider the five station network depicted in figure :ref:`fig-tokenring` above and assume that station `S1` sends a token. If we neglect the propagation delay on the inter-station links, as each station introduces a one bit delay, the first bit of the frame would return to `S1` while it sends the fifth bit of the token. If station `S1` is powered off at that time, only the first five bits of the token will travel on the ring. To avoid this problem, there is a special station called the `Monitor` on each Token Ring. To ensure that the token can travel forever on the ring, this `Monitor` inserts a delay that is equal to at least 24 bit transmission times. If station `S3` was the `Monitor` in figure :ref:`fig-tokenring`, `S1` would have been able to transmit the entire token before receiving the first bit of the token from its upstream neighbor. 862/10000 · 862
130 ../../principles/sharing.rst:796
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Now that we have explained how the token can be forwarded on the ring, let us analyze how a station can capture a token to transmit a data frame. For this, we need some information about the format of the data frames. An 802.5 data frame begins with the `Starting Delimiter` followed by the `Access Control` field whose `Token` bit is reset, a `Frame Control` field that enables the definition of several types of frames, destination and source address, a payload, a CRC, the `Ending Delimiter` and a `Frame Status` field. The format of the Token Ring data frames is illustrated below. 585/10000 · 585
131 ../../principles/sharing.rst:804
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 802.5 data frame format 23/10000 · 23
132 ../../principles/sharing.rst:807
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To capture a token, a station must operate in `Listen` mode. In this mode, the station receives bits from its upstream neighbor. If the bits correspond to a data frame, they must be forwarded to the downstream neighbor. If they correspond to a token, the station can capture it and transmit its data frame. Both the data frame and the token are encoded as a bit string beginning with the `Starting Delimiter` followed by the `Access Control` field. When the station receives the first bit of a `Starting Delimiter`, it cannot know whether this is a data frame or a token and must forward the entire delimiter to its downstream neighbor. It is only when it receives the fourth bit of the `Access Control` field (i.e. the `Token` bit) that the station knows whether the frame is a data frame or a token. If the `Token` bit is reset, it indicates a data frame and the remaining bits of the data frame must be forwarded to the downstream station. Otherwise (`Token` bit is set), this is a token and the station can capture it by resetting the bit that is currently in its buffer. Thanks to this modification, the beginning of the token is now the beginning of a data frame and the station can switch to `Transmit` mode and send its data frame starting at the fifth bit of the `Access Control` field. Thus, the one-bit delay introduced by each Token Ring station plays a key role in enabling the stations to efficiently capture the token. 1433/10000 · 1433
133 ../../principles/sharing.rst:809
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — After having transmitted its data frame, the station must remain in `Transmit` mode until it has received the last bit of its own data frame. This ensures that the bits sent by a station do not remain in the network forever. A data frame sent by a station in a Token Ring network passes in front of all stations attached to the network. Each station can detect the data frame and analyze the destination address to possibly capture the frame. 442/10000 · 442
134 ../../principles/sharing.rst:817
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The text above describes the basic operation of a Token Ring network when all stations work correctly. Unfortunately, a real Token Ring network must be able to handle various types of anomalies and this increases the complexity of Token Ring stations. We briefly list the problems and outline their solutions below. A detailed description of the operation of Token Ring stations may be found in [IEEE802.5]_. The first problem is when all the stations attached to the network start. One of them must bootstrap the network by sending the first token. For this, all stations implement a distributed election mechanism that is used to select the `Monitor`. Any station can become a `Monitor`. The `Monitor` manages the Token Ring network and ensures that it operates correctly. Its first role is to introduce a delay of 24 bit transmission times to ensure that the token can travel smoothly on the ring. Second, the `Monitor` sends the first token on the ring. It must also verify that the token passes regularly. According to the Token Ring standard [IEEE802.5]_, a station cannot retain the token to transmit data frames for a duration longer than the `Token Holding Time` (THT) (slightly less than 10 milliseconds). On a network containing `N` stations, the `Monitor` must receive the token at least every :math:`N \times THT` seconds. If the `Monitor` does not receive a token during such a period, it cuts the ring for some time and then re-initializes the ring and sends a token. 1482/10000 · 1482
135 ../../principles/sharing.rst:819
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Several other anomalies may occur in a Token Ring network. For example, a station could capture a token and be powered off before having resent the token. Another station could have captured the token, sent its data frame and be powered off before receiving all of its data frame. In this case, the bit string corresponding to the end of a frame would remain in the ring without being removed by its sender. Several techniques are defined in [IEEE802.5]_ to allow the `Monitor` to handle all these problems. If unfortunately, the `Monitor` fails, another station will be elected to become the new `Monitor`. 607/10000 · 607