doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc1626.txt b/doc/rfc/rfc1626.txt
new file mode 100644
index 0000000..73fff8b
--- /dev/null
+++ b/doc/rfc/rfc1626.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                        R. Atkinson
+Request for Comments: 1626                     Naval Research Laboratory
+Category: Standards Track                                       May 1994
+
+
+                  Default IP MTU for use over ATM AAL5
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Default Value for IP MTU over ATM AAL5
+
+   Protocols in wide use throughout the Internet, such as the Network
+   File System (NFS), currently use large frame sizes (e.g. 8 KB).
+   Empirical evidence with various applications over the Transmission
+   Control Protocol (TCP) indicates that larger Maximum Transmission
+   Unit (MTU) sizes for the Internet Protocol (IP) tend to give better
+   performance.  Fragmentation of IP datagrams is known to be highly
+   undesirable. [KM87] It is desirable to reduce fragmentation in the
+   network and thereby enhance performance by having the IP Maximum
+   Transmission Unit (MTU) for AAL5 be reasonably large.  NFS defaults
+   to an 8192 byte frame size.  Allowing for RPC/XDR, UDP, IP, and LLC
+   headers, NFS would prefer a default MTU of at least 8300 octets.
+   Routers can sometimes perform better with larger packet sizes because
+   most of the performance costs in routers relate to "packets handled"
+   rather than "bytes transferred".  So there are a number of good
+   reasons to have a reasonably large default MTU value for IP over ATM
+   AAL5.
+
+   RFC 1209 specifies the IP MTU over SMDS to be 9180 octets, which is
+   larger than 8300 octets but still in the same range. [RFC-1209] There
+   is no good reason for the default MTU of IP over ATM AAL5 to be
+   different from IP over SMDS, given that they will be the same
+   magnitude.  Having the two be the same size will be helpful in
+   interoperability and will also help reduce incidence of IP
+   fragmentation.
+
+   Therefore, the default IP MTU for use with ATM AAL5 shall be 9180
+   octets.  All implementations compliant and conformant with this
+   specification shall support at least the default IP MTU value for use
+   over ATM AAL5.
+
+
+
+
+
+Atkinson                                                        [Page 1]
+
+RFC 1626          Default IP MTU for use over ATM AAL5          May 1994
+
+
+Permanent Virtual Circuits
+
+   Implementations which only support Permanent Virtual Circuits (PVCs)
+   will (by definition) not implement any ATM signalling protocol.  Such
+   implementations shall use the default IP MTU value of 9180 octets
+   unless both parties have agreed in advance to use some other IP MTU
+   value via some mechanism not specified here.
+
+Switched Virtual Circuits
+
+   Implementations that support Switched Virtual Circuits (SVCs) MUST
+   attempt to negotiate the AAL CPCS-SDU size using the ATM signalling
+   protocol.  The industry standard ATM signalling protocol uses two
+   different parts of the Information Element named "AAL Parameters" to
+   exchange information on the MTU over the ATM circuit being setup
+   [ATMF93a].  The Forward Maximum CPCS-SDU Size field contains the
+   value over the path from the calling party to the called party.  The
+   Backwards Maximum CPCS-SDU Size Identifier field contains the value
+   over the path from the called party to the calling party.  The ATM
+   Forum specifies the valid values of this identifier as 1 to 65535
+   inclusive.  Note that the ATM Forum's User-to-Network-Interface (UNI)
+   signalling permits the MTU in one direction to be different from the
+   MTU in the opposite direction, so the Forward Maximum CPCS-SDU Size
+   Identifier might have a different value from the Backwards Maximum
+   CPCS-SDU Size Identifier on the same connection.
+
+   If the calling party wishes to use the default MTU it shall still
+   include the "AAL Parameters" information element with the default
+   values for the Maximum CPCS-SDU Size as part of the SETUP message of
+   the ATM signalling protocol [ATMF93b].  If the calling party desires
+   to use a different value than the default, it shall include the "AAL
+   Parameters" information element with the desired value for the
+   Maximum CPCS-SDU Size as part of the SETUP message of the ATM
+   Signalling Protocol.  The called party will respond using the same
+   information elements and identifiers in its CONNECT message response
+   [ATMF93c].
+
+   If the called party receives a SETUP message containing the "Maximum
+   CPCS-SDU Size" in the AAL Parameters information element, it shall
+   handle the Forward and Backward Maximum CPCS-SDU Size Identifier as
+   follows:
+
+    a) If it is able to accept the ATM MTU values proposed by the
+       SETUP message, it shall include an AAL Parameters information
+       element in its response.  The Forward and Backwards Maximum
+       CPCS-SDU Size fields shall be present and their values shall be
+       equal to the corresponding values in the SETUP message.
+
+
+
+
+Atkinson                                                        [Page 2]
+
+RFC 1626          Default IP MTU for use over ATM AAL5          May 1994
+
+
+    b) If it wishes a smaller ATM MTU size than that proposed, then
+       it shall set the values of the Maximum CPCS-SDU Size in the AAL
+       Parameters information elements equal to the desired value in the
+       CONNECT message responding to the original SETUP message.
+
+    c) If the calling endpoint receives a CONNECT message that does
+       not contain the AAL Parameters Information Element, but the
+       corresponding SETUP message did contain the AAL Parameters
+       Information Telement (including the forward and backward CPCS-SDU
+       Size fields), it shall clear the call with cause "AAL Parameters
+       cannot be supported".
+
+    d) If either endpoint receives a STATUS message with cause
+       "Information Element Non-existent or Not Implemented" or cause
+       ""Access Information Discarded", and with a diagnostic field
+       indicating the AAL Parameters Information Element identifier, it
+       shall clear the call with cause "AAL Parameters cannot be
+       supported."
+
+    e) If either endpoint receives CPCS-SDUs in excess of the
+       negotiated MTU size, it may use IP fragmentation or may clear the
+       call with cause "AAL Parameters cannot be supported".  In this
+       case, an error has occurred either due to a fault in an end
+       system or in the ATM network.  The error should be noted by ATM
+       network management for human examination and intervention.
+
+   If the called endpoint incorrectly includes the Forward and Backward
+   Maximum CPCS-SDU Size fields in the CONNECT messages (e.g.  because
+   the original SETUP message did not include these fields) or it sets
+   these fields to an invalid value, then the calling party shall clear
+   the call with cause "Invalid Information Element Contents".
+
+Path MTU Discovery Required
+
+   The Path MTU Discovery mechanism is an Internet Standard [RFC-1191]
+   and is an important mechanism for reducing IP fragmentation in the
+   Internet.  This mechanism is particularly important because new
+   subnet ATM uses a default MTU sizes significantly different from
+   older subnet technologies such as Ethernet and FDDI.
+
+   In order to ensure good performance throughout the Internet and also
+   to permit IP to take full advantage of the potentially larger IP
+   datagram sizes supported by ATM, all routers implementations that
+   comply or conform with this specification must also implement the IP
+   Path MTU Discovery mechanism as defined in RFC-1191 and clarified by
+   RFC-1435.  Host implementations should implement the IP Path MTU
+   Discovery mechanism as defined in RFC-1191.
+
+
+
+
+Atkinson                                                        [Page 3]
+
+RFC 1626          Default IP MTU for use over ATM AAL5          May 1994
+
+
+Applicability Statement
+
+   The Multiprotocol Encapsulation over ATM AAL5 defined in RFC-1483 is
+   not specific to any model of IP and ATM interaction. [RFC-1483]
+   Similarly, this specification is general enough to apply to all
+   models for use of IP over ATM AAL5.  Use of this specification is
+   recommended for all implementatons of IP over ATM AAL5 in order to
+   increase interoperability and performance.  This specification does
+   not conflict with the Classical IP over ATM specification and may be
+   used as a conforming extension to that specification.  [RFC-1577]
+   Applicability of this draft is not limited to the Classical IP over
+   ATM model.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+References
+
+   [RFC-791] Postel, J., "Internet Protocol - DARPA Internet Program
+   Protocol Specification", STD 5, RFC 791, DARPA, September
+   1981.
+
+   [RFC-793] Postel, J., "Transmission Control Protocol - DARPA
+   Internet Program Protocol Specification", STD 7, RFC 793,
+   DARPA, September 1981.
+
+   [RFC-1122] Braden, R., Editor, Requirements for Internet Hosts --
+   Communications Layers, STD 3, RFC 1122, USC/Information Sciences
+   Institute, October 1989, pp.58-60.
+
+   [RFC-1191] Mogul, J., and S. Deering, "Path MTU Discovery",
+   RFC 1191, DECWRL, Stanford University, November 1990.
+
+   [RFC-1209] Piscitello, D., and J. Lawrence, "The Transmission of
+   IP Datagrams over the SMDS Service", RFC 1209, Bell Communications
+   Research, March 1991.
+
+   [RFC-1435] Knowles, S., "IESG Advice from Experience with Path MTU
+   Discovery, RFC-1435, IESG, March 1993.
+
+   [RFC-1483] Heinanen, J., "Multiprotocol Encapsulation over ATM
+   Adapatation Layer 5", RFC 1483, Telecom Finland, July 1993.
+
+   [RFC-1577] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
+   Hewlett-Packard Laboratories, January 1994.
+
+
+
+
+
+Atkinson                                                        [Page 4]
+
+RFC 1626          Default IP MTU for use over ATM AAL5          May 1994
+
+
+   [ATMF93a] Breault, R., Grace, J., Jaeger, J., and L. Wojnaroski,
+   Editors, "ATM Forum User Network Interface Specification", Version
+   3.0, Section 5.4.5.5, p. 194-200, 10 September 1993, ATM Forum.
+
+   [ATMF93b] Breault, R., Grace, J., Jaeger, J., and L. Wojnaroski,
+   Editors, "ATM Forum User Network Interface Specification", Version
+   3.0, Section 5.3.1.7, p. 171-172, 10 September 1993, ATM Forum.
+
+   [ATMF93c] Breault, R., Grace, J., Jaeger, J., and L. Wojnaroski,
+   Editors, "ATM Forum User Network Interface Specification", Version
+   3.0, Section 5.3.1.3, p. 168, 10 September 1993, ATM Forum.
+
+   [KM87] Kent C., and J. Mogul, "Fragmentation Considered Harmful",
+   Proceedings of the ACM SIGCOMM '87 Workshop on Frontiers in
+   Computer Communications Technology, August 1987.
+
+Acknowledgements
+
+   While all members of the IETF's IP over ATM Working Group have been
+   helpful, Vern Schryver, Rob Warnock, Craig Partridge, Subbu
+   Subramaniam, and Bryan Lyles have been especially helpful to the
+   author in analysing the host and routing implications of the default
+   IP MTU value.  Similarly, Dan Grossman provided significant review
+   and help in ensuring alignment of this text with the related work in
+   the ATM Forum and ITU.
+
+Disclaimer
+
+   Author's organisation provided for identification purposes only.
+   This document presents the author's views and is not necessarily the
+   official opinion of his employer.
+
+Author's Address
+
+   Randall J. Atkinson
+   Information Technology Division
+   Naval Research Laboratory
+   Washington, DC 20375-5320
+   USA
+
+   EMail: atkinson@itd.nrl.navy.mil
+
+
+
+
+
+
+
+
+
+
+Atkinson                                                        [Page 5]
+