home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc1754.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  13.2 KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         M. Laubach
  8. Request for Comments: 1754                                   Com21, Inc.
  9. Category: Informational                                     January 1995
  10.  
  11.  
  12.                       IP over ATM Working Group's
  13.          Recommendations for the ATM Forum's Multiprotocol BOF
  14.                                Version 1
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. 1.  Abstract
  23.  
  24.    This document represents an initial list of requirements submitted to
  25.    the ATM Forum's Multiprotocol BOF for the operation of IP over ATM
  26.    networks as determined by the IETF IP over ATM Working Group and
  27.    other working groups. This RFC is issued for the benefit of community
  28.    members.  The information contained in this document is accurate as
  29.    of the date of publication, but is subject to change.  Subsequent
  30.    RFCs will reflect such changes.
  31.  
  32.    The content of this memo was submitted by the IETF Liaison to the ATM
  33.    Forum as contribution number 94-0954 in the ATM Forum's documentation
  34.    process on 14 September 1994.
  35.  
  36. 2.  Notice
  37.  
  38.    This contribution has been prepared to assist the ATM Forum.  This
  39.    document is offered to the Forum as a basis for discussion between
  40.    the ATM Forum Multiprotocol BOF and the IETF.  The statements are
  41.    subject to change in form and content after further study and
  42.    discussion.  Specifically, the IETF reserves reserves the right to
  43.    add to, amend or modify the statements contained herein.
  44.  
  45. 3.  Introduction
  46.  
  47.    The following is the charter statement from the Internet Engineering
  48.    Task Force's (IETF) IP over ATM Working Group (IPATM WG).  It is
  49.    being reproduced here for the benefit of those in the ATM Forum who
  50.    may not be familiar with it:
  51.  
  52.    "The IP over ATM Working Group will focus on the issues involved in
  53.    running internetworking protocols over Asynchronous Transfer Mode
  54.    (ATM) networks.  The final goal for the Working Group is to produce
  55.  
  56.  
  57.  
  58. Laubach                                                         [Page 1]
  59.  
  60. RFC 1754         IPATM WG ATM Forum Recommendations V1      January 1995
  61.  
  62.  
  63.    standards for the TCP/IP protocol suite and recommendations which
  64.    could be used by other internetworking protocol standards (e.g., ISO
  65.    CLNP and IEEE 802.2 Bridging).
  66.  
  67.    The Working Group will initially develop experimental protocols for
  68.    encapsulation, multicasting, addressing, address resolution, call set
  69.    up, and network management to allow the operation of internetwork
  70.    protocols over an ATM network.  The Working Group may later submit
  71.    these protocols for IETF standardization.
  72.  
  73.    The Working Group will not develop physical layer standards for ATM.
  74.    These are well covered in other standards groups and do not need to
  75.    be addressed in this Group.
  76.  
  77.    The Working Group will develop models of ATM internetworking
  78.    architectures.  This will be used to guide the development of
  79.    specific IP over ATM protocols.
  80.  
  81.    The Working Group will also develop and maintain a list of technical
  82.    unknowns that relate to internetworking over ATM.  These will be used
  83.    to direct future work of the Working Group or be submitted to other
  84.    standards or research groups as appropriate.
  85.  
  86.    The Working Group will coordinate its work with other relevant
  87.    standards bodies (e.g., ANSI T1S1.5) to insure that it does not
  88.    duplicate their work and that its work meshes well with other
  89.    activities in this area.  The Working Group will select among ATM
  90.    protocol options (e.g., selection of an adaptation layer) and make
  91.    recommendations to the ATM standards bodies regarding the
  92.    requirements for internetworking over ATM where the current ATM
  93.    standards do not meet the needs of internetworking."
  94.  
  95.    Historically, a large number of IETF IPATM WG participants are
  96.    employees of companies who are principal members of the ATM Forum.
  97.    Requirements between the two organizations have been communicated
  98.    informally by these participants.  With the establishment of the ATM
  99.    Forum's Multiprotocol BOF activities, it has become prudent now to
  100.    document IETF requirements in a more formal fashion.
  101.  
  102.    At the July 1994 meeting of the IETF in Toronto, Canada, a request
  103.    was presented to the IP over ATM Working Group by the ATM Forum
  104.    Liaison, Drew Perkins, for the working group to prepare a list of
  105.    requirements as input to the ATM Forum's Multiprotocol BOF
  106.    activities.  This document is a response to that request.
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Laubach                                                         [Page 2]
  115.  
  116. RFC 1754         IPATM WG ATM Forum Recommendations V1      January 1995
  117.  
  118.  
  119. 4.  List of Requirements for Consideration
  120.  
  121. 4.1  Standardization & Logistics
  122.  
  123.       - Formal communications between the IETF and the ATM Forum
  124.         should be made via IETF <> ATM Forum Liaison(s), specific
  125.         written communications (such as this document), and/or
  126.         presentations made at official IETF or ATM Forum meetings.
  127.  
  128.       - IETF standards define how the TCP/IP protocol suite is defined,
  129.         deployed, and carried over specific network technologies,
  130.         including ATM networks [1][2][8].
  131.  
  132.       - Any formal communications that affect the IETF standards
  133.         or processes must be made publicly available as the IETF is
  134.         a public international standards body.  Ideally, such
  135.         communications should be written as Internet Drafts [1], the
  136.         IETF's equivalent to incoming contributions.
  137.  
  138.       - We invite and encourage ATM Forum members to participate in
  139.         the IETF standards process.  See [1], [2], and [8] for
  140.         information on how to participate.
  141.  
  142. 4.2  IPv4 Encapsulation
  143.  
  144.       - RFC 1483 [3] and RFC 1577 [4] define how IP is encapsulated
  145.         and carried over ATM networks.  The IPATM WG requests that any
  146.         ATM Forum Multiprotocol work support these standards as
  147.         specified, and that any future changes to them be made via the
  148.         IETF standards process.
  149.  
  150. 4.3 Routing
  151.  
  152.       - RFC 1577 defines the default Logical IP Subnet (LIS) model.
  153.  
  154.       - The IETF Routing over Large Clouds Working Group is developing
  155.         the Next Hop Resolution Protocol, which allows the incremental
  156.         optimization of routing (and subnets) by routing datagrams
  157.         over preferential ATM paths [9].
  158.  
  159.       - The IETF IP over ATM Working Group will be working on the
  160.         next generation IP over ATM standards after RFC 1577 moves
  161.         from draft to proposed status.  Requirements to the ATM
  162.         Forum will be forthcoming.
  163.  
  164.       - ATM signaling should give an indication of connection
  165.         over LAN or WAN and include feedback of time vs byte
  166.         charging.
  167.  
  168.  
  169.  
  170. Laubach                                                         [Page 3]
  171.  
  172. RFC 1754         IPATM WG ATM Forum Recommendations V1      January 1995
  173.  
  174.  
  175. 4.4  Security
  176.  
  177.       - ATM signaling should support a user information element
  178.         that is used to convey security and authentication information
  179.         between IP members and applications.  The IETF IPATM WG would
  180.         like to define the IP specific content of this IE.
  181.  
  182. 4.5  Broadcast and Multicast
  183.  
  184.       - The IPATM WG is currently discussing models of how best to map
  185.         IP multicast facilities onto ATM facilities.  While this work is
  186.         preliminary, the IETF does support the ATM Forum's currently
  187.         planned multicasting enhancements, such as leaf-initiated joins
  188.         and support of multiple multicast congestion management
  189.         policies.  A further list of requirements will be presented at a
  190.         later time.
  191.  
  192. 4.6  Signaling and Addressing
  193.  
  194.       - The IPATM WG is currently producing a specification for using
  195.         UNI 3.0 and 3.1 signaling to support RFCs 1483 and 1577.  This
  196.         specification will be published as an informational reference
  197.         for UNI 3.0 signaling, and as a proposed standard for UNI 3.1
  198.         signaling following UNI 3.1's ratification and official
  199.         publication.
  200.  
  201.       - IPv6 packets will include a Flow ID field intended to support
  202.         service classes in some way. Until the semantics of this field
  203.         are fully defined it is hard to say much, but presumably a soft
  204.         mapping between this and the VC to be used is desirable.  A
  205.         further list of requirements will be presented at a later time.
  206.  
  207.       - IPv6 addresses will be 16 bytes and there will likely be a
  208.         defined embedding of them inside 20-byte NSAP format. There will
  209.         also likely be a mapping of US-GOSIP-like NSAPs into IPv6
  210.         addresses (deleting the unuseful bytes), but that is still
  211.         controversial in the IPv6 discussions.  A further list of
  212.         requirements will be presented at a later time.
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Laubach                                                         [Page 4]
  227.  
  228. RFC 1754         IPATM WG ATM Forum Recommendations V1      January 1995
  229.  
  230.  
  231. 4.7  Quality of Service, Performance, and Traffic Management
  232.  
  233.       - ATM should support extremely bursty applications with
  234.         significant elasticity in their bandwidth demands.
  235.  
  236.       - ATM should support elastic applications as defined in
  237.         RFC-1633 [7] very efficiently.  That means enable high
  238.         bottleneck utilization while keeping delay reasonably bounded
  239.         (i.e., doubling delay wouldn't be terrible for elastic apps).
  240.         This should not be at the expense of delay sensitive classes
  241.         of service.
  242.  
  243.       - ATM should provide a a class of service which strives to
  244.         cooperate with existing TCP congestion avoidance, thereby
  245.         explicitly providing support not only for directly ATM-attached
  246.         and -aware endstations, but also for endstations on LANs (or
  247.         using LAN Emulation) that are using current TCP implementations
  248.         and interconnected via ATM-attached bridges and routers.
  249.  
  250.       - Predictive QoS should be supported in addition to guaranteed QoS
  251.         to support applications which are somewhat tolerant of delay
  252.         variation and low levels of loss.
  253.  
  254.       - IP uses both point-to-point and point-to-multipoint (future)
  255.         connections.  To satisfy IP's needs an ABR-like service
  256.         would need to be applicable to both types of connections [6].
  257.  
  258.       - No specification of minimum or maximum bandwidths by the ATM
  259.         end-systems [6].
  260.  
  261.       - As simple as possible [6].
  262.  
  263.       - Full line-rate transmission over otherwise-idle links [6].
  264.  
  265.       - When end-to-end delay through the network is less than 1 second,
  266.         the cell loss for AAL5 frames over an ABR-like service should be
  267.         on the order of 3 in 10**8 cells for 1500 byte frames, or 3 in
  268.         10**9 cells for 18 Kbyte frames [6].
  269.  
  270. 5.  Security Considerations
  271.  
  272.    Security issues raised in this memo will be addressed by the IETF IP
  273.    over ATM Working Group and presented in subsequent updates to this
  274.    memo.
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Laubach                                                         [Page 5]
  283.  
  284. RFC 1754         IPATM WG ATM Forum Recommendations V1      January 1995
  285.  
  286.  
  287. 6.  Acknowledgement
  288.  
  289.    The basis of this memo is a summary of comments made on the email
  290.    discussion list of the IP over ATM Working Group.  The contribution
  291.    was reviewed by Drew Perkins and Andy Malis as a sanity check before
  292.    submission to the ATM Forum.
  293.  
  294. 7.  References
  295.  
  296.    [1]  IETF Secretariat and G. Malkin, "The Tao of the IETF - A Guide
  297.         for New Attendees of the Internet Engineering Task Force",
  298.         FYI 17, RFC 1718, CNRI, Xylogics, Inc., November 1994.
  299.  
  300.    [2]  Internet Architecture Board, and Internet Engineering Steering
  301.         Group, "The Internet Standards Process -- Revision 2", RFC 1602,
  302.         IAB, IESG, March 1994.
  303.  
  304.    [3]  Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
  305.         Layer 5", RFC 1483, Telecom Finland, July 1993.
  306.  
  307.    [4]  Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
  308.         Hewlett-Packard Laboratories, January 1994.
  309.  
  310.    [5]  Deering, S., "Host Extensions for IP Multicasting", STD 5,
  311.         RFC 1112, Stanford University, August 1989.
  312.  
  313.    [6]  McCloghrie, K., "Lan-Emulation's Needs for Traffic Management",
  314.         ATM-Forum/94-0533, ATM Forum, June 1994.
  315.  
  316.    [7]  Braden, R., Clark, D., and S. Shenker, "Integrated Services
  317.         in the Internet Architecture: an Overview", RFC 1633,
  318.         USC/Information Sciences Institute, MIT, Xerox PARC, June 1994.
  319.  
  320.    [8]  Postel, J., Editor, "Internet Official Protocol Standards",
  321.         STD 1, RFC 1720, USC/Information Sciences Institute, July 1994.
  322.  
  323.    [9]  Malis, A., "Routing Over Large Clouds Liaison to the ATM Forum
  324.         Multiprotocol BOF", ATM-Forum/94-0766, ATM Forum,
  325.         September 1994.
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Laubach                                                         [Page 6]
  339.  
  340. RFC 1754         IPATM WG ATM Forum Recommendations V1      January 1995
  341.  
  342.  
  343. 8.  IETF <> ATM Forum Liaison
  344.  
  345.    Drew Perkins
  346.    FORE Systems, Inc.
  347.    174 Thornhill Road
  348.    Warrendale, PA 15086
  349.    Phone: (412) 772-6527
  350.    Fax:   (412) 772-6500
  351.    Email: ddp@fore.com
  352.  
  353. 9.  Author's Address
  354.  
  355.    Mark Laubach
  356.    Com21, Inc.
  357.    2113 Landings Drive
  358.    Mountain View, CA 94043
  359.  
  360.    Phone: (415) 254-5882
  361.    Fax:   (415) 254-5883
  362.    EMail: laubach@com21.com
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Laubach                                                         [Page 7]
  395.  
  396.