[ Pobierz całość w formacie PDF ]
.2.Assuming that the network layer provides the equivalent of network layer multicastaddresses or simply that many servers of a certain type might all advertise a well-known network layer address, a source might want to do an expanding search to findthe closest station that answers a particular address.For this use, again, a simplehop count field would suffice.The source might first issue the packet with a very smallcount, and then, if no reply was received, the source might reissue the packet with alarger count, continuing the process until it either finds something or decides that thesearch is too expensive.3.The traceroute utility is a clever hack designed to force each router along the path, inturn, to return an error report.It works by setting the TTL first to 1 (causing the firstrouter to send an error report back to the source) and then setting it to 2 (causing thenext router to send an error report) and so forth until the packet reaches thedestination.A hop count field is preferable to a timer for this use.4.To reuse connection identifiers and similar fields, certain transport protocols needassurances from the network layer that packets will not live in the network longer thana certain amount of time.A hop count would not solve this problem because a packetmight be delayed a very long time at one router.The granularity of the lifetime field in both IP and CLNP, along with the difficulty of estimation,makes this field not very useful for purpose 4.For example, it is impossible to estimate thisfield when a router transmits a packet onto a bridged extended LAN.After the router hassuccessfully transmitted the packet onto its local LAN, the packet can be delayed for as longas 2 seconds per bridge.With the stipulation in CLNP that every router overestimate ratherthan underestimate, this implies that a router would need to decrement the CLNP lifetime fieldby 30 (half-seconds) each time the packet was forwarded onto a LAN.In another example, it is not feasible to estimate an absolute upper limit on the delay whenyou're transmitting onto FDDI (fiber distributed data interface).Usually, there is a very smalldelay before a station gets permission to transmit on FDDI, but in the worst case the delaycan be as long as 150 sec.Thus, theoretically, to comply with the CLNP overestimateconstraint a router would need to decrement the lifetime field by 300 (half-seconds), which islarger than the maximum value of the field (255).I believe that the only reasonable solution to the problem of guaranteeing the transport layer amaximum packet lifetime is to have the transport layer use large enough fields so that, giventhe natural characteristics of the network, there is an acceptable probability that they will notbe reused.Pretending that the lifetime field is accurate enough, or that it gives sufficientgranularity to be useful and safe, is not realistic.In fact, most router implementations treat thefield as a simple hop count.In IPX, DECnet, AppleTalk, and IPv6, the field is specified as a hop count (rather than a time)and is decreased or increased by exactly 1 at each router hop.As discussed in Section 8.3,it is preferable to count down rather than to count up.IPX, DECnet, and AppleTalk all countup.IPv6 counts down. In AppleTalk the field is 4 bits long.That is definitely not big enough, although the twoadjacent "reserved" bits can potentially be used as an extension to the field at some futuretime (although backward compatibility may be awkward).In DECnet it is 6 bits long.In IPX,IPv4, and IPv6 it is 8 bits long.Perhaps there might be paths longer than 256 hops, in whichcase it would be better to have a larger field.One argument against making it bigger (whichwas discussed for IPv6) is that then a looping packet would take longer to get discovered.Butrefuting this argument is easy.The field can be arbitrarily large, but it's not necessary to usethe full value.Especially given that IPv6 counts down, it is easy to have endnodes, by default,set the "hops remaining" field to something reasonable in today's networks (say, 100) buthave the field large enough and have packet sources configurable to be able to launchpackets with larger hops-remaining fields if necessary.The other argument against makingthe field bigger is that it wastes room in the header.But a single extra bit doubles the possiblepath lengths, so this hardly seems like a strong argument.10.4.13 VersionIPv4, IPv6, CLNP, and DECnet have a "version" field.The others do not.The lack of aversion field in IPX forced us to be creative in order to add features.We wound up defining anew destination socket number to mean that extra header information followed the old IPXheader.AppleTalk did the annoying thing of using the frame format (Ethernet versus 802.3) todecide the version of the AppleTalk packet, which caused problems for bridges (see Section3.6.3).In IPv4 and IPv6, this field is 4 bits long.However, it's not really a version number in the usualsense because version = 5 is not a newer version of IP.In CLNP, the version field is 8 bitslong.In IPv4, the value is 4; in IPv6, the value is 6; in CLNP, the value is 1.DECnet has a 1-bit version field! The designers did that on purpose because they never wanted to have to becompatible with more than one old version.If version is not the expected value, the packet is supposed to be discarded without an errorpacket's being generated.(Theoretically, the packet cannot necessarily be parsed to find thesource address, to which an error report would be transmitted
[ Pobierz całość w formacie PDF ]