南邮ip书后答案

1、Chapter 1 wirelessLa n an swerQuesti on:13.2 Single-cell wireless LAN: all of the wireless end systems are within range of a si ngle con trol module. Multiple-cell wireless LAN: there are multiple con trol modules in terc onn ected by a wired LAN; each con trol module supports a nu mber of wireless

2、end systems withi n its tran smissi on ran ge.13.3 An access point functions as a bridge to enable the linking of multiple separate 802.11 wireless LANs. A portal provides an interconnection point between an 802.11 wireless LAN and a wired LAN.13.4 It may or may not be.13.5Association: Establishes a

3、n initial association between a station and an AP.Authentication: Used to establish the identity of stations to each other .Deauthentication: This service is invoked whenever an existing authe nticati on is to be termi nated Disassociate n: A no tificati on from either a station or an AP that an exi

4、sting association is terminated. A station should give this no tificati on before leav ing an ESS or shutt ing dow n. Distributi on: used by stati ons to excha nge MAC frames whe n the frame must traverse the DS to get from a station in one BSS to a station in another BSSIntegration: enables transfe

5、r of data between a station on an IEEE 802.11 LAN and a station on an integrated IEEE 802.x LAN. MSDU delivery: delivery of MAC service data un its. Privacy: Used to preve nt the contents of messages from being read by other tha n the inten ded recipie nReassocatio n: En ables an established associa

6、tion to be transferred from one AP to another, allowing a mobile station to move from one BSS to ano ther.13.6 Mobility refers to the types of physical transitions that can be made by a mobile node within an 802.11 en vir onment (no tran siti on, moveme nt from one BSS to ano ther within an ESS, mov

7、eme nt from one ESS to ano therAssociatio n is a service that allows a mobile node that has made a transition to identify itself to the AP within a BSS so that the node can participate in data exchanges with other mobile no des.inic Hen lentDiiui+CFAlI下 POtlAPCFHilt!13.10Problem: 13.1Wired LANs beco

8、me part of a locati on's in frastructure and are therefore less flexible in maintenance and modificati on, however, the physical n ature of the wired LAN makes it in here ntly more con trollable. Wireless LANs are more flexible in impleme ntati on and modificati on, but require more complex main

9、tenance mecha ni sms because of their more fluid characteristics. Unique concerns for wireless LAN desig ners in clude: device power con sumpti on, quality and security of tran smissi on medium, lice nsing and other concerns related to the mobile n ature of the tech no logy.Chapter3 ipv618.6 Traffic

10、 Class (8 bits): Available for use by origi nati ng no des an d/or forwardi ng routers to ide ntify and disti nguish betwee n differe nt classes or priorities of IPv6 packets. The first six bits of the traffic class field are referred to as the DS (differentiated services) field, discussed in Chapte

11、r 19. The remaining 2 bits are reserved for an ECN (explicit congestion notification) field, currently in the process of sta ndardizati on Flow Label (20 bits): May be used by a host to label those packets for which it is requesting special handling by routers within an etwork. All packets that are

12、to be part of the same flow are assig ned the same flow label by the source.18.7 Uni cast: An ide ntifier for a si ngle in terface. A packet sent to a uni cast address is delivered to the in terface ide ntified by that addressA nycast: An ide ntifier for a set of in terfaces (typically bel onging to

13、 differe nt no des). A packet sent to anany cast address is delivered to one of the in terfaces ide ntified by that address (the "nearest" one, according to the routing protocols* measure of distanee). Multicast: An ide ntifier for a set of in terfaces (typically bel onging to differe nt n

14、o des). A packet sent to a multicast address is delivered to all in terfaces identified by that address.18.8 Hop-by-Hop Options header: Defines special options that require hop-by-hop process in g.Routi ng header: Provides exte nded rout ing, similar to IPv4 source routing. Fragment header: Contains

15、 fragmentation and reassembly information. Authentication header: Provides packet integrity and authentication.En capsulati ng Security Payload header: Provides privacy. Desti natio n Options header: Contains optional information to be examined by the dest in atio n no de.18.22 ?Version: Same field

16、appears in IPv6 header; value changes from 4 to 6.?IHL: Elim in ated; not n eeded since IPv6 header is fixed len gth.?Type of Service: This field is eliminated. Three bits of this field define an 8- level precede nce value; this is replaced with the priority field, which defi nes an 8-level precede

17、nce value for non-con gesti on-con trol traffic. The rema iningbits of the type-of-service field deal with reliability, delay, and throughput; equivale nt fun cti on ality may be supplied with the flow label filed.?Total Length: Replaced by Payload Length field.?Identification: Same field, with more

18、 bits, appears in Fragment header. ?Flags: The More bit appears in the Fragment header. In IPv6, only source fragmenting is allowed; therefore, the Don't Fragment bit is eliminated.?Fragme nt Offset: Same field appears in Fragme nt header?Time to Live: Replaced by Hop Limit field in IPv6 header,

19、 with in practice the same in terpretatio n.?Protocol: Replaced by Next Header field in IPv6 header, which either specifies the n ext IPv6 exte nsion header, or specifies the protocol that uses IPv6.?Header Checksum: This field is elim in ated. It was felt that the value of this checksum was outweig

20、hed by the performa nee pen alty.?Source Address: The 32-bit IPv4 source address field is replaced by the 128- bit source address in the IPv6 header.?Destination Address: The 32-bit IPv4 destination address field is replaced by the 128-bit source address in the IPv6 header.18.23 The recommended orde

21、r, with comments:1. IPv6 header: This is the only mandatory header, and will indicate if one or more additional headers follow.2. Hop-by-Hop Options header: After the IPv6 header is processed, a router will n eed to exam ine this header immediately afterwards to determ ine if there are any opti ons

22、to be exercised on this hop.3. Destination Options header: For options to be processed by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the Routing header. This header must precede the routi ng header, because it contains in struct io

23、ns to the node that receives this datagram and that will subseque ntly forward this datagram using the Rout ing header in formati on.4. Routing header: This header must precede the Fragment header, which is processed at the final dest in ati on, whereas the rout ing header must be processed by an in

24、 termediate no de.5. Fragment header: This header must precede the Authentication header, because authe nticati on is performed based on a calculati on on the origi nal datagram; therefore the datagram must be reassembled prior toauthe nticati on.6. Authentication header: The relative order of this

25、header and the En capsulat ing Security Payload header depe nds on the securitycon figurati on. Gen erally, authe nticati on is performed before en crypti on so that the authe nticati on in formatio n can be convenien tly stored with the message at the destination for later referenee. It is more con

26、venient to do this if the authe nticati on in formati on applies to the unen crypted message; otherwise the message would have to be re-e ncrypted to verify the authe nticati on in formati on.7. En capsulat ing Security Payload header: see precedi ng comme nt.8. Destination Options header: For optio

27、ns to be processed only by the final desti nati on of the packet. These opti ons are only to be processed after the datagram has bee n reassembled (if n ecessary) and authe nticated (ifn ecessary). If the En capsulat ing Security Payload header is used, the n this header is en crypted and can only b

28、e processed after process ing that header. There is no adva ntage to plac ing this header before the En capsulat ing Security Payload header; one might as well en crypt as much of the datagram as possible for security.18.24 These answers are taken from RFC 1809U sing the Flow Label Field in IPv6(Ju

29、ne 1995).a. The IPv6 specification allows routers to ignore Flow Labels and also allows for the possibility that IPv6 datagrams may carry flow setup in formatio n in their options. Unknown Flow Labels may also occur if a router crashes and loses its state. During a recovery period, the router will r

30、eceive datagrams with Flow Labels it does not know, but this is arguably not an error, but rather a part of the recovery period. Fin ally, if the con troversial suggesti on that each TCP conn ecti on be assig ned a separate Flow Label is adopted, it may be n ecessary to man age Flow Labels using an

31、LRU cache (to avoid Flow Label cache overflow in routers), i n which case an active butin freque ntly used flow's state may have bee n in ten ti on ally discarded. In any case, it is clear that treat ing this situatio n as an error and, say dropp ing the datagram and sending an ICMP message, is

32、in appropriate. In deed, it seems likely that in most cases, simply forwarding the datagram as one would a datagram with a zero Flow Label would give better service to the flow tha n dropp ing the datagram.b. An example is a router which has two paths to the datagram's destination, one via a hig

33、h-bandwidth satellite link and the other via a low-bandwidth terrestrial li nk. A high ban dwidth flow obviously should be routed via the high-bandwidth link, but if the router loses the flow state, the router may route the traffic via the low-bandwidth link, with the potential for the flow's tr

34、affic to swamp the low-bandwidth link. It seems likely, however, these situati ons will be excepti ons rather tha n the rule.18.25 These answers are taken from RFC 1809.a. An internet may have partitioned since the flow was created. Or the deletion message may be lost before reach ing all routers. F

35、urthermore, the source may crash before it can send out a Flow Label deletion message.b. The obvious mechanism is to use a timer. Routers should discard Flow Labels whose state has not bee n refreshed withi n some period of time. Atthe same time, a source that crashes must observe a quiet time, duri

36、ng which it creates no flows, until it knows that all Flow Labels from its previous life must have expired. (Sources can avoid quiet time restricti ons by keep ing in formatio n about active Flow Labels in stable storage that survives crashes). This is precisely how TCP initial seque nee nu mbers ar

37、e man aged and it seems the same mecha nism should work well for Flow Labels.18.26 Again, RFC 1809:The argume nt in favor of using Flow Labels on in dividual TCP connections is that eve n if the source does not request special service, a n etwork provider's routers may be able to recog nize a la

38、rge amount of traffic and use the Flow Label field to establish a special route that gives the TCP conn ecti on better service (e.g., lower delay or bigger ban dwidth).Ano ther argume nt is to assist in efficie nt demux at the receiver (i.e., IP and TCP demux ing could be done on ce).An argume nt ag

39、a inst using Flow Labels in in dividual TCP conn ecti ons is that it cha nges how we han dle route caches in routers. Curre ntly one can cache a route for a desti nati on host, regardless of how many differe nt sources are sending to that desti nati on host. Thus, if five sources each have two TCP c

40、onnections sending data to a server, one cache entry containing the route to the server handles all ten TCPs' traffic. Putting Flow Labels in each datagram cha nges the cache into a Flow Label cache, in which there is a cache en try for every TCP conn ecti on. So there's a pote ntial for cac

41、he explosi on. There are ways to alleviate this problem, such as man agi ng the Flow Label cache as an LRU cache, in which in freque ntly used Flow Labels get discarded (and the n recovered later). It is not clear, however, whether this will cause cache thrashi ng.Observe that there is no easy compr

42、omise betwee n these positi ons. One cannot, for instanee, let the application decide whether to use a Flow Label. Those who want different Flow Labels for every TCP connection assume that they may optimize a route without the application's knowledge. Forcing all applications to use Flow Labels

43、will force routing ven dors to deal with the cache explosi on issue, eve n if we later discover that we don't want to optimize in dividual TCP conn ecti ons.18.27 From RFC 1809:During its discussions, the End-to-End group realized this meant that if a router forwarded a datagram with an unknown

44、Flow Label, it had to ignore the Priority field, because the priority values might have been redefined. (For instanee, the priorities might have been in verted). The IPv6 com munity con cluded this behavior was un desirable. In deed, it seems likely that whe n the Flow Label is unknown, the router w

45、ill be able to give much better service if it uses the Priority field to make a more in formed routi ng decisi on.18.28 From RFC 1883:A Routing header is not examined or processed until it reaches the node identified in the Dest in ati on Address field of the IPv6 header. I n that no de, dispatch in

46、g on the Next Header field of the immediately preceding header causes the Routing module to be invoked, which, in the case of Routing Type 0, performs the following algorithm: ?If Next AddrvNumAddrs, swap the IPv6 Dest in ati on Address andAddress Next Addr, the n in creme nt Next Addr by on e. If b

47、it n of the Strict/Loose Bit Mask has value 0, where n equals the new value of Next Addr, or if the new Destination Address ide ntifies a n eighbor of the process ing no de, re-submit the packet to the IPv6 module for forwardi ng to the new dest in ati on. Otherwise, send an ICMP Desti nati on Un re

48、achable-Not a Neighbor message to the Source Address and discard the packet.?If Next Addr = NumAddrs, dispatch to the next header processing module, as identified by the Next Header field in the Routing header.?If Next Addr>NumAddrs, se nd an ICMP Parameter Problem, Code 0, message to the Source

49、Address, pointing to the NumAddrs field, and discard the packet.Chapter4 mobile ip19.14 a. IP datagram arriving at R1 from Internet (using header formats of Figure 12.7a):IP-HDA = IPDA(Rl)IP-HDA = IPDA(HA-A)TCP-H DataMAC frame leavi ng R1 onto LAN X:MAC-HDA = MACDA(A-X)LLC-HDSAP = DSAP (A)IP-HDA = I

50、PDA(HA-A)CP-H Datab. IP datagram arriving at R1 from Internet (using header formats of Figure 12.7b):IP-HDA = IPDA(Rl)IP-HDA = IPDA(HA-A)TCP-H DataMAC frame leavi ng R1 onto LAN X:MAC-HDA = MACDA(A-X)LLC-HDSAP = DSAP (A)IP-HDA = IPDA(HA-A)TCP-H Datac. IP datagram arriving at R1 from Internet (using

51、header formats of Figure 12.7a):IP-HDA = IPDA(A-X)IP-HDA = IPDA(HA-A)TCP-HDataMAC frame leavi ng R1 onto LAN XMAC-HDA = MACDA(A-X)LLC-HDSAP = DSAP(A)IP-HDA =IPDA(A-X)IP-H DA = IPDA(HA-A)TCP-HDatad. IP datagram arriving at R1 from Internet (using header formats of Figure 12.7b):IP-HDA = IPDA(A-X)IP-H

52、DA = IPDA(HA-A)TCP-HDataMAC frame leavi ng R1 onto LAN X:MAC-HDA = MACDA(A-X)LLC-HDSAP = DSAP(A)IP-H DA = IPDA(A-X)IP-HDA =IPDA(HA-A)TCP-HData19.15 Home address, care-of address, lifetime.19.16 Home address, home age nt address, MAC address, lifetimeChapter 5 con gesti on con trol20.1 Two general st

53、rategies can be adopted. The first such strategy is to discard any incomingpacket for which there is no available buffer space. The alter native is for the node that is experie ncing these problems to exercise some sort of flow con trol over its n eighbors so that the traffic flow rema ins man ageab

54、le.20.2 Here is a simple intuitive explanation of why delay must go to infinity. Suppose that each node in the n etwork is equipped with buffers of infin ite size and suppose that the in put load exceeds n etwork capacity. Un der ideal con diti ons, the n etwork will con ti nue to sustai n a normali

55、zed throughput of 1.0. Therefore, the rate of packets leaving the network is 1.0. Because the rate of packets en teri ng the n etwork is greater tha n 1.0 internal queue sizes grow. In the steady state, with in put greater tha n output, these queue sizes grow without bound and therefore queu ing del

56、ays grow without bound.20.3 Backpressure: This technique produces an effect similar to backpressure in fluids flowing dow n a pipe. It invo Ives lin k-by-li nk use of flow con trol in a directi on toward the source. Choke packet: A choke packet is a con trol packet gen erated at a con gested node an

57、d tran smitted back to a source node to restrict traffic flowm plicit con gesti on sig nali ng: If a source is able to detect in creased delays and packet discards, the n it has implicit evide nce of n etwork con gesti on .Explicit con gesti on sig nali ng: In gen eral terms, for explicit con gesti

58、on avoida nce, the n etwork alerts end systems to grow ing con gesti on within the n etwork and the end systems take steps to reduce the offered load to the netwoPolicing: A node in then etwork, typically the node to which the end system attaches, mon itors the traffic flow and compares it to the tr

59、affic con tract. Excess traffic is either discarded or marked to in dicate that it is liable to discard or delay.20.4 Backward: Notifies the source that congestion avoidance procedures should be initiated where applicable for traffic in the opposite direct ion of the received no tificatio n. It in dicates that