Presentation is loading. Please wait.

Presentation is loading. Please wait.

SMUCSE 4344 network layer (slide set 3). SMUCSE 4344 congestion control algorithms general principles of congestion control congestion prevention policies.

Similar presentations


Presentation on theme: "SMUCSE 4344 network layer (slide set 3). SMUCSE 4344 congestion control algorithms general principles of congestion control congestion prevention policies."— Presentation transcript:

1 SMUCSE 4344 network layer (slide set 3)

2 SMUCSE 4344 congestion control algorithms general principles of congestion control congestion prevention policies congestion control in virtual-circuit subnets congestion control in datagram subnets load shedding jitter control

3 SMUCSE 4344 factors contributing to congestion output queueing 1) multiple input streams vie for one egress link 2) queue eats up memory => load shedding 3) very long queues => sender timeout, re-txn slow CPUs low-capacity egress lines

4 SMUCSE 4344 congestion when too much traffic is offered, congestion sets in and performance degrades sharply

5 SMUCSE 4344 general principles flow control: pt-to-pt issue – one src => one sink congestion: subnet system issue question of balancing resources – open loop control: pre-computed, static design – closed loop control: dynamic, on-line, reactive

6 SMUCSE 4344 control theoretic systems view open loop (action at source or sink) –balance resources using static algorithms closed loop (implicit or explicit feedback) –balance resources dynamically using feedback –monitor system detect when and where congestion occurs –pass info to where action can be taken –adjust system operation, correct problem

7 SMUCSE 4344 measuring congestion # packets dropped (buffer space exceeded) average queue length # packets timed out average packet delay standard deviation of packet delay

8 SMUCSE 4344 open loop system congestion prevention link layer and transport layer –source-to-sink flows –go back n, selective repeat –window size controls flow rate network layer –many static choices available transport layer –nwk layer round-trip variance >> link round-trip –timeout hard to fine-tune

9 SMUCSE 4344 open loop congestion prevention 5-26 Timeout policy

10 SMUCSE 4344 closed loop systems explicit feedback –congested router warns source to cut back implicit feedback –source estimates congestion by local observation average ACK delay ACK delay trend approaches –increase resources –decrease load

11 SMUCSE 4344 propagation of congestion metrics send control packets –extra load “congestion field” in all packets “congestion probe” packets timing of reaction

12 SMUCSE 4344 closed loop congestion control in VC nwks admission control –“busy signal” –no new virtual circuits provisioned while congested resource reservation (memory, bandwidth) –allowed load, shape of traffic, QoS –regular circuit-switched bandwidth penalty route new VCs to avoid congestion

13 SMUCSE 4344 routing around congestion in VC subnets (a) congested subnet; (b) “pruned” subnet for new routing

14 SMUCSE 4344 generic congestion control each router maintains some set of state –queue length, dropped packets, link utilization, etc. –example: exponential weighted link utilization u: sampled instantaneous link utilization f in {0,1} u new = au old + (1 - a)f, for depreciation factor a (u new > threshold) => trigger sources respond to congestion feedback –binary window size reduction: ½, ¼, etc. –slower window expansion after trouble passes

15 SMUCSE 4344 congestion “messages” warning bit –DECNET, frame relay –congested router sets warning bit in packet –destination sets warning bit in ACK –source throttles back volume –response a bit sluggish choke packet –router tags congesting packet (“no more chokes”) –sends choke packet (mild, stern, kill) to source –source throttles back volume

16 SMUCSE 4344 hop-by-hop choke packets routers cooperate to choke flow sooner at each hop to source, half of flow is buffered; choke packet sent on toward source quick relief (a)regular choke packet example (b)hop-by-hop choke packet

17 SMUCSE 4344 load shedding (dropping packets) random strategy –drop any old packet “wine”: older packets are more valuable –situation: file transfer (no bit left behind) “milk”: newer packets are more valuable –situation: real-time flows (voice or multimedia) priority schemes random early detection (RED) (implicit fdbk) –drop a packet, no notification (Floyd/Jacobson)

18 SMUCSE 4344 jitter: unsteady arrival of packets metric: inter-packet arrival time (IPAT) low jitter: near constant IPATs high jitter: widely varying IPATs obtaining low jitter en route –FIFO slows the fast packets –rxr buffering for streaming, not for real-time

19 SMUCSE 4344 Quality of Service: QoS requirements techniques for achieving good QoS integrated services differentiated services label switching and MPLS

20 SMUCSE 4344 QoS requirements “flow”: end-to-end packet stream –connection-oriented: all packets on one path –connectionless: opportunistic path(s) flow metrics –reliability –delay –jitter –bandwidth

21 SMUCSE 4344 stringency of QoS requirements streaming real-time (no cksums)

22 SMUCSE 4344 QoS in ATM networks major ATM QoS categories: –CBR (circuit emulation) –real-time VBR –non-real-time VBR –available bit rate

23 SMUCSE 4344 achieving desired QoS over-provisioning –data traffic is bursty, so huge overcapacity is required to handle large bursts –Ethernet access links: 7X – 10X is common buffering at the receiver (non-real-time flows) –artificial delay, slow packets arrive before use –reduces jitter traffic shaping –at server and/or router

24 SMUCSE 4344 buffering at the receiver streaming content to a media playback device

25 SMUCSE 4344 traffic shaping data flow regulation –rate –burstiness SLAs –agreed (contractual) QoS parameters for flows –most expensive: real-time flows traffic policing

26 SMUCSE 4344 implementing traffic shaping leaky bucket token bucket resource reservation admission control proportional routing packet scheduling –fair queueing –weighted fair queueing

27 SMUCSE 4344 leaky bucket algorithm queue (the bucket) –enqueue arriving packets metered delivery (the leak) –enforcement of CBR txn X packets per tick (regular time interval) Y bytes per tick (implemented with byte counter) –constrains txn to max rate

28 SMUCSE 4344 leaky bucket illustration (a) leaky water bucket; (b) leaky packet bucket

29 SMUCSE 4344 token bucket algorithm output queue feeds this mechanism: token bucket has max capacity –burst length limited by bucket size token bucket stores packet txn “credits” –or byte transmission credits if token bucket is not empty, arriving flow is sent out at line rate after bucket empties, token arrival rate limits transmission rate token bucket does no load shedding

30 SMUCSE 4344 token bucket illustration (a) before; (b) after 5-34

31 SMUCSE 4344 leaky bucket, token bucket (a)1 MB flow input at line rate (b)2 MB/s leaky bucket output 2 MB/s token buckets: (c) 250 KB (d) 500 KB (e) 750 KB (f) 500KB token bucket feeding a 10-MB/s leaky bucket -pipe capacity: 25 MB/s

32 SMUCSE 4344

33 SMUCSE 4344 admission control reservation of resources is available arriving load can be shaped flow negotiation –sender, receiver(s), routers on path(s) –sender’s flow specification

34 SMUCSE 4344 flow specification min size packet: same overhead per packet tighter flow specs are better

35 SMUCSE 4344 proportional routing; packet scheduling flows may be spread across multiple paths packet scheduling –fair queueing flow queues for each output line round robin, by packet or by byte count –weighted fair queueing give better service to certain flows

36 SMUCSE 4344 packet scheduling example (a) router with five packets queued for output line O (b) finishing times for the five packets (c) sent in sorted order

37 SMUCSE 4344 integrated services flow-based QoS IETF streaming multimedia architecture unicast, multicast dynamic group membership

38 SMUCSE 4344 Resource reSerVation Protocol: RSVP multiple senders to multiple receiver groups receivers switch channels freely optimized bandwidth usage eliminates congestion setup must be accomplished in advance per-flow state in routers complex implementation

39 SMUCSE 4344 RSVP receivers reserve path by reverse path forwarding up tree to source(s)

40 SMUCSE 4344 RSVP (2) shared paths have capacity for largest flow

41 SMUCSE 4344 differentiated services: DiffServ IETF class-based QoS schemes much simpler than RSVP –local implementation –no advance setup, no end-to-end negotiation defined service class specifics –delay, jitter, discard probability supports agreed traffic shapes –specific leaky/token bucket rates, etc

42 SMUCSE 4344 expedited forwarding simplest of DiffServ schemes regular class + expedited class expedited class gets preferred treatment –expedited queue –regular queue example –10% of traffic is expedited class –expedited queue gets 20% of service weight

43 SMUCSE 4344 expedited forwarding illustration two logical pipes –expedited pipe gets disproportionate service

44 SMUCSE 4344 assured forwarding DiffServ scheme with 12 service classes –four priorities –three discard probabilities packet flows are classified, marked, and shaped at point of entry to network –IP header Type of Service field

45 SMUCSE 4344 assured forwarding illustration architecture of DiffServ assured forwarding network packet injection

46 SMUCSE 4344 MultiProtocol Label Switching (MPLS) datagram flow tagging or labeling (like ATM) IETF: MPLS, GMPLS switching/routing distinction no tag or label field in packet or frame header

47 SMUCSE 4344 MPLS layer encapsulation encapsulation by successive layers: PPP: layer 2; MPLS, layer “2.5”; IP, layer 3; TCP, layer 4

48 SMUCSE 4344 MPLS implementation layer 2.5 implementation supports ATM & IP MPLS switch/router state –forwarding table: {(label, egress, new label)} –“label swapping” (like a VC subnet) like flows are grouped with same label –according to route and service class –Forwarding Equivalence Class (FEC) –labels have only local scope flow identities are not lost in FEC aggregation –why?

49 SMUCSE 4344 MPLS forwarding table construction MPLS routing has no VC-like “set-up” phase data-driven approach (“colored threads”) –request label from next hop on shortest path control-driven approach (datagram nwks) –provide labels proactively to adjacent routers

50 SMUCSE 4344 Generalized MPLS: GMPLS first standardized optical routing protocol IP control protocols on non-IP devices –software only upgrade to support IP routing forward IP packets on non-IP hardware –ATM label switching –optical switches –TDM devices SONET mux-demux, “next-gen” SONET switches

51 SMUCSE 4344 current uses for (G)MPLS to support IP forwarding over non-IP networks explicit routing to override IP routing to support VPNs: tunneling –“pseudowire emulation” –any data can be encapsulated: IP, ATM, etc receiving end must know what to do with received data demux label “stacked” under switching label –recursive tunnels “stacked” labels, using S bit support non-IP forwarding over IP networks

52 SMUCSE 4344 about the next slides slide from 2006 presentation by Francisco Fuentes (Cisco Systems), Secretary General of the FTTH- Council Europe, to the Council Council: “quality life needs ultra fast broadband; optical fibre is the future --- infinite capacity to deliver home multimedia services” (focus: last mile) speaker’s motivation in talk: Europe needs to look sharp, or be left behind in cyber infrastructure context: –Japanese broadband companies compete for end-users –Japanese population crowded; US population spread out

53 SMUCSE 4344 Fiber based Infrastructure Competition Japan Fiber based Infrastructure Competition NTT Telephones NTT fibre Usen (music) Usen (fibre) TEPCO (CATV) TEPCO (fibre) Cable TV Source: Fujikura multiple fibers pass the same home! Tepco now offering 1Gb/sec to MDUs -100Mb/user will pass 8 million users by end 2004 Japan’s largest CATV provider (J-Comm) entering FTTH to compete with NTT Yahoo BB (Largest DSL competitor) to enter FTTH by leasing NTT lines KDDI planning to pass two million users with own fibre (currently lease NTT lines) USEN 12% of FTTH market, most new subscribers are former ADSL subscribers NTT Group is planning to invest a¥5 trillion (US$47 billion) in extending its FTTH (fiber to the home). The expansion would involve shifting 30 million customers to optical fiber access and next-generation network services by 2010 Source: Statistics Bureau, Ministry of Internal Affairs and Communication (Japan) Launched Triple Play

54 SMUCSE 4344 Operators and Local Communities US Operators and Local Communities Alabama *Midway Sylacauga Union Springs Arizona *La Bernie *Quantro Ranch *San Carlos California Amerige Heights Canyon Hills *Danbury Place *Elk Grove *Huntington Beach Kenwood *Lincoln Lincoln Crossing Mission Bay *Mission Trails Palo Alto Parc Metropolitan Poppy Meadows Roseville Sacramento Talavera Colorado Buckhorn Valley Chatfield Corner Colorado City Eagle Ranch * New to the list Rye *Two Rivers Village Deleware *Cinderberry Estates Florida Magnolia Lake *Palencia *Reunion *Tesoro Tradition *Tampa Venetian Bay Georgia *Barrington Point Dalton Dunwoody *The Reserve *Timberland *Victoria Place Iowa Cambridge Huxley Guthrie Center *Oskaloosa Slater Idaho Bear Creek *Holyrood Iuka *Kiowa Norton Osborne Quinter Sharon Turon Wakeeney Wamego Kentucky *Johnson County *McGoffin County Louisiana *Grand Lake Squire Creek Homes Maine *Auburn *Lewiston Norway *South Paris Massachusetts Pine Hils Tauton Maryland *McHenry *Shelbysport Michigan Cobblestone *Sunflower Village Minnesota Alberta Chokio Evermoor *Holloway *Lonsdale Morris New York Mills Town Lakes Victor Garden *Victoria *Windom Missouri *Bevier *Bucklin *Callao *Macon *New Cambria Montana Baxter Meadows Ironwood Nebraska Greenfield Addition New Mexico *Brettana *San Vincinte North Carolina *Columbus *Tyron North Dakota *Jamestown *Linton *Lisbon *Oakes *Steele *Wishek *Zeeland Ohio *Ft. Laramie *Fostoria *Lima *St Marys *Tiffin Oklahoma Hinton Oregon *Douglas County *Lexington Estates *Scio Woodburn Pennsylvania *Farmington *Friendsville *Indian Head *Fox Meadows *Fox Springs *Rupert *Teton Springs *The Settlements Illinois Paxton Salem Indiana Bay Creek *Emerald Springs *Fox Hollow Gateway Crossing *Greensburg *Reserve-Geist Rochester *Woodhaven Kansas Almena *Bogue *Burlington *Byron *Columbus *Edmond Hill City *Kecksburg Kutztown *Lastrobe *Mammoth *Markleysburg *Stahlstown South Carolina *Arborwood *Bridgemill Daniel Island *Edgewater Hampton Hall *Millwood *Palmetto Bluff *Ridge Point Sandy Point Tennessee *Jackson Texas Avery Ranch *Boerne Heights *Brookhollow Canyon Gate Brazos *Canyon Lake *Cooperstone Crystal Falls *Fountain Hills Grand Lake Estates Hometown *Keller Lake Ridge South Lakes on Eldridge *Lakewood Estates Laredo *Lookout Canyon *Monterey Mount Valley Heights *Mountain Valley Lakes Nothpointe *Oak Trail *Preston Manner Rock Creek Stone Gate *Suncrest *The Falls *Tivoli Estates *Trinity Oaks Victory Lakes Source: Render, Vanderslice & Associates New in 2004 Pre-2004 No deployments *Willow Creek *Windmill Farms *Wolfforth Utah *Canyon Meadow Deer Mountain *Empire *Park Crossing *Pemberly *Promontory Provo Star Mountain *Travis Mountain *Tuhaye Virginia *Abingdon Braemar Brambleton Bristol Independence Lansdowne *Leisure World Southern Washington Chelan County Clallam County Douglas County Grant County Issaquah Highlands Mason County *Okanaquan *Pend Oreille West Virginia *Hazelton Wisconsin Berkseth *Pabst Farms Prairie View Reedsburg *Woodville Source: KMI

55 SMUCSE 4344 US perspective broadband access: % coverage, cost, speed –1) S Korea –...)... –13) US –ranking within last couple of years

56 SMUCSE 4344 internetworks internet: 2 or more interconnected networks network layer protocol/architecture variety –TCP/IP –IBM SNA –ATM –AppleTalk –IEEE –Novell –FDDI –frame relay –SONET –many, many more

57 SMUCSE 4344 how networks differ plus: PHY modulation, link layer frame format, political and legal issues,...

58 SMUCSE 4344 interconnecting networks PHY layer: repeaters, hubs do not alter signal link layer: bridges, switches –frames, MAC addresses, forwarding network layer: routers transport layer: transport gateways application layer: application gateways

59 SMUCSE 4344 tunneling internetworking in general is hard special case of internetworking is tractable –source and sink use same network protocol –intervening networks can encapsulate flows intervening networks build “tunnels” aside from ingress and egress encapsulation, end-to-end traffic and intervening network are blissfully unaware of each other

60 SMUCSE 4344 tunneling illustration tunneling a car from France to England through the Chunnel

61 SMUCSE 4344 tunneling illustration

62 SMUCSE 4344 internetwork routing two-level routing hierarchy Autonomous System (AS) –independent, self-contained –interior gateway routing protocol ASes internetwork with each other –exterior gateway routing protocol routes may differ (jurisdictions, costs, QoS, etc) routers in a given AS speak to each other

63 SMUCSE 4344 internetwork routing illustration (a)internetwork diagram (b)graph of same internetwork

64 SMUCSE 4344 fragmentation networks differ in maximum packet size –hardware, OS, protocol, laws/regs, preference –ATM, 48 bytes; Enet, 1500; FDDI, 4500; IP, 64k packets may be fragmented in tunnels –transparent reconstruct fragmented packets at AS egress (ATM) only one egress; may have to be done repeatedly –non-transparent reassemble fragments at sink (IP) all packets need full header; all sinks able to reconstruct

65 SMUCSE 4344 fragmentation illustration

66 SMUCSE 4344 fragmentation illustration fragments identified by byte offset of first byte of fragment, with respect to full packet

67 SMUCSE 4344 fragment reassembly process at tunnel egress or sink build a fragment list per packet map the incoming fragment into fragment list insert fragment into list: compare sum of offset and length with offset of next fragment check to see if all the holes are filled if all present, join fragments, recreate datagram

68 SMUCSE 4344 Internet architecture, network layer IP protocol IP addresses Internet control protocols OSPF – interior gateway routing protocol BGP – exterior gateway routing protocol Internet multicasting mobile IP IPv6

69 SMUCSE 4344 design principles for Internet be sure it works keep it simple exploit modularity expect heterogeneity avoid static options and parameters strict sending, tolerant receiving scalability performance and cost

70 SMUCSE 4344

71 SMUCSE 4344 Internet service model connectionless (datagram-based) best-effort delivery (unreliable service) –packets are lost –packets are delivered out of order –duplicate copies of a packet are delivered –packets can be delayed for a long time

72 SMUCSE 4344 addressing & subnetting subnet in Internet context: subset of network network/host ID reinterpreted –high order host bits appropriated for subnetting –{network, host} => {network, subnet, host} subnet mask still, address allocation hamstrung by very large network blocks (class A, class B)

73 SMUCSE 4344 CIDR – Classless InterDomain Routing “sai-dur” smaller blocks of addresses can be allocated no pre-sorting addresses into classes single table of {(network, subnet, host)} use longest subnet masked match “aggregate entries” reduce table sizes

74 SMUCSE 4344 Network Address Translation (NAT) even with CIDR, too few IP addresses idea: behind one IP address, an entire subnet IPv4 plan: private (reserved) address ranges – /8 16M hosts (one class A network range) – /12 1M hosts – – /16 64K hosts (one class B network range)

75 SMUCSE 4344 NAT illustration

76 SMUCSE 4344 the translation 16-bits of TCP/UDP port fields hijacked 64K-entry NAT table NAT box rewrites packet header –saves to NAT table (NAT address, port#) –to packet (real IP address, NAT table index#) new checksums: TCP, IP headers

77 SMUCSE 4344 bad NAT IP address duplication (in NAT ranges) NAT boxes are single-point-of-failure cross-layer architecture (layer 3/4) non-TCP/UDP traffic cannot cross NAT box IP addresses not valid beyond NAT box addresses per NAT domain (4096 rsv) –(a limited hack)

78 SMUCSE 4344 Internet Control Message Protocol (ICMP) 5-61 router-to-router communications (more at

79 SMUCSE 4344 Address Resolution Protocol (ARP) have packet with IP address need MAC address ARP returns MAC address put packet in MAC frame, send off save IP/MAC address mapping for later proxy ARP –maps addresses beyond router, if desired

80 SMUCSE 4344 ARP illustration Three interconnected /24 networks: two Ethernets and an FDDI ring.

81 SMUCSE 4344 given MAC address, IP address? RARP (Reverse ARP) –requests are not forwarded beyond LAN BOOTP –needs manual configuration DHCP –auto or manual IP address assignment –DHCP relay agent per LAN –temporary assignments: leases

82 SMUCSE 4344 Dynamic Host Configuration Protocol

83 SMUCSE theme: avoiding manual configuration DHCP –edge host learns how to send packets –learns: own IP address, DNS servers, routing gateway ARP –others learn how to send packets to edge host –maps: IP address onto MAC address host DNS... host DNS... router / / ??? router

84 SMUCSE key ideas in ARP & DHCP broadcasting: when in doubt, shout! –broadcast query to all hosts in the local-area network –… when you don't know how to identify the right one caching: remember the past for a while –store the information you learn to reduce overhead –remember your own address & other hosts' addresses soft state: eventually forget the past –associate a time-to-live field with the information –… and either refresh or discard the information –key for robustness in the face of unpredictable change

85 SMUCSE 4344 interior gateway routing protocols intra-AS Internet routing RIP: ARPANET, Internet protocol –distance vector, based on Bellman-Ford OSPF (Open Shortest Path First) protocol –since 1990, based on link-state routing

86 SMUCSE 4344 OSPF open standard supports arbitrary routing cost metrics closed loop, fast response to network change supports QoS supports load balancing supports hierarchical routing supports tunneling

87 SMUCSE 4344 OSPF routing illustration (a)AS diagram of area 0 (b)graph of (a) “area” is illustrated by WAN 1, 2, 3, and LAN 2 Note that (b) has arcs, not edges (b) shows LANs, point-to-point lines, and multi-router networks

88 SMUCSE 4344 OSPF routing routers in one area use the same link state data structures and algorithms routers connected to multiple areas run a distinct OSPF process for each inter-area routing –to backbone, along backbone, and from backbone router classes –internal, area border, backbone, AS boundary

89 SMUCSE 4344 OSPF hierarchy illustration

90 SMUCSE 4344 OSPF implementation the five OSPF message types (packets) regular link state {(neighbor, cost)} flooding through each area backbone area, too each router keeps full OSPF details for adjacent areas

91 SMUCSE 4344 exterior gateway routing protocols inter-AS routing support non-technical constraints and policies –politics, jurisprudence, economics, security Border Gateway Protocol (BGP) (Internet)

92 SMUCSE 4344 BGP some definitions: l ocal traffic: autonomous system (AS) internal traffic transit traffic: traffic that passes through an AS stub AS: carries only local traffic, links to one other AS multihomed AS: links to >1 AS (carries only local traffic) transit AS: links to >1 AS, carries transit & local traffic

93 SMUCSE 4344 BGP connected BGP router pairs talk via TCP distance vector –{(sink, cost, {all nodes on path})} –all paths rated with arbitrary scoring function

94 SMUCSE 4344 BGP BGP advertises complete hop-by-hop paths to destinations, e.g., AS 1 AS 2 AS 5 AS 3 therefore  might not use optimal routes  reachability is more important! BGP “speakers” exchange reachability information between ASes (see next slide)

95 SMUCSE 4344 BGP AS 1 AS 2 AS 5 BGP 1 speaker BGP 2 speaker BGP 5 speaker gateway reachability info Notes: 1. reachability info is exchanged by BGP speakers using BGP protocol (shown in dotted lines) that runs between ASes 2. the actual information is transmitted over the physical layer 3. BGP speakers are sometimes (but not always) implemented in gateway routers shown above

96 SMUCSE 4344 BGP illustration what BGP routers see: each node is an AS

97 SMUCSE 4344 BGP figure 4.29: today's multibackbone Internet Backbone service provider Peering point Peering point Large corporation Small corporation “Consumer” ISP “Consumer” ISP “Consumer” ISP

98 SMUCSE 4344 Internet Protocol version 6 (IPv6) design goals –permanent solution to small IPv4 address space –limit routing table size –support QoS –enhance multicasting –support roaming –backward support for IPv4 has huge address space has simpler header/options supports authentication and privacy (optional) supports QoS (unicast, multicast) no explicit support for roaming (mobile IP)

99 SMUCSE 4344 IPv6 fixed header (40 bytes) version: IP protocol; traffic class: QoS; flow label: connection-oriented; payload length; next header: options or transport protocol; hop limit: TTL

100 SMUCSE 4344 changes from IPv4 fixed length header 1280 byte (1KB data) minimum packet size fragmentation –source, subnet, sink agree on max packet size –overlarge packets generate error report flow packets resized at source –what about 48 byte ATM payloads? no checksum –made redundant by link and transport layer cksums

101 SMUCSE 4344 optional extension headers optional headers appended to fixed header minimum length, any optional header: 8 bytes destination header: currently unused fragmentation header: used only by source, sink 5-69

102 SMUCSE 4344 hop-by-hop jumbogram optional header all routers examine hop-by-hop type headers header length: 0 bytes beyond 8 byte minimum code 194 for jumbogram hop-by-hop option 64 KB minimum size jumbogram length given in (4)-byte units

103 SMUCSE 4344 routing optional header packet must visit listed routers in order routing type: only type 0, IPv6 segments left: how many routers not yet visited data: the list of routers to visit


Download ppt "SMUCSE 4344 network layer (slide set 3). SMUCSE 4344 congestion control algorithms general principles of congestion control congestion prevention policies."

Similar presentations


Ads by Google