archive-gr.com » GR » T » TEIPIR.GR

Total: 878

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".

  • on Because these messages are quite rare it is strongly recommended that this be done through an exception mechanism rather than having the IP keep per host tables for all hosts 7 The Relationship between IP Datagram and TCP Segment Sizes The relationship between the value of the maximum IP datagram size and the maximum TCP segment size is obscure The problem is that both the IP header and the TCP header may vary in length The TCP Maximum Segment Size option MSS is defined to specify the maximum number of data octets in a TCP segment exclusive of TCP or IP header To notify the data sender of the largest TCP segment it is possible to receive the calculation of the MSS value to send is MSS MTU sizeof TCPHDR sizeof IPHDR On receipt of the MSS option the calculation of the size of segment that can be sent is SndMaxSegSiz MIN MTU sizeof TCPHDR sizeof IPHDR MSS Postel Page 4 RFC 879 November 1983 TCP Maximum Segment Size where MSS is the value in the option and MTU is the Maximum Transmission Unit or the maximum packet size allowed on the directly attached network This begs the question though What value should be used for the sizeof TCPHDR and for the sizeof IPHDR There are three reasonable positions to take the conservative the moderate and the liberal The conservative or pessimistic position assumes the worst that both the IP header and the TCP header are maximum size that is 60 octets each MSS MTU 60 60 MTU 120 If MTU is 576 then MSS 456 The moderate position assumes the that the IP is maximum size 60 octets and the TCP header is minimum size 20 octets because there are no TCP header options currently defined that would normally be sent at the same time as data segments MSS MTU 60 20 MTU 80 If MTU is 576 then MSS 496 The liberal or optimistic position assumes the best that both the IP header and the TCP header are minimum size that is 20 octets each MSS MTU 20 20 MTU 40 If MTU is 576 then MSS 536 If nothing is said about MSS the data sender may cram as much as possible into a 576 octet datagram and if the datagram has minimum headers which is most likely the result will be 536 data octets in the TCP segment The rule relating MSS to the maximum datagram size ought to be consistent with this A practical point is raised in favor of the liberal position too Since the use of minimum IP and TCP headers is very likely in the very large percentage of cases it seems wasteful to limit the TCP segment data to so much less than could be transmitted at once especially since it is less that 512 octets Postel Page 5 RFC 879 November 1983 TCP Maximum Segment Size For comparison 536 576 is 93 data 496 576 is 86 data 456 576 is 79 data 8 Maximum Packet Size Each network has some maximum packet size or maximum transmission unit MTU Ultimately there is some limit imposed by the technology but often the limit is an engineering choice or even an administrative choice Different installations of the same network product do not have to use the same maximum packet size Even within one installation not all host must use the same packet size this way lies madness though Some IP implementers have assumed that all hosts on the directly attached network will be the same or at least run the same implementation This is a dangerous assumption It has often developed that after a small homogeneous set of host have become operational additional hosts of different types are introduced into the environment And it has often developed that it is desired to use a copy of the implementation in a different inhomogeneous environment Designers of gateways should be prepared for the fact that successful gateways will be copied and used in other situation and installations Gateways must be prepared to accept datagrams as large as can be sent in the maximum packets of the directly attached networks Gateway implementations should be easily configured for installation in different circumstances A footnote The MTUs of some popular networks note that the actual limit in some installations may be set lower by administrative policy ARPANET MILNET 1007 Ethernet 10Mb 1500 Proteon PRONET 2046 9 Source Fragmentation A source host would not normally create datagram fragments Under normal circumstances datagram fragments only arise when a gateway must send a datagram into a network with a smaller maximum packet size than the datagram In this case the gateway must fragment the datagram unless it is marked don t fragment in which case it is discarded with the option of sending an ICMP message to the source reporting the problem It might be desirable for the source host to send datagram fragments Postel Page 6 RFC 879 November 1983 TCP Maximum Segment Size if the maximum segment size default or negotiated allowed by the data receiver were larger than the maximum packet size allowed by the directly attached network However such datagram fragments must not combine to a size larger than allowed by the destination host For example if the receiving TCP announced that it would accept segments up to 5000 octets in cooperation with the receiving IP then the sending TCP could give such a large segment to the sending IP provided the sending IP would send it in datagram fragments that fit in the packets of the directly attached network There are some conditions where source host fragmentation would be necessary If the host is attached to a network with a small packet size for example 256 octets and it supports an application defined to send fixed sized messages larger than that packet size for example TFTP 5 If the host receives ICMP Echo messages with data it is required to send an ICMP Echo

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0879.txt (2016-02-14)
    Open archived version from archive



  • of new TCP segments when new outgoing data arrives from the user if any previously transmitted data on the connection remains unacknowledged This inhibition is to be unconditional no timers tests for size of data received or other conditions are required Implementation typically requires one or two lines inside a TCP program At first glance this solution seems to imply drastic changes in the behavior of TCP This is not so It all works out right in the end Let us see why this is so When a user process writes to a TCP connection TCP receives some data It may hold that data for future sending or may send a packet immediately If it refrains from sending now it will typically send the data later when an incoming packet arrives and changes the state of the system The state changes in one of two ways the incoming packet acknowledges old data the distant host has received or announces the availability of buffer space in the distant host for new data This last is referred to as updating the window Each time data arrives on a connec tion TCP must reexamine its current state and perhaps send some packets out Thus when we omit sending data on arrival from the user we are simply deferring its transmission until the next message arrives from the distant host A message must always arrive soon unless the connection was previously idle or communi cations with the other end have been lost In the first case the idle connection our scheme will result in a packet being sent whenever the user writes to the TCP connection Thus we do not deadlock in the idle condition In the second case where RFC 896 Congestion Control in IP TCP Internetworks 1 6 84 the distant host has failed sending more data is futile anyway Note that we have done nothing to inhibit normal TCP retransmis sion logic so lost messages are not a problem Examination of the behavior of this scheme under various condi tions demonstrates that the scheme does work in all cases The first case to examine is the one we wanted to solve that of the character oriented Telnet connection Let us suppose that the user is sending TCP a new character every 200ms and that the connection is via an Ethernet with a round trip time including software processing of 50ms Without any mechanism to prevent small packet congestion one packet will be sent for each charac ter and response will be optimal Overhead will be 4000 but this is acceptable on an Ethernet The classic timer scheme with a limit of 2 packets per second will cause two or three characters to be sent per packet Response will thus be degraded even though on a high bandwidth Ethernet this is unnecessary Overhead will drop to 1500 but on an Ethernet this is a bad tradeoff With our scheme every character the user types will find TCP with an idle connection and the character will be sent at once just as in the no control case The user will see no visible delay Thus our scheme performs as well as the no control scheme and provides better responsiveness than the timer scheme The second case to examine is the same Telnet test but over a long haul link with a 5 second round trip time Without any mechanism to prevent small packet congestion 25 new packets would be sent in 5 seconds Overhead here is 4000 With the classic timer scheme and the same limit of 2 packets per second there would still be 10 packets outstanding and contributing to congestion Round trip time will not be improved by sending many packets of course in general it will be worse since the packets will contend for line time Overhead now drops to 1500 With our scheme however the first character from the user would find an idle TCP connection and would be sent immediately The next 24 characters arriving from the user at 200ms intervals would be held pending a message from the distant host When an ACK arrived for the first packet at the end of 5 seconds a single packet with the 24 queued characters would be sent Our scheme thus results in an overhead reduction to 320 with no penalty in response time Response time will usually be improved with our scheme because packet overhead is reduced here by a factor of 4 7 over the classic timer scheme Congestion will be reduced by this factor and round trip delay will decrease sharply For this This problem is not seen in the pure ARPANET case because the IMPs will block the host when the count of packets outstanding becomes excessive but in the case where a pure datagram local net such as an Ethernet or a pure datagram gateway such as an ARPANET MILNET gateway is involved it is possible to have large numbers of tiny packets outstanding RFC 896 Congestion Control in IP TCP Internetworks 1 6 84 case our scheme has a striking advantage over either of the other approaches We use our scheme for all TCP connections not just Telnet con nections Let us see what happens for a file transfer data con nection using our technique The two extreme cases will again be considered As before we first consider the Ethernet case The user is now writing data to TCP in 512 byte blocks as fast as TCP will accept them The user s first write to TCP will start things going our first datagram will be 512 40 bytes or 552 bytes long The user s second write to TCP will not cause a send but will cause the block to be buffered Assume that the user fills up TCP s outgoing buffer area before the first ACK comes back Then when the ACK comes in all queued data up to the window size will be sent From then on the window will be

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0896.txt (2016-02-14)
    Open archived version from archive


  • a status field which the sending gateway uses to indicate whether it thinks the receiving gateway is reachable or not This information can be useful for diagnostic purposes It also allows one gateway to make its reachability determination parasitic on the other only one gateway actually needs to send Hello messages and the other can declare it up or down based on the status field in the Hello That is the passive gateway which sends only I Heard You s declares the active one which sends only Hello s to be reachable when the Hello s from the active one indicate that it has declared the passive one to be reachable Of course this can only work if there is prior agreement as to which neighbor is to be the active one Ways of coming to this 12 RFC 827 Bolt Beranek and Newman Inc Eric C Rosen prior agreement are not part of the Exterior Gateway Protocol A direct neighbor gateway should also be declared unreachable if the network connecting it supplies lower level protocol information from which this can be deduced Thus for example if a gateway receives an 1822 Destination Dead message from the ARPANET which indicates that a direct neighbor is dead it should declare that neighbor unreachable The neighbor should not be declared reachable again until the requisite number of Hello I Heard You packets have been exchanged A direct neighbor which has become unreachable does not thereby cease to be a direct neighbor The neighbor can be declared reachable again without any need to go through the neighbor acquisition protocol again However if the neighbor remains unreachable for an extremely long period of time such as an hour the gateway should cease to treat it as a neighbor i e should cease sending Hello messages to it The neighbor acquisition protocol would then need to be repeated before it could become a direct neighbor again Hello and I Heard You messages from gateway G to gateway G also carry the identification number of the NR poll message see below which G has most recently received from G 13 RFC 827 Bolt Beranek and Newman Inc Eric C Rosen Hello and I Heard You messages from gateway G to gateway G also carry the minimum interval in minutes with which G is willing to be polled by G for NR messages see below Hello messages from sources other than direct neighbors should simply be ignored However logging the presence of any such messages might provide useful diagnostic information A gateway which is going down or whose interface to the network which connects it to a particular neighbor is going down should send a Gateway Going Down message to all direct neighbors which will no longer be able to reach it It should retransmit that message up to some number of times until it receives a Gateway Going Down Acknowledgment This provides the neighbors with an advance warning of an outage and enables them to prepare for it in a way which will minimize disruption to existing traffic 14 RFC 827 Bolt Beranek and Newman Inc Eric C Rosen 4 NETWORK REACHABILITY NR MESSAGE Terminology Let gateway G have an interface to network N We say that G is AN APPROPRIATE FIRST HOP to network M relative to network N where M and N are distinct networks if and only if the following condition holds Traffic which is destined for network M and which arrives at gateway G over its network N interface will be forwarded to M by G over a path which does not include any other gateway with an interface to network N In short G is an appropriate first hop for network M relative to network N just in case there is no better gateway on network N through which to route traffic which is destined for network M For optimal routing traffic in network N which is destined for network M ought always to be forwarded to a gateway which is an appropriate first hop In order for exterior neighbors G and G which are neighbors over network N to be able to use each other as packet switches for forwarding traffic to remote networks each needs to know the list of networks for which the other is an appropriate first hop The Exterior Gateway Protocol defines a message called the Network Reachability Message or NR message for transferring this information 15 RFC 827 Bolt Beranek and Newman Inc Eric C Rosen Let G be a gateway on network N Then the NR message which G sends about network N must contain the following information A list of all the networks for which G is an appropriate first hop relative to network N If G can obtain this information from exterior neighbor G then it knows that no traffic destined for networks which are NOT in that list should be forwarded to G It cannot simply conclude however that all traffic for any networks in that list ought to be forwarded via G since G may also have other neighbors which are also appropriate first hops to network N For example G and G might each be neighbors of G but might be equidistant from some network M Then each could be an appropriate first hop For each network in the list the NR message also contains a byte which specifies the distance according to some metric whose definition is left to the designers of the autonomous system of which gateway G is a member from G to that network This information might or might not be useful in the interior routing algorithm of gateway G or for diagnostic purposes The maximum value of distance 255 shall be taken to mean that the network is UNREACHABLE ALL OTHER VALUES WILL BE TAKEN TO MEAN THAT THE NETWORK IS REACHABLE 16 RFC 827 Bolt Beranek and Newman Inc Eric C Rosen If an NR message from some gateway G fails to mention some network N which was mentioned in the previous NR message from G it shall be assumed that N is still reachable from G HOWEVER IF N IS NOT MENTIONED IN TWO SUCCESSIVE NR MESSAGES FROM G THAT SHALL BE TAKEN TO MEAN THAT N IS NO LONGER REACHABLE FROM G This procedure is necessary to ensure that networks which can no longer be reached but which are never explicitly declared unreachable are timed out and removed from the list of reachable networks It may often be the case that where G and G are exterior neighbors on network N G knows of many more gateway neighbors on network N and knows for which networks those other neighbors are the appropriate first hop Since G may not know about all these other neighbors it is convenient and often more efficient for it to be able to obtain this information from G Therefore the EGP NR message also contains fields which allow G to specify the following information a A list of all neighbors both interior and exterior of G on network N which G has reliably determined to be reachable Gateways should be included in this list only if G is actively running its neighbor reachability protocol with them 17 RFC 827 Bolt Beranek and Newman Inc Eric C Rosen b For each of those neighbors the list of networks for which that neighbor is an appropriate first hop relative to network N c For each such pair the distance from that neighbor to that network Thus the NR message provides a means of allowing a gateway to discover new neighbors by seeing whether a neighbor that it already knows of has any additional neighbors on the same network This information also makes possible the implementation of the INDIRECT NEIGHBOR strategy defined below A more precise description of the NR message is the following The data portion of the message will consist largely of blocks of data Each block will be headed by a gateway address which will be the address either of the gateway sending the message or of one of that gateway s neighbors Each gateway address will be followed by a list of the networks for which that gateway is an appropriate first hop and the distance from that gateway to each network Preceding the list of data blocks is a The address of the network which this message is about 18 RFC 827 Bolt Beranek and Newman Inc Eric C Rosen If G and G are neighbors on network N then in the NR message going from G to G this is the address of network N For convenience four bytes have been allocated for this address the trailing one two or three bytes should be zero b The count one byte of the number of interior neighbors of G for which this message contains data blocks By convention this count will include the data block for G itself which should be the first one to appear c The count one byte of the number of exterior neighbors of G for which this message contains data blocks Then follow the data blocks themselves first the block for G itself then the blocks for all the interior neighbors of G if any then the blocks for the exterior neighbors Since all gateways mentioned are on the same network whose address has already been given the gateway addresses are given with the network address part one two or three bytes omitted to save space Each block includes a one byte count of the number of networks for which that gateway is the appropriate first hop In the list of networks each network address is either one two or three bytes depending on whether it is a class A class B or 19 RFC 827 Bolt Beranek and Newman Inc Eric C Rosen class C network No trailing bytes are used It may sometimes be necessary to fragment the NR message The NR message contains a byte indicating the number of this fragment fragments will be numbered from zero and a byte containing the number of the last fragment NOT the number of fragments If fragmentation is not used these bytes must both be zero EACH FRAGMENT MUST BE A FULLY SELF CONTAINED NR MESSAGE That is each fragment will begin with a count of interior and exterior neighbors and will have some integral number of gateway data blocks The number of data blocks in each fragment must correspond to the neighbor counts at the beginning of that fragment However only the first fragment should begin with a data block describing the sending gateway This scheme enables each fragment to be processed independently and requires no complex reassembly mechanisms It also enables processing of a message all of whose fragments have not been received If after some amount of time and some number of retransmissions of a poll not all fragments have been received the fragments which are present shall be processed as if they constituted the complete NR message This means that networks mentioned only in the missing fragment will retain the distance values they had in the previous NR message from that gateway However if no new value for a particular network is 20 RFC 827 Bolt Beranek and Newman Inc Eric C Rosen received in the next NR message from that gateway the network will be declared unreachable 21 RFC 827 Bolt Beranek and Newman Inc Eric C Rosen 5 POLLING FOR NR MESSAGES No gateway is required to send NR messages to any other gateway except as a response to an NR Poll from a direct neighbor However a gateway is required to respond to an NR Poll from a direct neighbor within several seconds subject to the qualification two paragraphs hence even if the gateway believes that neighbor to be down The EGP NR Poll message is defined for this purpose No gateway may poll another for an NR message more often than once per minute A gateway receiving more than one poll per minute may simply ignore the excess polls or may return an error message The Hello and I Heard You messages which gateway G sends to gateway G indicate the minimum interval which G will accept as the polling interval from G That is G will not guarantee to respond to polls from G that arrive less than that interval apart Polls must only be sent to direct neighbors which are declared reachable by the neighbor reachability protocol An NR Poll message contains an identification number chosen by the polling gateway The polled gateway will return this number in the NR message it sends in response to the poll to enable the polling gateway to match up received NR messages with 22 RFC 827 Bolt Beranek and Newman Inc Eric C Rosen polls It will be the responsibility of the polling gateway to choose an identification number which is sufficiently unique to allow detection of out of date NR messages which may still be floating around the network Since polls are relatively infrequent this is not expected to be much of a problem However to aid in choosing an identification number the Hello and I Heard You messages carry the identification number of the last NR poll received from the neighbor to which they are being sent In general a poll should be retransmitted some number of times with a reasonable interval between retransmissions until an NR message is received IF NO NR MESSAGE IS RECEIVED AFTER THE MAXIMUM NUMBER OF RETRANSMISSIONS THE POLLING GATEWAY SHOULD ASSUME THAT THE POLLED GATEWAY IS NOT AN APPROPRIATE FIRST HOP FOR ANY NETWORK WHATSOEVER The optimum parameters for the polling retransmission algorithm will be dependent on the characteristics of the two neighbors and of the network connecting them If only some fragments of an NR message are received after the maximum number of retransmissions the fragments that are present shall be treated as constituting the whole of the NR message 23 RFC 827 Bolt Beranek and Newman Inc Eric C Rosen Received NR messages whose identification numbers do not match the identification number of the most recently sent poll shall be ignored There is no provision for multiple outstanding polls to the same neighbor 24 RFC 827 Bolt Beranek and Newman Inc Eric C Rosen 6 SENDING NR MESSAGES In general NR messages are to be sent only in response to a poll However between two successive polls from an exterior neighbor a gateway may send one and only one unsolicited NR message to that neighbor This gives it limited ability to quickly announce network reachability changes that may have occurred in the interval since the last poll Excess unsolicited NR messages may be ignored or an error message may be returned An NR message should be sent within several seconds after receipt of a poll Failure to respond in a timely manner to an NR poll may result in the polling gateway s deciding that the polled gateway is not an appropriate first hop to any network NR messages sent in response to polls carry the identification number of the poll message in their identification number fields Unsolicited NR messages carry the identification number of the last poll received and have the unsolicited bit set Note that this allows for only a single unsolicited NR message per polling period To facilitate the sending of unsolicited NR messages the NR poll message has a byte indicating the polling interval in minutes 25 RFC 827 Bolt Beranek and Newman Inc Eric C Rosen Polls from non neighbors from neighbors which are not declared reachable or with bad IP source network fields should be responded to with an EGP error message with the appropriate reason field If G sends an NR poll to G with IP source network N and G is not a neighbor of G on its interface to network N or G does not have an interface to network N then the source network field is considered bad Duplicated polls successive polls with the same identification number should be responded to with duplicates of the same NR message If that message is fragmented the same fragments shall be sent each time Note that there is no provision for handling multiple outstanding polls from a single neighbor NOTE THAT IF THE SAME FRAGMENTS ARE NOT SENT IN RESPONSE TO DUPLICATED POLLS INCORRECT REASSEMBLY WILL BE THE PROBABLE RESULT If fragmentation is not being used however then no harm should result from responding to a duplicate poll with a different presumably more recent NR message 26 RFC 827 Bolt Beranek and Newman Inc Eric C Rosen 7 INDIRECT NEIGHBORS Becoming a direct neighbor of an exterior gateway requires three steps a neighbor acquisition b running a neighbor reachability protocol and c polling the neighbor periodically for NR messages Suppose however that gateway G receives an NR message from G in which G indicates the presence of other neighbors G1 Gn each of which is an appropriate first hop for some set of networks to which G itself is not an appropriate first hop Then G should be allowed to forward traffic for those networks directly to the appropriate one of G1 Gn without having to send it to G first In this case G may be considered an INDIRECT NEIGHBOR of G1 Gn since it is a neighbor of these other gateways for the purpose of forwarding traffic but does not perform neighbor acquisition neighbor reachability or exchange of NR messages with them Neighbor and network reachability information is obtained indirectly via G hence the designation indirect neighbor We say that G is an indirect neighbor of G1 Gn VIA G If G is an indirect neighbor of G via G and then G receives an NR message from G which does not mention G G should treat G as having become unreachable 27 RFC 827 Bolt Beranek and Newman Inc Eric C Rosen 8

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0827.txt (2016-02-14)
    Open archived version from archive


  • of its neighbors If a gateway concludes that a particular neighbor cannot be reached it should cease forwarding traffic to that gateway To make that determination a NEIGHBOR REACHABILITY protocol is needed The EGP protocol provides two messages types for this purpose a Hello message and an I Heard You message When a Hello message is received from a direct neighbor an I Heard You must be returned to that neighbor immediately The delay between receiving a Hello and returning an I Heard You should never be more than a few seconds Core gateways will use the following algorithm for determining reachablility of an exterior neighbor A reachable neighbor shall be declared unreachable if during the time in which the core gateway sent its last n Hello s it received fewer than k I Heard You s in return An unreachable neighbor shall be declared reachable if during the time in which the core gateway sent its last m Hello s it received at least j I Heard You s in return 10 RFC 888 JANUARY 1984 Stub gateways may also send Hello s to their direct neighbors and receive I Heard You s in return The algorithm for determining reachability may be similar to the algorithm described above However it is not necessary for stubs to send Hello s The Hello and I Heard You messages have a status field which the sending gateway uses to indicate whether it thinks the receiving gateway is reachable or not This information can be useful for diagnostic purposes It also allows a stub gateway to make its reachability determination parasitic on its core neighbor only the core gateway actually needs to send Hello messages and the stub can declare it up or down based on the status field in the Hello That is the stub gateway which sends only I Heard You s declares the core gateway which sends only Hello s to be reachable when the Hello s from the core indicate that it has declared the stub to be reachable The frequency with which the Hello s are sent and the values of the parameters k n j and m cannot be specified here For best results this will depend on the characteristics of the neighbor and of the network which the neighbors have in common THIS IMPLIES THAT THE PROPER PARAMETERS MAY NEED TO BE DETERMINED JOINTLY BY THE DESIGNERS AND IMPLEMENTERS OF THE TWO NEIGHBORING 11 RFC 888 JANUARY 1984 GATEWAYS choosing algorithms and parameters in isolation without considering the characteristics of the neighbor and the connecting network would not be expected to result in optimum reachability determinations However the Neighbor Acquisition Request and Reply messages provide neighbors with a way to inform each other of the minimum frequency at which they are willing to answer Hellos When gateway G sends a Neighbor Acquisition Request to gateway G it states that it does not wish to answer Hellos from G more frequently than once every X seconds G in its Neighbor Acquisition Reply states that it does not wish to answer Hellos from G more frequently than once every Y seconds The two frequencies do not have to be the same but each neighbor must conform to the interval requested by the other A gateway may send Hellos less frequently than requested but not more A direct neighbor gateway should also be declared unreachable if the network connecting it supplies lower level protocol information from which this can be deduced Thus for example if a gateway receives an 1822 Destination Dead message from the ARPANET which indicates that a direct neighbor is dead it should declare that neighbor unreachable The neighbor should 12 RFC 888 JANUARY 1984 not be declared reachable again until the requisite number of Hello I Heard You packets have been exchanged A direct neighbor which has become unreachable does not thereby cease to be a direct neighbor The neighbor can be declared reachable again without any need to go through the neighbor acquisition protocol again However if the neighbor remains unreachable for an extremely long period of time such as an hour the gateway should cease to treat it as a neighbor i e should cease sending Hello messages to it The neighbor acquisition protocol would then need to be repeated before it could become a direct neighbor again Hello messages from sources other than direct neighbors should simply be ignored However logging the presence of any such messages might provide useful diagnostic information A gateway which is going down or whose interface to the network which connects it to a particular neighbor is going down should send a Neighbor Cease message to all direct neighbors which will no longer be able to reach it The Cease message should use the info field to specify the reason as going down It should retransmit that message up to some number of times until it receives a Neighbor Cease Acknowledgment This provides 13 RFC 888 JANUARY 1984 the neighbors with an advance warning of an outage and enables them to prepare for it in a way which will minimize disruption to existing traffic 14 RFC 888 JANUARY 1984 5 NETWORK REACHABILITY NR MESSAGE Terminology Let gateway G have an interface to network N We say that G is AN APPROPRIATE FIRST HOP to network M relative to network N where M and N are distinct networks if and only if the following condition holds Traffic which is destined for network M and which arrives at gateway G over its network N interface will be forwarded to M by G over a path which does not include any other gateway with an interface to network N In short G is an appropriate first hop for network M relative to network N just in case there is no better gateway on network N through which to route traffic which is destined for network M For optimal routing traffic in network N which is destined for network M ought always to be forwarded to a gateway which is an appropriate first hop In order for exterior neighbors G and G which are neighbors over network N to be able to use each other as packet switches for forwarding traffic to remote networks each needs to know the list of networks for which the other is an appropriate first hop The Exterior Gateway Protocol defines a message 15 RFC 888 JANUARY 1984 called the Network Reachability Message or NR message for transferring this information Let G be a gateway on network N Then the NR message which G sends about network N must contain the following information A list of all the networks for which G is an appropriate first hop relative to network N If G can obtain this information from exterior neighbor G then it knows that no traffic destined for networks which are NOT in that list should be forwarded to G It cannot simply conclude however that all traffic for any networks in that list ought to be forwarded via G since G may also have other neighbors which are also appropriate first hops to network N For example G and G might each be neighbors of G but might be equidistant from some network M Then each could be an appropriate first hop For each network in the list the NR message also specifies the distance according to some metric whose definition is left to the designers of the autonomous system of which gateway G is a member from G to that network Core gateways will report distances less than 128 for networks that can be reached without 16 RFC 888 JANUARY 1984 leaving the core system and greater than or equal to 128 otherwise A stub gateway should report distances less than 128 for all networks listed in its NR messages The maximum value of distance 255 shall be taken to mean that the network is UNREACHABLE ALL OTHER VALUES WILL BE TAKEN TO MEAN THAT THE NETWORK IS REACHABLE If an NR message from some gateway G fails to mention some network N which was mentioned in the previous NR message from G it is possible that N has become unreachable from G If several successive NR messages from G omit mention of N it should be taken to mean that N is no longer reachable from G This procedure is necessary to ensure that networks which can no longer be reached but which are never explicitly declared unreachable are timed out and removed from the list of reachable networks It will often be the case that where a core gateway G and a stub gateway G are direct neighbors on network N G knows of many more gateway neighbors on network N and knows for which networks those gateway neighbors are the appropriate first hop Since the stub G may not know about all these other neighbors it is convenient and often more efficient for it to be able to 17 RFC 888 JANUARY 1984 obtain this information from G Therefore the EGP NR message also contains fields which allow the core gateway G to specify the following information a A list of all neighbors both interior and exterior of G on network N which G has reliably determined to be reachable G may also include indirect neighbors in this list see below b For each of those neighbors the list of networks for which that neighbor is an appropriate first hop relative to network N c For each such pair the distance from that neighbor to that network Thus the NR message provides a means of allowing a gateway to discover new neighbors by seeing whether a neighbor that it already knows of has any additional neighbors on the same network This information also makes possible the implementation of the INDIRECT NEIGHBOR strategy defined below A more precise description of the NR message is the following 18 RFC 888 JANUARY 1984 The data portion of the message will consist largely of blocks of data Each block will be headed by a gateway address which will be the address either of the gateway sending the message or of one of that gateway s neighbors Each gateway address will be followed by a list of the networks for which that gateway is an appropriate first hop All networks at the same distance from the gateway will be grouped together in this list preceded by the distance itself and the number of networks at that distance The whole list is preceded by a count of the distance groups in the list Preceding the list of data blocks is a The count one byte of the number of interior neighbors of G for which this message contains data blocks By convention this count will include the data block for G itself which should be the first one to appear b The count one byte of the number of exterior neighbors of G for which this message contains data blocks c The address of the network which this message is about If G and G are neighbors on network N then in the NR message going from G to G this is the address of 19 RFC 888 JANUARY 1984 network N For convenience four bytes have been allocated for this address the trailing one two or three bytes should be zero Then follow the data blocks themselves first the block for G itself then the blocks for all the interior neighbors of G if any then the blocks for the exterior neighbors Since all gateways mentioned are on the same network whose address has already been given the gateway addresses are given with the network address part one two or three bytes omitted to save space In the list of networks each network address is either one two or three bytes depending on whether it is a class A class B or class C network No trailing bytes are used The NR message sent by a stub should be the simplest allowable That is it should have only a single data block headed by its own address on the network it has in common with the neighboring core gateway listing just the networks to which it is an appropriate first hop These will be just the networks that can be reached no other way in general 20 RFC 888 JANUARY 1984 The core gateways will send complete NR messages containing information about all other gateways on the common network both core gateways which shall be listed as interior neighbors and other gateways which shall be listed as exterior neighbors and may include the stub itself This information will enable the stub to become an indirect neighbor see below of all these other gateways That is the stub shall forward traffic directly to these other gateways as appropriate but shall not become direct neighbors with them The stub should NEVER forward to any directly or indirectly neighboring core gateway any traffic for which that gateway is not an appropriate first hop as indicated in an NR message Of course this does not apply to datagrams which are using the source route option any such datagrams should always be forwarded as indicated in the source route option field even if that requires forwarding to a gateway which is not an appropriate first hop 21 RFC 888 JANUARY 1984 6 POLLING FOR NR MESSAGES No gateway is required to send NR messages to any other gateway except as a response to an NR Poll from a direct neighbor However a gateway is required to respond to an NR Poll from a direct neighbor within several seconds subject to the qualification two paragraphs hence even if the gateway believes that neighbor to be down The EGP NR Poll message is defined for this purpose No gateway may poll another for an NR message more often than once per minute A gateway receiving more than one poll per minute may simply ignore the excess polls or may return an error message The minimum interval which gateway G will accept as the polling interval from gateway G and the minimum interval which G will accept as the polling interval from G are specified at the time that G and G become direct neighbors Both the Neighbor Acquisition Request and the Neighbor Acquisition Reply allow the sender to specify in seconds its desired minimum polling interval If G specifies to G that its minimum polling interval is X G should not poll G more frequently than once every X seconds G will not guarantee to answer more frequent 22 RFC 888 JANUARY 1984 polls Polls must only be sent to direct neighbors which are declared reachable by the neighbor reachability protocol An NR Poll message contains a sequence number chosen by the polling gateway The polled gateway will return this number in the NR message it sends in response to the poll to enable the polling gateway to match up received NR messages with polls In general a poll should be retransmitted some number of times with a reasonable interval between retransmissions until an NR message is received IF NO NR MESSAGE IS RECEIVED AFTER THE MAXIMUM NUMBER OF RETRANSMISSIONS THE POLLING GATEWAY SHOULD ASSUME THAT THE POLLED GATEWAY IS NOT AN APPROPRIATE FIRST HOP FOR ANY NETWORK WHATSOEVER The optimum parameters for the polling retransmission algorithm will be dependent on the characteristics of the two neighbors and of the network connecting them Received NR messages whose identification numbers do not match the identification number of the most recently sent poll shall be ignored There is no provision for multiple outstanding polls to the same neighbor 23 RFC 888 JANUARY 1984 7 SENDING NR MESSAGES In general NR messages are to be sent only in response to a poll However between two successive polls from an exterior neighbor a gateway may send one and only one unsolicited NR message to that neighbor This gives it limited ability to quickly announce network reachability changes that may have occurred in the interval since the last poll Excess unsolicited NR messages may be ignored or an error message may be returned An NR message should be sent within several seconds after receipt of a poll Failure to respond in a timely manner to an NR poll may result in the polling gateway s deciding that the polled gateway is not an appropriate first hop to any network NR messages sent in response to polls carry the sequence number of the poll message in their sequence number fields Unsolicited NR messages carry the identification number of the last poll received and have the unsolicited bit set Note that this allows for only a single unsolicited NR message per polling period Polls from non neighbors from neighbors which are not declared reachable or with bad IP source network fields should 24 RFC 888 JANUARY 1984 be responded to with an EGP error message with the appropriate reason field If G sends an NR poll to G with IP source network N and G is not a neighbor of G on its interface to network N or G does not have an interface to network N then the source network field is considered bad A gateway is normally not required to send more than one NR message within the minimum interval specified at the time of the neighbor acquisition An exception to this must be made for duplicate polls successive polls with the same sequence number which occur when an NR message is lost in transit A gateway should send an NR message containing its most recent information in response to a duplicate poll 25 RFC 888 JANUARY 1984 8 INDIRECT NEIGHBORS Becoming a direct neighbor of an exterior gateway requires three steps a neighbor acquisition b running a neighbor reachability protocol and c polling the neighbor periodically for NR messages Suppose however that gateway G receives an NR message from G in which G indicates the presence

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0888.txt (2016-02-14)
    Open archived version from archive


  • only in some states however a Stop event has meaning in all states In all except the Idle state the abort timer t3 is presumed running This timer is initialized at P5 seconds upon entry to any state and at P4 seconds upon receipt of a neighbor reachability indication in the Down and Up states If it expires a Stop event is declared A Stop event can also be declared by an intrinsic system action such as a resource problem or operator command If the abort timer is not implemented a manually initiated Stop event can be used to stop the protocol If this is done in the Down or Up states the machine will transition to the Cease state and emit a Cease command If the neighbor does not respond to this command the machine will stay in the Cease state indefinately however a second Stop event can be used in this state to force a transition to the Idle state A Cease command received in any state will cause the gateway to immediately send the Cease ack response and transition to the Idle state This causes the protocol to be stopped and all system resources committed to the gateway process to be released The interval between the time the gateway enters the Idle state as the result of receiving a Cease command and the time when it next sends a Request command to resume the protocol is not specified however it is recommended this interval be at least P5 seconds It may happen that the Cease ack response is lost in the network causing the neighbor to retransmit the Cease response indefinately at least if it has not implemented the abort timer option In order to reduce the likelihood of this happening it is suggested that a gateway in the Idle state be prepared to reply to a Cease command with a Cease ack response whenever possible 4 3 Determining Neighbor Reachability The purpose of the neighbor reachability algorithm is to confirm that the neighbor can safely be considered operational and capable of Exterior Gateway Protocol Formal Specification Page 14 D L Mills providing reliable net reachability information An equally important purpose is to filter noisy reachability information before sending it on to the remainder of the Internet gateway system thus avoiding unneccesary reachability changes As described above a gateway operating in the active mode sends periodic Hello commands and listens for I H U responses in order to determine neighbor reachability indications A gateway operating in the passive mode determines reachability indications by means of the Status field in received Hello commands Poll commands and Update responses can be used in lieu of Hello commands and I H U responses respectively since they contain the same Status field information The neighbor reachability algorithm runs continuously while the gateway is in the Down and Up states and operates as follows Define a moving window in time starting at the present and extending backwards for t seconds Then count the number n of neighbor reachability indications which have occured in that window If n increases to j then declare a Up event If n decreases to k then declare a Down event The number n is set to zero upon entering the Down state from any state other than the Up state The window t in this algorithm is defined as T3 seconds the value of which is suggested as four times T1 which itself is determined during the Request Confirm exchange For proper operation of the algorithm only one neighbor reachability indication is significant in any window of T1 seconds and additional ones are ignored Note that the only way n can increase is as the result of a new neighbor reachability indication and the only way it can decrease is as the result of an old neighbor reachability indication moving out of the window The behavior of the algorithm described above and using the suggested fixed parameters j and k differs depending on whether the gateway is operating in the active or passive mode In the active mode j 3 k 1 and T3 T1 4 once the neighbor has been declared down it will be forced down for at least two T1 intervals and once it has been declared up it will be forced up for at least two T1 intervals It will not change state unless at least three of the last four determinations of reachability have indicated that change In the passive mode j 1 k 4 and T3 T1 4 the neighbor will be considered up from the first time the Status field of a Hello or Poll command or Update response indicates Up state until four successive T1 intervals have passed without such indication This design suggested by similar designs used in the ARPANET has proven effective in the experimental implementations but may need to be adjusted for other configurations It is convenient for the active gateway to send Hello commands at a rate of one every T1 seconds and substitute a Poll command for a Hello Exterior Gateway Protocol Formal Specification Page 15 D L Mills command approximately once every T2 seconds with the neighbor reachability indication generated by the corresponding I H U or Update responses Its passive neighbor generates neighbor reachability indications from the Status field of received Hello and Poll commands and Update responses Implementors may find the following model useful in the understanding and implementation of this algorithm Consider an n bit shift register that shifts one bit to the right each T1 second interval If a neighbor reachability indication was received during the preceeding T1 second interval a one bit is shifted into the register at the end of the interval otherwise a zero bit is shifted A table of 2 n entries indexed by the contents of the register can be used to calculate the number of one bits which can then be used to declare the appropriate event to the state machine A value of n equal to four has been found useful in the experimental implementations 4 4 Determining Network Reachability Network reachability information is encoded into Update messages in the form of lists of nets and gateways The IP Source Address field of the Poll command is used to specify a network common to the autonomous systems of each of the neighbors which is usually but not necessarily the one common to the neighbors themselves The Update response includes a list of gateways on the common net Associated with each gateway is a list of the networks reachable via that gateway together with corresponding hop counts It is important to understand that at the present state of development as described in RFC 827 and RFC 888 the EGP architectural model restricts the interpretation of reachable in this context This consideration as well as the implied topological restrictions are beyond the scope of discussion here The reader is referred to the RFCs for further discussion Two types of gateway lists can be included in the Update response the format of which is described in Appendix A Both lists include only those gateways directly connected to the net specified in the IP Source Network field of the last received Poll command The internal list includes some or all of the gateways in the same autonomous system as the sender together with the nets which are reachable via these gateways with the sending gateway listed first A net is reachable in this context if a path exists to that net including only gateways in the system The external list includes those gateways in other autonomous systems known to the sender It is important to realize that the hop counts do not represent a routing metric and are comparable between different gateways only if those gateways belong to the same autonomous system that is are in the internal list Exterior Gateway Protocol Formal Specification Page 16 D L Mills According to the current system architectural model only gateways belonging to a designated system called the core system may include the external list in their Update responses All other gateways may include only those gateways belonging to the same system and can claim reachability for a particular net only if that net is reachable in the same system The interval between successive Poll commands T2 is determined during the Request Confirm exchange However the specification permits at most one unsolicited Update indication between succeeding Poll commands received from the neighbor It is the intent of the model here that an Update indication is sent a upon entry to the Up state and b when a change in the reachability data base is detected subject to this limitation Occasionally it may happen that a Poll command or Update response is lost in the network with the effect that net reachability information may not be available until after another T2 interval As an implementation option the gateway sending a Poll command and not receiving an Update response after T1 seconds may send another Poll The gateway receiving this Poll may either a send an Update response if it never received the original Poll for that interval b send a second Update response which counts as the unsolicited Update indication mentioned in the preceeding paragraph or c send an Error response or not respond at all in other cases 4 5 Error Messages Error messages can be used to report problems such as described in Appendix A in connection with the Error Response Indication message format In general an Error message is sent upon receipt of another command or response with bad format content or ordering but never in response to another Error message Receipt of an Error message should be considered advisory and not result in change of state except possibly to evoke a Stop event Exterior Gateway Protocol Formal Specification Page 17 D L Mills Appendix A EGP Message Formats The formats for the various EGP messages are described in this section All EGP messages include a ten octet header of six fields which may be followed by additional fields depending on message type The format of the header is shown below along with a description of its fields 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 EGP Version Type Code Status Checksum Autonomous System Sequence EGP Version assigned number identifying the EGP version currently 2 Type identifies the message type Code identifies the message code subtype Status contains message dependent status information Checksum The EGP checksum is the 16 bit one s complement of the one s complement sum of the EGP message starting with the EGP version number field When computing the checksum the checksum field itself should be zero Autonomous System assigned number identifying the particular autonomous system Sequence send state variable commands or receive state variable responses and indications Following is a description of each of the message formats Note that the above description applies to all formats and will not be repeated Exterior Gateway Protocol Formal Specification Page 18 D L Mills A 1 Neighbor Acquisition Messages 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 EGP Version Type Code Status Checksum Autonomous System Sequence Hello Interval Poll Interval Note the Hello Interval and Poll Interval fields are present only in Request and Confirm messages Type 3 Code 0 Request command 1 Confirm response 2 Refuse response 3 Cease command 4 Cease ack response Status see below 0 unspecified 1 active mode 2 passive mode 3 insufficient resources 4 administratively prohibited 5 going down 6 parameter problem 7 protocol violation Hello Interval minimum Hello command polling interval seconds Poll Interval minumum Poll command polling interval seconds Following is a summary of the assigned Status codes along with a list of scenarios in which they might be used Exterior Gateway Protocol Formal Specification Page 19 D L Mills Code Status Scenarios 0 unspecified when nothing else fits 1 active mode Request Confirm only 2 passive mode Request Confirm only 3 insufficient resources 1 out of table space 2 out of system resources 4 administratively 1 unknown Autonomous System prohibited 2 use another gateway 5 going down 1 operator initiated Stop 2 abort timeout 6 parameter problem 1 nonsense polling parameters 2 unable to assume compatible mode 7 protocol violation 1 Invalid command or response received in this state Exterior Gateway Protocol Formal Specification Page 20 D L Mills A 2 Neighbor Reachability Messages 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 EGP Version Type Code Status Checksum Autonomous System Sequence Type 5 Code 0 Hello command 1 I H U response Status 0 indeterminate 1 Up state 2 Down state Exterior Gateway Protocol Formal Specification Page 21 D L Mills A 3 Poll Command 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 EGP Version Type Code Status Checksum Autonomous System Sequence Reserved IP Source Network Type 2 Code 0 Status 0 indeterminate 1 Up state 2 Down state IP Source Network IP network number of the network about which reachability information is being requested coded as 1 2 or 3 octets left justified with trailing zeros Exterior Gateway Protocol Formal Specification Page 22 D L Mills A 4 Update Response Indication 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 EGP Version Type Code Status Checksum Autonomous System Sequence of Int Gwys of Ext Gwys IP Source Network Gateway 1 IP address without network 1 3 octets Distances Distance 1 Nets net 1 1 1 1 3 octets net 1 1 2 1 3 octets Distance 2 Nets net 1 2 1 1 3 octets net 1 2 2 1 3 octets Gateway n IP address without network Distances Distance 1 Nets net n 1 1 1 3 octets net n 1 2 1 3 octets Distance 2 Nets net n 2 1 1 3 octets net n 2 2 1 3 octets Exterior Gateway Protocol Formal Specification Page 23 D L Mills Type 1 Code 0 Status 0 indeterminate 1 Up state 2 Down state 128 unsolicited message bit of Int Gwys number of interior gateways appearing in this message of Ext Gwys number of exterior gateways appearing in this message IP Source Network IP network number of the network about which reachability information is being supplied coded as 1 2 or 3 octets left justified with trailing zeros Gateway IP addresses IP address without network number of the gateway block coded as 1 2 or 3 octets of Distances number of distances in the gateway block Distances numbers depending on autonomous system architecture of Nets number of nets at each distance Nets IP network number reachable via the gateway Exterior Gateway Protocol Formal Specification Page 24 D L Mills A 5 Error Response Indication 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 EGP Version Type Code Status Checksum Autonomous System Sequence Reason Error Message Header first three 32 bit words of EGP header Type 8 Code 0 Status 0 indeterminate 1 Up state 2 Down state 128 unsolicited message bit Reason see below 0 unspecified 1 bad EGP header format 2 bad EGP data field format 3 reachability info unavailable 4 excessive polling rate 5 no response Error Message Header first three 32 bit words of EGP header Following is a summary of the assigned Reason codes along with a list of scenarios in which they might be used Exterior Gateway Protocol Formal Specification Page 25 D L Mills Code Reason Scenarios 0 unspecified when nothing else fits 1 bad EGP header format 1 bad message length 2 invalid Type Code or Status fields Notes The recipient can determine which of the above hold by inspecting the EGP header included in the message An instance of a wrong EGP version or bad checksum should not be reported since the original recipient can not trust the header format An instance of an unknown autonomous system should be caught at acquistion time 2 bad EGP data field 1 nonsense polling rates format Request Confirm 2 invalid Update message format 3 response IP Net Address field does not match command Update Notes An instance of nonsense polling intervals e g too long to be useful specified in a Request or Confirm should result in a Refuse or Cease with this cause specified 3 reachability info 1 no info available on net specified in unavailable IP Net Address field Poll 4 excessive polling rate 1 two or more Hello commands received within minimum specified polling interval 2 two or more Poll commands received within minimum specified polling interval 3 two or more Request commands received within some reasonably short interval Notes The recipient can determine which of the above hold by inspecting the EGP header included in the message 5 no response 1 no Update received for Poll within some reasonably long interval Exterior Gateway Protocol Formal Specification Page 26 D L Mills Appendix B Comparison with RFC 888 Minor functional enhancements are necessary in the RFC 888 message formats to support certain features assumed of the state machine model

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0904.txt (2016-02-14)
    Open archived version from archive


  • and B ARPANET gateways According to the restrictions above gateway C A could list net C in EGP messages sent to A ARPANET while A ARPANET could list ARPANET in messages sent to C A but not other nets which it may learn about from the core Thus gateway C A cannot acquire full routing information unless it runs EGP directly with a core gateway Mills Page 4 RFC 975 February 1986 Autonomous Confederations 2 Autonomous Systems and Confederations The second example above illustrates the need for a mechanism in which arbitrary routing information can be exchanged between non core gateways without degrading the degree of robustness relative to a mutually agreed security model One way of doing this is is to extend the existing single core autonomous system model to include multiple core systems This requires both a topological model which can be used to define the scope of these systems together with a global trusted metric that can be used to drive the routing computations An appropriate topological model is described in the next section while an appropriate metric is suggested in the following section 2 1 Topological Models An autonomous system consists of a set of gateways each of which can reach any other gateway in the same system using paths via gateways only in that system The gateways of a system cooperatively maintain a routing data base using an interior gateway protocol IGP and a intra system trusted routing mechanism of no further concern here The IGP is expected to include security mechanisms to insure that only gateways of the same system can acquire each other as neighbors One or more gateways in an autonomous system can run EGP with one or more gateways in a neighboring system There is no restriction on the number or configuration of EGP neighbor paths other than the requirement that each path involve only gateways of one system or the other and not intrude on a third system It is specifically not required that EGP neighbors share a common network although most probably will An autonomous confederation consists of a set of autonomous systems sharing a common security model that is they trust each other to compute routes to other systems in the same confederation Each gateway in a confederation can reach any other gateway in the same confederation using paths only in that confederation Although there is no restriction on the number or configuration of EGP paths other than the above it is expected that some mechanism be available so that potential EGP neighbors can discover whether they are in the same confederation This could be done by access control lists for example or by partitioning the set of system numbers A network is directly reachable from an autonomous system if a gateway in that system has an interface to it Every gateway in Mills Page 5 RFC 975 February 1986 Autonomous Confederations that system is entitled to list all directly reachable networks in EGP messages sent to any other system In general it may happen that a particular network is directly reachable from more than one system A network is reachable from an autonomous system if it is directly reachable from an autonomous system belonging to the same confederation A directly reachable net is always reachable from the same system Every gateway in that confederation is entitled to list all reachable nets in EGP messages sent to any other system It may happen that a particular net is either directly reachable or reachable from different confederations In order to preserve global routing stability in the Internet it is explicitly assumed that routes within an autonomous system to a directly reachable net are always preferred over routes outside that system and that routes within an autonomous confederation are always preferred over routes outside that confederation The mechanism by which this is assured is described in the next section In general EGP Update messages can include two lists of gateways one for those gateways belonging to the same system internal neighbors and the other for gateways belonging to different systems external neighbors Directly reachable nets must always be associated with gateways of the same system that is with internal neighbors while non directly reachable nets can be associated with either internal or external neighbors Nets that are reachable but not directly reachable must always be associated with gateways of the same confederation 2 2 Trusted Routing Metrics There seems to be a general principle which characterizes distributed systems The nearer a thing is the more dynamic and trustable it is while the farther a thing is the more static and suspicious it is For instance the concept of network is intrinsic to the Internet model as is the concept of gateways which bind them together A cluster of gateways near each other e g within an autonomous system typically exchange routing information using a high performance routing algorithm capable of sensitive monitoring of and rapid adaptation to changing performance indicators such as queueing delays and link loading However clusters of gateways far from each other e g widely separated autonomous systems usually need only coarse routing information possibly only hints on the best likely next hop to Mills Page 6 RFC 975 February 1986 Autonomous Confederations the general destination area On the other hand mutual suspicion increases with distance so these clusters may need elaborate security considerations including peer authentication confidentiality secrecy and signature verification In addition considerations of efficiency usually dictate that the allowable network bandidth consumed by the routing protocol itself decreases with distance The price paid for both of these things typically is in responsiveness with the effect that the more distant clusters are from each other the less dynamic is the routing algorithm The above observations suggest a starting point for the evolution of a globally acceptable routing metric Assume the metric is represented by an integer with low values representing finer distinctions nearer the gateway and high values coarser distinctions farther from it Values less

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0975.txt (2016-02-14)
    Open archived version from archive


  • Address Mask messages described in RFC 950 It is highly desirable although not required to provide correct data for ICMP Timestamp messages which have been found useful in network debugging and maintenance 2 3 Exterior Gateway Protocol EGP This is the basic protocol used to exchange information between gateway systems of the Internet and is described in RFC 904 11 However EGP as presently specified is an asymmetric protocol with only the non core procedures defined in RFC 904 There are at present no core procedures specified which would be necessary for a stand alone Internet RFC 975 27 suggests certain modifications leading to a symmetric model however this is not an official specification In principle a stand alone Internet can be built with non core EGP gateways using the EGP distance field to convey some metric NTAG Page 7 RFC 985 May 1986 Requirements for Internet Gateways DRAFT such as hop count However the use of EGP in this way as a routing algorithm is discouraged since typical implementations adapt very slowly to changing topology and have no loop protection features The EGP model requires each gateway belong to an autonomous system of gateways If a routing algorithm is operated in one or more gateways of an autonomous system its data base must be coupled to the EGP implementation in such a way that when a net is declared down by the routing algorithm the net is also declared down via EGP to other autonomous systems This requirement is designed to minimize spurious traffic to black holes and insure fair utilization of the resources on other systems There are no peer discovery or authentication procedures defined in the present EGP specification and no defined interpretation of the distance fields in the update messages although such procedures may be defined in future see RFC 975 There is currently no guidance on the selection of polling parameters and no specific recovery procedures in case of certain error messages e g administratively prohibited It is recommended that EGP implementations include provisions to initialize these parameters as part of the monitoring and control procedures and that changing these procedures not require recompilation or rebooting the gateway 2 4 Address Resolution Protocol ARP This is an auxiliary protocol used to manage the address translation function between hardware addresses in a local net environment and Internet addresses and described in RFC 826 4 However there are a number of unresolved issues having to do with subnets and response to addresses not in the same subnet or net These issues which are intertwined with ICMP and various gateway models are discussed in Appendix A 3 Subnets The concept of subnets was introduced in order to allow arbitrary complexity of interconnected LAN structures within an organization while insulating the Internet system against explosive growth in network numbers and routing complexity The subnet architecture described in RFC 950 21 is intended to specify a standard approach that does not require reconfiguration for host implementations regardless of subnetting scheme The document also specifies a new NTAG Page 8 RFC 985 May 1986 Requirements for Internet Gateways DRAFT ICMP Address Mask message which a gateway can use to specify certain details of the subnetting scheme to hosts and is required in new host and gateway implementations The current subnet specification RFC 950 does not describe the specific procedures to be used by the gateway except by implication It is recommended that a sub net address and address mask be provided for each network interface and that these values be established as part of the gateway configuration procedure It is not usually necessary to change these values during operation of any particular gateway however it should be possible to add new gateways and or sub nets and make other configuration changes to a gateway without taking the entire network down 4 Local Network Interface The packet format used for transmission of datagrams on the various subnetworks is described in a number of documents summarized below 4 1 Public data networks via X 25 The formats specified for public data networks via X 25 access are described in RFC 877 8 Datagrams are transmitted over standard level 3 virtual circuits as complete packet sequences Virtual circuits are usually established dynamically as required and time out after a period of no traffic Retransmission resequencing and flow control are performed by the network for each virtual circuit and by the LAPB link level protocol Multiple parallel virtual circuits are often used in order to improve the utilization of the subscriber access line which can result in random resequencing The correspondence between Internet and X 121 addresses is usually established by table lookup It is expected that this will be replaced by some sort of directory procedure in future 4 2 ARPANET via 1822 Local Host Distant Host or HDLC Distant Host The formats specified for ARPANET networks via 1822 access are described in BBN Report 1822 3 which includes the procedures for several subscriber access methods The Local Host LH and Very Distant Host VDH methods are not recommended for new implementations The Distant Host DH method is used when the host and IMP are separated by not more than about 2000 feet of cable while the HDLC Distant Host is used for greater distances where a modem is required Retransmission resequencing and flow control are performed by the network and by the HDLC link level protocol when used While the ARPANET 1822 protocols are widely NTAG Page 9 RFC 985 May 1986 Requirements for Internet Gateways DRAFT used at present they are expected to be eventually overtaken by the DDN Standard X 25 protocol see below and the new PSN End to End Protocol described in RFC 979 29 While the cited report gives details of the various ARPANET subscriber access methods it specifies neither the IP packet encapsulation format nor address mappings While these are generally straightforward and easy to implement the details involve considerations beyond the scope of readily accessable documentation Potential vendors are encouraged to contact one of the individuals listed at the beginning of this document for further information Gateways connected to ARPANET MILNET IMPs must incorporate features to avoid host port blocking RFNM counting and to detect and report as ICMP Unreachable messages the failure of destination hosts or gateways 4 3 ARPANET via DDN Standard X 25 The formats specified for ARPANET networks via X 25 are described in the Defense Data Network X 25 Host Interface Specification 6 This document describes two sets of procedures the DDN Basic X 25 and the DDN Standard X 25 but only the latter is suitable for use in the Internet system The DDN Standard X 25 procedures are similar to the public data subnetwork X 25 procedures except in the address mappings Retransmission resequencing and flow control are performed by the network and by the LAPB link level protocol 4 4 Ethernets The formats specified for Ethernet networks are described in RFC 894 10 Datagrams are encapsulated as Ethernet packets with 48 bit source and destination address fields and a 16 bit type field Address translation between Ethernet addresses and Internet addresses is managed by the Address Resolution Protocol which is required in all Ethernet implementations There is no explicit retransmission resequencing or flow control although most hardware interfaces will retransmit automatically in case of collisions on the cable It is expected that amendments will be made to this specification as the result of IEEE 802 3 evolution See RFC 948 20 for further discussion and recommendations in this area Note also that the IP broadcast address which has primary application to Ethernets and similar technologies that support an inherent NTAG Page 10 RFC 985 May 1986 Requirements for Internet Gateways DRAFT broadcast function has an all ones value in the host field of the IP address Some early implementations chose the all zeros value for this purpose which is presently not in conformance with the definitive specification RFC 950 21 See Appendix A for further considerations 4 5 Serial Line Protocols Gateways may be used as packet switches in order to build networks In some configurations gateways may be interconnected with each other and some hosts by means of serial asynchronous or synchronous lines with or without modems When justified by the expected error rate and other factors a link level protocol may be required on the serial line While there is no requirement that a particular standard protocol be used for this it is recommended that standard hardware and protocols be used unless a convincing reason to the contrary exists In order to support the greatest variety of configurations it is recommended that some variation on full X 25 i e symmetric mode be used where resources permit however X 25 LAPB would also be acceptable where requirements permit In the case of asynchronous lines no clear choice is apparent 5 Interoperability In order to assure interoperability between gateways procured from different vendors it is necessary to specify points of protocol demarcation With respect to interoperability of the routing function this is specified as EGP All gateway systems must include one or more gateways which support EGP with a core gateway as described in RFC 904 11 It is desirable that these gateways be able to operate in a mode that does not require a core gateway or system Additional discussion on these issues can be found in RFC 975 27 With respect to the interoperability at the network layer and below two points of protocol demarcation are specified one for Ethernets and the other for serial lines In the case of Ethernets the protocols are as specified in Section 4 4 and Appendix A of this document For serial lines between gateways of different vendors the protocols are specified in Section 4 5 of this document Exceptions to these requirements may be appropriate in some cases NTAG Page 11 RFC 985 May 1986 Requirements for Internet Gateways DRAFT 6 Subnetwork Architecture It is recognized that gateways may also function as general packet switches to build networks of modest size This requires additional functionality in order to manage network routing control and configuration While it is beyond the scope of this document to specify the details of the mechanisms used in any particular perhaps proprietary architecture there are a number of basic requirements which must be provided by any acceptable architecture 6 1 Reachability Procedures The architecture must provide a robust mechanism to establish the operational status of each link and node in the network including the gateways the links connecting them and where appropriate the hosts as well Ordinarily this requires at least a link level reachability protocol involving a periodic exchange of hello messages across each link This function might be intrinsic to the link level protocols used e g LAPB DDCMP However it is in general ill advised to assume a host or gateway is operating correctly if its link level reachability protocol is operating correctly Additional confirmation is required in the form of an operating routing algorithm or peer level reachability protocol such as used in EGP Failure and restoration of a link and or gateway are considered network events and must be reported to the control center It is desirable although not required that reporting paths not require correct functioning of the routing algorithm itself 6 2 Routing Algorithm It has been the repeated experience of the Internet community participants that the routing mechanism whether static or dynamic is the single most important engineering issue in network design In all but trivial network topologies it is necessary that some degree of routing dynamics is vital to successful operation whether it be affected by manual or automatic means or some combination of both In particular if routing changes are made manually the changes must be possible without taking down the gateways for reconfiguration and preferably be possible from a remote site such as a control center It is not likely that all nets can be maintained from a full service control center so that automatic fallback or rerouting features may be required This must be considered the normal case so that systems of gateways operating as the only NTAG Page 12 RFC 985 May 1986 Requirements for Internet Gateways DRAFT packet switches in a network would normally be expected to have a routing algorithm with the capability of reacting to link and other gateway failures and changing the routing automatically Following is a list of features considered necessary 1 The algorithm must sense the failure or restoration of a link or other gateway and switch to appropriate paths within an interval less than the typical TCP user timeout one minute is a safe assumption 2 The algorithm must never form routing loops between neighbor gateways and must contain provisions to avoid and suppress routing loops that may form between non neighbor gateways In no case should a loop persist for longer than an interval greater than the typical TCP user timeout 3 The control traffic necessary to operate the routing algorithm must not significantly degrade or disrupt normal network operation Changes in state which might momentarily disrupt normal operation in a local area must not cause disruption in remote areas of the network 4 As the size of the network increases the demand on resources must be controlled in an efficient way Table lookups should be hashed for example and data base updates handled piecemeal with only the changes broadcast over a wide area Reachability and delay metrics if used must not depend on direct connectivity to all other gateways or the use of network specific broadcast mechanisms Polling procedures e g for consistency checking should be used only sparingly and in no case introduce an overhead exceeding a constant independent of network topology times the longest non looping path 5 The use of a default gateway as a means to reduce the size of the routing data base is strongly discouraged in view of the many problems with multiple paths loops and mis configuration vulnerabilities If used at all it should be limited to a discovery function with operational routes cached from external or internal data bases via either the routing algorithm or EGP 6 This document places no restriction on the type of routing algorithm such as node based link based or any other algorithm or metric such as delay or hop count However the size of the routing data base must not be allowed to exceed a constant independent of network topology times the NTAG Page 13 RFC 985 May 1986 Requirements for Internet Gateways DRAFT number of nodes times the mean connectivity average number of incident links An advanced design would not require that the entire routing data base be kept in any particular gateway so that discovery and caching techniques would be necessary 7 Operation and Maintenance Gateways and packets switches are often operated as a system by some organization who agrees to operate and maintain the gateways as well as to resolve link problems with the respective common carriers It is important to note that the network control site may not be physically attached to the network being monitored In general the following requirements apply 1 Each gateway must operate as a stand alone device for the purposes of local hardware maintenance Means must be available to run diagnostic programs at the gateway site using only on site tools which might be only a diskette or tape and local terminal It is desirable although not required to run diagnostics via the network and to automatically reboot and dump the gateway via the net in case of fault In general this requires special hardware The use of full blown transport services such as TCP is in general ill advised if required just to reboot and dump the gateway Consideration should be given simple retransmission overlay protocols based on UDP or specific monitoring protocols such as HMP described in RFC 869 7 2 It must be possible to reboot and dump the gateway manually from the control site Every gateway must include a watchdog timer that either initiates a reboot or signals a remote control site if not reset periodically by the software It is desirable that the data involved reside at the control site and be transmitted via the net however the use of local devices at the gateway site is acceptable Nevertheless the operation of initiating reboot or dump must be possible via the net assuming a path is available and the connecting links are operating 3 A mechanism must be provided to accumulate traffic statistics including but not limited to packet tallies error message tallies and so forth The preferred method of retrieving these data is by explicit periodic request from the control site using a standard datagram protocol based on UDP or HMP NTAG Page 14 RFC 985 May 1986 Requirements for Internet Gateways DRAFT The use of full blown transport services such as TCP is in general ill advised if required just to collect statistics from the gateway Consideration should be given simple retransmission overlay protocols based on UDP or HMP 4 Exception reports traps occuring as the result of hardware or software malfunctions should be transmitted immediately batched to reduce packet overheads when possible to the control site using a standard datagram protocol based on UDP or HMP 5 A mechanism must be provided to display link and node status on a continuous basis at the control site While it is desirable that a complete map of all links and nodes be available it is acceptable that only those components in use by the routing algorithm be displayed This information is usually available locally at the control site assuming that site is a participant in the routing algorithm The above functions require in general the participation of a control site or agent The preferred way to provide this is as a user program suitable for operation in a standard software environment such as

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0985.txt (2016-02-14)
    Open archived version from archive

  • TCP
    ôá õäñïìåßïõ ÂëÝðå RFC 821 êáé RFC 822 ãéá äéåõêñéíßóåéò óôï çëåêôñïíéêü ôá õäñïìåßï ÂëÝðå RFC 937 ãéá ôï ðñùôüêïëëï ðïõ Ý åé ó åäéáóôåß ãéá ñÞóç áðü ôïõò ì Õ þóôå íá åßíáé äõíáôÞ ç áíÜãíùóç ìçíõìÜôùí áðü ôïí åîõðçñåôçôÞ ÁõôÝò ïé õðçñåóßåò ðñÝðåé íá õðÜñ ïõí óå êÜèå åöáñìïãÞ ôïõ TCP IP åêôüò áðü åöáñìïãÝò ðñïóáíáôïëéóìÝíåò óå ì Õ ðïõ èá ìðïñïýóáí íá ìçí õðïóôçñßæïõí çëåêôñïíéêü ôá õäñïìåßï ÁõôÝò ïé ðáñáäïóéáêÝò åöáñìïãÝò ðáßæïõí áêüìá ðïëý óçìáíôéêü ñüëï óôá äßêôõá ðïõ åßíáé âáóéóìÝíá óôï TCP IP Ðáñ üëá áõôÜ ðñüóöáôá ï ôñüðïò ìò ôïí ïðïßï ñçóéìïðïéïýíôáé ôá äßêôõá áëëÜæåé Ôï ðáëéü ìïíôÝëï äéêôýùí ìåãÜëùí áõôÜñêùí õðïëïãéóôþí êáôáñãåßôáé Ôþñá ðïëëÝò åãêáôáóôÜóåéò Ý ïõí äéÜöïñá åßäç õðïëïãéóôþí óõìðåñéëáìâáíïìÝíùí ì Õ óôáèìþí åñãáóßáò mini õðïëïãéóôþí êáé mainframes Áõôïß ïé õðïëïãéóôÝò äéåîÜãïõí åéäéêÝò åñãáóßåò Áí êáé ïé Üíèñùðïé åßíáé óõíçèéóìÝíïé íá äïõëåýïõí óå Ýíá óõãêåêñéìÝíï õðïëïãéóôÞ ï õðïëïãéóôÞò áõôüò ìðïñåß íá óõíäåèåß óå Üëëá óõóôÞìáôá óôï äßêôõï ãéá ðáñï Þ åéäéêþí õðçñåóéþí ÁõôÞ ç ôáêôéêÞ ïäÞãçóå óôï ìïíôÝëï ðåëÜôç åîõðçñåôçôÞ ãá ôéò õðçñåóßåò ôùí äéêôýùí Ï åîõðçñåôçôÞò åßíáé Ýíá óýóôçìá ðïõ ðáñÝ åé ìéá åéäéêåõìÝíç õðçñåóßá ãéá ôï õðüëïéðï äßêôõï Ï ðåëÜôçò åßíáé Ýíá Üëëï óýóôçìá ðïõ ñçóéìïðïéåß ôçí õðçñåóßá áõôÞ ï åîõðçñåôçôÞò êáé ï ðåëÜôçò äåí ñåéÜæåôáé áðáñáßôçôá íá âñßóêïíôáé óå äéáöïñåôéêïýò õðïëïãéóôÝò Ìðïñåß íá åßíáé äéáöïñåôéêÜ ðñïãñÜììáôá ðïõ ôñÝ ïõí óôïí ßäéï õðïëïãéóôÞ ÐáñáêÜôù áíáöÝñïíôáé ôá ôõðéêÜ åßäç åîõðçñåôçôþí ðïõ õðÜñ ïõí óå Ýíá ìïíôÝñíï äßêôõï Ïé õðçñåóßåò áõôÝò åßíáé äéáèÝóéìåò ìÝóù ôïõ ðëáéóßïõ åñãáóßáò ôïõ TCP IP TABLE OF TOPICS TABLE OF INDEX 2 4 ÕÐÇÑÅÓÉÁ ÓÕÓÔÇÌÁÔÙÍ ÁÑ ÅÉÏÕ NETWORK FILE SYSTEMS NFS ÅðéôñÝðåé óå Ýíá óýóôçìá íá ðñïóðåëÜóåé áñ åßá óå Ýíáí Üëëï õðïëïãéóôÞ ìå Ýíáí ôñüðï ðéï ïëïêëçñùìÝíï áðü üôé ôï FTP Ôï óýóôçìá áñ åßùí äéêôýïõ äßíåé ôçí øåõäáßóèçóç üôé ïé äßóêïé Þ Üëëåò óõóêåõÝò åíüò óõóôÞìáôïò åßíáé áðåõèåßáò óõíäå äåìÝíåò óå Üëëá óõóôÞìáôá Äåí åßíáé áðáñáßôçôç ç ñÞóç êÜðïéïõ åéäéêïý utility ôïõ äéêôýïõ ãéá ôçí ðñïóðÝëáóç åíüò áñ åßïõ áðü Üëëï óýóôçìá Ï õðïëïãéóôÞò óáò áðëþò íïìßæåé üôé äéáèÝôåé åðéðëÝïí ìïíÜäåò äßóêïõ ÁõôÝò ïé åðéðëÝïí åéêïíéêÝò ìïíÜäåò áíáöÝñïíôáé óôïõò äßóêïõò åíüò Üëëïõ óõóôÞìáôïò Ç äõíáôüôçôá áõôÞ åßíáé ñÞóéìç ãéá ðïëëïýò äéáöïñåôéêïýò óêïðïýò ÅðéôñÝðåé ôçí åéóáãùãÞ ìåãÜëùí äßóêùí óå ëßãïõò ìüíï õðïëïãéóôÝò ôïõ äéêôýïõ áëëÜ ôáõôü ñïíá äßíåé óôïõò Üëëïõò ôç äõíáôüôçôá ðñüóâáóçò óôï þñï ôùí äßóêùí ÐÝñá áðü ôá ðñïöáíÞ ïéêïíïìéêÜ ðëåïíåêôÞìáôá åðéôñÝðåé óå Üôïìá ðïõ äïõëåýïõí óå äéáöïñåôéêïýò õðïëïãéóôÝò íá ìïéñÜæïíôáé êïéíÜ áñ åßá Åðßóçò ç óõíôÞñçóç ôùí óõóôçìÜôùí êáé ôï backup åßíáé åõêïëüôåñá åöüóïí äåí ñåéÜæåôáé íá ãßíïíôáé áíôßãñáöá áðü ðïëëÝò ìç áíÝò Áêüìá ðïëëïß êáôáóêåõáóôÝò ðñïóöÝñïõí ôþñá õðïëïãéóôÝò ùñßò äßóêïõò ðïëý õøçëþí åðéäüóåùí ðïõ åßíáé åîáñôçìÝíïé áðü äßóêïõò ðñïóáñôçìÝíïõò óå êïéíïýò åîõðçñåôçôÝò áñ åßùí ÂëÝðå RFC 1001 êáé RFC 1002 ãéá ðåñéãñáöÞ ôïõ ðñïóáíáôïëéóìÝíïõ óå PC NetBIOS ðÜíù óôï TCP Óôçí ðåñé Þ ôùí minis êáé ôùí óôáèìþí åñãáóßáò ñçóéìïðïéåßôáé óõíÞèùò ôï Network File System ôçò SUN Äéåõêñéíßóåéò ãéá ôï ðñùôüêïëëï åßíáé äéáèÝóéìåò áðü ôç Sun Microsystems TABLE OF TOPICS TABLE OF INDEX 2 5 ÁÐÏÌÁÊÑÕÓÌÅÍÇ ÅÊÔÕÐÙÓÇ ÅðéôñÝðåé ôçí ðñüóâáóç óå åêôõðùôÝò Üëëùí

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/tcp/inter1.htm (2016-02-14)
    Open archived version from archive



  •