From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1754.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc1754.txt (limited to 'doc/rfc/rfc1754.txt') diff --git a/doc/rfc/rfc1754.txt b/doc/rfc/rfc1754.txt new file mode 100644 index 0000000..26767ff --- /dev/null +++ b/doc/rfc/rfc1754.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group M. Laubach +Request for Comments: 1754 Com21, Inc. +Category: Informational January 1995 + + + IP over ATM Working Group's + Recommendations for the ATM Forum's Multiprotocol BOF + Version 1 + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +1. Abstract + + This document represents an initial list of requirements submitted to + the ATM Forum's Multiprotocol BOF for the operation of IP over ATM + networks as determined by the IETF IP over ATM Working Group and + other working groups. This RFC is issued for the benefit of community + members. The information contained in this document is accurate as + of the date of publication, but is subject to change. Subsequent + RFCs will reflect such changes. + + The content of this memo was submitted by the IETF Liaison to the ATM + Forum as contribution number 94-0954 in the ATM Forum's documentation + process on 14 September 1994. + +2. Notice + + This contribution has been prepared to assist the ATM Forum. This + document is offered to the Forum as a basis for discussion between + the ATM Forum Multiprotocol BOF and the IETF. The statements are + subject to change in form and content after further study and + discussion. Specifically, the IETF reserves reserves the right to + add to, amend or modify the statements contained herein. + +3. Introduction + + The following is the charter statement from the Internet Engineering + Task Force's (IETF) IP over ATM Working Group (IPATM WG). It is + being reproduced here for the benefit of those in the ATM Forum who + may not be familiar with it: + + "The IP over ATM Working Group will focus on the issues involved in + running internetworking protocols over Asynchronous Transfer Mode + (ATM) networks. The final goal for the Working Group is to produce + + + +Laubach [Page 1] + +RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995 + + + standards for the TCP/IP protocol suite and recommendations which + could be used by other internetworking protocol standards (e.g., ISO + CLNP and IEEE 802.2 Bridging). + + The Working Group will initially develop experimental protocols for + encapsulation, multicasting, addressing, address resolution, call set + up, and network management to allow the operation of internetwork + protocols over an ATM network. The Working Group may later submit + these protocols for IETF standardization. + + The Working Group will not develop physical layer standards for ATM. + These are well covered in other standards groups and do not need to + be addressed in this Group. + + The Working Group will develop models of ATM internetworking + architectures. This will be used to guide the development of + specific IP over ATM protocols. + + The Working Group will also develop and maintain a list of technical + unknowns that relate to internetworking over ATM. These will be used + to direct future work of the Working Group or be submitted to other + standards or research groups as appropriate. + + The Working Group will coordinate its work with other relevant + standards bodies (e.g., ANSI T1S1.5) to insure that it does not + duplicate their work and that its work meshes well with other + activities in this area. The Working Group will select among ATM + protocol options (e.g., selection of an adaptation layer) and make + recommendations to the ATM standards bodies regarding the + requirements for internetworking over ATM where the current ATM + standards do not meet the needs of internetworking." + + Historically, a large number of IETF IPATM WG participants are + employees of companies who are principal members of the ATM Forum. + Requirements between the two organizations have been communicated + informally by these participants. With the establishment of the ATM + Forum's Multiprotocol BOF activities, it has become prudent now to + document IETF requirements in a more formal fashion. + + At the July 1994 meeting of the IETF in Toronto, Canada, a request + was presented to the IP over ATM Working Group by the ATM Forum + Liaison, Drew Perkins, for the working group to prepare a list of + requirements as input to the ATM Forum's Multiprotocol BOF + activities. This document is a response to that request. + + + + + + + +Laubach [Page 2] + +RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995 + + +4. List of Requirements for Consideration + +4.1 Standardization & Logistics + + - Formal communications between the IETF and the ATM Forum + should be made via IETF <> ATM Forum Liaison(s), specific + written communications (such as this document), and/or + presentations made at official IETF or ATM Forum meetings. + + - IETF standards define how the TCP/IP protocol suite is defined, + deployed, and carried over specific network technologies, + including ATM networks [1][2][8]. + + - Any formal communications that affect the IETF standards + or processes must be made publicly available as the IETF is + a public international standards body. Ideally, such + communications should be written as Internet Drafts [1], the + IETF's equivalent to incoming contributions. + + - We invite and encourage ATM Forum members to participate in + the IETF standards process. See [1], [2], and [8] for + information on how to participate. + +4.2 IPv4 Encapsulation + + - RFC 1483 [3] and RFC 1577 [4] define how IP is encapsulated + and carried over ATM networks. The IPATM WG requests that any + ATM Forum Multiprotocol work support these standards as + specified, and that any future changes to them be made via the + IETF standards process. + +4.3 Routing + + - RFC 1577 defines the default Logical IP Subnet (LIS) model. + + - The IETF Routing over Large Clouds Working Group is developing + the Next Hop Resolution Protocol, which allows the incremental + optimization of routing (and subnets) by routing datagrams + over preferential ATM paths [9]. + + - The IETF IP over ATM Working Group will be working on the + next generation IP over ATM standards after RFC 1577 moves + from draft to proposed status. Requirements to the ATM + Forum will be forthcoming. + + - ATM signaling should give an indication of connection + over LAN or WAN and include feedback of time vs byte + charging. + + + +Laubach [Page 3] + +RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995 + + +4.4 Security + + - ATM signaling should support a user information element + that is used to convey security and authentication information + between IP members and applications. The IETF IPATM WG would + like to define the IP specific content of this IE. + +4.5 Broadcast and Multicast + + - The IPATM WG is currently discussing models of how best to map + IP multicast facilities onto ATM facilities. While this work is + preliminary, the IETF does support the ATM Forum's currently + planned multicasting enhancements, such as leaf-initiated joins + and support of multiple multicast congestion management + policies. A further list of requirements will be presented at a + later time. + +4.6 Signaling and Addressing + + - The IPATM WG is currently producing a specification for using + UNI 3.0 and 3.1 signaling to support RFCs 1483 and 1577. This + specification will be published as an informational reference + for UNI 3.0 signaling, and as a proposed standard for UNI 3.1 + signaling following UNI 3.1's ratification and official + publication. + + - IPv6 packets will include a Flow ID field intended to support + service classes in some way. Until the semantics of this field + are fully defined it is hard to say much, but presumably a soft + mapping between this and the VC to be used is desirable. A + further list of requirements will be presented at a later time. + + - IPv6 addresses will be 16 bytes and there will likely be a + defined embedding of them inside 20-byte NSAP format. There will + also likely be a mapping of US-GOSIP-like NSAPs into IPv6 + addresses (deleting the unuseful bytes), but that is still + controversial in the IPv6 discussions. A further list of + requirements will be presented at a later time. + + + + + + + + + + + + + +Laubach [Page 4] + +RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995 + + +4.7 Quality of Service, Performance, and Traffic Management + + - ATM should support extremely bursty applications with + significant elasticity in their bandwidth demands. + + - ATM should support elastic applications as defined in + RFC-1633 [7] very efficiently. That means enable high + bottleneck utilization while keeping delay reasonably bounded + (i.e., doubling delay wouldn't be terrible for elastic apps). + This should not be at the expense of delay sensitive classes + of service. + + - ATM should provide a a class of service which strives to + cooperate with existing TCP congestion avoidance, thereby + explicitly providing support not only for directly ATM-attached + and -aware endstations, but also for endstations on LANs (or + using LAN Emulation) that are using current TCP implementations + and interconnected via ATM-attached bridges and routers. + + - Predictive QoS should be supported in addition to guaranteed QoS + to support applications which are somewhat tolerant of delay + variation and low levels of loss. + + - IP uses both point-to-point and point-to-multipoint (future) + connections. To satisfy IP's needs an ABR-like service + would need to be applicable to both types of connections [6]. + + - No specification of minimum or maximum bandwidths by the ATM + end-systems [6]. + + - As simple as possible [6]. + + - Full line-rate transmission over otherwise-idle links [6]. + + - When end-to-end delay through the network is less than 1 second, + the cell loss for AAL5 frames over an ABR-like service should be + on the order of 3 in 10**8 cells for 1500 byte frames, or 3 in + 10**9 cells for 18 Kbyte frames [6]. + +5. Security Considerations + + Security issues raised in this memo will be addressed by the IETF IP + over ATM Working Group and presented in subsequent updates to this + memo. + + + + + + + +Laubach [Page 5] + +RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995 + + +6. Acknowledgement + + The basis of this memo is a summary of comments made on the email + discussion list of the IP over ATM Working Group. The contribution + was reviewed by Drew Perkins and Andy Malis as a sanity check before + submission to the ATM Forum. + +7. References + + [1] IETF Secretariat and G. Malkin, "The Tao of the IETF - A Guide + for New Attendees of the Internet Engineering Task Force", + FYI 17, RFC 1718, CNRI, Xylogics, Inc., November 1994. + + [2] Internet Architecture Board, and Internet Engineering Steering + Group, "The Internet Standards Process -- Revision 2", RFC 1602, + IAB, IESG, March 1994. + + [3] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation + Layer 5", RFC 1483, Telecom Finland, July 1993. + + [4] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, + Hewlett-Packard Laboratories, January 1994. + + [5] Deering, S., "Host Extensions for IP Multicasting", STD 5, + RFC 1112, Stanford University, August 1989. + + [6] McCloghrie, K., "Lan-Emulation's Needs for Traffic Management", + ATM-Forum/94-0533, ATM Forum, June 1994. + + [7] Braden, R., Clark, D., and S. Shenker, "Integrated Services + in the Internet Architecture: an Overview", RFC 1633, + USC/Information Sciences Institute, MIT, Xerox PARC, June 1994. + + [8] Postel, J., Editor, "Internet Official Protocol Standards", + STD 1, RFC 1720, USC/Information Sciences Institute, July 1994. + + [9] Malis, A., "Routing Over Large Clouds Liaison to the ATM Forum + Multiprotocol BOF", ATM-Forum/94-0766, ATM Forum, + September 1994. + + + + + + + + + + + + +Laubach [Page 6] + +RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995 + + +8. IETF <> ATM Forum Liaison + + Drew Perkins + FORE Systems, Inc. + 174 Thornhill Road + Warrendale, PA 15086 + Phone: (412) 772-6527 + Fax: (412) 772-6500 + Email: ddp@fore.com + +9. Author's Address + + Mark Laubach + Com21, Inc. + 2113 Landings Drive + Mountain View, CA 94043 + + Phone: (415) 254-5882 + Fax: (415) 254-5883 + EMail: laubach@com21.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laubach [Page 7] + -- cgit v1.2.3