Magazine - 1000 BiT

More documents

Recommendations

Info

~~scd to store Iicccssar!z ciata and pointers; hr mostfunction calls, it is only necessary to pass a pointerto tliis structure. Tliis redl~ccs the stack o\.erhcad ,lndalso !riclds mod~llar ,)lid c:~sil\r cstcnsible subroutines.lPl.6 lias a cicdic.~tcd interrupt processing thread,,lnd rccci\,cci 111.6 packets arc placed onto thcir o\\,ninterface inp~~r queue (ifcll~cuc). PVhcn an Ih.6 pacl,~cltcts ,11-c checked to scc that thedestination m,ltcIics one of tlic system's ndcircsscs. Intlic special cnsc of the pacltct bcing t'irgctcd to a linkloc.ilacicircss, only tlic link-loc~ll .~dtfrcss for the recci\ringintcrhcc is comp,lrcd. If there is ,in exact match,the p~cltct is proccsscd normnlly; otlicr\visc, it isp'lsscd to tlic ~~nicast pacltct for\varding ro~~tinc.Header ProcessingAkcr ,i pacl
message contains the MTU of the constricting linlc.The source node adjusts its packet size to fit throughthis link.Path MTU information is kept on a per-destinationbasis and is stored in the ro~lting table entry for a givendestination. Packcts sent on that route \\,ill bc sizedaccording to the path MTU value. When a PTB messageis received, the appropriate route is updated tocontain the new path IMTU value as reported in thePTB message, and a tirner is started. When the timerexpires, tlic path MTU value is increased to the(known) MTU of the first hop link. This allows thenodc to detect increases in the path IMTU.Switches are provided to disable path lMTU discoverysystem-widc, on a per-destination basis and ona pa-socket basis. When path LMTU discovery is disabled,packets are limited to 576 bytes.FragmentationA packet that is larger than the lMTU of tlie path onwhich it is to be sent must be fragmented. Unlike IPv4,the IPv6 header contains no fields to carry fiagmentationinformation. Instead, this infor~nation is carriedin a specialized estension header, called the fragmentheader. As shown in Figure 3, the fields in the fragmenthcader include an offset, in eight octet units, andan identifier common to all fragments of the originalpacltct. 1M (managed) flag is used to indicate internicdiatefragments; the terminal fragment has the bitRESERVED\ \NEXT HEADER RESERVED FRAGMENT OFFSET \ 1 MI IDENTIFICATION 1Figure 3Fragment Headercleal-ed. Note that the amount of data in a fragmentpacket is derived from the total pacltct length.The first step in the fragmentation process isto idcntifjl the fragmentable and unfragmentable partsof the original pacltet (see Figure 4). 'The unfragnicntablepart ofthc paclcet consists of the Il'v6 headerand any estension lieadcrs that must be processed byeach node traversed by the pacltet (c.g., hop-by-hopheader, routing header). The fragment Iieadcr isappended to the unfragmcntable part. The rest of thepaclcet is divided into fragments, and each fragment isappended to a copy of the LIII~I-agmcntable part plusfragnlent headcr.When the fragment header is appended to theu~lfrngmentable part, nvo fields in the unfragmentablepart must be updated. First, the payload length field inthe IPv6 header 11111st be upciated to reflect thc lengthoftlie fragment pacltct. Second, the ncxt header fieldin the last header of the unfi-agmcntable part must bcchanged to indicate that a fragnient headcr follo\\s.A copy of the unfragmentable part is created foreach fragment packet. As an optin~izntion, DigitalUNIS allo\vs portions of a pacltrt to be shared amongcopies of the paclwt, to avoid an actual data copy. Aswith IPv4, care must be taken to clls~~re tl~at fieldsbeing updated are not co~itai~led in shared buffers.This is typically accomplished by copying tlie portionsthat 1n11st be updated into a private memory buffer(mbuf). Unlilte IPv4, the ~~nfragmentable part maynot fit in a single mbuf, and the Il'v6 fag~nentationcode must be capable of handling this case.To reduce the possibility of fragment loss at thesource node, all tlie fragnient pacltets arc built beforeany is passed to thc data link for transmission.A question that arises herc is how big shouldthe fragment pacltets be? Should they be sized accordingto the path IMTU, or sho~~ld they be limited to576 bytes? The former yields the desirable largerFRAGMENTABLE PARTORIGINAL PACKET .UNFRAGMENTABLE FIRST1 SECOND 1 ,'.:IPARTFRAGMENT FRAGMENT FRAGMENTFRAGMENT PACKETSUNFRAGMENTABLE FRAGMENT FIRSTI PART 1 HEADER I FRAGMENT 1UNFRAGMENTABLE FRAGMENT SECOND1 PART I HEADER I FRAGMENT II PARTFigure 4Fragmcn tationDigitdl Tccllnic.il Jour1l.11 Vo1. 8 No. 3 1996 9
Page 1: IINTERNET PROTOCOL V.6DigitalTechni
Page 6 and 7: lie! elements of the protocol,Digit
Page 8 and 9: Intcrnct. Within tlic IETt', severa
Page 12 and 13: packets, \\,hilt the latter avoids
Page 14 and 15: * Test address for IPv4 characteris
Page 16 and 17: ROUTER SOLICITATIONTYPECODECHECKSUF
Page 18 and 19: 7 .ncn\.orlt. The solution is to al
Page 20 and 21: AUTOCONFIGURATIONPROCESSINGUSER SPA
Page 22 and 23: pilssing tlic olx~i x)ckcts to them
Page 24 and 25: James P. BoundJIII~ Bol~nd 15 ,I co
Page 26 and 27: process of restoring a p;~rtic~~I~r
Page 28 and 29: Table 2 (continued)Year Item Descri
Page 30 and 31: Table 3Goals of the Australian Digi
Page 32 and 33: fidelity, tlic tcst of \\~liicli is
Page 34 and 35: An important consideration is that
Page 36 and 37: Table 8Architectures Implemented by
Page 38 and 39: ucoder~ novaNOVA simulator V2.2bsim
Page 40 and 41: BiographiesMaxwell M. BurnetMax Bur
Page 42 and 43: no\\. tli;it appropriate stantlards
Page 44: High Perfor~nance Fortran V1.l is c
Page 47 and 48: 5. For ca;i~i~l~lc scc /'I.OC.CY'L/
Page 49 and 50: tllc s\,stcIn under test to use the
Page 51 and 52: WAREHOUSEW.89,0.000089'WDISTRICTW'1
Page 53 and 54: III 8-CPU. 8-GB 8-CPU, 8-GB II -II
Page 55 and 56: ~ILI~LIC. In othcr \\.orcis, the gr
Page 57 and 58: ~norc to ~ I ~ S L Ithe I . ~ ~.cj>
Page 59 and 60: 13. 1)igital Eqi~ip~ncnt Corporatio
Page 61 and 62:
TPC-C Benchmark7 -.I. lie TPC-C bcn
Page 63 and 64:
Lock OptimizationL,ocl
Page 65 and 66:
DATABASE CACHE SIZE IN GBFigure 2Ua
Page 67 and 68:
Engineering Group); Marl< Davis and
Page 69 and 70:
H\,pcrtc\-t Transfer I'rotocol (HTT
Page 71 and 72:
Grc~pliical objccts such as definit
Page 73 and 74:
select box part of the toollcit pro
Page 75 and 76:
work on it was limited, \ve divided
Page 77 and 78:
Further ReadingsThc Digital Technic
Page 79 and 80:
J. Iroccssor," PI-ocec~di7rg.i ?/'l
Page 81 and 82:
B. Lce, E. Atnkov, and J. ClementM.
Page 83:
Printcd in U.S.A. EC-N7285-18/9612
show all

Magazine - 1000 BiT

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?