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".

  • addition it is strongly recommended that the enterprise will also register its networking subsystems under this subtree in order to provide an unambiguous identification mechanism for use in management protocols For example if the Flintstones Inc enterprise produced networking subsystems then they could request a node under the enterprises subtree from the Assigned Numbers authority Such a node might be numbered 1 3 6 1 4 1 42 The Flintstones Inc enterprise might then register their Fred Router under the name of 1 3 6 1 4 1 42 1 1 3 2 Syntax Syntax is used to define the structure corresponding to object types ASN 1 constructs are used to define this structure although the full generality of ASN 1 is not permitted The ASN 1 type ObjectSyntax defines the different syntaxes which may be used in defining an object type 3 2 1 Primitive Types Only the ASN 1 primitive types INTEGER OCTET STRING OBJECT IDENTIFIER and NULL are permitted These are sometimes referred to as non aggregate types 3 2 1 1 Guidelines for Enumerated INTEGERs If an enumerated INTEGER is listed as an object type then a named number having the value 0 shall not be present in the list of Rose McCloghrie Page 7 RFC 1065 SMI August 1988 enumerations Use of this value is prohibited 3 2 2 Constructor Types The ASN 1 constructor type SEQUENCE is permitted providing that it is used to generate either lists or tables For lists the syntax takes the form SEQUENCE where each resolves to one of the ASN 1 primitive types listed above Further these ASN 1 types are always present the DEFAULT and OPTIONAL clauses do not appear in the SEQUENCE definition For tables the syntax takes the form SEQUENCE OF where resolves to a list constructor Lists and tables are sometimes referred to as aggregate types 3 2 3 Defined Types In addition new application wide types may be defined so long as they resolve into an IMPLICITly defined ASN 1 primitive type list table or some other application wide type Initially few application wide types are defined Future memos will no doubt define others once a consensus is reached 3 2 3 1 NetworkAddress This CHOICE represents an address from one of possibly several protocol families Currently only one protocol family the Internet family is present in this CHOICE 3 2 3 2 IpAddress This application wide type represents a 32 bit internet address It is represented as an OCTET STRING of length 4 in network byte order When this ASN 1 type is encoded using the ASN 1 basic encoding rules only the primitive encoding form shall be used 3 2 3 3 Counter This application wide type represents a non negative integer which Rose McCloghrie Page 8 RFC 1065 SMI August 1988 monotonically increases until it reaches a maximum value when it wraps around and starts increasing again from zero This memo specifies a maximum value of 2 32 1 4294967295 decimal for counters 3 2 3 4 Gauge This application wide type represents a non negative integer which may increase or decrease but which latches at a maximum value This memo specifies a maximum value of 2 32 1 4294967295 decimal for gauges 3 2 3 5 TimeTicks This application wide type represents a non negative integer which counts the time in hundredths of a second since some epoch When object types are defined in the MIB which use this ASN 1 type the description of the object type identifies the reference epoch 3 2 3 6 Opaque This application wide type supports the capability to pass arbitrary ASN 1 syntax A value is encoded using the ASN 1 basic rules into a string of octets This in turn is encoded as an OCTET STRING in effect double wrapping the original ASN 1 value Note that a conforming implementation need only be able to accept and recognize opaquely encoded data It need not be able to unwrap the data and then interpret its contents Further note that by use of the ASN 1 EXTERNAL type encodings other than ASN 1 may be used in opaquely encoded data 3 3 Encodings Once an instance of an object type has been identified its value may be transmitted by applying the basic encoding rules of ASN 1 to the syntax for the object type Rose McCloghrie Page 9 RFC 1065 SMI August 1988 4 Managed Objects Although it is not the purpose of this memo to define objects in the MIB this memo specifies a format to be used by other memos which define these objects An object type definition consists of five fields OBJECT A textual name termed the OBJECT DESCRIPTOR for the object type along with its corresponding OBJECT IDENTIFIER Syntax The abstract syntax for the object type This must resolve to an instance of the ASN 1 type ObjectSyntax defined below Definition A textual description of the semantics of the object type Implementations should ensure that their instance of the object fulfills this definition since this MIB is intended for use in multi vendor environments As such it is vital that objects have consistent meaning across all machines Access One of read only read write write only or not accessible Status One of mandatory optional or obsolete Future memos may also specify other fields for the objects which they define 4 1 Guidelines for Object Names No object type in the Internet Standard MIB shall use a sub identifier of 0 in its name This value is reserved for use with future extensions Each OBJECT DESCRIPTOR corresponding to an object type in the internet standard MIB shall be a unique but mnemonic printable string This promotes a common language for humans to use when discussing the MIB and also facilitates simple table mappings for user interfaces 4 2 Object Types and Instances An object type is a definition of a kind of managed object it is Rose McCloghrie Page 10 RFC

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



  • not supplied by the transport layer protocol Access read write Status mandatory McCloghrie Rose Page 25 RFC 1066 MIB August 1988 OBJECT ipInReceives ip 3 Syntax Counter Definition The total number of input datagrams received from interfaces including those received in error Access read only Status mandatory OBJECT ipInHdrErrors ip 4 Syntax Counter Definition The number of input datagrams discarded due to errors in their IP headers including bad checksums version number mismatch other format errors time to live exceeded errors discovered in processing their IP options etc Access read only Status mandatory OBJECT ipInAddrErrors ip 5 Syntax Counter Definition The number of input datagrams discarded because the IP address in their IP header s destination field was not a McCloghrie Rose Page 26 RFC 1066 MIB August 1988 valid address to be received at this entity This count includes invalid addresses e g 0 0 0 0 and addresses of unsupported Classes e g Class E For entities which are not IP Gateways and therefore do not forward datagrams this counter includes datagrams discarded because the destination address was not a local address Access read only Status mandatory OBJECT ipForwDatagrams ip 6 Syntax Counter Definition The number of input datagrams for which this entity was not their final IP destination as a result of which an attempt was made to find a route to forward them to that final destination In entities which do not act as IP Gateways this counter will include only those packets which were Source Routed via this entity and the Source Route option processing was successful Access read only Status mandatory OBJECT ipInUnknownProtos ip 7 Syntax Counter Definition The number of locally addressed datagrams received successfully but discarded because of an unknown or unsupported protocol McCloghrie Rose Page 27 RFC 1066 MIB August 1988 Access read only Status mandatory OBJECT ipInDiscards ip 8 Syntax Counter Definition The number of input IP datagrams for which no problems were encountered to prevent their continued processing but which were discarded e g for lack of buffer space Note that this counter does not include any datagrams discarded while awaiting re assembly Access read only Status mandatory OBJECT ipInDelivers ip 9 Syntax Counter Definition The total number of input datagrams successfully delivered to IP user protocols including ICMP Access read only Status mandatory OBJECT ipOutRequests ip 10 McCloghrie Rose Page 28 RFC 1066 MIB August 1988 Syntax Counter Definition The total number of IP datagrams which local IP user protocols including ICMP supplied to IP in requests for transmission Note that this counter does not include any datagrams counted in ipForwDatagrams Access read only Status mandatory OBJECT ipOutDiscards ip 11 Syntax Counter Definition The number of output IP datagrams for which no problem was encountered to prevent their transmission to their destination but which were discarded e g for lack of buffer space Note that this counter would include datagrams counted in ipForwDatagrams if any such packets met this discretionary discard criterion Access read only Status mandatory OBJECT ipOutNoRoutes ip 12 Syntax Counter McCloghrie Rose Page 29 RFC 1066 MIB August 1988 Definition The number of IP datagrams discarded because no route could be found to transmit them to their destination Note that this counter includes any packets counted in ipForwDatagrams which meet this no route criterion Access read only Status mandatory OBJECT ipReasmTimeout ip 13 Syntax INTEGER Definition The maximum number of seconds which received fragments are held while they are awaiting reassembly at this entity Access read only Status mandatory OBJECT ipReasmReqds ip 14 Syntax Counter Definition The number of IP fragments received which needed to be reassembled at this entity Access read only Status mandatory McCloghrie Rose Page 30 RFC 1066 MIB August 1988 OBJECT ipReasmOKs ip 15 Syntax Counter Definition The number of IP datagrams successfully re assembled Access read only Status mandatory OBJECT ipReasmFails ip 16 Syntax Counter Definition The number of failures detected by the IP re assembly algorithm for whatever reason timed out errors etc Note that this is not necessarily a count of discarded IP fragments since some algorithms notably RFC 815 s can lose track of the number of fragments by combining them as they are received Access read only Status mandatory OBJECT ipFragOKs ip 17 Syntax Counter McCloghrie Rose Page 31 RFC 1066 MIB August 1988 Definition The number of IP datagrams that have been successfully fragmented at this entity Access read only Status mandatory OBJECT ipFragFails ip 18 Syntax Counter Definition The number of IP datagrams that have been discarded because they needed to be fragmented at this entity but could not be e g because their Don t Fragment flag was set Access read only Status mandatory OBJECT ipFragCreates ip 19 Syntax Counter Definition The number of IP datagram fragments that have been generated as a result of fragmentation at this entity Access read only Status mandatory McCloghrie Rose Page 32 RFC 1066 MIB August 1988 5 4 1 The IP Address Table The Ip Address table contains this entity s IP addressing information OBJECT ipAddrTable ip 20 Syntax SEQUENCE OF IpAddrEntry Definition The table of addressing information relevant to this entity s IP addresses Access read only Status mandatory OBJECT ipAddrEntry ipAddrTable 1 Syntax IpAddrEntry SEQUENCE ipAdEntAddr IpAddress ipAdEntIfIndex INTEGER ipAdEntNetMask IpAddress ipAdEntBcastAddr INTEGER Definition The addressing information for one of this entity s IP addresses Access read only McCloghrie Rose Page 33 RFC 1066 MIB August 1988 Status mandatory OBJECT ipAdEntAddr ipAddrEntry 1 Syntax IpAddress Definition The IP address to which this entry s addressing information pertains Access read only Status mandatory OBJECT ipAdEntIfIndex ipAddrEntry 2 Syntax INTEGER Definition The index value which uniquely identifies the interface to which this entry is applicable The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex Access read only Status mandatory OBJECT ipAdEntNetMask ipAddrEntry 3 McCloghrie Rose Page 34 RFC 1066 MIB August 1988 Syntax IpAddress Definition The subnet mask associated with the IP address of this entry The value of the mask is an IP address with all the network bits set to 1 and all the hosts bits set to 0 Access read only Status mandatory OBJECT ipAdEntBcastAddr ipAddrEntry 4 Syntax INTEGER Definition The value of the least significant bit in the IP broadcast address used for sending datagrams on the logical interface associated with the IP address of this entry For example when the Internet standard all ones broadcast address is used the value will be 1 Access read only Status mandatory 5 4 2 The IP Routing Table The IP Routing Table contains an entry for each route presently known to this entity Note that the action to be taken in response to a request to read a non existent entry is specific to the network management protocol being used OBJECT ipRoutingTable ip 21 McCloghrie Rose Page 35 RFC 1066 MIB August 1988 Syntax SEQUENCE OF IpRouteEntry Definition This entity s IP Routing table Access read write Status mandatory OBJECT ipRouteEntry ipRoutingTable 1 Syntax IpRouteEntry SEQUENCE ipRouteDest IpAddress ipRouteIfIndex INTEGER ipRouteMetric1 INTEGER ipRouteMetric2 INTEGER ipRouteMetric3 INTEGER ipRouteMetric4 INTEGER ipRouteNextHop IpAddress ipRouteType INTEGER ipRouteProto INTEGER ipRouteAge INTEGER Definition A route to a particular destination Access read write McCloghrie Rose Page 36 RFC 1066 MIB August 1988 Status mandatory We now consider the individual components of each route in the IP Routing Table OBJECT ipRouteDest ipRouteEntry 1 Syntax IpAddress Definition The destination IP address of this route An entry with a value of 0 0 0 0 is considered a default route Multiple such default routes can appear in the table but access to such multiple entries is dependent on the table access mechanisms defined by the network management protocol in use Access read write Status mandatory OBJECT ipRouteIfIndex ipRouteEntry 2 Syntax INTEGER Definition The index value which uniquely identifies the local interface through which the next hop of this route should be reached The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex Access read write Status mandatory McCloghrie Rose Page 37 RFC 1066 MIB August 1988 OBJECT ipRouteMetric1 ipRouteEntry 3 Syntax INTEGER Definition The primary routing metric for this route The semantics of this metric are determined by the routing protocol specified in the route s ipRouteProto value If this metric is not used its value should be set to 1 Access read write Status mandatory OBJECT ipRouteMetric2 ipRouteEntry 4 Syntax INTEGER Definition An alternate routing metric for this route The semantics of this metric are determined by the routing protocol specified in the route s ipRouteProto value If this metric is not used its value should be set to 1 Access read write Status mandatory OBJECT ipRouteMetric3 ipRouteEntry 5 Syntax INTEGER McCloghrie Rose Page 38 RFC 1066 MIB August 1988 Definition An alternate routing metric for this route The semantics of this metric are determined by the routing protocol specified in the route s ipRouteProto value If this metric is not used its value should be set to 1 Access read write Status mandatory OBJECT ipRouteMetric4 ipRouteEntry 6 Syntax INTEGER Definition An alternate routing metric for this route The semantics of this metric are determined by the routing protocol specified in the route s ipRouteProto value If this metric is not used its value should be set to 1 Access read write Status mandatory OBJECT ipRouteNextHop ipRouteEntry 7 Syntax IpAddress Definition The IP address of the next hop of this route Access read write Status mandatory McCloghrie Rose Page 39 RFC 1066 MIB August 1988 OBJECT ipRouteType ipRouteEntry 8 Syntax INTEGER other 1 none of the following invalid 2 an invalidated route route to directly direct 3 connected sub network route to a non local remote 4 host network sub network Definition The type of route Access read write Status mandatory OBJECT ipRouteProto ipRouteEntry 9 Syntax INTEGER other 1 none of the following non protocol information e g manually configured local 2 entries set via a network management netmgmt 3 protocol obtained via ICMP icmp 4 e g Redirect the remaining values are all gateway routing protocols egp 5 McCloghrie Rose Page 40 RFC 1066 MIB August 1988 ggp 6 hello 7 rip 8 is is 9 es is 10 ciscoIgrp 11 bbnSpfIgp 12 oigp 13 Definition The routing mechanism via which this route was learned Inclusion of values for gateway routing protocols is not intended to imply that hosts should support those protocols Access read only Status mandatory OBJECT ipRouteAge ipRouteEntry 10 Syntax INTEGER Definition The number of seconds since this route was last updated or otherwise determined to be correct Note that no semantics of too old can be implied except through knowledge of the routing protocol by which the route was learned Access read write Status mandatory McCloghrie Rose Page 41 RFC 1066 MIB August 1988 5 5 The ICMP Group Implementation of the ICMP group is mandatory for all systems The ICMP group contains the ICMP input and output statistics Note that individual counters for ICMP message sub codes have been omitted from this version of the MIB for simplicity OBJECT icmpInMsgs icmp 1 Syntax Counter Definition The total number of ICMP messages which the entity received Note that this counter includes all those counted by icmpInErrors Access read only Status mandatory OBJECT icmpInErrors icmp 2 Syntax Counter Definition The number of ICMP messages which the entity received but determined as having errors bad ICMP checksums bad length etc Access read only Status mandatory McCloghrie Rose Page 42 RFC 1066 MIB August 1988 OBJECT icmpInDestUnreachs icmp 3 Syntax Counter Definition The number of ICMP Destination Unreachable messages received Access read only Status mandatory OBJECT icmpInTimeExcds icmp 4 Syntax Counter Definition The number of ICMP Time Exceeded messages received Access read only Status mandatory OBJECT icmpInParmProbs icmp 5 Syntax Counter Definition The number of ICMP Parameter Problem messages received Access read only McCloghrie Rose Page 43 RFC 1066 MIB August 1988 Status mandatory OBJECT icmpInSrcQuenchs icmp 6 Syntax Counter Definition The number of ICMP Source Quench messages received Access read only Status mandatory OBJECT icmpInRedirects icmp 7 Syntax Counter Definition The number of ICMP Redirect messages received Access read only Status mandatory OBJECT icmpInEchos icmp 8 Syntax Counter Definition The number of ICMP Echo request messages received McCloghrie Rose Page 44 RFC 1066 MIB August 1988 Access read only Status mandatory OBJECT icmpInEchoReps icmp 9 Syntax Counter Definition The number of ICMP Echo Reply messages received Access read only Status mandatory OBJECT icmpInTimestamps icmp 10 Syntax Counter Definition The number of ICMP Timestamp request messages received Access read only Status mandatory OBJECT icmpInTimestampReps icmp 11 Syntax Counter McCloghrie Rose Page 45 RFC 1066 MIB August 1988 Definition The number of ICMP Timestamp Reply messages received Access read only Status mandatory OBJECT icmpInAddrMasks icmp 12 Syntax Counter Definition The number of ICMP Address Mask Request messages received Access read only Status mandatory OBJECT icmpInAddrMaskReps icmp 13 Syntax Counter Definition The number of ICMP Address Mask Reply messages received Access read only Status mandatory OBJECT icmpOutMsgs icmp 14 McCloghrie Rose Page 46 RFC 1066 MIB August 1988 Syntax Counter Definition The total number of ICMP messages which this entity attempted to send Note that this counter includes all those counted by icmpOutErrors Access read only Status mandatory OBJECT icmpOutErrors icmp 15 Syntax Counter Definition The number of ICMP messages which this entity did not send due to problems discovered within ICMP such as a lack of buffers This value should not include errors discovered outside the ICMP layer such as the inability of IP to route the resultant datagram In some implementations there may be no types of error which contribute to this counter s value Access read only Status mandatory OBJECT icmpOutDestUnreachs icmp 16 Syntax Counter Definition The number of ICMP Destination Unreachable messages sent McCloghrie Rose Page 47 RFC 1066 MIB August 1988 Access read only Status mandatory OBJECT icmpOutTimeExcds icmp 17 Syntax Counter Definition The number of ICMP Time Exceeded messages sent Access read only Status mandatory OBJECT icmpOutParmProbs icmp 18 Syntax Counter Definition The number of ICMP Parameter Problem messages sent Access read only Status mandatory OBJECT icmpOutSrcQuenchs icmp 19 Syntax Counter McCloghrie Rose Page 48 RFC 1066 MIB August 1988 Definition The number of ICMP Source Quench messages sent Access read only Status mandatory OBJECT icmpOutRedirects icmp 20 Syntax Counter Definition The number of ICMP Redirect messages sent Access read only Status mandatory OBJECT icmpOutEchos icmp 21 Syntax Counter Definition The number of ICMP Echo request messages sent Access read only Status mandatory OBJECT icmpOutEchoReps icmp 22 McCloghrie Rose Page 49 RFC 1066 MIB August 1988 Syntax Counter Definition The number of ICMP Echo Reply messages sent Access read only Status mandatory OBJECT icmpOutTimestamps icmp 23 Syntax Counter Definition The number of ICMP Timestamp request messages sent Access read only Status mandatory OBJECT icmpOutTimestampReps icmp 24 Syntax Counter Definition The number of ICMP Timestamp Reply messages sent Access read only Status mandatory McCloghrie Rose Page 50 RFC 1066 MIB August 1988 OBJECT icmpOutAddrMasks icmp 25 Syntax Counter Definition The number of ICMP Address Mask Request messages sent Access read only Status mandatory OBJECT icmpOutAddrMaskReps icmp 26 Syntax Counter Definition The number of ICMP Address Mask Reply messages sent Access read only Status mandatory McCloghrie Rose Page 51 RFC 1066 MIB August 1988 5 6 The TCP Group Implementation of the TCP group is mandatory for all systems that implement the TCP protocol Note that instances of object types that represent information about a particular TCP connection are transient they persist only as long as the connection in question OBJECT tcpRtoAlgorithm tcp 1 Syntax INTEGER other 1 none of the following constant 2 a constant rto rsre 3 MIL STD 1778 Appendix B vanj 4 Van Jacobson s algorithm 11 Definition The algorithm used to determine the timeout value used for retransmitting unacknowledged octets Access read only Status mandatory OBJECT tcpRtoMin tcp 2 Syntax INTEGER Definition The minimum value permitted by a TCP implementation for the retransmission timeout measured in milliseconds More refined semantics for objects of this type depend upon the algorithm used to determine the retransmission timeout In particular when the timeout algorithm is rsre 3 an object of this type has the semantics of the LBOUND quantity described in RFC 793 McCloghrie Rose Page 52 RFC 1066 MIB August 1988 Access read only Status mandatory OBJECT tcpRtoMax tcp 3 Syntax INTEGER Definition The maximum value permitted by a TCP implementation for the retransmission timeout measured in milliseconds More refined semantics for objects of this type depend upon the algorithm used to determine the retransmission timeout In particular when the timeout algorithm is rsre 3 an object of this type has the semantics of the UBOUND quantity described in RFC 793 Access read only Status mandatory OBJECT tcpMaxConn tcp 4 Syntax INTEGER Definition The limit on the total number of TCP connections the entity can support In entities where the maximum number of connections is dynamic this object should contain the value 1 Access read only McCloghrie Rose Page 53 RFC 1066 MIB August 1988 Status mandatory OBJECT tcpActiveOpens tcp 5 Syntax Counter Definition The number of times TCP connections have made a direct transition to the SYN SENT state from the CLOSED state Access read only Status mandatory OBJECT tcpPassiveOpens tcp 6 Syntax Counter Definition The number of times TCP connections have made a direct transition to the SYN RCVD state from the LISTEN state Access read only Status mandatory OBJECT tcpAttemptFails tcp 7 Syntax Counter McCloghrie Rose Page 54 RFC 1066 MIB August 1988 Definition The number of times TCP connections have made a direct transition to the CLOSED state from either the SYN SENT state or the SYN RCVD state plus the number of times TCP connections have made a direct transition to the LISTEN state from the SYN RCVD state Access read only Status mandatory OBJECT tcpEstabResets tcp 8 Syntax Counter Definition The number of times TCP

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


  • INOC Region 2 INOC PC in Region 3 Domain Region 1 Domain Region 2 Domain Region 3 CPU super mini 1 CPU super mini 1 CPU Clone 1 PCommunity pub PCommunity pub PCommunity slate Region 3 INOC Domain Region 3 Domain Region 3 Domain Region 3 CPU router 1 CPU mainframe 1 CPU modem 1 DCommunity secret DCommunity secret DCommunity secret Domain the administrative domain of the element PCommunity the name of a community utilizing a proxy agent DCommunity the name of a direct community Figure 1 Example Network Management Configuration Case Fedor Schoffstall Davin Page 10 RFC 1067 SNMP August 1988 3 2 6 Form and Meaning of References to Managed Objects The SMI requires that the definition of a conformant management protocol address 1 the resolution of ambiguous MIB references 2 the resolution of MIB references in the presence multiple MIB versions and 3 the identification of particular instances of object types defined in the MIB 3 2 6 1 Resolution of Ambiguous MIB References Because the scope of any SNMP operation is conceptually confined to objects relevant to a single network element and because all SNMP references to MIB objects are implicitly or explicitly by unique variable names there is no possibility that any SNMP reference to any object type defined in the MIB could resolve to multiple instances of that type 3 2 6 2 Resolution of References across MIB Versions The object instance referred to by any SNMP operation is exactly that specified as part of the operation request or in the case of a get next operation its immediate successor in the MIB as a whole In particular a reference to an object as part of some version of the Internet standard MIB does not resolve to any object that is not part of said version of the Internet standard MIB except in the case that the requested operation is get next and the specified object name is lexicographically last among the names of all objects presented as part of said version of the Internet Standard MIB 3 2 6 3 Identification of Object Instances The names for all object types in the MIB are defined explicitly either in the Internet standard MIB or in other documents which conform to the naming conventions of the SMI The SMI requires that conformant management protocols define mechanisms for identifying individual instances of those object types for a particular network element Each instance of any object type defined in the MIB is identified in SNMP operations by a unique name called its variable name In general the name of an SNMP variable is an OBJECT IDENTIFIER of the form x y where x is the name of a non aggregate object type defined in the MIB and y is an OBJECT IDENTIFIER fragment that in a way Case Fedor Schoffstall Davin Page 11 RFC 1067 SNMP August 1988 specific to the named object type identifies the desired instance This naming strategy admits the fullest exploitation of the semantics of the GetNextRequest PDU see Section 4 because it assigns names for related variables so as to be contiguous in the lexicographical ordering of all variable names known in the MIB The type specific naming of object instances is defined below for a number of classes of object types Instances of an object type to which none of the following naming conventions are applicable are named by OBJECT IDENTIFIERs of the form x 0 where x is the name of said object type in the MIB definition For example suppose one wanted to identify an instance of the variable sysDescr The object class for sysDescr is iso org dod internet mgmt mib system sysDescr 1 3 6 1 2 1 1 1 Hence the object type x would be 1 3 6 1 2 1 1 1 to which is appended an instance sub identifier of 0 That is 1 3 6 1 2 1 1 1 0 identifies the one and only instance of sysDescr 3 2 6 3 1 ifTable Object Type Names The name of a subnet interface s is the OBJECT IDENTIFIER value of the form i where i has the value of that instance of the ifIndex object type associated with s For each object type t for which the defined name n has a prefix of ifEntry an instance i of t is named by an OBJECT IDENTIFIER of the form n s where s is the name of the subnet interface about which i represents information For example suppose one wanted to identify the instance of the variable ifType associated with interface 2 Accordingly ifType 2 would identify the desired instance 3 2 6 3 2 atTable Object Type Names The name of an AT cached network address x is an OBJECT IDENTIFIER of the form 1 a b c d where a b c d is the value in the familiar dot notation of the atNetAddress object type associated with x The name of an address translation equivalence e is an OBJECT IDENTIFIER value of the form s w such that s is the value of that instance of the atIndex object type associated with e and such that w is the name of the AT cached network address associated with e Case Fedor Schoffstall Davin Page 12 RFC 1067 SNMP August 1988 For each object type t for which the defined name n has a prefix of atEntry an instance i of t is named by an OBJECT IDENTIFIER of the form n y where y is the name of the address translation equivalence about which i represents information For example suppose one wanted to find the physical address of an entry in the address translation table ARP cache associated with an IP address of 89 1 1 42 and interface 3 Accordingly atPhysAddress 3 1 89 1 1 42 would identify the desired instance 3 2 6 3 3 ipAddrTable Object Type Names The name of an IP addressable network element x is the OBJECT IDENTIFIER of the form a b c d such that a b c d is the value in the familiar dot notation of that instance of the ipAdEntAddr object type associated with x For each object type t for which the defined name n has a prefix of ipAddrEntry an instance i of t is named by an OBJECT IDENTIFIER of the form n y where y is the name of the IP addressable network element about which i represents information For example suppose one wanted to find the network mask of an entry in the IP interface table associated with an IP address of 89 1 1 42 Accordingly ipAdEntNetMask 89 1 1 42 would identify the desired instance 3 2 6 3 4 ipRoutingTable Object Type Names The name of an IP route x is the OBJECT IDENTIFIER of the form a b c d such that a b c d is the value in the familiar dot notation of that instance of the ipRouteDest object type associated with x For each object type t for which the defined name n has a prefix of ipRoutingEntry an instance i of t is named by an OBJECT IDENTIFIER of the form n y where y is the name of the IP route about which i represents information For example suppose one wanted to find the next hop of an entry in the IP routing table associated with the destination of 89 1 1 42 Accordingly ipRouteNextHop 89 1 1 42 would identify the desired instance 3 2 6 3 5 tcpConnTable Object Type Names The name of a TCP connection x is the OBJECT IDENTIFIER of the form a b c d e f g h i j such that a b c d is the value in the familiar Case Fedor Schoffstall Davin Page 13 RFC 1067 SNMP August 1988 dot notation of that instance of the tcpConnLocalAddress object type associated with x and such that f g h i is the value in the familiar dot notation of that instance of the tcpConnRemoteAddress object type associated with x and such that e is the value of that instance of the tcpConnLocalPort object type associated with x and such that j is the value of that instance of the tcpConnRemotePort object type associated with x For each object type t for which the defined name n has a prefix of tcpConnEntry an instance i of t is named by an OBJECT IDENTIFIER of the form n y where y is the name of the TCP connection about which i represents information For example suppose one wanted to find the state of a TCP connection between the local address of 89 1 1 42 on TCP port 21 and the remote address of 10 0 0 51 on TCP port 2059 Accordingly tcpConnState 89 1 1 42 21 10 0 0 51 2059 would identify the desired instance 3 2 6 3 6 egpNeighTable Object Type Names The name of an EGP neighbor x is the OBJECT IDENTIFIER of the form a b c d such that a b c d is the value in the familiar dot notation of that instance of the egpNeighAddr object type associated with x For each object type t for which the defined name n has a prefix of egpNeighEntry an instance i of t is named by an OBJECT IDENTIFIER of the form n y where y is the name of the EGP neighbor about which i represents information For example suppose one wanted to find the neighbor state for the IP address of 89 1 1 42 Accordingly egpNeighState 89 1 1 42 would identify the desired instance Case Fedor Schoffstall Davin Page 14 RFC 1067 SNMP August 1988 4 Protocol Specification The network management protocol is an application protocol by which the variables of an agent s MIB may be inspected or altered Communication among protocol entities is accomplished by the exchange of messages each of which is entirely and independently represented within a single UDP datagram using the basic encoding rules of ASN 1 as discussed in Section 3 2 2 A message consists of a version identifier an SNMP community name and a protocol data unit PDU A protocol entity receives messages at UDP port 161 on the host with which it is associated for all messages except for those which report traps i e all messages except those which contain the Trap PDU Messages which report traps should be received on UDP port 162 for further processing An implementation of this protocol need not accept messages whose length exceeds 484 octets However it is recommended that implementations support larger datagrams whenever feasible It is mandatory that all implementations of the SNMP support the five PDUs GetRequest PDU GetNextRequest PDU GetResponse PDU SetRequest PDU and Trap PDU RFC1067 SNMP DEFINITIONS BEGIN IMPORTS ObjectName ObjectSyntax NetworkAddress IpAddress TimeTicks FROM RFC1065 SMI top level message Message SEQUENCE version version 1 for this RFC INTEGER version 1 0 community community name OCTET STRING data e g PDUs if trivial ANY authentication is being used Case Fedor Schoffstall Davin Page 15 RFC 1067 SNMP August 1988 protocol data units PDUs CHOICE get request GetRequest PDU get next request GetNextRequest PDU get response GetResponse PDU set request SetRequest PDU trap Trap PDU the individual PDUs and commonly used data types will be defined later END 4 1 Elements of Procedure This section describes the actions of a protocol entity implementing the SNMP Note however that it is not intended to constrain the internal architecture of any conformant implementation In the text that follows the term transport address is used In the case of the UDP a transport address consists of an IP address along with a UDP port Other transport services may be used to support the SNMP In these cases the definition of a transport address should be made accordingly The top level actions of a protocol entity which generates a message are as follows 1 It first constructs the appropriate PDU e g the GetRequest PDU as an ASN 1 object 2 It then passes this ASN 1 object along with a community name its source transport address and the destination transport address to the service which implements the desired authentication scheme This authentication Case Fedor Schoffstall Davin Page 16 RFC 1067 SNMP August 1988 service returns another ASN 1 object 3 The protocol entity then constructs an ASN 1 Message object using the community name and the resulting ASN 1 object 4 This new ASN 1 object is then serialized using the basic encoding rules of ASN 1 and then sent using a transport service to the peer protocol entity Similarly the top level actions of a protocol entity which receives a message are as follows 1 It performs a rudimentary parse of the incoming datagram to build an ASN 1 object corresponding to an ASN 1 Message object If the parse fails it discards the datagram and performs no further actions 2 It then verifies the version number of the SNMP message If there is a mismatch it discards the datagram and performs no further actions 3 The protocol entity then passes the community name and user data found in the ASN 1 Message object along with the datagram s source and destination transport addresses to the service which implements the desired authentication scheme This entity returns another ASN 1 object or signals an authentication failure In the latter case the protocol entity notes this failure possibly generates a trap and discards the datagram and performs no further actions 4 The protocol entity then performs a rudimentary parse on the ASN 1 object returned from the authentication service to build an ASN 1 object corresponding to an ASN 1 PDUs object If the parse fails it discards the datagram and performs no further actions Otherwise using the named SNMP community the appropriate profile is selected and the PDU is processed accordingly If as a result of this processing a message is returned then the source transport address that the response message is sent from shall be identical to the destination transport address that the original request message was sent to Case Fedor Schoffstall Davin Page 17 RFC 1067 SNMP August 1988 4 1 1 Common Constructs Before introducing the six PDU types of the protocol it is appropriate to consider some of the ASN 1 constructs used frequently request response information RequestID INTEGER ErrorStatus INTEGER noError 0 tooBig 1 noSuchName 2 badValue 3 readOnly 4 genErr 5 ErrorIndex INTEGER variable bindings VarBind SEQUENCE name ObjectName value ObjectSyntax VarBindList SEQUENCE OF VarBind RequestIDs are used to distinguish among outstanding requests By use of the RequestID an SNMP application entity can correlate incoming responses with outstanding requests In cases where an unreliable datagram service is being used the RequestID also provides a simple means of identifying messages duplicated by the network A non zero instance of ErrorStatus is used to indicate that an Case Fedor Schoffstall Davin Page 18 RFC 1067 SNMP August 1988 exception occurred while processing a request In these cases ErrorIndex may provide additional information by indicating which variable in a list caused the exception The term variable refers to an instance of a managed object A variable binding or VarBind refers to the pairing of the name of a variable to the variable s value A VarBindList is a simple list of variable names and corresponding values Some PDUs are concerned only with the name of a variable and not its value e g the GetRequest PDU In this case the value portion of the binding is ignored by the protocol entity However the value portion must still have valid ASN 1 syntax and encoding It is recommended that the ASN 1 value NULL be used for the value portion of such bindings 4 1 2 The GetRequest PDU The form of the GetRequest PDU is GetRequest PDU 0 IMPLICIT SEQUENCE request id RequestID error status always 0 ErrorStatus error index always 0 ErrorIndex variable bindings VarBindList The GetRequest PDU is generated by a protocol entity only at the request of its SNMP application entity Upon receipt of the GetRequest PDU the receiving protocol entity responds according to any applicable rule in the list below 1 If for any object named in the variable bindings field the object s name does not exactly match the name of some object available for get operations in the relevant MIB view then the receiving entity sends to the originator of the received message the GetResponse PDU of identical form except that the value of the error status field is noSuchName and the value of the error index field is the index of said object name component in the received Case Fedor Schoffstall Davin Page 19 RFC 1067 SNMP August 1988 message 2 If for any object named in the variable bindings field the object is an aggregate type as defined in the SMI then the receiving entity sends to the originator of the received message the GetResponse PDU of identical form except that the value of the error status field is noSuchName and the value of the error index field is the index of said object name component in the received message 3 If the size of the GetResponse PDU generated as described below would exceed a local limitation then the receiving entity sends to the originator of the received message the GetResponse PDU of identical form except that the value of the error status field is tooBig and the value of the error index field is zero 4 If for any object named in the variable bindings field the value of the object cannot be retrieved for reasons not covered by any of the foregoing rules then the receiving entity sends to the originator of the received message the GetResponse PDU of identical form except that the value of the error status field

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


  • server acts on them and responds with responses often interspersed with data The client opens a connection waits for the greeting then sends a LOGIN command with user name and password arguments to establish authorization Following an OK response from the server the client then sends a SELECT command to access the desired mailbox The user s default mailbox has a special reserved name of INBOX which is independent of the operating system that the server is implemented on The server will generally send a list of valid flags number of messages and number of messages arrived since last access for this mailbox as unsolicited data followed by an OK response The client may terminate access to this mailbox and access a different one with another SELECT command The client reads mailbox information by means of FETCH commands The actual data is transmitted via the unsolicited data mechanism that is FETCH should be viewed as poking the server to include the desired data along with any other data it wishes to transmit to the client There are three major categories of data which may be fetched The first category is that data which is associated with a message as an entity in the mailbox There are presently three such items of data the internal date the RFC 822 size and the flags The internal date is the date and time that the message was placed in the mailbox The RFC 822 size is subject to deletion in the future it is the size in bytes of the message expressed as an RFC 822 text string Current clients only use it as part of a status display Crispin Page 5 RFC 1064 IMAP2 July 1988 line The flags are a list of status flags associated with the message see below All of the first category data can be fetched by using the macro fetch word FAST that is FAST expands to FLAGS INTERNALDATE RFC822 SIZE The second category is that data which describes the composition and delivery information of a message that is information such as the message sender recipient lists message ID subject etc This is the information which is stored in the message header in RFC 822 format message and is traditionally called the envelope Note this should not be confused with the SMTP RFC 821 envelope which is strictly limited to delivery information IMAP2 defines a structured and unambiguous representation for the envelope which is particularly nice for Lisp based parsers A client can use the envelope for operations such as replying and not worry about RFC 822 at all Envelopes are discussed in more detail below The first and second category data can be fetched together by using the macro fetch word ALL that is ALL expands to FLAGS INTERNALDATE RFC822 SIZE ENVELOPE The third category is that data which is intended for direct human viewing The present RFC 822 based IMAP2 defines three such items RFC822 HEADER RFC822 TEXT and RFC822 the latter being the two former appended together in a single text string Fetching RFC822 is equivalent to typing the RFC 822 representation of the message as stored on the mailbox without any filtering or processing Typically a client will FETCH ALL for some or all of the messages in the mailbox for use as a presentation menu and when the user wishes to read a particular message will FETCH RFC822 TEXT to get the message body A more primitive client could of course simply FETCH RFC822 a la POP2 type functionality The client can alter certain data presently only the flags by means of a STORE command As an example a message is deleted from a mailbox by a STORE command which includes the DELETED flag as one of the flags being set Other client operations include copying a message to another mailbox COPY command permanently removing deleted messages EXPUNGE command checking for new messages CHECK command and searching for messages which match certain criteria SEARCH command The client terminates the session with the LOGOUT command The server returns a BYE followed by an OK Crispin Page 6 RFC 1064 IMAP2 July 1988 A Typical Scenario Client Server Wait for Connection Open Connection EXISTS response to the client giving the flags list for this mailbox simply the system flags if this mailbox doesn t have any special flags and the number of messages in the mailbox It is also recommended that the server send a RECENT unsolicited response to the client for the benefit of clients which make use of the number of new messages in a mailbox Multiple SELECT commands are permitted in a session in which case the prior mailbox is deselected first The default mailbox for the SELECT command is INBOX which is a special name reserved to mean the primary mailbox for this user on this server The format of other mailbox names is operating system dependent as of this writing it reflects the filename path of the mailbox file on the current servers EXAMPLE A002 SELECT INBOX selects the default mailbox tag CHECK The CHECK command forces a check for new messages and a rescan of the mailbox for internal change for those implementations which allow multiple simultaneous read write access to the same mailbox e g TOPS 20 It is recommend that periodic implicit checks for new mail be done by servers as well The server should send an unsolicited EXISTS response prior to returning an OK to the client tag EXPUNGE The EXPUNGE command permanently removes all messages with the DELETED flag set in its flags from the mailbox Prior to returning an OK to the client for each message which is removed an unsolicited EXPUNGE response is sent indicating which message was removed The message number of each subsequent message in the mailbox is immediately decremented by 1 this means that if the last 5 messages in a 9 message mail file are expunged you will receive 5 5 EXPUNGE responses To ensure mailbox integrity and server client synchronization it is recommended that the server do an implicit check prior to commencing the expunge and again when the expunge is completed Furthermore if the server allows multiple simultaneous access to the same mail file the server must lock the mail file for exclusive access while an expunge is taking place Crispin Page 10 RFC 1064 IMAP2 July 1988 EXPUNGE is not allowed if the user does not have write access to this mailbox tag COPY sequence mailbox The COPY command copies the specified message s to the specified destination mailbox If the destination mailbox does not exist the server should create it Prior to returning an OK to the client the server should return an unsolicited COPY response for each message copied A copy should set the SEEN flag for all messages which were successfully copied provided of course that the user has write access to this mailbox EXAMPLE A003 COPY 2 4 MEETING copies messages 2 3 and 4 to mailbox MEETING COPY is not allowed if the user does not have write access to the destination mailbox tag FETCH sequence data The FETCH command retrieves data associated with a message in the mailbox The data items to be fetched may be either a single atom or an S expression list The currently defined data items that can be fetched are ALL Macro equivalent to FLAGS INTERNALDATE RFC822 SIZE ENVELOPE ENVELOPE The envelope of the message The envelope is computed by the server by parsing the RFC 822 header into the component parts defaulting various fields as necessary FAST Macro equivalent to FLAGS INTERNALDATE RFC822 SIZE Crispin Page 11 RFC 1064 IMAP2 July 1988 FLAGS The flags which are set for this message This may include the following system flags RECENT Message arrived since last read of this mail file SEEN Message has been read ANSWERED Message has been answered FLAGGED Message is flagged for urgent special attention DELETED Message is deleted for removal by later EXPUNGE INTERNALDATE The date and time the message was written to the mailbox RFC822 The message in RFC 822 format RFC822 HEADER The RFC 822 format header of the message RFC822 SIZE The number of characters in the message as expressed in RFC 822 format RFC822 TEXT The text body of the message omitting the RFC 822 header EXAMPLES A003 FETCH 2 4 ALL fetches the flags internal date RFC 822 size and envelope for messages 2 3 and 4 A004 FETCH 3 RFC822 fetches the RFC 822 representation for message 3 A005 FETCH 4 FLAGS RFC822 HEADER fetches the flags and RFC 822 format header for message 4 tag STORE sequence data value The STORE command alters data associated with a message in the mailbox The currently defined data items that can be stored are FLAGS Replace the flags for the message with the argument in flag list format FLAGS Add the flags in the argument to the message s flag list Crispin Page 12 RFC 1064 IMAP2 July 1988 FLAGS Remove the flags in the argument from the message s flag list STORE is not allowed if the user does not have write access to this mailbox EXAMPLE A003 STORE 2 4 FLAGS DELETED marks messages 2 3 and 4 for deletion tag SEARCH search criteria The SEARCH command searches the mailbox for messages which match the given set of criteria The unsolicited SEARCH response from the server is a list of messages which express the intersection AND function of all the messages The currently defined criteria are ALL All messages in the mailbox the default initial criterion for ANDing ANSWERED Messages with the ANSWERED flag set BCC string Messages which contain the specified string in the envelope s BCC field BEFORE date Messages whose internal date is earlier than the specified date BODY string Messages which contain the specified string in the body of the message CC string Messages which contain the specified string in the envelope s CC field DELETED Messages with the DELETED flag set FLAGGED Messages with the FLAGGED flag set KEYWORD flag Messages with the specified flag set NEW Messages which have the RECENT flag set but not the SEEN flag This is functionally equivalent to RECENT UNSEEN OLD Messages which do not have the RECENT flag set Crispin Page 13 RFC 1064 IMAP2 July 1988 ON date Messages whose internal date is the same as the specified date RECENT Messages which have the RECENT flag set SEEN Messages which have the SEEN flag set SINCE date Messages whose internal date is later than the specified date SUBJECT string Messages which contain the specified string in the envelope s SUBJECT field TEXT string Messages which contain the specified string TO string Messages which contain the specified string in the envelope s TO field UNANSWERED Messages which do not have the ANSWERED flag set UNDELETED Messages which do not have the DELETED flag set UNFLAGGED Messages which do not have the FLAGGED flag set UNKEYWORD flag Messages which do not have the specified flag set UNSEEN Messages which do not have the SEEN flag set EXAMPLE A003 SEARCH DELETED FROM SMITH SINCE 1 OCT 87 returns the message numbers for all deleted messages from Smith that were placed in the mail file since October 1 1987 Crispin Page 14 RFC 1064 IMAP2 July 1988 Responses tag OK text This response identifies successful completion of the command with the indicated tag The text is a line of human readable text which may be useful in a protocol telemetry log for debugging purposes tag NO text This response identifies unsuccessful completion of the command with the indicated tag The text is a line of human readable text which probably should be displayed to the user in an error report by the client tag BAD text This response indicates faulty protocol received from the client and indicates a bug in the client The text is a line of human readable text which should be recorded in any telemetry as part of a bug report to the maintainer of the client number message data This response occurs as a result of several different commands The message data is one of the following EXISTS The specified number of messages exists in the mailbox RECENT The specified number of messages have arrived since the last time this mailbox was read EXPUNGE The specified message number has been permanently removed from the mailbox and the next message in the mailbox if any becomes that message number STORE data Functionally equivalent to FETCH only it happens as a result of a STORE command FETCH data This is the principle means by which data about a message is returned to the client The data is in a Lisp like S expression property list form The current properties are ENVELOPE An S expression format list which describes the Crispin Page 15 RFC 1064 IMAP2 July 1988 envelope of a message The envelope is computed by the server by parsing the RFC 822 header into the component parts defaulting various fields as necessary The fields of the envelope are in the following order date subject from sender reply to to cc bcc in reply to and message id The date subject in reply to and message id fields are strings The from sender reply to to cc and bcc fields are lists of addresses An address is an S expression format list which describes an electronic mail address The fields of an address are in the following order personal name source route a k a the at domain list in SMTP mailbox name and host name Any field of an envelope or address which is not applicable is presented as the atom NIL Note that the server must default the reply to and sender fields from the from field a client is not expected to know to do this FLAGS An S expression format list of flags which are set for this message This may include the following system flags RECENT Message arrived since last read of this mail file SEEN Message has been read ANSWERED Message has been answered FLAGGED Message is flagged for urgent special attention DELETED Message is deleted for removal by later EXPUNGE INTERNALDATE A string containing the date and time the message was written to the mailbox RFC822 A string expressing the message in RFC 822 format RFC822 HEADER A string expressing the RFC 822 format header of the message RFC822 SIZE A number indicating the number of Crispin Page 16 RFC 1064 IMAP2 July 1988 characters in the message as expressed in RFC 822 format RFC822 TEXT A string expressing the text body of the message omitting the RFC 822 header FLAGS flag list This response occurs as a result of a SELECT command The flag list are the list of flags at a minimum the system defined flags which are applicable for this mailbox Flags other than the system flags are a function of the server implementation SEARCH number s This response occurs as a result of a SEARCH command The number s refer those messages which match the search criteria Each number is delimited by a space e g SEARCH 2 3 6 BYE text This response indicates that the server is about to close the connection The text is a line of human readable text which should be displayed to the user in a status report by the client This may be sent as part of a normal logout sequence or as a panic shutdown announcement by the server It is also used by some servers as an announcement of an inactivity autologout OK text This response indicates that the server is alive No special action on the part of the client is called for This is presently only used by servers at startup as a greeting message indicating that they are ready to accept the first command The text is a line of human readable text which may be logged in protocol telemetry NO text This response indicates some operational error at the server which cannot be traced to any protocol command The text is a line of human readable text which should be logged in protocol telemetry for the maintainer of the server and or the client No known server currently outputs such a response BAD text This response indicates some protocol error at the server which Crispin Page 17 RFC 1064 IMAP2 July 1988 cannot be traced to any protocol command The text is a line of human readable text which should be logged in protocol telemetry for the maintainer of the server and or the client This generally indicates a protocol synchronization problem on the part of the client and examination of the protocol telemetry is advised to determine the cause of the problem text This response indicates that the server is ready to accept the text of a literal from the client Normally a command from the client is a single text line If the server detects an error in the command it can simply discard the remainder of the line It cannot do this in the case of commands which contain literals since a literal can be an arbitrarily long amount of text and the server may not even be expecting a literal This mechanism is provided so the client knows not to send a literal until the server definitely expects it preserving client server synchronization In actual practice this situation is rarely encountered In the current protocol the only client command likely to contain a literal is the LOGIN command Consider a situation in which a server validates the user before checking the password If the password contains funny characters and hence is sent as a literal then if the user is invalid an error would occur before the password is parsed No such synchronization protection is provided for literals sent from the server to the client for performance reasons Any synchronization problems in this direction would be

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


  • specified let alone officially specified anywhere implementation of USP is difficult for sites wishing to implement Pcmail on different systems We therefore have decided to completely redesign DMSP It is now a very simple request response protocol similar to SMTP or NNTP running directly on a reliable bidirectional byte stream such as TCP The TCP contact port for DMSP has been designated 158 Requests and responses consist of ASCII characters on octet based transmission streams each character is transmitted rightjustified in an octet with the high order bit cleared to zero 4 1 DMSP commands DMSP operations consist of an operation name followed by zero or more tab or space characters followed by zero or more arguments each of which is separated from the operation name and other arguments by one or more space or tab characters All operation requests as well as all responses must be terminated with a carriage return plus line feed CR LF pair All operation names and arguments must be taken from the set of alphanumeric characters plus the characters dash underscore and period DMSP operation names are case insensitive they may be transmitted in any combination of upper and lower case DMSP arguments are case insensitive but case preserving in other words a mailbox named MarkL may be referred to by an operation argument markl but will always be stored and transmitted in a repository response as MarkL furthermore any attempt to create a new mailbox MaRkL will not be permitted Each operation argument may contain no more than 64 characters No single request or response line may contain more than 512 characters including all white space and the terminating CR LF 4 2 DMSP responses A DMSP operation always results in a response which may be followed Lambert Page 8 RFC 1056 PCMAIL June 1988 in turn by a list consisting of zero or more lines of CR LF terminated text terminated by a single period plus a CR LF A response is always prefaced by a three digit reply code possible text following the response code can be in any format The response code is sufficient to determine whether the operation succeeded or failed or whether more text is forthcoming following the response line Any text following the response code is for information only and need not follow any particular format The first digit indicates whether the operation succeeded or failed and if it succeeded whether or not more text should be presented to the repository Definitions of the first digit are similar to those of NNTP 1XX Informative message 2XX Operation completed successfully 3XX Operation completed successfully present remainder of text and terminate with a single period plus CR LF pair 4XX Operation was performed and failed for some reason 5XX Operation could not be performed because of a protocol syntax error of some sort The second digit indicates the type of object referred to by the response X0X Miscellaneous X1X User operation X2X Client operation X3X Mailbox operation Lambert Page 9 RFC 1056 PCMAIL June 1988 X4X Subscription operation X5X Message operation X6X Address operation In an error response the final digit can describe the type of error that occurred Otherwise it simply gives a response a unique number Numbers 0 through 3 are significant in 4XX class error responses only Numbers 0 9 in all other responses serve only to differentiate responses dealing with the same type of object under different circumstances 4X0 Operation failed because object exists 4X1 Operation failed because object does not exist 4X2 Operation failed because of an internal error 4X3 Operation failed because of an argument syntax error Each operation generates one of a set of responses detailed in the protocol specification appendix List termination is determined solely by a well known character sequence CR LF period CR LF Since application data could well accidentally contain this termination sequence the transmitting protocol module must modify application data so it contains no termination sequences The receiving module must similarly undo the modification before presenting the data to the application at the receiving end The transmitting module modifies application data as follows If a line of application data begins with a period that period is duplicated Since the termination sequence is a single period accidental termination has now been prevented The receiving protocol checks incoming all incoming data lines for a leading period A single period is a list terminator a period followed by other text is removed before being presented to the Lambert Page 10 RFC 1056 PCMAIL June 1988 receiving application 4 3 DMSP sessions A DMSP session proceeds as follows a client begins the session with the repository by opening a connection to the repository s machine The client then authenticates both itself and its user to the repository with a login operation If the authentication is successful the user performs an arbitrary number of DMSP operations before ending the session with a logout operation at which time the connection is closed by the repository Because DMSP can manipulate a pair of mail states local and global at once it is extremely important that all DMSP operations are failure atomic Failure of any DMSP operation must leave both states in a consistent known state For this reason a DMSP operation is defined to have failed unless an explicit acknowledgement is received by the operation initiator This acknowledgement consists of a response code possibly followed by information as described above Following is a general discussion of all the DMSP operations The operations are broken down by type general operations user operations client operations mailbox operations address operations subscription operations and message operations Detailed operation specifications appear at the end of this document 4 4 General operations The first group of DMSP operations perform general functions that operate on no one particular class of object DMSP has three general operations which provide the following services In order to prevent protocol version skew between clients and the repository DMSP provides a send version operation The client supplies its DMSP version number as an argument the operation succeeds if the supplied version number matches the repository s DMSP version number It fails if the two version numbers do not match The version number is a natural number like 100 101 200 The send version operation should be the first that a client sends to the repository since no other operation may work correctly if the client and repository are using different versions of DMSP Users can send mail to other users via the send message operation The message must have an Internet style header as defined by NIC RFC 822 The repository takes the message and distributes it to the mailboxes specified by the message header s destination fields If one or more of the mailboxes exists outside the repository s user community the repository is responsible for handing the message to a Lambert Page 11 RFC 1056 PCMAIL June 1988 local SMTP server The message envelope is generated by the repository from the message contents since it may be difficult for some clients to perform envelope generation functions such as address verification and syntax checking A success acknowledgement is sent from the repository only if 1 the entire message was successfully transmitted from client to repository and 2 the message header was properly formatted Once the repository has successfully received the message from the client any subsequent errors in queueing or delivery must be noted via return mail to the user The last general operation is the help operation The repository responds to help by printing an acknowledgement followed by a list of supported commands terminated with a period plus CR LF The information is intended for display and can be in any format as long as the individual lines of text returned by the repository are CR LF terminated 4 5 User operations The next series of DMSP operations manipulates user objects The most common of these operations are login and logout A client must perform a login operation before being able to access a user s mail state A DMSP login operation takes five arguments 1 the user s name 2 the user s password 3 the name of the client performing the login 4 a flag set to 1 if the repository should create a client object for the client if one does not exist 0 else and 5 a flag set to 1 if the client wishes to operate in batch mode and 0 if the client wishes to operate in interactive mode The last flag value allows the repository to tune internal parameters for either mode of operation The repository can make one of three responses First it can make a success response indicating successful authentication Second it can make one of several failure responses indicating failed authentication Finally it can make a special response indicating that authentication was successful but that the client has not been used in over a week This last response serves as a hint that the client should consider erasing its local mail state and pulling over a complete version of the repository s mail state This is done on the assumption that so many mail state changes have been made in a week that it would be inefficient to perform a normal synchronization When a client has completed a session with the repository it performs a logout operation This allows the repository to perform any necessary cleanup before closing the network connection Lambert Page 12 RFC 1056 PCMAIL June 1988 A user can change his password via the set password operation The operation works much the same as the UNIX change password operation taking as arguments the user s current password and a desired new password If the current password given matches the user s current password the user s current password is changed to the new password given Because encryption can be difficult to perform on some resource poor clients passwords are transmitted in clear text Clearly this is not an acceptable long term solution and alternatives are welcomed 4 6 Client operations DMSP provides four operations to manipulate client objects The first list clients tells the repository to send the user s client list to the requesting client The list is a series of lines one per client containing the client s name followed by whitespace followed by a status string The status is either inactive or active As with all text responses the list is terminated with a period plus CR LF The create client operation allows a user to add a client object to his list of client objects Although the login operation duplicates this functionality via the create this client flag the create client operation is a useful means of creating a number of new client objects while logged into the repository via an existing client The create client operation requires as an argument the name of the client to create The delete client operation removes an existing client object from a user s client list The client being removed cannot be in use by anyone at the time Delete client also requires as an argument the name of the client to delete The last client operation reset client causes the repository to place all of the messages in all mailboxes onto the named client s update list When a client next synchronizes with the repository it will end up receiving a list of all descriptors when it requests a list of changed message descriptors for a particular mailbox This is useful for two reasons First a client s local mail state could easily become lost or damaged especially if it is stored on a floppy disk Second if a client has been marked as inactive by the repository the reset client operation provides a fast way of resynchronizing with the repository assuming that so many differences exist between the local and global mail states that a normal synchronization would take far too much time Lambert Page 13 RFC 1056 PCMAIL June 1988 4 7 Mailbox operations DMSP supports seven operations that manipulate mailbox objects First list mailboxes has the repository send to the requesting client information on each mailbox The repository transmits one line of information per mailbox terminating the list with a period plus CR LF Each line contains in order and separated by whitespace the mailbox name next available UID total message count and unseen message count This operation is useful in synchronizing local and global mail states since it allows a client to compare the user s global mailbox list with a client s local mailbox list The list of mailboxes also provides a quick summary of each mailbox s contents without having the contents present The create mailbox has the repository create a new mailbox and attach it to the user s list of mailboxes It takes as an argument the name of the mailbox to create Delete mailbox removes a mailbox from the user s list of mailboxes All messages within the mailbox are also deleted and permanently removed from the system Any address objects binding the mailbox name to RFC 822 style mailbox addresses are also removed from the system Delete mailbox takes as an argument the name of the mailbox to delete Create bboard mailbox allows a user to create a bboard mailbox The name given as an argument must be unique across the entire repository user community Once the bboard mailbox has been created other users may subscribe to it using subscription objects to keep track of which messages they have read on which bboard mailboxes Delete bboard mailbox allows a bboard s owner to delete a bboard mailbox Subscribers who attempt to read from a bboard mailbox after it has been deleted are told that the bboard no longer exists Again the operation s argument is the name of the bboard mailbox to delete Reset mailbox causes the repository to place all of the messages in a named mailbox onto the current client s update list When the client next requests a list of changed message descriptors for this mailbox it will receive a list of all message descriptors in the mailbox This operation is merely a more specific version of the reset client operation which allows the client to pull over a complete copy of the user s global mail state Its primary use is for mailboxes whose contents have accidentally been destroyed locally Finally DMSP has an expunge mailbox operation Any message can be Lambert Page 14 RFC 1056 PCMAIL June 1988 deleted and undeleted at will since this simply changes the value of a flag attached to the message Deletions are made permanent by performing an expunge mailbox operation The expunge operation causes the repository to look through a named mailbox removing from the system any messages marked deleted Expunge mailbox takes as an argument the name of the mailbox to expunge 4 8 Address operations DMSP provides three operations that allow users to manipulate address objects First the list address operation returns a list of address objects associated with a particular mailbox Each address is transmitted on a separate line terminated by a CR LF the list is terminated with a period plus CR LF The create address operation adds a new address object that associates a user name mailbox name pair with a given RFC 822 style mailbox address It takes as arguments the mailbox name and the address name Finally the delete address operation destroys the address object binding the given RFC 822 style mail address and the given user name mailbox name pair Arguments are the address to delete and the mailbox it belongs to 4 9 Subscription operations DMSP provides five subscription operations The first list subscriptions gives the user a list of the bboards he is currently subscribing to The list consists of one line of information per subscription Each entry contains the following information in order The bulletin board s name The UID of the first message the subscriber has not yet seen The number of messages the subscriber has not yet seen The highest message UID in the bulletin board List available subscriptions gives the user a list of all bboards he can subscribe to The list consists of bboard names one per line terminated by a period plus CR LF Createsubscription adds a subscription to the user s list of subscriptions it takes as an argument the name of the bboard to subscribe to Delete subscription removes a subscription from the list and takes as an Lambert Page 15 RFC 1056 PCMAIL June 1988 argument the name of the subscription to remove Note that this does not delete the associated bboard mailbox obviously only the bboard s owner can do that It merely removes the user from the list of the bboard s subscribers Finally DMSP allows the user to tell the repository which messages in a bboard he has seen Every subscription object contains the UID of the first message the user has not yet seen the reset subscription operation updates that number insuring that the user sees a given bboard message only once Reset subscription takes as arguments the name of the subscription and the new UID value 4 10 Message operations The most commonly manipulated Pcmail objects are messages DMSP therefore provides special message operations to allow efficient synchronization as well as a set of operations to perform standard message manipulation functions A user may request a series of descriptors with the fetch descriptors operation The series is identified by a pair of message UIDs representing the lower and upper bounds of the list Since UIDs are defined to be monotonically increasing numbers a pair of UIDs is sufficient to completely identify the series of descriptors If the lower bound UID does not exist the repository starts the series with the first message with UID greater than the lower bound Similarly if the upper bound does not exist the repository ends the series with the last message with UID less than the upper bound If certain UIDs within the series no longer exist the repository obviously does not send them The repository returns the descriptors in a list with the following format If a descriptor has been expunged the repository transmits two consecutive lines of information the word expunged on one line followed by the message UID on the next line Expunged notifications are only transmitted in response to a fetch changed descriptors command they are an indication to the client that someone else has expunged the mailbox and that the client should remove the local copy of the expunged message If a descriptor has not been expunged it is presented as six consecutive lines of information the word descriptor on the first line followed by a second line containing the message UID flag states see examples following message length in bytes and message length in lines followed by four lines containing in order the message from field to field date field and subject field The entire list of descriptors is terminated by a period plus CR LF individual descriptors are not specially terminated since the first line expunged or descriptor of a list entry determines Lambert Page 16 RFC 1056 PCMAIL June 1988 the exact length of the entry two lines or six lines The fetch changed descriptors operation is intended for use during state synchronization Whenever a descriptor changes state one of its flags is cleared for example the repository notes those clients which have not yet recorded the change locally Fetch changed descriptors has the repository send to the client a maximum of the first N descriptors which have changed since the client s last synchronization where N is a number sent by the client The list sent begins with the descriptor with lowest UID Note that the list of descriptors is only guaranteed to be monotonically increasing for a given call to fetch changed descriptors messages with lower UIDs may be changed by other clients in between calls to fetch changeddescriptors Fetch changed descriptors takes two arguments the name of the mailbox to search and the maximum number of descriptors for the repository to return Once the changed descriptors have been looked at a user will want to inform the repository that the current client has recorded the change locally The reset descriptors command causes the repository to mark as recorded by current client a given series of descriptors The series is identified by a low UID and a high UID UIDs within the series that no longer exist are ignored Arguments are mailbox name low UID in range and high UID in range Whole messages are transmitted from repository to user with the fetch message operation The separation of fetchdescriptors and fetch message operations allows clients with small amounts of disk storage to obtain a small message summary via fetch descriptors or fetch changed descriptors without having to pull over the entire message Arguments are mailbox name followed by message UID Frequently a message may be too large for some clients to store locally Users can still look at the message contents via the print message operation This operation has the repository send a copy of the message to a named printer The printer name need only have meaning to the particular repository implementation DMSP transmits the name only as a means of identification Arguments are mailbox name followed by message UID followed by printer identification Copying of one message into another mailbox is accomplished via the copy message operation A descriptor list of length one containing a descriptor for the copied message is returned if the copy operation is successful This descriptor is required because the copied message acquires a UID different from the original message The client cannot be expected to know which UID has been assigned the copy hence the repository s sending a descriptor Lambert Page 17 RFC 1056 PCMAIL June 1988 containing the UID Arguments to copy message are source mailbox name target mailbox name and source message UID Each message has associated with it sixteen flags as described earlier These flags can be set and cleared using the set message flag operation The first eight flags have special meaning to the repository as described above the remaining eight are for user use Set message flag takes four arguments mailbox name message UID flag number 0 through 15 and desired flag state 0 or 1 5 Client Architecture Clients can be any of a number of different workstations Pcmail s architecture must therefore take into account the range of characteristics of these workstations First most workstations are much more affordable than the large computers currently used for mail service It is therefore possible that a user may well have more than one Second some workstations are portable and they are not expected to be constantly tied into a network Finally many of the smaller workstations resource poor so they are not expected to be able to store a significant amount of state information locally The following subsections describe the particular parts of Pcmail s client architecture that address these different characteristics 5 1 Multiple clients The fact that Pcmail users may own more than one workstation forms the rationale for the multiple client model that Pcmail uses A Pcmail user may have one client at home another at an office and maybe even a third portable client Each client maintains a separate copy of the user s mail state hence Pcmail s distributed nature The notion of separate clients allows Pcmail users to access mail state from several different locations Pcmail places no restrictions on a user s ability to communicate with the repository from several clients at the same time Instead the decision to allow several clients concurrent access to a user s mail state is made by the repository implementation 5 2 Synchronization Some workstations tend to be small and fairly portable the likelihood of their always being connected to a network is relatively small This is another reason for each client s maintaining a local copy of a user s mail state The user can then manipulate the local mail state while not connected to the network and the repository This immediately brings up the problem of synchronization between local and global mail states The repository is continually in a position to receive global mail state updates either in the form of Lambert Page 18 RFC 1056 PCMAIL June 1988 incoming mail or in the form of changes from other clients A client that is not always connected to the net cannot immediately receive the global changes In addition the client s user can make his own changes on the local mail state Pcmail s architecture allows fast synchronization between client local mail states and the repository s global mail state Each client is identified in the repository by a client object attached to the user This object forms the basis for synchronization between local and global mail states Some of the less common state changes include the adding and deleting of user mailboxes and the adding and deleting of address objects Synchronization of these changes is performed via DMSP list operations which allow clients to compare their local versions of mailbox and address object lists with the repository s global version and make any appropriate changes The majority of possible changes to a user s mail state are in the form of changed descriptors Since most users will have a large number of messages and message states will change relatively often special attention needs to be paid to message synchronization An existing descriptor can be changed in one of three ways first one of its sixteen flag values can be changed this encompasses the user s reading an unseen message deleting a message printing a message etc Second a descriptor can be created either by the delivery of a new message or by the copying of a message from one mailbox to another Finally a descriptor can be destroyed via an expunge mailbox operation In the above cases synchronization is required between the repository and every client that has not previously noted the change To keep track of which clients have noticed a global mail state change and changed their local states accordingly each mailbox has associated with it a list of active clients Each client has a potentially empty update list of messages which have changed since that client last synchronized When a client connects to the repository it executes a DMSP fetch changed descriptors operation This causes the repository to return a list of all descriptors on that client s update list When the client receives the changed descriptors it may do one of two things if the descriptor is marked expunged it can remove the corresponding message from the local mailbox If the descriptor is not expunged the client can store the descriptor thus updating the local mail state After a changed descriptor has been recorded the client uses the DMSP reset descriptors operation to remove descriptors from its update list Those descriptors will now not be sent to the client unless 1 it is explicitly requested via a fetch descriptors operation or 2 it changes again Lambert Page 19 RFC 1056 PCMAIL June 1988 In this manner a client can run through its user s mailboxes getting all changes incorporating them into the local mail state and marking the changes as recorded 5 3 Batch operation versus interactive operation Because of the portable nature of some workstations they may not always be connected to a network and able to communicate with the repository Since each client maintains a local mail state Pcmail users can manipulate the local state while not connected to the repository This is known as batch operation since all changes are recorded by the client and made to the repository s global state in a batch when the client next connects to the repository Interactive operation occurs when a client is always connected to the repository In interactive mode changes made to the local mail state are also immediately made to the global state via DMSP operations In batch mode interaction between client and repository takes the following form the client connects to the repository and sends over all the changes made by the user to the local mail state The repository changes its global mail state accordingly When all changes have been processed the client begins synchronization this incorporates newly arrived mail as well as mail state changes by other clients into the local state In interactive mode since local changes are immediately propagated to the repository the first part of batch type operation is eliminated The synchronization process also changes although one synchronization is required when the client first opens a connection to the repository subsequent synchronizations can be performed either at the user s request or automatically every so often by the client 5 4 Message summaries Smaller workstations may have little in the way of disk storage Clients running on these workstations may never have enough room for a complete local copy of a user s global mail state This means that Pcmail s client architecture must allow user s to obtain a clear picture of their mail state without having all their messages present Descriptors provide message information without taking up large amounts of storage Each descriptor contains a summary of information on a message This information includes the message UID its length in bytes and lines its status contained in the eight system defined and eight user defined flags and portions of its Lambert Page 20 RFC 1056 PCMAIL June 1988 RFC 822 header the from to date and subject fields All of this information can be encoded in a small around 100 bytes data structure whose length is independent of the size of the message it describes Most clients should be able to store a complete list of message descriptors with little problem This allows a user to get a complete picture of his mail state without having all his messages present locally If a client has extremely limited amounts of disk storage it is also possible to get a subset of the descriptors from the repository Short messages can reside on the client along with the descriptors and long messages can either be printed via the DMSP print message operation or specially pulled over via the fetch message operation 6 Typical interactive style client repository interaction The following example describes a typical communication session between the repository and a client mail reader The client is one of three belonging to user Fred Its name is office client and since Fred has used the client within the last week it is marked as active Fred has two mailboxes fred is where all of his current mail is stored archive is where messages of lasting importance are kept The example will run through a simple synchronization operation Typically the synchronization will be performed by a mail reader as part of a get new mail operation First Fred s mail reader connects to the repository and receives the following banner 200 Pcmail repository version 3 0 0 ready In order to access his global mail state the mail reader must authenticate Fred to the repository this is done via the DMSP login operation login fred fred password office client 0 0 This tells the repository that Fred is logging in via office client and that office client is identified by an existing client object in Fred s mail state The first argument to the login operation is Fred s repository user name The second argument is Fred s password The third argument is the name of the client communicating with the repository The fourth argument tells the repository not to create office client even if it cannot find its client object The final argument tells the repository that Fred s client is not operating in batch mode but rather in interactive mode Lambert Page 21 RFC 1056 PCMAIL June 1988 Fred s authentication checks out so the repository logs him in 200 command OK Now that Fred is logged in the mail reader performs an initial synchronization This process starts with the mail reader s asking for an up to date list of mailboxes list mailboxes The repository replies with 230 mailbox list follows fred 2313 10 1 archive 101 100 0 This tells the mail reader that there are two mailboxes fred and archive Fred has 10 messages one of which is unseen The next incoming message will be assigned a UID of 2313 Archive on the other hand has 100 messages none of which are unseen The next message sent to archive will be assigned the UID 101 There are no new mailboxes in the list if there were the mail reader would create them On the other hand if some mailboxes in the mail reader s local list were not in the repository s list the program would assume them deleted by another client and delete them locally as well To synchronize the mail reader need only look at each mailbox s contents to see if 1 any new mail has arrived or 2 if Fred changed any messages on one of his other two clients subsequent to office client s last connection to the repository The mail reader asks for any changed descriptors via the fetch changed descriptors operation It requests at most ten changed descriptors since storage is very limited on Fred s workstation fetch changed descriptors fred 10 The repository responds with 250 descriptor list follows expunged Lambert Page 22 RFC 1056 PCMAIL June 1988 2101 expunged 2104 descriptor 2107 1100011100000010 1400 30 foo bar edu Foo Jones fred PTT LCS MIT EDU Wed 9 Dec 87 10 43 52 EST A typical subject line descriptor 2312 0000000000000000 12232 320 joe athena mit edu fred PTT LCS MIT EDU Thu 17 Dec 87 18 24 09 PST Another typical subject line If a descriptor changed because it was expunged it is transmitted as two lines the word expunged on one line followed by the message UID on the next line If one of its flags changed state or it is a new message it is transmitted as six lines the word descriptor on one line followed by a line containing the message UID flags and length in bytes and lines followed by the to from date and subject fields each on one line The flags are transmitted as a single string of ones and zeroes a one if the flag is on and a zero if the flag is off All 16 flags are always transmitted Flag zero s state is the first character in the flag string flag fifteen s is the last character in the flag string The first two descriptors in the list have been expunged presumably by Fred s expunging his mailbox on another client The mail reader removes messages 2101 and 2104 from its local copy of mailbox fred The next descriptor in the list is one which Fred marked for deletion on another client yesterday The mail reader marks the local version of the message as deleted The last descriptor in the list is a new one The mail reader adds the descriptor to its local list Since all changes to mailbox fred have now been recorded locally the update list can be reset reset descriptors fred 1 2312 The repository responds with 200 command OK indicating that it has removed from office client s update list all Lambert Page 23 RFC 1056 PCMAIL June 1988 messages in mailbox fred with UIDs between 1 and 2312 inclusive in this case just two messages Fred has now been synchronized The mail reader now turns to Fred s archive mailbox and asks for the first ten changed descriptors fetch changed descriptors archive 10 The repository responds with 250 descriptor list follows The zero length list tells the mail reader

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


  • for the greeting then sends the HELO command with the user name and password arguments to establish authorization to access mailboxes The server returns the number of messages in the default mailbox The client may read the default mailbox associated with the user name or may select another mailbox by using the FOLD command The server returns the number of messages in the mailbox selected The client begins a message reading transaction with a READ command The read command may optionally indicate which message number to read the default is the current message incremented when a message is read and set to one when a new folder is selected The server returns the number of characters in the message Butler et al Page 2 RFC 937 February 1985 Post Office Protocol The client asks for the content of the message to be sent with the RETR command The server sends the message data When all the data has been received the client sends an acknowledgment command This is one of ACKS ACKD and NACK ACKS means I ve received the message successfully and please keep it in the mailbox ACKD means I ve received the message successfully and please delete it from the mailbox NACK means I did not receive the message and please keep it in the mailbox In the case of ACKS or ACKD the server increments the current message indicator In the case of NACK the current message indicator stays the same In all cases the server returns the number of characters in the now current message The client terminates the session with the QUIT command The server returns an ok Butler et al Page 3 RFC 937 February 1985 Post Office Protocol The Normal Scenario Client Server Wait for Connection Open Connection Go back to start Butler et al Page 14 RFC 937 February 1985 Post Office Protocol Formal Syntax 0 1 2 3 4 5 6 7 8 9 A B C Z a b c z any one of the 128 ASCII codes carriage return code 10 line feed code 13 space code 32 Butler et al Page 15 RFC 937 February 1985 Post Office Protocol HELO FOLD READ RETR ACKS ACKD NACK QUIT POP2 Butler et al Page 16 RFC 937 February 1985 Post Office Protocol Client State Diagram BYE Open Greet Close V QUIT CALL EXIT Greet HELO NNN NNN V V FOLD QUIT NNN CCC READ FOLD CCC V CCC QUIT SIZE READ HELO NNN QUIT V FOLD BYE MBOX NNN BYE ITEM CCC QUIT V V CALL HELO NMBR EXIT AUTH AUTH AUTH NNN Bye QUIT V V FOLD NMBR READ SIZE EXIT MBOX MBOX MBOX NNN QUIT NNN V V READ SIZE RETR XFER EXIT ITEM ITEM ITEM CCC DONE Butler et al Page 19 RFC 937 February 1985 Post Office Protocol Client Decision Table STATE INPUT CALL NMBR SIZE XFER EXIT Greet 2 1 1 1 6 NNN 1 3 1 1 6 CCC 1 1 4 1

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


  • Mills Page 8 RFC 1059 Network Time Protocol July 1988 2 2 Network Configurations A primary time server is connected to a primary reference source usually a radio clock synchronized to national standard time A secondary time server derives time synchronization possibly via other secondary servers from a primary server Under normal circumstances it is intended that a subnet of primary and secondary servers assumes a hierarchical master slave configuration with the more accurate servers near the top and the less accurate below Following conventions established by the telephone industry the accuracy of each server is defined by a number called its stratum with the stratum of a primary server assigned as one and each level downwards in the hierarchy assigned as one greater than the preceding level With current technology and available receiving equipment single sample accuracies in the order of a millisecond can be achieved at the radio clock interface and in the order of a few milliseconds at the packet interface to the net Accuracies of this order require special care in the design and implementation of the operating system such as described in 15 and the logical clock mechanism such as described in Section 5 As the stratum increases from one the single sample accuracies achievable will degrade depending on the communication paths and local clock stabilities In order to avoid the tedious calculations 4 necessary to estimate errors in each specific configuration it is useful to assume the errors accumulate approximately in proportion to the minimum total roundtrip path delay between each server and the primary reference source to which it is synchronized This is called the synchronization distance Again drawing from the experience of the telephone industry who learned such lessons at considerable cost the synchronization paths should be organized to produce the highest accuracies but must never be allowed to form a loop The clock filter and selection algorithms used in NTP accomplish this by using a variant of the Bellman Ford distributed routing algorithm 29 to compute the minimum weight spanning trees rooted on the primary servers This results in each server operating at the lowest stratum and in case of multiple peers at the same stratum at the lowest synchronization distance As a result of the above design the subnet reconfigures automatically in a hierarchical master slave configuration to produce the most accurate time even when one or more primary or secondary servers or the communication paths between them fail This includes the case where all normal primary servers e g backbone WWVB clocks on a possibly partitioned subnet fail but one or more backup primary servers e g local WWV clocks continue operation Mills Page 9 RFC 1059 Network Time Protocol July 1988 However should all primary servers throughout the subnet fail the remaining secondary servers will synchronize among themselves for some time and then gradually drop off the subnet and coast using their last offset and frequency computations Since these computations are expected to be very precise especially in frequency even extend outage periods of a day or more should result in timekeeping errors of not over a few tens of milliseconds In the case of multiple primary servers the spanning tree computation will usually select the server at minimum synchronization distance However when these servers are at approximately the same distance the computation may result in random selections among them as the result of normal dispersive delays Ordinarily this does not degrade accuracy as long as any discrepancy between the primary servers is small compared to the synchronization distance If not the filter and selection algorithms will select the best of the available servers and cast out outlyers as intended 2 3 Time Scales Since 1972 the various national time scales have been based on International Atomic Time TA which is currently maintained using multiple cesium beam clocks to an accuracy of a few parts in 10 12 The Bureau International de l Heure BIH uses astronomical observations provided by the US Naval Observatory and other observatories to determine corrections for small changes in the mean rotation period of the Earth This results in Universal Coordinated Time UTC which is presently decreasing from TA at a fraction of a second per year When the magnitude of the correction approaches 0 7 second a leap second is inserted or deleted in the UTC time scale on the last day of June or December Further information on time scales can be found in 26 For the most precise coordination and timestamping of events since 1972 it is necessary to know when leap seconds were inserted or deleted in UTC and how the seconds are numbered A leap second is inserted following second 23 59 59 on the last day of June or December and becomes second 23 59 60 of that day A leap second would be deleted by omitting second 23 59 59 on one of these days although this has never happened Leap seconds were inserted on the following fourteen occasions prior to January 1988 courtesy US Naval Observatory Mills Page 10 RFC 1059 Network Time Protocol July 1988 1 June 1972 8 December 1978 2 December 1972 9 December 1979 3 December 1973 10 June 1981 4 December 1974 11 June 1982 5 December 1975 12 June 1983 6 December 1976 13 June 1985 7 December 1977 14 December 1987 Table 2 1 Dates of Leap Second Insertion Like UTC NTP operates with an abstract oscillator synchronized in frequency to the TA time scale At 0000 hours on 1 January 1972 the NTP time scale was set to 2 272 060 800 representing the number of TA seconds since 0000 hours on 1 January 1900 The insertion of leap seconds in UTC does not affect the oscillator itself only the translation between TA and UTC or conventional civil time However since the only institutional memory assumed by NTP is the UTC radio broadcast service the NTP time scale is in effect reset to UTC as each offset estimate is computed When a leap second is inserted in UTC and subsequently in NTP knowledge of all previous leap seconds is lost Thus if a clock synchronized to NTP in early 1988 was used to establish the time of an event that occured in early 1972 it would be fourteen seconds early When NTP is used to measure intervals between events that straddle a leap second special considerations apply When it is necessary to determine the elapsed time between events such as the half life of a proton NTP timestamps of these events can be used directly When it is necessary to establish the order of events relative to UTC such as the order of funds transfers NTP timestamps can also be used directly however if it is necessary to establish the elapsed time between events relative to UTC such as the intervals between payments on a mortgage NTP timestamps must be converted to UTC using the above table and its successors The current formats used by NBS radio broadcast services 2 do not include provisions for advance notice of leap seconds so this information must be determined from other sources NTP includes provisions to distribute advance warnings of leap seconds using the Leap Indicator bits described in Section 3 The protocol is designed so that these bits can be set manually at the primary clocks and then automatically distributed throughout the system for delivery to all logical clocks and then effected as described in Section 5 Mills Page 11 RFC 1059 Network Time Protocol July 1988 3 Network Time Protocol This section consists of a formal definition of the Network Time Protocol including its data formats entities state variables events and event processing procedures The specification model is based on the implementation model illustrated in Figure 2 1 but it is not intended that this model is the only one upon which a specification can be based In particular the specification is intended to illustrate and clarify the intrinsic operations of NTP and serve as a foundation for a more rigorous comprehensive and verifiable specification 3 1 Data Formats All mathematical operations expressed or implied herein are in two s complement arithmetic Data are specified as integer or fixed point quantities Since various implementations would be expected to scale externally derived quantities for internal use neither the precision nor decimal point placement for fixed point quantities is specified Unless specified otherwise all quantities are unsigned and may occupy the full field width if designated with an implied zero preceding the most significant leftmost bit Hardware and software packages designed to work with signed quantities will thus yield surprising results when the most significant sign bit is set It is suggested that externally derived unsigned fixed point quantities such as timestamps be shifted right one bit for internal use since the precision represented by the full field width is seldom justified Since NTP timestamps are cherished data and in fact represent the main product of the protocol a special timestamp format has been established NTP timestamps are represented as a 64 bit unsigned fixed point number in seconds relative to 0000 UT on 1 January 1900 The integer part is in the first 32 bits and the fraction part in the last 32 bits as shown in the following diagram 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 Integer Part Fraction Part This format allows convenient multiple precision arithmetic and conversion to Time Protocol representation seconds but does complicate the conversion to ICMP Timestamp message representation milliseconds The precision of this representation is about 0 2 Mills Page 12 RFC 1059 Network Time Protocol July 1988 nanosecond which should be adequate for even the most exotic requirements Timestamps are determined by copying the current value of the logical clock to a timestamp variable when some significant event such as the arrival of a message occurs In order to maintain the highest accuracy it is important that this be done as close to the hardware or software driver associated with the event as possible In particular departure timestamps should be redetermined for each link level retransmission In some cases a particular timestamp may not be available such as when the host is rebooted or the protocol first starts up In these cases the 64 bit field is set to zero indicating the value is invalid or undefined Note that since some time in 1968 the most significant bit bit 0 of the Integer Part has been set and that the 64 bit field will overflow some time in 2036 Should NTP be in use in 2036 some external means will be necessary to qualify time relative to 1900 and time relative to 2036 and other multiples of 136 years Timestamped data requiring such qualification will be so precious that appropriate means should be readily available There will exist an 0 2 nanosecond interval henceforth ignored every 136 years when the 64 bit field will be zero and thus considered invalid 3 2 State Variables and Parameters Following is a tabular summary of the various state variables and parameters used by the protocol They are separated into classes of system variables which relate to the operating system environment and logical clock mechanism peer variables which are specific to each peer operating in symmetric mode or client mode packet variables which represent the contents of the NTP message and parameters which are fixed in all implementations of the current version For each class the description of the variable is followed by its name and the procedure or value which controls it Note that variables are in lower case while parameters are in upper case Mills Page 13 RFC 1059 Network Time Protocol July 1988 System Variables Name Control Logical Clock sys clock update Clock Source sys peer selection algorithm Leap Indicator sys leap update Stratum sys stratum update Precision sys precision system Synchronizing Distance sys distance update Estimated Drift Rate sys drift system Reference Clock Identifier sys refid update Reference Timestamp sys reftime update Table 3 1 System Variables Peer Variables Name Control Peer Address peer srcadr system Peer Port peer srcport system Local Address peer dstadr system Local Port peer dstport system Peer State peer state receive transmit Reachability Register peer reach receive transmit Peer Timer peer timer system Timer Threshold peer threshold system Leap Indicator peer leap receive Stratum peer stratum receive Peer Poll Interval peer ppoll receive Host Poll Interval peer hpoll receive transmit Precision peer precision receive Synchronizing Distance peer distance receive Estimated Drift Rate peer drift receive Reference Clock Identifier peer refid receive Reference Timestamp peer reftime receive Originate Timestamp peer org receive Receive Timestamp peer rec receive Filter Register peer filter filter algorithm Delay Estimate peer delay filter algorithm Offset Estimate peer offset filter algorithm Dispersion Estimate peer dispersion filter Table 3 2 Peer Variables Mills Page 14 RFC 1059 Network Time Protocol July 1988 Packet Variables Name Control Peer Address pkt srcadr transmit Peer Port pkt srcport transmit Local Address pkt dstadr transmit Local Port pkt dstport transmit Leap Indicator pkt leap transmit Version Number pkt version transmit Stratum pkt stratum transmit Poll pkt poll transmit Precision pkt precision transmit Synchronizing Distance pkt distance transmit Estimated Drift Rate pkt drift transmit Reference Clock Identifier pkt refid transmit Reference Timestamp pkt reftime transmit Originate Timestamp pkt org transmit Receive Timestamp pkt rec transmit Transmit Timestamp pkt xmt transmit Table 3 3 Packet Variables Parameters Name Value NTP Version NTP VERSION 1 NTP Port NTP PORT 123 Minimum Polling Interval NTP MINPOLL 6 64 sec Maximum Polling Interval NTP MAXPOLL 10 1024 sec Maximum Dispersion NTP MAXDISP 65535 ms Reachability Register Size PEER WINDOW 8 Shift Register Size PEER SHIFT 4 8 Dispersion Threshold PEER THRESHOLD 500 ms Filter Weight PEER FILTER 5 Select Weight PEER SELECT 75 Table 3 4 Parameters Following is a description of the various variables used in the protocol Additional details on formats and use are presented in later sections and appendices 3 2 1 Common Variables The following variables are common to the system peer and packet classes Peer Address peer srcadr pkt srcadr Peer Port peer srcport pkt srcport Mills Page 15 RFC 1059 Network Time Protocol July 1988 These are the 32 bit Internet address and 16 bit port number of the remote host Local Address peer dstadr pkt dstadr Local Port peer dstport pkt dstport These are the 32 bit Internet address and 16 bit port number of the local host They are included among the state variables to support multi homing Leap Indicator sys leap peer leap pkt leap This is a two bit code warning of an impending leap second to be inserted in the NTP time scale The bits are set before 23 59 on the day of insertion and reset after 00 01 on the following day This causes the number of seconds rollover interval in the day of insertion to be increased or decreased by one In the case of primary servers the bits are set by operator intervention while in the case of secondary servers the bits are set by the protocol The two bits are coded as follows 00 no warning day has 86400 seconds 01 1 second day has 86401 seconds seconds 10 1 second day has 86399 seconds seconds 11 alarm condition clock not synchronized In all except the alarm condition 11 NTP itself does nothing with these bits except pass them on to the time conversion routines that are not part of NTP The alarm condition occurs when for whatever reason the logical clock is not synchronized such as when first coming up or after an extended period when no outside reference source is available Stratum sys stratum peer stratum pkt stratum This is an integer indicating the stratum of the logical clock A value of zero is interpreted as unspecified one as a primary clock synchronized by outside means and remaining values as the stratum level synchronized by NTP For comparison purposes a value of zero is considered greater than any other value Peer Poll Interval peer ppoll pkt poll This is a signed integer used only in symmetric mode and indicating the minimum interval between messages sent to the peer in seconds as a power of two For instance a value of six Mills Page 16 RFC 1059 Network Time Protocol July 1988 indicates a minimum interval of 64 seconds The value of this variable must not be less than NTP MINPOLL and must not be greater than NTP MAXPOLL Precision sys precision peer precision pkt precision This is a signed integer indicating the precision of the logical clock in seconds to the nearest power of two For instance a 60 Hz line frequency clock would be assigned the value 6 while a 1000 Hz crystal derived clock would be assigned the value 10 Synchronizing Distance sys distance peer distance pkt distance This is a fixed point number indicating the estimated roundtrip delay to the primary clock in seconds Estimated Drift Rate sys drift peer drift pkt drift This is a fixed point number indicating the estimated drift rate of the local clock in dimensionless units Reference Clock Identifier sys refid peer refid pkt refid This is a code identifying the particular reference clock or server The interpretation of the value depends on the stratum For stratum values of zero unspecified or one primary clock the value is an ASCII string identifying the reason or clock respectively For stratum values greater than one synchronized by NTP the value is the 32 bit Internet address of the reference server Reference Timestamp sys reftime peer reftime pkt reftime This is the local time in timestamp format when the logical clock was last updated If the logical clock has never been synchronized the value is zero 3 2 2 System Variables

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


  • gateways connecting the networks If the networks are not adjacent the message may pass through several intervening networks and the gateways connecting them Once the message gets to a gateway that is on the same network as the destination that network s own technology is used to get to the destination Throughout this section the term network is used generically to cover a single broadcast network e g an Ethernet a point to point line or the ARPANET The critical point is that a network is treated as a single entity by IP Either no routing is necessary as with a point to point line or that routing is done in a manner that is transparent to IP allowing IP to treat the entire network as a single fully connected system as with an Ethernet or the ARPANET Note that the term network is used in a somewhat different way in discussions of IP addressing A single IP network number may be assigned to a collection of networks with subnet addressing being used to describe the individual networks In effect we are using the term network here to refer to subnets in cases where subnet addressing is in use A number of different approaches for finding routes between networks are possible One useful way of categorizing these approaches is on the basis of the type of information the gateways need to exchange in order to be able to find routes Distance vector algorithms are based on the exchange of only a small amount of information Each Hedrick Page 5 RFC 1058 Routing Information Protocol June 1988 entity gateway or host that participates in the routing protocol is assumed to keep information about all of the destinations within the system Generally information about all entities connected to one network is summarized by a single entry which describes the route to all destinations on that network This summarization is possible because as far as IP is concerned routing within a network is invisible Each entry in this routing database includes the next gateway to which datagrams destined for the entity should be sent In addition it includes a metric measuring the total distance to the entity Distance is a somewhat generalized concept which may cover the time delay in getting messages to the entity the dollar cost of sending messages to it etc Distance vector algorithms get their name from the fact that it is possible to compute optimal routes when the only information exchanged is the list of these distances Furthermore information is only exchanged among entities that are adjacent that is entities that share a common network Although routing is most commonly based on information about networks it is sometimes necessary to keep track of the routes to individual hosts The RIP protocol makes no formal distinction between networks and hosts It simply describes exchange of information about destinations which may be either networks or hosts Note however that it is possible for an implementor to choose not to support host routes See section 3 2 In fact the mathematical developments are most conveniently thought of in terms of routes from one host or gateway to another When discussing the algorithm in abstract terms it is best to think of a routing entry for a network as an abbreviation for routing entries for all of the entities connected to that network This sort of abbreviation makes sense only because we think of networks as having no internal structure that is visible at the IP level Thus we will generally assign the same distance to every entity in a given network We said above that each entity keeps a routing database with one entry for every possible destination in the system An actual implementation is likely to need to keep the following information about each destination address in IP implementations of these algorithms this will be the IP address of the host or network gateway the first gateway along the route to the destination interface the physical network which must be used to reach the first gateway metric a number indicating the distance to the Hedrick Page 6 RFC 1058 Routing Information Protocol June 1988 destination timer the amount of time since the entry was last updated In addition various flags and other internal information will probably be included This database is initialized with a description of the entities that are directly connected to the system It is updated according to information received in messages from neighboring gateways The most important information exchanged by the hosts and gateways is that carried in update messages Each entity that participates in the routing scheme sends update messages that describe the routing database as it currently exists in that entity It is possible to maintain optimal routes for the entire system by using only information obtained from neighboring entities The algorithm used for that will be described in the next section As we mentioned above the purpose of routing is to find a way to get datagrams to their ultimate destinations Distance vector algorithms are based on a table giving the best route to every destination in the system Of course in order to define which route is best we have to have some way of measuring goodness This is referred to as the metric In simple networks it is common to use a metric that simply counts how many gateways a message must go through In more complex networks a metric is chosen to represent the total amount of delay that the message suffers the cost of sending it or some other quantity which may be minimized The main requirement is that it must be possible to represent the metric as a sum of costs for individual hops Formally if it is possible to get from entity i to entity j directly i e without passing through another gateway between then a cost d i j is associated with the hop between i and j In the normal case where all entities on a given network are considered to be the same d i j is the same for all destinations on a given network and represents the cost of using that network To get the metric of a complete route one just adds up the costs of the individual hops that make up the route For the purposes of this memo we assume that the costs are positive integers Let D i j represent the metric of the best route from entity i to entity j It should be defined for every pair of entities d i j represents the costs of the individual steps Formally let d i j represent the cost of going directly from entity i to entity j It is infinite if i and j are not immediate neighbors Note that d i i Hedrick Page 7 RFC 1058 Routing Information Protocol June 1988 is infinite That is we don t consider there to be a direct connection from a node to itself Since costs are additive it is easy to show that the best metric must be described by D i i 0 all i D i j min d i k D k j otherwise k and that the best routes start by going from i to those neighbors k for which d i k D k j has the minimum value These things can be shown by induction on the number of steps in the routes Note that we can limit the second equation to k s that are immediate neighbors of i For the others d i k is infinite so the term involving them can never be the minimum It turns out that one can compute the metric by a simple algorithm based on this Entity i gets its neighbors k to send it their estimates of their distances to the destination j When i gets the estimates from k it adds d i k to each of the numbers This is simply the cost of traversing the network between i and k Now and then i compares the values from all of its neighbors and picks the smallest A proof is given in 2 that this algorithm will converge to the correct estimates of D i j in finite time in the absence of topology changes The authors make very few assumptions about the order in which the entities send each other their information or when the min is recomputed Basically entities just can t stop sending updates or recomputing metrics and the networks can t delay messages forever Crash of a routing entity is a topology change Also their proof does not make any assumptions about the initial estimates of D i j except that they must be non negative The fact that these fairly weak assumptions are good enough is important Because we don t have to make assumptions about when updates are sent it is safe to run the algorithm asynchronously That is each entity can send updates according to its own clock Updates can be dropped by the network as long as they don t all get dropped Because we don t have to make assumptions about the starting condition the algorithm can handle changes When the system changes the routing algorithm starts moving to a new equilibrium using the old one as its starting point It is important that the algorithm will converge in finite time no matter what the starting point Otherwise certain kinds of changes might lead to non convergent behavior The statement of the algorithm given above and the proof assumes that each entity keeps copies of the estimates that come from each of its neighbors and now and then does a min over all of the neighbors In fact real implementations don t necessarily do that They simply Hedrick Page 8 RFC 1058 Routing Information Protocol June 1988 remember the best metric seen so far and the identity of the neighbor that sent it They replace this information whenever they see a better smaller metric This allows them to compute the minimum incrementally without having to store data from all of the neighbors There is one other difference between the algorithm as described in texts and those used in real protocols such as RIP the description above would have each entity include an entry for itself showing a distance of zero In fact this is not generally done Recall that all entities on a network are normally summarized by a single entry for the network Consider the situation of a host or gateway G that is connected to network A C represents the cost of using network A usually a metric of one Recall that we are assuming that the internal structure of a network is not visible to IP and thus the cost of going between any two entities on it is the same In principle G should get a message from every other entity H on network A showing a cost of 0 to get from that entity to itself G would then compute C 0 as the distance to H Rather than having G look at all of these identical messages it simply starts out by making an entry for network A in its table and assigning it a metric of C This entry for network A should be thought of as summarizing the entries for all other entities on network A The only entity on A that can t be summarized by that common entry is G itself since the cost of going from G to G is 0 not C But since we never need those 0 entries we can safely get along with just the single entry for network A Note one other implication of this strategy because we don t need to use the 0 entries for anything hosts that do not function as gateways don t need to send any update messages Clearly hosts that don t function as gateways i e hosts that are connected to only one network can have no useful information to contribute other than their own entry D i i 0 As they have only the one interface it is easy to see that a route to any other network through them will simply go in that interface and then come right back out it Thus the cost of such a route will be greater than the best cost by at least C Since we don t need the 0 entries non gateways need not participate in the routing protocol at all Let us summarize what a host or gateway G does For each destination in the system G will keep a current estimate of the metric for that destination i e the total cost of getting to it and the identity of the neighboring gateway on whose data that metric is based If the destination is on a network that is directly connected to G then G simply uses an entry that shows the cost of using the network and the fact that no gateway is needed to get to the destination It is easy to show that once the computation has converged to the correct metrics the neighbor that is recorded by this technique is in fact the first gateway on the path to the destination If there are Hedrick Page 9 RFC 1058 Routing Information Protocol June 1988 several equally good paths it is the first gateway on one of them This combination of destination metric and gateway is typically referred to as a route to the destination with that metric using that gateway The method so far only has a way to lower the metric as the existing metric is kept until a smaller one shows up It is possible that the initial estimate might be too low Thus there must be a way to increase the metric It turns out to be sufficient to use the following rule suppose the current route to a destination has metric D and uses gateway G If a new set of information arrived from some source other than G only update the route if the new metric is better than D But if a new set of information arrives from G itself always update D to the new value It is easy to show that with this rule the incremental update process produces the same routes as a calculation that remembers the latest information from all the neighbors and does an explicit minimum Note that the discussion so far assumes that the network configuration is static It does not allow for the possibility that a system might fail To summarize here is the basic distance vector algorithm as it has been developed so far Note that this is not a statement of the RIP protocol There are several refinements still to be added The following procedure is carried out by every entity that participates in the routing protocol This must include all of the gateways in the system Hosts that are not gateways may participate as well Keep a table with an entry for every possible destination in the system The entry contains the distance D to the destination and the first gateway G on the route to that network Conceptually there should be an entry for the entity itself with metric 0 but this is not actually included Periodically send a routing update to every neighbor The update is a set of messages that contain all of the information from the routing table It contains an entry for each destination with the distance shown to that destination When a routing update arrives from a neighbor G add the cost associated with the network that is shared with G This should be the network over which the update arrived Call the resulting distance D Compare the resulting distances with the current routing table entries If the new distance D for N is smaller than the existing value D adopt the new route That is change the table entry for N to have metric D and gateway G If G is the gateway Hedrick Page 10 RFC 1058 Routing Information Protocol June 1988 from which the existing route came i e G G then use the new metric even if it is larger than the old one 2 1 Dealing with changes in topology The discussion above assumes that the topology of the network is fixed In practice gateways and lines often fail and come back up To handle this possibility we need to modify the algorithm slightly The theoretical version of the algorithm involved a minimum over all immediate neighbors If the topology changes the set of neighbors changes Therefore the next time the calculation is done the change will be reflected However as mentioned above actual implementations use an incremental version of the minimization Only the best route to any given destination is remembered If the gateway involved in that route should crash or the network connection to it break the calculation might never reflect the change The algorithm as shown so far depends upon a gateway notifying its neighbors if its metrics change If the gateway crashes then it has no way of notifying neighbors of a change In order to handle problems of this kind distance vector protocols must make some provision for timing out routes The details depend upon the specific protocol As an example in RIP every gateway that participates in routing sends an update message to all its neighbors once every 30 seconds Suppose the current route for network N uses gateway G If we don t hear from G for 180 seconds we can assume that either the gateway has crashed or the network connecting us to it has become unusable Thus we mark the route as invalid When we hear from another neighbor that has a valid route to N the valid route will replace the invalid one Note that we wait for 180 seconds before timing out a route even

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



  •