home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ion-classic2-01.txt < prev    next >
Text File  |  1996-11-26  |  63KB  |  1,455 lines
  1.  
  2. Network Working Group                                       Mark Laubach
  3. INTERNET DRAFT                                               Com21, Inc.
  4. Expires 26 May 1997
  5. Obsoletes: 1577, 1626                                       Joel Halpern
  6. <draft-ion-ipatm-classic2-01.txt>               Newbridge Networks, Inc.
  7.  
  8.                                                         26 November 1996
  9.  
  10.  
  11.  
  12.  
  13.                      Classical IP and ARP over ATM
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This memo is an internet draft. Internet Drafts are working documents
  19.    of the Internet Engineering Task Force (IETF), its Areas, and its
  20.    Working Groups. Note that other groups may also distribute working
  21.    documents as Internet Drafts.
  22.  
  23.    Internet Drafts are draft documents valid for a maximum of six
  24.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  25.    other documents at any time. It is not appropriate to use Internet
  26.    Drafts as reference material or to cite them other than as a "working
  27.    draft" or "work in progress".  Please check the lid-abstracts.txt
  28.    listing contained in the internet-drafts shadow directories on
  29.    nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or
  30.    munnari.oz.au to learn the current status of any Internet Draft.
  31.  
  32. Update Information
  33.  
  34.    This draft represents an update to RFC-1577 and RFC-1626.  The
  35.    following changes are included in this memo:
  36.  
  37.    o   Pointer to Classical MIB I-D for setting of variables
  38.  
  39.    o   Single ATMARP server address to ATMARP server list, configurable
  40.        via the MIB.
  41.  
  42.    o   RFC1626 text replaces MTU section
  43.  
  44.    o   Client registration procedure from In_ATMARP to first
  45.        ATMARP_Request
  46.  
  47.    o   Clarification of variable length ATMARP packet format
  48.  
  49.    o   Clarification of ARP_NAK packet format
  50.  
  51.  
  52.  
  53. Laubach+Halpern                                                 [Page 1]
  54.  
  55. DRAFT                 Classical IP and ARP over ATM        November 1996
  56.  
  57.  
  58.    o   Clarification of InATMARP packet format for null IPv4 addresses
  59.  
  60.    o   Clarification on ATMARP registration and use of InATMARP_Reply
  61.        for clients having more than one IP address in a LIS
  62.  
  63.  
  64. Table of Contents
  65.  
  66.    1. ABSTRACT  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  67.    2. ACKNOWLEDGMENT  . . . . . . . . . . . . . . . . . . . . . . .  3
  68.    3. CONVENTIONS . . . . . . . . . . . . . . . . . . . . . . . . .  3
  69.    4. INTRODUCTION  . . . . . . . . . . . . . . . . . . . . . . . .  4
  70.    5. IP SUBNETWORK CONFIGURATION . . . . . . . . . . . . . . . . .  7
  71.    5.1  Background  . . . . . . . . . . . . . . . . . . . . . . . .  7
  72.    5.2  LIS Configuration Requirements  . . . . . . . . . . . . . .  7
  73.    5.3  LIS Router Additional Configuration . . . . . . . . . . . .  9
  74.    6. IP PACKET FORMAT  . . . . . . . . . . . . . . . . . . . . . .  9
  75.    7. DEFAULT VALUE FOR IP MTU OVER ATM AAL5  . . . . . . . . . . .  9
  76.    7.1  Permanent Virtual Circuits  . . . . . . . . . . . . . . . . 10
  77.    7.2  Switched Virtual Circuits . . . . . . . . . . . . . . . . . 10
  78.    7.3  Path MTU Discovery Required . . . . . . . . . . . . . . . . 12
  79.    8. LIS ADDRESS RESOLUTION SERVICES . . . . . . . . . . . . . . . 12
  80.    8.1  ATM-based ARP and InARP Equivalent Services . . . . . . . . 12
  81.    8.2  Permanent Virtual Connections . . . . . . . . . . . . . . . 12
  82.    8.3  Switched Virtual Connections  . . . . . . . . . . . . . . . 13
  83.    8.4  ATMARP Single Server Operational Requirements . . . . . . . 14
  84.    8.5  ATMARP Client Operational Requirements  . . . . . . . . . . 15
  85.    8.5.1  Client ATMARP Table Aging . . . . . . . . . . . . . . . . 16
  86.    8.5.2  Non-Normal VC Operations  . . . . . . . . . . . . . . . . 17
  87.    8.6  Address Resolution Server Selection . . . . . . . . . . . . 17
  88.    8.6.1  PVCs to ATMARP Servers  . . . . . . . . . . . . . . . . . 18
  89.    8.7  ATMARP Packet Formats . . . . . . . . . . . . . . . . . . . 18
  90.    8.7.1  ATMARP/InATMARP Request and Reply Packet Formats  . . . . 18
  91.    8.7.2  Receiving Unknown ATMARP packets  . . . . . . . . . . . . 20
  92.    8.7.3  TL, ATM Number, and ATM Subaddress Encoding . . . . . . . 20
  93.    8.7.4  ATMARP_NAK Packet Format  . . . . . . . . . . . . . . . . 21
  94.    8.7.5  Variable Length Requirements for ATMARP Packets . . . . . 22
  95.    8.8  ATMARP/InATMARP Packet Encapsulation  . . . . . . . . . . . 22
  96.    9. IP BROADCAST ADDRESS  . . . . . . . . . . . . . . . . . . . . 23
  97.    10. IP MULTICAST ADDRESS . . . . . . . . . . . . . . . . . . . . 23
  98.    11. SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . 24
  99.    12. MIB SPECIFICATION  . . . . . . . . . . . . . . . . . . . . . 24
  100.    13. OPEN ISSUES  . . . . . . . . . . . . . . . . . . . . . . . . 24
  101.    14. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . 24
  102.    15. AUTHORS  . . . . . . . . . . . . . . . . . . . . . . . . . . 26
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109. Laubach+Halpern                                                 [Page 2]
  110.  
  111. DRAFT                 Classical IP and ARP over ATM        November 1996
  112.  
  113.  
  114. 1.  ABSTRACT
  115.  
  116.    This memo defines an initial application of classical IP and ARP in
  117.    an Asynchronous Transfer Mode (ATM) network environment configured as
  118.    a Logical IP Subnetwork (LIS) as described in Section 5.  This memo
  119.    does not preclude the subsequent development of ATM technology into
  120.    areas other than a LIS; specifically, as single ATM networks grow to
  121.    replace many Ethernet local LAN segments and as these networks become
  122.    globally connected, the application of IP and ARP will be treated
  123.    differently.  This memo considers only the application of ATM as a
  124.    direct replacement for the "wires" and local LAN segments connecting
  125.    IP end-stations ("members") and routers operating in the "classical"
  126.    LAN-based paradigm. Issues raised by MAC level bridging and LAN
  127.    emulation are beyond the scope of this paper.
  128.  
  129.    This memo introduces general ATM technology and nomenclature.
  130.    Readers are encouraged to review the ATM Forum and ITU-TS (formerly
  131.    CCITT) references for more detailed information about ATM
  132.    implementation agreements and standards.
  133.  
  134.  
  135. 2.  ACKNOWLEDGMENT
  136.  
  137.    The authors would like to thank the efforts of the IP over ATM
  138.    Working Group of the IETF. Without their substantial, and sometimes
  139.    contentious support, of the Classical IP over ATM model, this updated
  140.    memo would not have been possible. Section 7, on Default MTU, has
  141.    been incorporated directly from Ran Atkinson's RFC-1626, with his
  142.    permission.  Thanks for Andy Malis for an early review and comments
  143.    for rolc and ion related issues.
  144.  
  145.  
  146.  
  147. 3.  CONVENTIONS
  148.  
  149.    The following language conventions are used in the items of
  150.    specification in this document:
  151.  
  152.    o   MUST, SHALL, or MANDATORY -- the item is an absolute requirement
  153.        of the specification.
  154.  
  155.    o   SHOULD or RECOMMEND -- this item should generally be followed for
  156.        all but exceptional circumstances.
  157.  
  158.    o   MAY or OPTIONAL -- the item is truly optional and may be followed
  159.        or ignored according to the needs of the implementor.
  160.  
  161.  
  162.  
  163.  
  164.  
  165. Laubach+Halpern                                                 [Page 3]
  166.  
  167. DRAFT                 Classical IP and ARP over ATM        November 1996
  168.  
  169.  
  170. 4.  INTRODUCTION
  171.  
  172.    The goal of this specification is to allow compatible and
  173.    interoperable implementations for transmitting IP datagrams and ATM
  174.    Address Resolution Protocol (ATMARP) requests and replies over ATM
  175.    Adaptation Layer 5 (AAL5)[2,6].
  176.  
  177.    This memo specifies the stable foundation baseline operational model
  178.    which will always be available in IP and ARP over ATM
  179.    implementations. Subsequent memos will build upon and refine this
  180.    model, however, in the absence or failure of those extensions,
  181.    operations will default to the specifications contained in this memo.
  182.    Consequently, this memo will not reference these other extensions.
  183.  
  184.    This memo defines only the operation of IP and address resolution
  185.    over ATM, and is not meant to describe the operation of ATM networks.
  186.    Any reference to virtual connections, permanent virtual connections,
  187.    or switched virtual connections applies only to virtual channel
  188.    connections used to support IP and address resolution over ATM, and
  189.    thus are assumed to be using AAL5.  This memo places no restrictions
  190.    or requirements on virtual connections used for other purposes.
  191.  
  192.    Initial deployment of ATM provides a LAN segment replacement for:
  193.  
  194.    1)  Local area networks (e.g., Ethernets, Token Rings and FDDI).
  195.  
  196.    2)  Local-area backbones between existing (non-ATM) LANs.
  197.  
  198.    3)  Dedicated circuits or frame relay PVCs between IP routers.
  199.  
  200.    Note: In 1), local IP routers with one or more ATM interfaces will be
  201.    able to connect islands of ATM networks.  In 3), public or private
  202.    ATM Wide Area networks will be used to connect IP routers, which in
  203.    turn may or may not connect to local ATM networks.  ATM WANs and LANs
  204.    may be interconnected.
  205.  
  206.    Private ATM networks (local or wide area) will use the private ATM
  207.    address structure specified in the ATM Forum UNI 3.1 specification
  208.    [9]. This structure is modeled after the format of an OSI Network
  209.    Service Access Point Address. A private ATM address uniquely
  210.    identifies an ATM endpoint.  Public networks will use either the
  211.    address structure specified in ITU-TS recommendation E.164 or the
  212.    private network ATM address structure. An E.164 address uniquely
  213.    identifies an interface to a public network.
  214.  
  215.    The characteristics and features of ATM networks are different than
  216.    those found in LANs:
  217.  
  218.  
  219.  
  220.  
  221. Laubach+Halpern                                                 [Page 4]
  222.  
  223. DRAFT                 Classical IP and ARP over ATM        November 1996
  224.  
  225.  
  226.    o   ATM provides a Virtual Connection (VC) switched environment. VC
  227.        setup may be done on either a Permanent Virtual Connection (PVC)
  228.        or dynamic Switched Virtual Connection (SVC) basis. SVC call
  229.        management signalling is performed via implementations of the UNI
  230.        3.1 protocol [7,9].
  231.  
  232.    o   Data to be passed by a VC is segmented into 53 octet quantities
  233.        called cells (5 octets of ATM header and 48 octets of data).
  234.  
  235.    o   The function of mapping user Protocol Data Units (PDUs) into the
  236.        information field of the ATM cell and vice versa is performed in
  237.        the ATM Adaptation Layer (AAL).  When a VC is created a specific
  238.        AAL type is associated with the VC.  There are four different AAL
  239.        types, which are referred to individually as "AAL1", "AAL2",
  240.        "AAL3/4", and "AAL5".  (Note: this memo concerns itself with the
  241.        mapping of IP and ATMARP over AAL5 only.  The other AAL types are
  242.        mentioned for introductory purposes only.)  The AAL type is known
  243.        by the VC end points via the call setup mechanism and is not
  244.        carried in the ATM cell header.  For PVCs the AAL type is
  245.        administratively configured at the end points when the Connection
  246.        (circuit) is set up.  For SVCs, the AAL type is communicated
  247.        along the VC path via UNI 3.1 as part of call setup establishment
  248.        and the end points use the signaled information for
  249.        configuration.  ATM switches generally do not care about the AAL
  250.        type of VCs.  The AAL5 format specifies a packet format with a
  251.        maximum size of (64K - 1) octets of user data. Cells for an AAL5
  252.        PDU are transmitted first to last, the last cell indicating the
  253.        end of the PDU.  ATM standards guarantee that on a given VC, cell
  254.        ordering is preserved end-to-end.  NOTE: AAL5 provides a non-
  255.        assured data transfer service - it is up to higher-level
  256.        protocols to provide retransmission.
  257.  
  258.    o   ATM Forum signaling defines point-to-point and point-to-
  259.        multipoint Connection setup [9].  Multipoint-to-multipoint VCs
  260.        are not yet specified by ITU-TS or ATM Forum.
  261.  
  262.    o   An ATM Forum ATM endpoint address is either encoded as an NSAP
  263.        Address (NSAPA) or is an E.164 Public-UNI address [9].  In some
  264.        cases, both an ATM endpoint address and an E.164 Public UNI
  265.        address are needed by an ATMARP client to reach another host or
  266.        router.  Since the use of ATM endpoint addresses and E.164 public
  267.        UNI addresses by ATMARP are analogous to the use of Ethernet
  268.        addresses, the notion of "hardware address" is extended to
  269.        encompass ATM addresses in the context of ATMARP, even though ATM
  270.        addresses need not have hardware significance.  ATM Forum NSAPAs
  271.        use the same basic format as U.S. GOSIP NSAPAs [11].  Note: ATM
  272.        Forum addresses should not be construed as being U.S. GOSIP
  273.        NSAPAs.  They are not, the administration is different, which
  274.  
  275.  
  276.  
  277. Laubach+Halpern                                                 [Page 5]
  278.  
  279. DRAFT                 Classical IP and ARP over ATM        November 1996
  280.  
  281.  
  282.        fields get filled out are different, etc.
  283.  
  284.    This memo describes the initial deployment of ATM within "classical"
  285.    IP networks as a direct replacement for local area networks
  286.    (Ethernets) and for IP links which interconnect routers, either
  287.    within or between administrative domains. The "classical" model here
  288.    refers to the treatment of the ATM host adapter as a networking
  289.    interface to the IP protocol stack operating in a LAN-based paradigm.
  290.  
  291.    Characteristics of the classical model are:
  292.  
  293.    o   The same maximum transmission unit (MTU) size is the default for
  294.        all VCs in a LIS [2]. However, on a VC-by-VC point-to-point
  295.        basis, the MTU size may be negotiated during connection setup
  296.        using Path MTU Discovery to better suit the needs of the
  297.        cooperating pair of IP members or the attributes of the
  298.        communications path. (Refer to Section 7.3)
  299.    o   Default LLC/SNAP encapsulation of IP packets.
  300.  
  301.    o   End-to-end IP routing architecture stays the same.
  302.  
  303.    o   IP addresses are resolved to ATM addresses by use of an ATMARP
  304.        service within the LIS - ATMARPs stay within the LIS.  From a
  305.        client's perspective, the ATMARP architecture stays faithful to
  306.        the basic ARP model presented in [3].
  307.  
  308.    o   One IP subnet is used for many hosts and routers. Each VC
  309.        directly connects two IP members within the same LIS.
  310.  
  311.    Future memos will describe the operation of IP over ATM when ATM
  312.    networks become globally deployed and interconnected.
  313.  
  314.    The deployment of ATM into the Internet community is just beginning
  315.    and will take many years to complete. During the early part of this
  316.    period, we expect deployment to follow traditional IP subnet
  317.    boundaries for the following reasons:
  318.  
  319.    o   Administrators and managers of IP subnetworks will tend to
  320.        initially follow the same models as they currently have deployed.
  321.        The mindset of the community will change slowly over time as ATM
  322.        increases its coverage and builds its credibility.
  323.  
  324.    o   Policy administration practices rely on the security, access,
  325.        routing, and filtering capability of IP Internet gateways: i.e.
  326.        firewalls. ATM will not be allowed to "back-door" around these
  327.        mechanisms until ATM provides better management capability than
  328.        the existing services and practices.
  329.  
  330.  
  331.  
  332.  
  333. Laubach+Halpern                                                 [Page 6]
  334.  
  335. DRAFT                 Classical IP and ARP over ATM        November 1996
  336.  
  337.  
  338.    o   Standards for global IP over ATM will take some time to complete
  339.        and deploy.
  340.  
  341.    This memo details the treatment of the classical model of IP and
  342.    ATMARP over ATM. This memo does not preclude the subsequent treatment
  343.    of ATM networks within the IP framework as ATM becomes globally
  344.    deployed and interconnected; this will be the subject of future
  345.    documents. This memo does not address issues related to transparent
  346.    data link layer interoperability.
  347.  
  348.  
  349. 5.  IP SUBNETWORK CONFIGURATION
  350.  
  351. 5.1 Background
  352.  
  353.    In the LIS scenario, each separate administrative entity configures
  354.    its hosts and routers within a LIS. Each LIS operates and
  355.    communicates independently of other LISs on the same ATM network.
  356.  
  357.    In the classical model, hosts communicate directly via ATM to other
  358.    hosts within the same LIS using the ATMARP service as the mechanism
  359.    for resolving target IP addresses to target ATM endpoint addresses.
  360.    The ATMARP service has LIS scope only and serves all hosts in the
  361.    LIS. Communication to hosts located outside of the local LIS is
  362.    provided via an IP router. This router is an ATM endpoint attached to
  363.    the ATM network that is configured as a member of one or more LISs.
  364.    This configuration MAY result in a number of disjoint LISs operating
  365.    over the same ATM network. Using this model hosts of differing IP
  366.    subnets MUST communicate via an intermediate IP router even though it
  367.    may be possible to open a direct VC between the two IP members over
  368.    the ATM network.
  369.  
  370.    By default, the ATMARP service and the classical LIS routing model
  371.    MUST be available to any IP member client in the LIS.
  372.  
  373. 5.2 LIS Configuration Requirements
  374.  
  375.    The requirements for IP members  (hosts, routers) operating in an ATM
  376.    LIS configuration are:
  377.  
  378.    o   All members of the LIS have the same IP network/subnet number and
  379.        address mask [8].
  380.  
  381.    o   All members within a LIS are directly connected to the ATM
  382.        network.
  383.  
  384.    o   All members of a LIS MUST have a mechanism for resolving IP
  385.        addresses to ATM addresses via ATMARP (based on [3]) and vice
  386.  
  387.  
  388.  
  389. Laubach+Halpern                                                 [Page 7]
  390.  
  391. DRAFT                 Classical IP and ARP over ATM        November 1996
  392.  
  393.  
  394.        versa via InATMARP (based on [12]) when using SVCs.  Refer to
  395.        Section 8 "Address Resolution" in this memo.
  396.  
  397.    o   All members of a LIS MUST have a mechanism for resolving VCs to
  398.        IP addresses via InATMARP (based on [12]) when using PVCs.  Refer
  399.        to Section 8 "Address Resolution" in this memo.
  400.  
  401.    o   All members within a LIS MUST be able to communicate via ATM with
  402.        all other members in the same LIS; i.e., the Virtual Connection
  403.        topology underlying the intercommunication among the members is
  404.        fully meshed.
  405.  
  406.    The following list identifies the set of ATM specific parameters that
  407.    MUST be implemented in each IP station connected to the ATM network:
  408.  
  409.    o   ATM Hardware Address (atm$ha). The ATM address of the individual
  410.        IP station.
  411.  
  412.    o   ATMARP Request Address list (atm$arp-req-list): atm$arp-req-list
  413.        is a list containing one or more ATM addresses of individual
  414.        ATMARP servers located within the LIS. In an SVC environment,
  415.        ATMARP servers are used to resolve target IP addresses to target
  416.        ATM address via an ATMARP request and reply protocol. ATMARP
  417.        servers MUST have authoritative responsibility for resolving
  418.        ATMARP requests of all IP members using SVCs located within the
  419.        LIS.
  420.  
  421.    A LIS MUST have a single ATMARP service entry configured and
  422.    available to all members of the LIS who use SVCs.
  423.  
  424.    In the case where there is only a single ATMARP server within the
  425.    LIS, then all ATMARP clients MUST be configured identically to have
  426.    only one non-null entry in atm$arp-req-list configured with the same
  427.    address of the single ATMARP service.
  428.  
  429.    If the IP member is operating with PVCs only, then atm$arp-req-list
  430.    MUST be configured with all null entries and the client MUST not make
  431.    queries to either address resolution service.
  432.  
  433.    Within the restrictions mentioned above and in Section 8, local
  434.    administration MUST decide which server address(es) are appropriate
  435.    for atm$arp-req-list.
  436.  
  437.    By default, atm$arp-req-list MUST be configured using the MIB [18].
  438.  
  439.    Manual configuration of the addresses and address lists presented in
  440.    this section is implementation dependent and beyond the scope of this
  441.    document; i.e. this memo does not require any specific configuration
  442.  
  443.  
  444.  
  445. Laubach+Halpern                                                 [Page 8]
  446.  
  447. DRAFT                 Classical IP and ARP over ATM        November 1996
  448.  
  449.  
  450.    method. This memo does require that these addresses MUST be
  451.    configured completely on the client, as appropriate for the LIS,
  452.    prior to use by any service or operation detailed in this memo.
  453.  
  454. 5.3 LIS Router Additional Configuration
  455.  
  456.    It is RECOMMENDED that routers providing LIS functionality over the
  457.    ATM network also support the ability to interconnect multiple LISs.
  458.    Routers that wish to provide interconnection of differing LISs MUST
  459.    be able to support multiple sets of these parameters (one set for
  460.    each connected LIS) and be able to associate each set of parameters
  461.    to a specific IP network/ subnet number. In addition, it is
  462.    RECOMMENDED that a router be able to provide this multiple LIS
  463.    support with a single physical ATM interface that may have one or
  464.    more individual ATM endpoint addresses.  Note: this does not
  465.    necessarily mean different End System Identifiers (ESIs) when NSAPAs
  466.    are used.  The last octet of an NSAPA is the NSAPA Selector (SEL)
  467.    field which can be used to differentiate up to 256 different LISs for
  468.    the same ESI. (Refer to Section 5.1.3.1, "Private Networks" in [9].)
  469.  
  470.  
  471. 6.  IP PACKET FORMAT
  472.  
  473.    Implementations MUST support IEEE 802.2 LLC/SNAP encapsulation as
  474.    described in [2].  LLC/SNAP encapsulation is the default packet
  475.    format for IP datagrams.
  476.  
  477.    This memo recognizes that other encapsulation methods may be used
  478.    however, in the absence of other knowledge or agreement, LLC/SNAP
  479.    encapsulation is the default.
  480.  
  481.    This memo recognizes that end-to-end signaling within ATM may allow
  482.    negotiation of encapsulation method on a per-VC basis.
  483.  
  484. 7.  DEFAULT VALUE FOR IP MTU OVER ATM AAL5
  485.  
  486.    Protocols in wide use throughout the Internet, such as the Network
  487.    File System (NFS), currently use large frame sizes (e.g. 8 KB).
  488.    Empirical evidence with various applications over the Transmission
  489.    Control Protocol (TCP) indicates that larger Maximum Transmission
  490.    Unit (MTU) sizes for the Internet Protocol (IP) tend to give better
  491.    performance. Fragmentation of IP datagrams is known to be highly
  492.    undesirable [16]. It is desirable to reduce fragmentation in the
  493.    network and thereby enhance performance by having the IP Maximum
  494.    Transmission Unit (MTU) for AAL5 be reasonably large.  NFS defaults
  495.    to an 8192 byte frame size. Allowing for RPC/XDR, UDP, IP, and LLC
  496.    headers, NFS would prefer a default MTU of at least 8300 octets.
  497.    Routers can sometimes perform better with larger packet sizes because
  498.  
  499.  
  500.  
  501. Laubach+Halpern                                                 [Page 9]
  502.  
  503. DRAFT                 Classical IP and ARP over ATM        November 1996
  504.  
  505.  
  506.    most of the performance costs in routers relate to "packets handled"
  507.    rather than "bytes transferred". So there are a number of good
  508.    reasons to have a reasonably large default MTU value for IP over ATM
  509.    AAL5.
  510.  
  511.    RFC-1209 specifies the IP MTU over SMDS to be 9180 octets, which is
  512.    larger than 8300 octets but still in the same range [1]. There is no
  513.    good reason for the default MTU of IP over ATM AAL5 to be different
  514.    from IP over SMDS, given that they will be the same magnitude. Having
  515.    the two be the same size will be helpful in interoperability and will
  516.    also help reduce incidence of IP fragmentation.
  517.  
  518.    Therefore, the default IP MTU for use with ATM AAL5 shall be 9180
  519.    octets.  All implementations compliant and conformant with this
  520.    specification shall support at least the default IP MTU value for use
  521.    over ATM AAL5.
  522.  
  523. 7.1  Permanent Virtual Circuits
  524.  
  525.    Implementations which only support Permanent Virtual Circuits (PVCs)
  526.    will (by definition) not implement any ATM signalling protocol. Such
  527.    implementations shall use the default IP MTU value of 9180 octets
  528.    unless both parties have agreed in advance to use some other IP MTU
  529.    value via some mechanism not specified here.
  530.  
  531. 7.2  Switched Virtual Circuits
  532.  
  533.    Implementations that support Switched Virtual Circuits (SVCs) MUST
  534.    attempt to negotiate the AAL CPCS-SDU size using the ATM signalling
  535.    protocol. The industry standard ATM signalling protocol uses two
  536.    different parts of the Information Element named "AAL Parameters" to
  537.    exchange information on the MTU over the ATM circuit being setup [9].
  538.    The Forward Maximum CPCS-SDU Size field contains the value over the
  539.    path from the calling party to the called party. The Backwards
  540.    Maximum CPCS-SDU Size Identifier field contains the value over the
  541.    path from the called party to the calling party. The ATM Forum
  542.    specifies the valid values of this identifier as 1 to 65535
  543.    inclusive. Note that the ATM Forum's User-to-Network-Interface (UNI)
  544.    signalling permits the MTU in one direction to be different from the
  545.    MTU in the opposite direction, so the Forward Maximum CPCS-SDU Size
  546.    Identifier might have a different value from the Backwards Maximum
  547.    CPCS-SDU Size Identifier on the same connection.
  548.  
  549.    If the calling party wishes to use the default MTU it shall still
  550.    include the "AAL Parameters" information element with the default
  551.    values for the Maximum CPCS-SDU Size as part of the SETUP message of
  552.    the ATM signalling protocol [9]. If the calling party desires to use
  553.    a different value than the default, it shall include the "AAL
  554.  
  555.  
  556.  
  557. Laubach+Halpern                                                [Page 10]
  558.  
  559. DRAFT                 Classical IP and ARP over ATM        November 1996
  560.  
  561.  
  562.    Parameters" information element with the desired value for the
  563.    Maximum CPCS-SDU Size as part of the SETUP message of the ATM
  564.    Signalling Protocol. The called party will respond using the same
  565.    information elements and identifiers in its CONNECT message response
  566.    [9].
  567.  
  568.    If the called party receives a SETUP message containing the "Maximum
  569.    CPCS-SDU Size" in the AAL Parameters information element, it shall
  570.    handle the Forward and Backward Maximum CPCS-SDU Size Identifier as
  571.    follows:
  572.  
  573.    a)  If it is able to accept the ATM MTU values proposed by the SETUP
  574.        message, it shall include an AAL Parameters information element
  575.        in its response.  The Forward and Backwards Maximum CPCS-SDU Size
  576.        fields shall be present and their values shall be equal to the
  577.        corresponding values in the SETUP message.
  578.  
  579.    b)  If it wishes a smaller ATM MTU size than that proposed, then it
  580.        shall set the values of the Maximum CPCS-SDU Size in the AAL
  581.        Parameters information elements equal to the desired value in the
  582.        CONNECT message responding to the original SETUP message.
  583.  
  584.    c)  If the calling endpoint receives a CONNECT message that does not
  585.        contain the AAL Parameters Information Element, but the
  586.        corresponding SETUP message did contain the AAL Parameters
  587.        Information element (including the forward and backward CPCS-SDU
  588.        Size fields), it shall clear the call with cause "AAL Parameters
  589.        cannot be supported".
  590.  
  591.    d)  If either endpoint receives a STATUS message with cause
  592.        "Information Element Non-existent or Not Implemented" or cause
  593.        ""Access Information Discarded", and with a diagnostic field
  594.        indicating the AAL Parameters Information Element identifier, it
  595.        shall clear the call with cause "AAL Parameters cannot be
  596.        supported."
  597.  
  598.    e)  If either endpoint receives CPCS-SDUs in excess of the negotiated
  599.        MTU size, it may use IP fragmentation or may clear the call with
  600.        cause "AAL Parameters cannot be supported".  In this case, an
  601.        error has occurred either due to a fault in an end system or in
  602.        the ATM network.  The error should be noted by ATM network
  603.        management for human examination and intervention.
  604.  
  605.    If the called endpoint incorrectly includes the Forward and Backward
  606.    Maximum CPCS-SDU Size fields in the CONNECT messages (e.g. because
  607.    the original SETUP message did not include these fields) or it sets
  608.    these fields to an invalid value, then the calling party shall clear
  609.    the call with cause "Invalid Information Element Contents".
  610.  
  611.  
  612.  
  613. Laubach+Halpern                                                [Page 11]
  614.  
  615. DRAFT                 Classical IP and ARP over ATM        November 1996
  616.  
  617.  
  618. 7.3  Path MTU Discovery Required
  619.  
  620.    The Path MTU Discovery mechanism is Internet Standard RFC-1191 [17]
  621.    and is an important mechanism for reducing IP fragmentation in the
  622.    Internet. This mechanism is particularly important because new subnet
  623.    ATM uses a default MTU sizes significantly different from older
  624.    subnet technologies such as Ethernet and FDDI.
  625.  
  626.    In order to ensure good performance throughout the Internet and also
  627.    to permit IP to take full advantage of the potentially larger IP
  628.    datagram sizes supported by ATM, all routers implementations that
  629.    comply or conform with this specification must also implement the IP
  630.    Path MTU Discovery mechanism as defined in RFC-1191 and clarified by
  631.    RFC-1435 [14]. Host implementations should implement the IP Path MTU
  632.    Discovery mechanism as defined in RFC-1191.
  633.  
  634. 8.  LIS ADDRESS RESOLUTION SERVICES
  635.  
  636. 8.1 ATM-based ARP and InARP Equivalent Services
  637.  
  638.    Address resolution within an ATM LIS SHALL make use of the ATM
  639.    Address Resolution Protocol (ATMARP) (based on [3]) and the Inverse
  640.    ATM Address Resolution Protocol (InATMARP) (based on [12]) and as
  641.    defined in this memo.  ATMARP is the same protocol as the ARP
  642.    protocol presented in [3] with extensions needed to support address
  643.    resolution in a unicast server ATM environment. InATMARP is the same
  644.    protocol as the original InARP protocol presented in [12] but applied
  645.    to ATM networks. All IP stations MUST support these protocols as
  646.    updated and extended in this memo.  Use of these protocols differs
  647.    depending on whether PVCs or SVCs are used.
  648.  
  649. 8.2 Permanent Virtual Connections
  650.  
  651.    An IP station MUST have a mechanism (e.g. manual configuration) for
  652.    determining what PVCs it has, and in particular which PVCs are being
  653.    used with LLC/SNAP encapsulation.  The details of the mechanism are
  654.    beyond the scope of this memo.
  655.  
  656.    All IP members supporting PVCs are required to use the Inverse ATM
  657.    Address Resolution Protocol (InATMARP) (refer to [12]) on those VCs
  658.    using LLC/SNAP encapsulation. In a strict PVC environment, the
  659.    receiver SHALL infer the relevant VC from the VC on which the
  660.    InATMARP_Request or response InATMARP_REPLY was received. When the
  661.    ATM source and/or target address is unknown, the corresponding ATM
  662.    address length in the InATMARP packet MUST be set to zero (0)
  663.    indicating a null length, and no storage be allocated in the InATMARP
  664.    packet, otherwise the appropriate address field should be filled in
  665.    and the corresponding length set appropriately. InATMARP packet
  666.  
  667.  
  668.  
  669. Laubach+Halpern                                                [Page 12]
  670.  
  671. DRAFT                 Classical IP and ARP over ATM        November 1996
  672.  
  673.  
  674.    format details are presented later in this memo.
  675.  
  676.    Directly from [12]: "When the requesting station receives the
  677.    In[ATM]ARP_Reply, it may complete the [ATM]ARP table entry and use
  678.    the provided address information. Note: as with [ATM]ARP, information
  679.    learned via In[ATM]ARP may be aged or invalidated under certain
  680.    circumstances." IP stations supporting PVCs MUST re-validate ATMARP
  681.    table entries as part of the table aging process. See the Section
  682.    8.5.1 "Client ATMARP Table Aging".
  683.  
  684.    If a client has more than one IP address within the LIS and if using
  685.    PVCs, when an InATMARP_Request is received an InATMARP_Reply MUST be
  686.    generated for each such address.
  687.  
  688.  
  689. 8.3 Switched Virtual Connections
  690.  
  691.    SVCs require support from address resolution services for resolving
  692.    target IP addresses to target ATM endpoint addresses. All members in
  693.    the LIS MUST use the same service. This service MUST have
  694.    authoritative responsibility for resolving the ATMARP requests of all
  695.    IP members within the LIS.
  696.  
  697.    ATMARP servers do not actively establish connections. They depend on
  698.    the clients in the LIS to initiate connections for the ATMARP
  699.    registration procedure and for transmitting ATMARP requests. An
  700.    individual client connects to the ATMARP server using a point-to-
  701.    point LLC/SNAP VC. The client sends normal ATMARP request packets to
  702.    the server. The ATMARP server examines each ATMARP_Request packet for
  703.    the source protocol and source hardware address information of the
  704.    sending client and uses this information to build its ATMARP table
  705.    cache. This information is used to generate replies to any ATMARP
  706.    requests it receives.
  707.  
  708.    InATMARP_Request packets MUST specify valid address information for
  709.    ATM source number, ATM target number, and source protocol address;
  710.    i.e., these fields MUST be non-null in InATMARP_Request packets.
  711.  
  712.    This memo defines the address resolution service in the LIS and
  713.    constrains it to consist of a single ATMARP server.  Client-server
  714.    interaction is defined by using a single server approach as a
  715.    reference model.
  716.  
  717.    This memo recognizes the future development of standards and
  718.    implementations of multiple-ATMARP-server models that will extend the
  719.    operations as defined in this memo to provide a highly reliable
  720.    address resolution service.
  721.  
  722.  
  723.  
  724.  
  725. Laubach+Halpern                                                [Page 13]
  726.  
  727. DRAFT                 Classical IP and ARP over ATM        November 1996
  728.  
  729.  
  730. 8.4 ATMARP Single Server Operational Requirements
  731.  
  732.    A single ATMARP server accepts ATM calls/connections from other ATM
  733.    end points.  After receiving any ATMARP_Request, the server will
  734.    examine the source and target address information in the packet and
  735.    make note of the VC on which the ATMARP_Request arrived. It will use
  736.    this information as necessary to build and update its ATMARP table
  737.    entries.
  738.  
  739.    For each ATMARP_Request, then:
  740.  
  741.    1.  If the source IP protocol address is the same as the target IP
  742.        protocol address and a table entry exists for that IP address and
  743.        if the source ATM hardware address does not match the table entry
  744.        ATM address and there is an open VC associated with that table
  745.        entry that is not the same as the VC associated with the
  746.        ATMARP_Request, the server MUST return the table entry
  747.        information in the ATMARP_Reply, and MUST raise a "duplicate IP
  748.        address detected" condition to the server's management. The table
  749.        entry is not updated.
  750.  
  751.    2.  Otherwise, if the source IP protocol address is the same as the
  752.        target IP protocol address, and either there is no table entry
  753.        for that IP address, or a table entry exists for that IP address
  754.        and there is no open VC associated with that table entry, or if
  755.        the VC associated with that entry is the same as the VC for the
  756.        ATMARP_Request, the server MUST either create a new entry or
  757.        update the old entry as appropriate and returns that table entry
  758.        information in the ATMARP Reply.
  759.  
  760.    3.  Otherwise, when the source IP protocol address does not match the
  761.        target IP protocol address, the ATMARP server will generate the
  762.        corresponding ATMARP_Reply if it has an entry for the target
  763.        information in its ATMARP table. Otherwise it will generate a
  764.        negative ATMARP reply (ATMARP_NAK).
  765.  
  766.    4.  Additionally, when the source IP protocol address does not match
  767.        the target IP protocol address and when the server receives an
  768.        ATMARP_Request over a VC, where the source IP and ATM address do
  769.        not have a corresponding table entry, the ATMARP server MUST
  770.        create a new table entry for the source information. Explanation:
  771.        this allows old RFC1577 clients to register with this ATMARP
  772.        service by just issuing requests to it.
  773.  
  774.    5.  Additionally, when the source IP protocol address does not match
  775.        the target IP protocol address and where the source IP and ATM
  776.        addresses match the association already in the ATMARP table and
  777.        the ATM address matches that associated with the VC, the server
  778.  
  779.  
  780.  
  781. Laubach+Halpern                                                [Page 14]
  782.  
  783. DRAFT                 Classical IP and ARP over ATM        November 1996
  784.  
  785.  
  786.        MUST update the table timeout on the source ATMARP table entry
  787.        but only if it has been more than 10 minutes since the last
  788.        update. Explanation: if the client is sending ATMARP requests to
  789.        the server over the same VC that it used to register its ATMARP
  790.        entry, the server should examine the ATMARP request and note that
  791.        the client is still "alive" by updating the timeout on the
  792.        client's ATMARP table entry.
  793.  
  794.    An ATMARP server MUST have knowledge of any open VCs it has and their
  795.    association with an ATMARP table entry, and in particular, which VCs
  796.    support LLC/SNAP encapsulation. In normal operation, active ATMARP
  797.    clients will revalidate their entries prior to the server aging
  798.    process taking effect.
  799.  
  800.    Server ATMARP table entries are valid for 20 minutes.  If an entry
  801.    ages beyond 20 minutes without being updated, that entry is deleted
  802.    from the table regardless of the state of any VCs that may be
  803.    associated with that entry.
  804.  
  805.  
  806. 8.5 ATMARP Client Operational Requirements
  807.  
  808.    The ATMARP client is responsible for contacting the ATMARP service to
  809.    register its own ATMARP information.
  810.  
  811.    The client is also responsible for using the ATMARP service to gain
  812.    and refresh entry/information about other IP members (server
  813.    selection overview is discussed in Section 8.6). As noted in Section
  814.    5.2, ATMARP clients MUST be configured with the ATM address(es) of
  815.    the appropriate servers prior to operation.
  816.  
  817.    IP clients MUST register their ATM endpoint address with their ATMARP
  818.    server using the ATM address structure appropriate for their ATM
  819.    network connection: i.e., LISs implemented over ATM LANs following
  820.    ATM Forum UNI 3.1 should register using Structure 1; LISs implemented
  821.    over an E.164 "public" ATM network should register using Structure 2.
  822.    A LIS implemented over a combination of ATM LANs and public ATM
  823.    networks may need to register using Structure 3.  Implementations
  824.    based on this memo MUST support all three ATM address structures.
  825.    See Section 8.7.1 for more details regarding the ATMARP Request
  826.    packet format.
  827.  
  828.    To handle the case when a client has more than one IP address within
  829.    a LIS, when using an ATMARP server, the client MUST register each
  830.    such address.
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837. Laubach+Halpern                                                [Page 15]
  838.  
  839. DRAFT                 Classical IP and ARP over ATM        November 1996
  840.  
  841.  
  842.    For operation, clients MUST:
  843.  
  844.    1.  Initiate the LLC/SNAP VC connection to a server in the ATMARP
  845.        service for transmitting and receiving ATMARP packets.
  846.  
  847.    2.  Immediately after opening a successful connection to the ATMARP
  848.        service, the client MUST transmit an ATMARP_Request packet,
  849.        requesting a target ATM address for its own IP address as the
  850.        target IP protocol address. The client checks the ATMARP_Reply
  851.        and if the source hardware and protocol addresses match the
  852.        respective target hardware and protocol addresses, the client is
  853.        registered with the ATMARP service. If the addresses do not
  854.        match, the client MAY take action, raise alarms, etc.; however,
  855.        these actions are beyond the scope of this memo.  In the case of
  856.        a client having more than one IP address in the list, this step
  857.        MUST be repeated for each IP address.
  858.  
  859.    3.  Clients MUST respond to ATMARP_Request and InATMARP_Request
  860.        packets received on any VC appropriately. (Refer to Section 7,
  861.        "Protocol Operation" in RFC1293 [12].)
  862.  
  863.    4.  Generate and transmit address resolution request packets to the
  864.        address resolution service.  Respond to address resolution reply
  865.        packets appropriately to build/refresh its own client ATMARP
  866.        table entries.
  867.  
  868.    5.  Generate and transmit InATMARP_Request packets as needed and to
  869.        process InATMARP_Reply packets appropriately.  InATMARP_Reply
  870.        packets should be used to build/refresh its own client ATMARP
  871.        table entries.  (Refer to Section 7, "Protocol Operation" in
  872.        [12].)  If a client has more than one IP address within the LIS
  873.        when an InATMARP_Request is received an InATMARP_Reply MUST be
  874.        generated for each such address.
  875.  
  876.    If the client does not maintain an open VC to the server, the client
  877.    MUST refresh its ATMARP information with the server at least once
  878.    every 15 minutes. This is done by repeating steps 1 and 2.
  879.  
  880.    An ATMARP client MUST have knowledge of any open VCs it has
  881.    (permanent or switched), their association with an ATMARP table
  882.    entry, and in particular, which VCs support LLC/SNAP encapsulation.
  883.  
  884. 8.5.1 Client ATMARP Table Aging
  885.  
  886.    Client ATMARP table entries are valid for a maximum time of 15
  887.    minutes.
  888.  
  889.    When an ATMARP table entry ages, an ATMARP client MUST invalidate the
  890.  
  891.  
  892.  
  893. Laubach+Halpern                                                [Page 16]
  894.  
  895. DRAFT                 Classical IP and ARP over ATM        November 1996
  896.  
  897.  
  898.    table entry. If there is no open VC associated with the invalidated
  899.    entry, that entry is deleted. In the case of an invalidated entry and
  900.    an open VC, the client MUST revalidate the entry prior to
  901.    transmitting any non address resolution traffic on that VC; this
  902.    requirement applies to both PVCs and SVCs.  NOTE: the client is
  903.    permitted to revalidate an ATMARP table entry before it ages, thus
  904.    restarting the aging time when the table entry is successfully
  905.    revalidate.  The client MAY continue to use the open VC, as long as
  906.    the table entry has not aged, while revalidation is in progress.
  907.  
  908.    In the case of an open PVC, the client revalidates the entry by
  909.    transmitting an InATMARP_REQUEST and updating the entry on receipt of
  910.    an InATMARP_REPLY.
  911.  
  912.    In the case of an open SVC, the client revalidates the entry by
  913.    querying the address resolution service.  If a valid reply is
  914.    received (e.g., ATMARP_Reply), the entry is updated.  If the address
  915.    resolution service cannot resolve the entry (i.e., "host not found"),
  916.    the SVC should be closed and the associated table entry removed.  If
  917.    the address resolution service is not available (i.e. "server
  918.    failure") and if the SVC is LLC/SNAP encapsulated, the client MUST
  919.    attempt to revalidate the entry by transmitting an InATMARP_Request
  920.    on that VC and updating the entry on receipt of an InATMARP_Reply. If
  921.    the InATMARP_Request attempt fails to return an InATMARP_Reply, the
  922.    SVC should be closed and the associated table entry removed.
  923.  
  924.    If a VC with an associated invalidated ATMARP table entry is closed,
  925.    that table entry is removed.
  926.  
  927. 8.5.2 Non-Normal VC Operations
  928.  
  929.    The specific details on client procedures for detecting non-normal VC
  930.    connection establishment or closures, or failed communications on an
  931.    established VC are beyond the scope of this memo. It is REQUIRED
  932.    however, that the client MUST remove the associated ATMARP entry for
  933.    a VC that fails to operate properly, as defined by the client, when
  934.    the client closes that VC, when it releases its resources for a VC,
  935.    or prior to any attempt to reopen that VC. This behavior specifically
  936.    REQUIRES that the client MUST refresh its ATMARP table information
  937.    prior to any attempt to re-establish communication to an IP member
  938.    after a non-normal communications problem has occurred on a VC
  939.    previously to that IP member.
  940.  
  941.  
  942. 8.6 Address Resolution Server Selection
  943.  
  944.    If the client supports PVCs only, the ATMARP server list is empty and
  945.    the client MUST not generate any address resolution requests other
  946.  
  947.  
  948.  
  949. Laubach+Halpern                                                [Page 17]
  950.  
  951. DRAFT                 Classical IP and ARP over ATM        November 1996
  952.  
  953.  
  954.    than the InATMARP requests on a PVC needed to validate that PVC.
  955.  
  956.    If the client supports SVCs, then the client MUST have an non-NULL
  957.    atm$arp-req-list pointing to the ATMARP server(s) which provide
  958.    ATMARP service for the LIS.
  959.  
  960.    The client MUST register with a server from atm$arp-req-list.
  961.  
  962.    The client SHALL attempt to communicate with any of the servers until
  963.    a successful registration is accomplished.  The order in which client
  964.    selects servers to attempt registration, is a local matter, as are
  965.    the number of retries and timeouts for such attempts.
  966.  
  967. 8.6.1 PVCs to ATMARP Servers
  968.  
  969.    In a mixed PVC and SVC LIS environment, an ATMARP client MAY have a
  970.    PVC to an ATMARP server.  In this case, this PVC is used for ATMARP
  971.    requests and responses as if it were an established SVC.  NOTE: if
  972.    this PVC is to be used for IP traffic, then the ATMARP server MUST be
  973.    prepared to accept and respond appropriately to InATMARP traffic.
  974.  
  975. 8.7 ATMARP Packet Formats
  976.  
  977.    Internet addresses are assigned independently of ATM addresses.  Each
  978.    host implementation MUST know its own IP and ATM address(es) and MUST
  979.    respond to address resolution requests appropriately.  IP members
  980.    MUST also use ATMARP and InATMARP to resolve IP addresses to ATM
  981.    addresses when needed.
  982.  
  983.    Note: the ATMARP packet format presented in this memo is general in
  984.    nature in that the ATM number and ATM subaddress fields SHOULD map
  985.    directly to the corresponding UNI 3.1 fields used for ATM
  986.    call/connection setup signalling messages.  The IP over ATM Working
  987.    Group expects ATM Forum NSAPA numbers (Structure 1) to predominate
  988.    over E.164 numbers (Structure 2) as ATM endpoint identifiers within
  989.    ATM LANs.  The ATM Forum's VC Routing specification is not complete
  990.    at this time and therefore its impact on the operational use of ATM
  991.    Address Structure 3 is undefined. The ATM Forum will be defining this
  992.    relationship in the future.  It is for this reason that IP members
  993.    need to support all three ATM address structures.
  994.  
  995. 8.7.1 ATMARP/InATMARP Request and Reply Packet Formats
  996.  
  997.    The ATMARP and InATMARP request and reply protocols use the same
  998.    hardware type (ar$hrd), protocol type (ar$pro), and operation code
  999.    (ar$op) data formats as the ARP and InARP protocols [3,12].  The
  1000.    location of these three fields within the ATMARP packet are in the
  1001.    same byte position as those in ARP and InARP packets.  A unique
  1002.  
  1003.  
  1004.  
  1005. Laubach+Halpern                                                [Page 18]
  1006.  
  1007. DRAFT                 Classical IP and ARP over ATM        November 1996
  1008.  
  1009.  
  1010.    hardware type value has been assigned for ATMARP.  In addition,
  1011.    ATMARP makes use of an additional operation code for ARP_NAK.  The
  1012.    remainder of the ATMARP/InATMARP packet format is different than the
  1013.    ARP/InARP packet format.
  1014.  
  1015.    The ATMARP and InATMARP protocols have several fields that have the
  1016.    following format and values:
  1017.  
  1018.    Data:
  1019.      ar$hrd   16 bits  Hardware type
  1020.      ar$pro   16 bits  Protocol type
  1021.      ar$shtl   8 bits  Type & length (TL) of source ATM number (q)
  1022.      ar$sstl   8 bits  Type & length (TL) of source ATM subaddress (r)
  1023.      ar$op    16 bits  Operation code (request, reply, or NAK)
  1024.      ar$spln   8 bits  Length of source protocol address (s)
  1025.      ar$thtl   8 bits  Type & length (TL) of target ATM number (x)
  1026.      ar$tstl   8 bits  Type & length (TL) of target ATM subaddress (y)
  1027.      ar$tpln   8 bits  Length of target protocol address (z)
  1028.      ar$sha   qoctets of source ATM number
  1029.      ar$ssa   roctets of source ATM subaddress
  1030.      ar$spa   soctets of source protocol address
  1031.      ar$tha   xoctets of target ATM number
  1032.      ar$tsa   yoctets of target ATM subaddress
  1033.      ar$tpa   zoctets of target protocol address
  1034.  
  1035.    Where:
  1036.      ar$hrd  -  assigned to ATM Forum address family and is
  1037.                 19 decimal (0x0013) [4].
  1038.  
  1039.      ar$pro  -  see Assigned Numbers for protocol type number for
  1040.                 the protocol using ATMARP. (IP is 0x0800).
  1041.  
  1042.      ar$shtl -  Type and length of source ATM number.  See
  1043.                 Section 8.7.4 for TL encoding details.
  1044.  
  1045.      ar$sstl -  Type and length of source ATM subaddress.  See
  1046.                 Section 8.7.4 for TL encoding details.
  1047.  
  1048.      ar$op   -  The operation type value (decimal):
  1049.  
  1050.                 ATMARP_Request   = ARP_REQUEST   = 1
  1051.                 ATMARP_Reply     = ARP_REPLY     = 2
  1052.                 InATMARP_Request = InARP_REQUEST = 8
  1053.                 InATMARP_Reply   = InARP_REPLY   = 9
  1054.                 ATMARP_NAK       = ARP_NAK       = 10
  1055.  
  1056.      ar$spln -  length in octets of the source protocol address. Value
  1057.                 range is 0 or 4 (decimal).  For IPv4 ar$spln is 4.
  1058.  
  1059.  
  1060.  
  1061. Laubach+Halpern                                                [Page 19]
  1062.  
  1063. DRAFT                 Classical IP and ARP over ATM        November 1996
  1064.  
  1065.  
  1066.      ar$thtl -  Type and length of target ATM number.  See
  1067.                 Section 8.7.4 for TL encoding details.
  1068.  
  1069.      ar$tstl -  Type and length of target ATM subaddress.  See
  1070.                 Section 8.7.4 for TL encoding details.
  1071.  
  1072.      ar$tpln -  length in octets of the target protocol address. Value
  1073.                 range is 0 or 4 (decimal).  For IPv4 ar$tpln is 4.
  1074.  
  1075.      ar$sha  -  source ATM number (E.164 or ATM Forum NSAPA)
  1076.  
  1077.      ar$ssa  -  source ATM subaddress (ATM Forum NSAPA)
  1078.  
  1079.      ar$spa  -  source protocol address
  1080.  
  1081.      ar$tha  -  target ATM number (E.164 or ATM Forum NSAPA)
  1082.  
  1083.      ar$tsa  -  target ATM subaddress (ATM Forum NSAPA)
  1084.  
  1085.      ar$tpa  -  target protocol address
  1086.  
  1087. 8.7.2 Receiving Unknown ATMARP packets
  1088.  
  1089.    If an ATMARP client receives an ATMARP message with an operation code
  1090.    (ar$op) for which it is not coded to support, it MUST gracefully
  1091.    discard the message and continue normal operation.  An ATMARP client
  1092.    is NOT REQUIRED to return any message to the sender of the
  1093.    unsupported message.
  1094.  
  1095. 8.7.3 TL, ATM Number, and ATM Subaddress Encoding
  1096.  
  1097.    The encoding of the 8-bit TL (type and length) fields in ATMARP and
  1098.    In_ATMARP packets is as follows:
  1099.  
  1100.  
  1101.      MSB   8     7     6     5     4     3     2     1   LSB
  1102.         +-----+-----+-----+-----+-----+-----+-----+-----+
  1103.         |  0  | 1/0 |   Octet length of address         |
  1104.         +-----+-----+-----+-----+-----+-----+-----+-----+
  1105.  
  1106.    Where:
  1107.      bit.8   (reserved) = 0  (for future use)
  1108.  
  1109.      bit.7   (type)     = 0  ATM Forum NSAPA format
  1110.                         = 1  E.164 format
  1111.  
  1112.      bit.6-1 (length)   = 6 bit unsigned octet length of address
  1113.                           (MSB = bit.6, LSB = bit.1)  Value
  1114.  
  1115.  
  1116.  
  1117. Laubach+Halpern                                                [Page 20]
  1118.  
  1119. DRAFT                 Classical IP and ARP over ATM        November 1996
  1120.  
  1121.  
  1122.                           range is from 0 to 20 (decimal).
  1123.  
  1124.    ATM addresses, as defined by the ATM Forum UNI 3.1 signaling
  1125.    specification [9], include a "Calling Party Number Information
  1126.    Element" and a "Calling Party Subaddress Information Element". These
  1127.    Information Elements (IEs) SHOULD map to ATMARP/InATMARP source ATM
  1128.    number and source ATM subaddress respectively. Furthermore, ATM Forum
  1129.    defines a "Called Party Number Information Element" and a "Called
  1130.    Party Subaddress Information Element".  These IEs map to
  1131.    ATMARP/InATMARP target ATM number and target ATM subaddress
  1132.    respectively.
  1133.  
  1134.    The ATM Forum defines three structures for the combined use of number
  1135.    and subaddress [9]:
  1136.  
  1137.                         ATM Number      ATM Subaddress
  1138.                       --------------    --------------
  1139.         Structure 1   ATM Forum NSAPA        null
  1140.         Structure 2       E.164              null
  1141.         Structure 3       E.164         ATM Forum NSAPA
  1142.  
  1143.    ATMARP and InATMARP requests and replies for ATM address structures 1
  1144.    and 2 MUST indicate a null or unknown ATM subaddress by setting the
  1145.    appropriate subaddress length to zero; i.e. ar$sstl.length = 0 or
  1146.    ar$tstl.length = 0, the corresponding type field (ar$sstl.type or
  1147.    ar$tstl.type) MUST be ignored and the physical space for the ATM
  1148.    subaddress buffer MUST not be allocated in the ATMARP packet. For
  1149.    example, if ar$sstl.length=0, the storage for the source ATM
  1150.    subaddress is not allocated and the first byte of the source protocol
  1151.    address ar$spa follows immediately after the last byte of the source
  1152.    hardware address ar$sha in the packet.
  1153.  
  1154.    Null or unknown ATM addresses are MUST be indicated by setting the
  1155.    appropriate address length to zero; i.e., ar$shtl.length and
  1156.    ar$thtl.length is zero and the corresponding type field (ar$sstl.type
  1157.    or ar$tstl.type) MUST be ignored and the physical space for the ATM
  1158.    address or ATM subaddress buffer MUST not be allocated in the ATMARP
  1159.    packet.
  1160.  
  1161. 8.7.4 ATMARP_NAK Packet Format
  1162.  
  1163.    The ATMARP_NAK packet format is the same as the received
  1164.    ATMARP_Request packet format with the operation code set to ARP_NAK,
  1165.    i.e., the ATMARP_Request packet data is exactly copied (e.g. using
  1166.    bcopy) for transmission with the ATMARP_Request operation code
  1167.    changed to ARP_NAK value.
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173. Laubach+Halpern                                                [Page 21]
  1174.  
  1175. DRAFT                 Classical IP and ARP over ATM        November 1996
  1176.  
  1177.  
  1178. 8.7.5 Variable Length Requirements for ATMARP Packets
  1179.  
  1180.    ATMARP and InATMARP packets are variable in length.
  1181.  
  1182.    A null or unknown source or target protocol address is indicated by
  1183.    the corresponding length set to zero: e.g., when ar$spln or ar$tpln
  1184.    is zero the physical space for the corresponding address structure
  1185.    MUST not be allocated in the packet.
  1186.  
  1187.    For backward compatibility with previous implementations, a null IPv4
  1188.    protocol address may be received with length = 4 and an allocated
  1189.    address in storage set to the value 0.0.0.0. Receiving stations MUST
  1190.    be liberal in accepting this format of a null IPv4 address, however
  1191.    on transmitting an ATMARP or InATMARP packet, a null IPv4 address
  1192.    MUST only be indicated by the length set to zero and MUST have no
  1193.    storage allocated.
  1194.  
  1195. 8.8 ATMARP/InATMARP Packet Encapsulation
  1196.  
  1197.    ATMARP and InATMARP packets are to be encoded in AAL5 PDUs using
  1198.    LLC/SNAP encapsulation. The format of the AAL5 CPCS-SDU payload field
  1199.    for ATMARP/InATMARP PDUs is:
  1200.  
  1201.                Payload Format for ATMARP/InATMARP PDUs:
  1202.                +------------------------------+
  1203.                |        LLC 0xAA-AA-03        |
  1204.                +------------------------------+
  1205.                |        OUI 0x00-00-00        |
  1206.                +------------------------------+
  1207.                |     Ethertype 0x08-06        |
  1208.                +------------------------------+
  1209.                |                              |
  1210.                |   ATMARP/InATMARP Packet     |
  1211.                |                              |
  1212.                +------------------------------+
  1213.  
  1214.    The LLC value of 0xAA-AA-03 (3 octets) indicates the presence of a
  1215.    SNAP header.
  1216.  
  1217.    The OUI value of 0x00-00-00 (3 octets) indicates that the following
  1218.    two-bytes is an ethertype.
  1219.  
  1220.    The Ethertype value of 0x08-06 (2 octets) indicates ARP [4].
  1221.  
  1222.    The total size of the LLC/SNAP header is fixed at 8-octets. This
  1223.    aligns the start of the ATMARP packet on a 64-bit boundary relative
  1224.    to the start of the AAL5 CPCS-SDU.
  1225.  
  1226.  
  1227.  
  1228.  
  1229. Laubach+Halpern                                                [Page 22]
  1230.  
  1231. DRAFT                 Classical IP and ARP over ATM        November 1996
  1232.  
  1233.  
  1234.    The LLC/SNAP encapsulation for ATMARP/InATMARP presented here is
  1235.    consistent with the treatment of multiprotocol encapsulation of IP
  1236.    over ATM AAL5 as specified in [2] and in the format of ATMARP over
  1237.    IEEE 802 networks as specified in [5].
  1238.  
  1239.    Traditionally, address resolution requests are broadcast to all
  1240.    directly connected IP members within a LIS. It is conceivable in the
  1241.    future that larger scaled ATM networks may handle ATMARP requests to
  1242.    destinations outside the originating LIS, perhaps even globally;
  1243.    issues raised by ATMARPing outside the LIS or by a global ATMARP
  1244.    mechanism are beyond the scope of this memo.
  1245.  
  1246. 9.  IP BROADCAST ADDRESS
  1247.  
  1248.    ATM does not support broadcast addressing, therefore there are no
  1249.    mappings available from IP broadcast addresses to ATM broadcast
  1250.    services. Note: this lack of mapping does not restrict members from
  1251.    transmitting or receiving IP datagrams specifying any of the four
  1252.    standard IP broadcast address forms as described in [8].  Members,
  1253.    upon receiving an IP broadcast or IP subnet broadcast for their LIS,
  1254.    MUST process the packet as if addressed to that station.
  1255.  
  1256.    This memo recognizes the future development of standards and
  1257.    implementations that will extend the operations as defined in this
  1258.    memo to provide an IP broadcast capability for use by the classical
  1259.    client.
  1260.  
  1261. 10.  IP MULTICAST ADDRESS
  1262.  
  1263.    ATM does not directly support IP multicast address services,
  1264.    therefore there are no mappings available from IP multicast addresses
  1265.    to ATM multicast services.  Current IP multicast implementations
  1266.    (i.e., MBONE and IP tunneling, see [10]) will continue to operate
  1267.    over ATM based logical IP subnets if operated in the WAN
  1268.    configuration.
  1269.  
  1270.    This memo recognizes the future development of ATM multicast service
  1271.    addressing by the ATM Forum. When available and widely implemented,
  1272.    the roll-over from the current IP multicast architecture to this new
  1273.    ATM architecture will be straightforward.
  1274.  
  1275.    This memo recognizes the future development of standards and
  1276.    implementations that will extend the operations as defined in this
  1277.    memo to provide an IP multicast capability for use by the classical
  1278.    client.
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285. Laubach+Halpern                                                [Page 23]
  1286.  
  1287. DRAFT                 Classical IP and ARP over ATM        November 1996
  1288.  
  1289.  
  1290. 11.  SECURITY
  1291.  
  1292.    Not all of the security issues relating to IP over ATM are clearly
  1293.    understood at this time, due to the fluid state of ATM
  1294.    specifications, newness of the technology, and other factors.
  1295.  
  1296.    It is believed that ATM and IP facilities for authenticated call
  1297.    management, authenticated end-to-end communications, and data
  1298.    encryption will be needed in globally connected ATM networks.  Such
  1299.    future security facilities and their use by IP networks are beyond
  1300.    the scope of this memo.
  1301.  
  1302.    There are known security issues relating to host impersonation via
  1303.    the address resolution protocols used in the Internet [13].  No
  1304.    special security mechanisms have been added to the address resolution
  1305.    mechanism defined here for use with networks using IP over ATM.
  1306.  
  1307. 12.  MIB SPECIFICATION
  1308.  
  1309.    Clients built to this specification MUST implement and provide a
  1310.    Management Information Base (MIB) as defined in "Definitions of
  1311.    Managed Objects for Classical IP and ARP Over ATM Using SMIv2" [18].
  1312.  
  1313. 13.  OPEN ISSUES
  1314.  
  1315.    o   Automatic configuration of client ATM addresses via DHCP [15] or
  1316.        via ATM UNI 3.1 Interim Local Management Interface (ILMI)
  1317.        services would be a useful extended service addition to this
  1318.        document and should be addressed in a separate memo.
  1319.  
  1320.    o   ATMARP packets are not authenticated.  This is a potentially
  1321.        serious flaw in the overall system by allowing a mechanism by
  1322.        which corrupt information may be introduced into the server
  1323.        system.
  1324.  
  1325.  
  1326. 14. REFERENCES
  1327.  
  1328.    [1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS
  1329.        Service", RFC-1209, USC/Information Sciences Institute, March
  1330.        1991.
  1331.  
  1332.    [2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation
  1333.        Layer 5", RFC-1483, USC/Information Sciences Institute, July
  1334.        1993.
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341. Laubach+Halpern                                                [Page 24]
  1342.  
  1343. DRAFT                 Classical IP and ARP over ATM        November 1996
  1344.  
  1345.  
  1346.    [3] Plummer, D., "An Ethernet Address Resolution Protocol - or -
  1347.        Converting Network Addresses to 48.bit Ethernet Address for
  1348.        Transmission on Ethernet Hardware", RFC-826, MIT, November 1982.
  1349.  
  1350.    [4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1340, USC/
  1351.        Information Sciences Institute, July 1992.
  1352.  
  1353.    [5] Postel, J., and Reynolds, J., "A Standard for the Transmission of
  1354.        IP Datagrams over IEEE 802 Networks", RFC-1042, USC/Information
  1355.        Sciences Institute, February 1988.
  1356.  
  1357.    [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII,
  1358.        Geneva, 19-29 January 1993.
  1359.  
  1360.    [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September
  1361.        - 2 October 1992.
  1362.  
  1363.    [8] Braden, R., "Requirements for Internet Hosts -- Communication
  1364.        Layers", RFC-1122, USC/Information Sciences Institute, October
  1365.        1989.
  1366.  
  1367.    [9] ATM Forum, "ATM User-Network Interface (UNI) Specification
  1368.        Version 3.1.", ISBN 0-13-393828-X, Prentice-Hall, Inc., Upper
  1369.        Saddle River, NJ, 07458, September, 1994.
  1370.  
  1371.    [10] Deering, S, "Host Extensions for IP Multicasting", RFC-1112,
  1372.        USC/Information Sciences Institute, August 1989.
  1373.  
  1374.    [11] Colella, Richard, and Gardner, Ella, and Callon, Ross,
  1375.        "Guidelines for OSI NSAP Allocation in the Internet", RFC-1237,
  1376.        USC/Information Sciences Institute, July 1991.
  1377.  
  1378.    [12] Bradely, T., and Brown, C., "Inverse Address Resolution
  1379.        Protocol", RFC-1293, USC/Information Sciences Institute, January
  1380.        1992.
  1381.  
  1382.    [13] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol
  1383.        Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp.
  1384.        32-48, 1989.
  1385.  
  1386.    [14] Knowles, S., "IESG Advice from Experience with Path MTU
  1387.        Discovery, RFC-1435, IESG, March 1993.
  1388.  
  1389.    [15] Droms, R., "Dynamic Host Configuration Protocol", RFC1541,
  1390.        Bucknell University, October 1993.
  1391.  
  1392.  
  1393.  
  1394.  
  1395.  
  1396.  
  1397. Laubach+Halpern                                                [Page 25]
  1398.  
  1399. DRAFT                 Classical IP and ARP over ATM        November 1996
  1400.  
  1401.  
  1402.    [16] Kent C., and J. Mogul, "Fragmentation Considered Harmful",
  1403.        Proceedings of the ACM SIGCOMM '87 Workshop on Frontiers in
  1404.        Computer Communications Technology, August 1987.
  1405.  
  1406.    [17] Mogul, J., and S. Deering, "Path MTU Discovery", RFC-1191,
  1407.        DECWRL, Stanford University, November 1990.
  1408.  
  1409.    [18] Green, M., Luciani, J., White, K., Kuo, T., "Definitions of
  1410.        Managed Objects for Classical IP and ARP over ATM Using SMIv2",
  1411.        IETF, draft-ietf-ipatm-mib-01 (work in progress), February, 1996.
  1412.  
  1413. 15. AUTHORS
  1414.  
  1415.    Mark Laubach
  1416.    Com21, Inc.
  1417.    750 Tasman Drive
  1418.    Milpitas, CA 95035
  1419.  
  1420.    Phone: 408.953.9175
  1421.    FAX:   408.953.9299
  1422.    EMail: laubach@com21.com
  1423.  
  1424.  
  1425.    Joel Halpern
  1426.    Newbridge Networks, Inc.
  1427.    593 Herndon Parkway
  1428.    Herndon, VA  22070-5241
  1429.  
  1430.    Phone: 703.736.5954
  1431.    FAX:   703.736.5959
  1432.    EMail: jhalpern@Newbridge.com
  1433.  
  1434.  
  1435.  
  1436.  
  1437.  
  1438.  
  1439.  
  1440.  
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453. Laubach+Halpern                                                [Page 26]
  1454.  
  1455.