2. cnp3-ebook
3. English
4. Zen

180 ../../principles/linkstate.rst:62
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — These LSPs must be reliably distributed inside the network without using the router's routing table since these tables can only be computed once the LSPs have been received. The `Flooding` algorithm is used to efficiently distribute the LSPs of all routers. Each router that implements `flooding` maintains a `link state database` (LSDB) containing the most recent LSP sent by each router. When a router receives a LSP, it first verifies whether this LSP is already stored inside its LSDB. If so, the router has already distributed the LSP earlier and it does not need to forward it. Otherwise, the router forwards the LSP on all its links except the link over which the LSP was received. Flooding can be implemented by using the following pseudo-code. 752/10000 · 752
180 ../../principles/sharing.rst:1470
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In general, the links have a non-zero delay. This is illustrated in the figure below where a delay has been added on the link between `R` and `C`. 146/10000 · 146
180 ../../protocols/email.rst:289
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 0x14 4/10000 · 4
180 ../../protocols/ipv6.rst:635
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Until now, we have focused our discussion on the utilization of IPv6 on point-to-point links. Although there are point-to-point links in the Internet, mainly between routers and sometimes hosts, most of the hosts are attached to datalink layer networks such as Ethernet LANs or WiFi networks. These datalink layer networks play an important role in today's Internet and have heavily influenced the design of the operation of IPv6. To understand IPv6 and ICMPv6 completely, we first need to correctly understand the key principles behind these datalink layer technologies. 571/10000 · 571
180 ../../protocols/wifi.rst:141
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 657/10000 · 657
180 ../../protocols/tcp.rst:609
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The `TIME\_WAIT` state is different from the other states of the TCP FSM. A TCP entity enters this state after having sent the last `ACK` segment on a TCP connection. This segment indicates to the remote host that all the data that it has sent have been correctly received and that it can safely release the TCP connection and discard the corresponding :term:`TCB`. After having sent the last `ACK` segment, a TCP connection enters the `TIME\_WAIT` and remains in this state for :math:`2*MSL` seconds. During this period, the TCB of the connection is maintained. This ensures that the TCP entity that sent the last `ACK` maintains enough state to be able to retransmit this segment if this `ACK` segment is lost and the remote host retransmits its last `FIN` segment or another one. The delay of :math:`2*MSL` seconds ensures that any duplicate segments on the connection would be handled correctly without causing the transmission of an `RST` segment. Without the `TIME\_WAIT` state and the :math:`2*MSL` seconds delay, the connection release would not be graceful when the last `ACK` segment is lost. 1102/10000 · 1102
181 ../../glossary.rst:198
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The telnet protocol is defined in :rfc:`854` 44/10000 · 44
181 ../../principles/reliability.rst:941
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The main advantage of `go-back-n` is that it can be easily implemented, and it can also provide good performance when only a few frames are lost. However, when there are many losses, the performance of `go-back-n` quickly drops for two reasons : 245/10000 · 245
181 ../../principles/sharing.rst:1517
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Footnotes 9/10000 · 9
181 ../../protocols/email.rst:291
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 00010100 8/10000 · 8
181 ../../protocols/ipv6.rst:637
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As explained earlier, devices attached to a Local Area Network can directly exchange frames among themselves. For this, each datalink layer interface on a device (host, router, ...) attached to such a network is identified by a MAC address. Each datalink layer interface includes a unique hardwired MAC address. MAC addresses are allocated to manufacturers in blocks and interface is numbered with a unique address. Thanks to the global unicity of the MAC addresses, the datalink layer service can assume that two hosts attached to a LAN have different addresses. Most LANs provide an unreliable connectionless service and a datalink layer frame has a header containing : 671/10000 · 671
181 ../../protocols/wifi.rst:144
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — IP over 802.11 14/10000 · 14
181 ../../protocols/tcp.rst:611
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TIME\_WAIT on busy TCP servers 30/10000 · 30
181 ../../principles/linkstate.rst:76
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In this pseudo-code, `LSDB(r)` returns the most recent `LSP` originating from router `r` that is stored in the `LSDB`. `newer(lsp1, lsp2)` returns true if `lsp1` is more recent than `lsp2`. See the note below for a discussion on how `newer` can be implemented. 260/10000 · 260
182 ../../glossary.rst:226
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TLD 3/10000 · 3
182 ../../principles/reliability.rst:943
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `go-back-n` receiver does not accept out-of-sequence frames 63/10000 · 63
182 ../../principles/linkstate.rst:78
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Which is the most recent LSP ? 30/10000 · 30
182 ../../protocols/email.rst:293
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 000101 000000 13/10000 · 13
182 ../../protocols/ipv6.rst:639
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the source MAC address 22/10000 · 22
182 ../../protocols/wifi.rst:146
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 653/10000 · 653