encapsulated version of such a protocol. It MAY accept the SNAP
encapsulation but should not be required to do so as these frames
are noncompliant.
b) Fragmentation was removed. To date there are no interoperable
implementations of the fragmentation algorithm presented in RFC
1490. Additionally, there have been several suggestions that the
proposed mechanisms are insufficient for some frame relay
applications. To this end, fragmentation was removed from this
document, and has been replaced by the fragmentation specified in
FRF.12 [18].
c) The address resolution presented in RFC1490 referred only to PVC
environments and is insufficient for SVC environments. Therefore
the section title was changed to reflect this. Further work on
SVC address resolution will take place in the ION working group.
d) The encapsulation for Source Routing BPDUs was added, and the
lists in Appendix A were augmented.
e) The use of canonical and non-canonical MAC destination addresses
in the bridging encapsulations was clarified.
f) The Inverse ARP description was moved to the Inverse ARP
specification [11].
g) A new security section was added.
14. References
[1] International Telecommunication Union, "ISDN Data Link Layer
Specification for Frame Mode Bearer Services", ITU-T
Recommendation Q.922, 1992.
[2] International Telecommunication Union, "Signalling Specifications
for Frame Mode Switched and Permanent Virtual Connection Control
and Status Monitoring", ITU-T Recommendation Q.933, 1995.
[3] Information technology - Telecommunications and Information
Exchange between systems - Protocol Identification in the Network
Layer, ISO/IEC TR 9577: 1992.
[4] Baker, F., and R. Bowen, "PPP Bridging Control Protocol (BCP)",
RFC1638, June 1994.
[5] International Standard, Information Processing Systems - Local
Area Networks - Logical Link Control, ISO 8802-2, ANSI/IEEE,
Second Edition, 1994-12-30.
[6] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Protocol Addresses to 48.bit Ethernet Address
for Transmission on Ethernet Hardware", STD 37, RFC826, November
1982.
[7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC1700,
October 1994. See also: http://www.iana.org/numbers.html
[8] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A Reverse
Address Resolution Protocol", STD 38, RFC903, June 1984.
[9] Postel, J., and J. Reynolds, "A Standard for the Transmission of
IP Datagrams over IEEE 802 Networks", RFC1042, February 1988.
[10] IEEE, "IEEE Standard for Local and Metropolitan Area Networks:
Overview and architecture", IEEE Standard 802-1990.
[11] Bradley, T., Brown, C., and A. Malis, "Inverse Address
Resolution Protocol", RFC2390, September 1998.
[12] IEEE, "IEEE Standard for Local and Metropolitan Networks: Media
Access Control (MAC) Bridges", IEEE Standard 802.1D-1990.
[13] ISO/IEC 15802-5 : 1998 (IEEE Standard 802.1G), Remote Media
Access Control (MAC) Bridging, March 12, 1997.
[14] Frame Relay Forum, "Data Compression Over Frame Relay
Implementation Agreement", FRF.9, January 22, 1996.
[15] Frame Relay Forum, "Multiprotocol Encapsulation Implementation
Agreement", FRF.3.1, June 22, 1995.
[16] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[17] Simpson, W., "PPP in Frame Relay", RFC1973, June 1996.
[18] Frame Relay Forum, "Frame Relay Fragmentation Implementation
Agreement", FRF.12, December 1997.
[19] Frame Relay Forum, "Frame Relay PVC Multicast Service and
Protocol Implementation Agreement", FRF.7, October 21, 1994.
15. Authors' Addresses
Caralyn Brown
Consultant
EMail: cbrown@juno.com
Andrew Malis
Ascend Communications, Inc.
1 Robbins Road
Westford, MA 01886
Phone: (978) 952-7414
EMail: malis@ascend.com
16. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.