📄 rfc979.txt
字号:
RFC 979 March 1986PSN End-to-End Functional Specification o The new EE supports congestion control and improved resource allocation policies which ensure fairness and graceful degradation of service under extreme load. Certain resources can be prereserved to each host port, and each port can also be limited in its use of shared resources. This ensures that no host can be totally shut out from PSN resources by the actions of other hosts at the same PSN. In addition, each PSN is sensitive to congestion in both of the PSNs at the endpoints of each connection, and it can exert backpressure (flow control) on hosts, as necessary, to prevent congestion. 3.1.2 X.25 The new EE's X.25 service represents an improvement over the X.25 service available from the old EE. The following paragraphs summarize the X.25 support in the new EE: o The new EE provides both DDN Standard and Basic X.25 service, as described in BBN Reports 5476, "DDN X.25 Host Interface Specification," and 5500, "C/30 PSN X.25 Interface Specification," respectively. In addition, the description of DDN Standard Service, Version 2, is found in Section 3.1.4 of this document. o All data packets and call requests are source-buffered in the source PSN to provide a better level of reliability for network traffic. This should keep the network from issuing a reset on an open connection as a result of a lost packet in the subnet or any other occasional subnetwork failure. Except in cases of extreme network or node congestion, recovery from lost subnet packets is automatic and transparent to the end user or host. o Both local and end-to-end significance for host window advancement (based upon the D bit from the host) are planned, but only end-to-end significance is included in the initial release (the old EE did not include local significance). The D bit is passed through the network transparently. 3.1.3 AHIP Another service provided by the new EE is defined in BBN Report 1822, "Specifications for the Interconnection of a Host and an IMP", as amended by Report 5506, "The ARPANET 1822L Host Access Protocol". This ARPANET Host-IMP Protocol (AHIP) service isMalis [Page 6] RFC 979 March 1986PSN End-to-End Functional Specification supported in a backwards-compatible manner by the new EE; since this is a BBNCC-private protocol, the new EE can improve the service to better match its current uses (the AHIP protocol was first designed over twelve years ago). The main changes to AHIP are to remove the absolute eight-message-in-flight restriction for connection-based traffic, and to improve the PSN's "datagram" support for non-connection-based traffic. For this new support, datagram service is planned (for PSN Release 8.0) to include fragmentation and reassembly by the network, but without requiring the network overhead used by connections, and without the reliability, message sequencing, and duplicate detection that connections provide. However, "destination dead" indications will be provided to the source host where possible and appropriate. With the new EE, hosts are also able to create multiple connections between host pairs by using the 8-bit "handling type" field to specify up to 256 different connections. The field is divided into high-order bits that specify the connection's precedence, and low-order bits that distinguish between multiple connections at the same precedence level. Since the new EE is using four precedence levels, the handling type field is used to specify 64 different connections at each of the four precedence levels. AHIP connections will continue to be implicitly created and automatically torn down after a configurable period (nominally three minutes) of inactivity, or because of connection block contention. To summarize the new end-to-end's AHIP support: o The old EE's AHIP services are supported in a backwards-compatible manner (except where listed below). o The old EE's uncontrolled (subtype 3) message service will be replaced, in PSN Release 8.0, by the datagram service mentioned above. This service will provide fragmentation and reassembly, so that there is no special restriction on the size of datagrams; will not insure that messages are delivered in order or unduplicated, or provide a delivery confirmation; will notify the source host if the destination host or PSN is dead; will not require the connection block overhead associated with connections; and may lose messages in the subnet, without notification to the source host, in the event of subnetMalis [Page 7] RFC 979 March 1986PSN End-to-End Functional Specification congestion or component failures. This service could be useful for applications that do not need the absolute reliability or sequentiality of connections and therefore wish to avoid their associated overhead. Datagrams are not supported by the new EE in PSN Release 7.0. o Connections no longer have the old EE's "eight messages in flight" restriction, and a pair of hosts can be connected with up to 256 simultaneous implicit connections. In addition, multiple precedence levels are supported. o The new EE supports interoperability between AHIP and X.25 hosts (see Section 3.1.4 for further details). o AHIP local, distant, and HDH (both message and packet mode) hosts are supported. The new EE does not support VDH hosts. VHA and 32-bit leaders are supported. o Packet-mode HDH has been extended to allow longer packet data frames (see BBN Report 1822, Appendix J, for a description of the HDH protocol). Middle packet frames can now contain up to 128 octets of data, rather than the previous 126 (although there must still be an even number of octets per frame). Last packet frames can now contain up to 127 octets of data, rather than the previous 125, and the number of octets need not be even. However, the maximum total message size is still 1007 data octets. The PSN uses these new packet frame size limits when sending packet frames to packet-mode HDH hosts unless the host is configured to allow only 126-octet frames. In addition, there are restrictions on packet-mode HDH when interoperating with DDN Standard X.25 hosts; these restrictions are discussed in Section 3.1.4. 3.1.4 Interoperability (DDN Standard X.25) One of the main goals of the new EE is to provide interoperability between AHIP and X.25 hosts. On the surface, this may appear difficult, since the two host access protocols have little in common: X.25 presents a connection-oriented interface with explicit windowing, while AHIP presents a reliable datagram-oriented interface with implicit flow control. However, they both have the same underlyingMalis [Page 8] RFC 979 March 1986PSN End-to-End Functional Specification functionality: they allow the hosts to submit and receive messages, and they both provide a reliable and sequenced delivery service. The key to interoperability is the fact that in the new EE, both X.25 and AHIP connections use the same underlying protocols and constructs. The new EE has AHIP and X.25 Level 3 modules that translate between the specific host protocols and the EE mechanisms. Since these Level 3 host modules share a common interface with the EE, the fact that the two hosts on either side of an EE connection are not using the same access protocol is largely hidden. As a result, the new EE supports basic interoperability. However, there are some special cases that need to be mapped from one protocol to the other, or just not supported because no mapping exists. For example, AHIP has no analogue of X.25's Interrupt packet, while X.25 does not support an unreliable datagram service such as AHIP's subtype 3 messages. For each of these cases, the recommendations of BBN Report 5476, "DDN X.25 Host Interface Specification," have been followed. The interoperable service provided by the new EE is called DDN Standard Service, Version 2. Standard Service, Version 1, is defined in BBN Reports 5760, "Preliminary Interoperable Software Design," and 5900 Revision 1, "Supplement to BBN Report Nos. 5476 and 5760". The major differences between Versions 1 and 2 are: o Version 2 offers improved performance over Version 1. o The EE now provides four precedence levels. Therefore, the four precedence levels allowed in the DDN-private Call Precedence Negotiation are mapped directly to subnet precedence levels, instead of being collapsed into two subnet precedence levels as in Version 1. o On an interoperable connection, the X.25 protocol ID in an X.25-originated message is translated to an AHIP link number (the upper eight bits of the message-ID field) using a lookup table. Version 1 supports only the IP protocol ID and corresponding link number of 155 (decimal). Version 2 allows new values to be added to the lookup table. At present, IP is the only protocol supported. In addition, the AHIP link number is also used to distinguish one connection from another. ThisMalis [Page 9] RFC 979 March 1986PSN End-to-End Functional Specification guarantees that when an AHIP host is sending messages to an X.25 host, messages using different link numbers come into the X.25 host on different X.25 connections. o Since a "translation module" is no longer necessary in the PSN, interoperable connections now have end-to-end significance, with a direct correspondence between X.25 RRs and AHIP RFNMs. This preserves the meaning of the RFNM as defined in Report 1822. Although Release 7.0 only offers end-to-end significance, the D bit is passed transparently on Standard Service connections between two X.25 hosts. o Up to 256 simultaneous connections are supported between host pairs that are using the same addresses and precedence levels. Version 1 only supported one such connection. The following Version 1 services are not offered by Version 2: o Permanent Virtual Circuits. o X.25 protocol bypass (a BBN-private service). A number of items in Report 5760 were the subject of some discussion, and three of them need to be specifically mentioned here. First, for DDN Standard Service, Version 1, acknowledgments have local significance only, and the D bit must be set to 0 in the call request. In DDN Standard Service, Version 2, only end-to-end significance is being provided, as was mentioned above. For backwards compatibility with Version 1, the D bit can be set to 0 or 1 in a call, but hosts are advised that only end-to-end significance is provided in Version 2. Second, non-standard Default Precedence is not supported by either Standard Service Version 1 or Version 2. Support for this facility in Version 1 was withdrawn at the request of DCA. Third, although DTEs are allowed to request maximum packet sizes of 16, 32, and 64 octets, the DCE always negotiates up to 128 octets, as per Section 6.12 ("Flow Control Parameter Negotiation") of the CCITT 1984 X.25 Recommendation. This is true of both Version 1 and Version 2. Since IP and TCP are required when Standard Service is in use, this is a reasonable restriction (due to the length of IP and TCP headers).Malis [Page 10] ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -