[ Pobierz całość w formacie PDF ]
.2.1.7.1 CIDR ImplementationThe implementation of CIDR in the Internet is primarily based on Border GatewayProtocol Version 4 (see 3.4.2, Border Gateway Protocol (BGP-4) on page 135).The implementation strategy, described in RFC 1520 Exchanging RoutingInformation Across Provider Boundaries in the CIDR Environment involves a stagedprocess through the routing hierarchy beginning with backbone routers.Networkservice providers are divided into four types:Type 1Those that cannot employ any default inter-domain routing.Type 2Those that use default inter-domain routing but require explicit routes for asubstantial proportion of the assigned IP network numbers.Type 3Those that use default inter-domain routing and supplement it with a smallnumber of explicit routes.Type 4Those that perform all inter-domain routing using only default routes.The CIDR implementation involves an implementation beginning with the Type 1network providers, then the Type 2 and finally the Type 3 ones.CIDR has alreadybeen widely deployed in the backbone and over 9,000 class-based routes havebeen replaced by approximately 2,000 CIDR-based routes.Chapter 2.Internetworking and Transport Layer Protocols 47 2.1.8 IP DatagramThe unit of transfer of a data packet in TCP/IP is called an IP datagram.It is madeup of a header containing information for IP and data that is only relevant to thehigher level protocols.header database IP datagram.physical network header IP datagram as dataencapsulated within the physical network's frame3376\3376F203Figure 19.IP - Format of a Base IP DatagramIP can handle fragmentation and re-assembly of IP datagrams.The maximumlength of an IP datagram is 65,535 bytes (or octets).There is also a requirementfor all TCP/IP hosts to support IP datagrams of size up to 576 bytes withoutfragmentation.Fragments of a datagram all have a header, basically copied from the originaldatagram, and data following it.They are treated as normal IP datagrams whilebeing transported to their destination.Note, however, that if one of the fragmentsgets lost, the complete datagram is considered lost since IP does not provide anyacknowledgment mechanism, so the remaining fragments will simply be discardedby the destination host.2.1.8.1 IP Datagram FormatThe IP datagram header is a minimum of 20 bytes long:48 TCP/IP Tutorial and Technical Overview 1 1 2 30 4 8 6 9 4 1ServiceVERS HLENTotal LengthTypeFragmentID FLGOffsetHeaderTTL ProtocolChecksumSource IP AddressDestination IP AddressIP Options PaddingData.Figure 20.IP - Format of an IP Datagram HeaderWhere:VERSThe version of the IP protocol.The current version is 4.5 is experimentaland 6 is IPv6 (see 6.2, The IPv6 Header Format on page 358).HLENThe length of the IP header counted in 32-bit quantities.This does notinclude the data field.Service TypeThe service type is an indication of the quality of service requested for this IPdatagram.0 1 2 3 4 5 6 7precedence TOS MBZ3376\3376F205Figure 21.IP - Service TypeWhere:PrecedenceIs a measure of the nature and priority of this datagram:000 Routine001 Priority010 Immediate011 Flash100 Flash overrideChapter 2.Internetworking and Transport Layer Protocols 49 101 Critical110 Internetwork control111 Network controlTOSSpecifies the type of service value:1000Minimize delay0100Maximize throughput0010Maximize reliability0001Minimize monetary cost0000Normal serviceMBZReserved for future use (must be zero unless participating in an Internetprotocol experiment, which makes use of this bit).A detailed description of the type of service can be found in the RFC1349 (please also refer to 10.1, Why QoS? on page 505 for moredetails).Total LengthThe total length of the datagram, header and data, specified in bytes.IdentificationA unique number assigned by the sender to aid in reassembling a fragmenteddatagram.Fragments of a datagram will have the same identification number.FlagsVarious control flags:0 1 2D M0 F FFigure 22.IP - FlagsWhere:0 Reserved, must be zero.DF Don't Fragment: 0 means allow fragmentation, 1 means do not allowfragmentation.MF More Fragments: 0 means that this is the last fragment of this datagram,1 means that this is not the last fragment.Fragment OffsetUsed with fragmented datagrams, to aid in reassembly of the full datagram.The value is the number of 64-bit pieces (header bytes are not counted) thatare contained in earlier fragments.In the first (or only) fragment, this value isalways zero.50 TCP/IP Tutorial and Technical Overview Time to LiveSpecifies the time (in seconds) this datagram is allowed to travel.Each routerwhere this datagram passes is supposed to subtract from this field itsprocessing time for this datagram.Actually a router is able to process adatagram in less than 1 second; thus it will subtract one from this field, andthe TTL becomes a hop-count metric rather than a time metric.When thevalue reaches zero, it is assumed that this datagram has been traveling in aclosed loop and it is discarded.The initial value should be set by the higherlevel protocol that creates the datagram.Protocol NumberIndicates the higher level protocol to which IP should deliver the data in thisdatagram.Some important values are:0 Reserved1 Internet Control Message Protocol (ICMP)2 Internet Group Management Protocol (IGMP)3 Gateway-to-Gateway Protocol (GGP)4 IP (IP encapsulation)5 Stream6 Transmission Control Protocol (TCP)8 Exterior Gateway Protocol (EGP)9 Private Interior Routing Protocol17 User Datagram Protocol (UDP)41 IP Version 6 (IPv6)50 Encap Security Payload for IPv6 (ESP)51 Authentication Header for IPv6 (AH)89 Open Shortest Path FirstThe full list can be found in STD 2 Assigned Internet Numbers.Header ChecksumIs a checksum on the header only.It does not include the data.Thechecksum is calculated as the 16-bit one's complement of the one'scomplement sum of all 16-bit words in the header.For the purpose of thiscalculation, the checksum field is assumed to be zero.If the headerchecksum does not match the contents, the datagram is discarded because atleast one bit in the header is corrupt, and the datagram may even havearrived at the wrong destination.Source IP AddressThe 32-bit IP address of the host sending this datagram.Destination IP AddressThe 32-bit IP address of the destination host for this datagram.OptionsVariable length.An IP implementation is not required to be capable ofgenerating options in the datagrams it creates, but all IP implementations arerequired to be able to process datagrams containing options.The Optionsfield is variable in length.There may be zero or more options.There are twoChapter 2.Internetworking and Transport Layer Protocols 51 option formats.The format for each is dependent on the value of the optionnumber found in the first byte.A type byte alone.type1 byteFigure 23.IP - A Type ByteA type byte, a length byte and one or more option data bytes./ /type length option data./ /1 byte 1 bytelength - 2 bytesFigure 24.IP - A Type Byte, a Length Byte and One or More Option Data BytesThe type byte has the same structure in both cases:0 1 2 3 4 5 6 7fc class option number3376\3376F209Figure 25.IP - The Type Byte StructureWhere:fc Flag copy indicates whether (1) or not (0) the option field is to be copiedwhen the datagram is fragmented.classThe option class is a 2-bit unsigned integer:0 control1 reserved2 debugging and measurement3 reservedoption numberThe option number is a 5-bit unsigned integer
[ Pobierz całość w formacie PDF ]