doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

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]
+