As per Relevance of the word specific, we have this rfc below:
Network Working Group R.
Request for Comments: 1626 Naval Research
Category: Standards Track May 1994
Default IP MTU for use over ATM AAL
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Default Value for IP MTU over ATM AAL
Protocols in wide use throughout the Internet, such as the
File System (NFS), currently use large frame sizes (e.g. 8 KB).
Empirical evidence with various applications over the
Control Protocol (TCP) indicates that larger Maximum
Unit (MTU) sizes for the Internet Protocol (IP) tend to give
performance. Fragmentation of IP datagrams is known to be
undesirable. [KM87] It is desirable to reduce fragmentation in
network and thereby enhance performance by having the IP
Transmission Unit (MTU) for AAL5 be reasonably large. NFS
to an 8192 byte frame size. Allowing for RPC/XDR, UDP, IP, and
headers, NFS would prefer a default MTU of at least 8300 octets
Routers can sometimes perform better with larger packet sizes
most of the performance costs in routers relate to "packets handled
rather than "bytes transferred". So there are a number of
reasons to have a reasonably large default MTU value for IP over
AAL5.
RFC 1209 specifies the IP MTU over SMDS to be 9180 octets, which
larger than 8300 octets but still in the same range. [RFC-1209]
is no good reason for the default MTU of IP over ATM AAL5 to
different from IP over SMDS, given that they will be the
magnitude. Having the two be the same size will be helpful
interoperability and will also help reduce incidence of
fragmentation
Therefore, the default IP MTU for use with ATM AAL5 shall be 9180
octets. All implementations compliant and conformant with
specification shall support at least the default IP MTU value for
over ATM AAL5.
Atkinson [Page 1]
RFC 1626 Default IP MTU for use over ATM AAL5 May 1994
Permanent Virtual
Implementations which only support Permanent Virtual Circuits (PVCs
will (by definition) not implement any ATM signalling protocol.
implementations shall use the default IP MTU value of 9180
unless both parties have agreed in advance to use some other IP
value via some mechanism not specified here
Switched Virtual
Implementations that support Switched Virtual Circuits (SVCs)
attempt to negotiate the AAL CPCS-SDU size using the ATM
protocol. The industry standard ATM signalling protocol uses
different parts of the Information Element named "AAL Parameters"
exchange information on the MTU over the ATM circuit being
[ATMF93a]. The Forward Maximum CPCS-SDU Size field contains
value over the path from the calling party to the called party.
Backwards Maximum CPCS-SDU Size Identifier field contains the
over the path from the called party to the calling party. The
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
MTU in the opposite direction, so the Forward Maximum CPCS-SDU
Identifier might have a different value from the Backwards
CPCS-SDU Size Identifier on the same connection
If the calling party wishes to use the default MTU it shall
include the "AAL Parameters" information element with the
values for the Maximum CPCS-SDU Size as part of the SETUP message
the ATM signalling protocol [ATMF93b]. If the calling party
to use a different value than the default, it shall include the "
Parameters" information element with the desired value for
Maximum CPCS-SDU Size as part of the SETUP message of the
Signalling Protocol. The called party will respond using the
information elements and identifiers in its CONNECT message
[ATMF93c].
If the called party receives a SETUP message containing the "
CPCS-SDU Size" in the AAL Parameters information element, it
handle the Forward and Backward Maximum CPCS-SDU Size Identifier
follows
a) If it is able to accept the ATM MTU values proposed by
SETUP message, it shall include an AAL Parameters
element in its response. The Forward and Backwards
CPCS-SDU Size fields shall be present and their values shall
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,
it shall set the values of the Maximum CPCS-SDU Size in the
Parameters information elements equal to the desired value in
CONNECT message responding to the original SETUP message
c) If the calling endpoint receives a CONNECT message that
not contain the AAL Parameters Information Element, but
corresponding SETUP message did contain the AAL
Information Telement (including the forward and backward CPCS-
Size fields), it shall clear the call with cause "AAL
cannot be supported".
d) If either endpoint receives a STATUS message with
"Information Element Non-existent or Not Implemented" or
""Access Information Discarded", and with a diagnostic
indicating the AAL Parameters Information Element identifier,
shall clear the call with cause "AAL Parameters cannot
supported."
e) If either endpoint receives CPCS-SDUs in excess of
negotiated MTU size, it may use IP fragmentation or may clear
call with cause "AAL Parameters cannot be supported". In
case, an error has occurred either due to a fault in an
system or in the ATM network. The error should be noted by
network management for human examination and intervention
If the called endpoint incorrectly includes the Forward and
Maximum CPCS-SDU Size fields in the CONNECT messages (e.g.
the original SETUP message did not include these fields) or it
these fields to an invalid value, then the calling party shall
the call with cause "Invalid Information Element Contents".
Path MTU Discovery
The Path MTU Discovery mechanism is an Internet Standard [RFC-1191]
and is an important mechanism for reducing IP fragmentation in
Internet. This mechanism is particularly important because
subnet ATM uses a default MTU sizes significantly different
older subnet technologies such as Ethernet and FDDI
In order to ensure good performance throughout the Internet and
to permit IP to take full advantage of the potentially larger
datagram sizes supported by ATM, all routers implementations
comply or conform with this specification must also implement the
Path MTU Discovery mechanism as defined in RFC-1191 and clarified
RFC-1435. Host implementations should implement the IP Path
Discovery mechanism as defined in RFC-1191.
Atkinson [Page 3]
RFC 1626 Default IP MTU for use over ATM AAL5 May 1994
Applicability
The Multiprotocol Encapsulation over ATM AAL5 defined in RFC-1483
not specific to any model of IP and ATM interaction. [RFC-1483]
Similarly, this specification is general enough to apply to
models for use of IP over ATM AAL5. Use of this specification
recommended for all implementatons of IP over ATM AAL5 in order
increase interoperability and performance. This specification
not conflict with the Classical IP over ATM specification and may
used as a conforming extension to that specification. [RFC-1577]
Applicability of this draft is not limited to the Classical IP
ATM model
Security
Security issues are not discussed in this memo
[RFC-791] Postel, J., "Internet Protocol - DARPA Internet
Protocol Specification", STD 5, RFC 791, DARPA,
1981.
[RFC-793] Postel, J., "Transmission Control Protocol -
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
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
IP Datagrams over the SMDS Service", RFC 1209, Bell
Research, March 1991.
[RFC-1435] Knowles, S., "IESG Advice from Experience with Path
Discovery, RFC-1435, IESG, March 1993.
[RFC-1483] Heinanen, J., "Multiprotocol Encapsulation over
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",
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",
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",
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
Computer Communications Technology, August 1987.
While all members of the IETF's IP over ATM Working Group have
helpful, Vern Schryver, Rob Warnock, Craig Partridge,
Subramaniam, and Bryan Lyles have been especially helpful to
author in analysing the host and routing implications of the
IP MTU value. Similarly, Dan Grossman provided significant
and help in ensuring alignment of this text with the related work
the ATM Forum and ITU
Author's organisation provided for identification purposes only
This document presents the author's views and is not necessarily
official opinion of his employer
Author's
Randall J.
Information Technology
Naval Research
Washington, DC 20375-5320
EMail: atkinson@itd.nrl.navy.
Atkinson [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
