Default IP MTU for use over ATM AAL5
obsoleted by
- rfc-2225 — Classical IP and ARP over ATM
Extracted elements (17)
Path MTU Discovery is considered particularly important for ATM because ATM's default MTU differs significantly from older subnet technologies such as Ethernet and FDDI, making it essential for routers and hosts to avoid unnecessary fragmentation across heterogeneous networks.
The 9180-octet MTU was chosen to accommodate NFS (which uses 8 KB frames plus RPC/XDR/UDP/IP/LLC headers requiring at least 8300 octets), to benefit router performance (costs are per-packet not per-byte), and because empirical evidence shows larger MTUs improve TCP performance. Fragmentation is known to be highly undesirable.
The default IP MTU for ATM AAL5 was set to 9180 octets to match RFC 1209's MTU for IP over SMDS, since there is no good reason for them to differ given similar magnitudes; alignment reduces fragmentation and aids interoperability between the two technologies.
This specification is compatible with RFC 1483 (Multiprotocol Encapsulation over ATM AAL5) and RFC 1577 (Classical IP and ARP over ATM), and may be used as a conforming extension to RFC 1577. Its applicability is not limited to the Classical IP over ATM model.
All router implementations compliant with this specification must implement the IP Path MTU Discovery mechanism as defined in RFC-1191 and clarified by RFC-1435. Host implementations should also implement Path MTU Discovery.
If either endpoint receives a STATUS message with cause 'Information Element Non-existent or Not Implemented' or 'Access Information Discarded' and diagnostic indicating the AAL Parameters IE, it shall clear the call with cause 'AAL Parameters cannot be supported'.
If either endpoint receives CPCS-SDUs exceeding the negotiated MTU size, it may use IP fragmentation or may clear the call with cause 'AAL Parameters cannot be supported'; the error should be noted by ATM network management.
If the called endpoint incorrectly includes Forward and Backward Maximum CPCS-SDU Size fields in the CONNECT message or sets them to invalid values, the calling party shall clear the call with cause 'Invalid Information Element Contents'.
If the called party accepts the proposed ATM MTU values from the SETUP message, it shall include an AAL Parameters IE in its CONNECT response with Forward and Backwards Maximum CPCS-SDU Size fields equal to the corresponding SETUP values.
If the called party wishes a smaller ATM MTU than proposed, it shall set the Maximum CPCS-SDU Size in the AAL Parameters IE of its CONNECT response to the desired smaller value.
If the calling endpoint receives a CONNECT message without the AAL Parameters IE, but its SETUP message included that IE with CPCS-SDU Size fields, it shall clear the call with cause 'AAL Parameters cannot be supported'.
If the calling party wishes to use the default MTU, it shall still include the 'AAL Parameters' IE with default Maximum CPCS-SDU Size values in the SETUP message; if a non-default value is desired, it shall include the desired value instead.
PVC-only implementations shall use the default IP MTU of 9180 octets unless both parties have agreed in advance to use some other value via an unspecified out-of-band mechanism.
SVC implementations MUST attempt to negotiate the AAL CPCS-SDU size using the ATM signalling protocol, including the 'AAL Parameters' Information Element in SETUP messages.
The default IP MTU for use with ATM AAL5 shall be 9180 octets. All compliant implementations must support at least this default IP MTU value.
Security issues are not discussed in this memo.
The ATM 'AAL Parameters' Information Element contains two fields for MTU negotiation: Forward Maximum CPCS-SDU Size (calling to called party path) and Backwards Maximum CPCS-SDU Size Identifier (called to calling party path). Valid values are 1 to 65535 inclusive, and the two directions may differ.