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-discov-atmarp-00.txt < prev    next >
Text File  |  1997-08-21  |  10KB  |  358 lines
  1.  
  2.  
  3.  
  4. Internet-Draft                                           Mike Davison
  5.                                                          Cisco Systems
  6.                                                          August 21, 1997
  7.  
  8.  
  9.  
  10.                  ILMI-Based Server Discovery for ATMARP
  11.                  <draft-ietf-ion-discov-atmarp-00.txt>
  12.  
  13.  
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This document is an Internet-Draft.  Internet-Drafts are working
  19.    documents of the Internet Engineering Task Force (IETF), its areas,
  20.    and its working groups.  Note that other groups may also distribute
  21.    working documents as Internet-Drafts.
  22.  
  23.    Internet-Drafts are draft documents valid for a maximum of six months
  24.    and may be updated, replaced, or obsoleted by other documents at any
  25.    time.  It is inappropriate to use Internet- Drafts as reference
  26.    material or to cite them other than as "work in progress."
  27.  
  28.    To view the entire list of current Internet-Drafts, please check the
  29.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  30.    Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
  31.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  32.    ftp.isi.edu (US West Coast).
  33.  
  34.  
  35. Abstract
  36.  
  37.  
  38.    This memo defines how ILMI-based Server Discovery, which provides a
  39.    method for ATM-attached hosts and routers to dynamically determine
  40.    the ATM address of servers,  shall be used to locate ATMARP servers.
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55. Davison                Expires February 21, 1998                [Page 1]
  56.  
  57.  
  58.  
  59.  
  60.  
  61. Internet Draft                                           August 21, 1997
  62.  
  63.  
  64. 1. Introduction
  65.  
  66.  
  67.    Presently, configuring a host or router to use ATMARP [1,2] is
  68.    cumbersome and error-prone since it requires at least one ATM
  69.    addresses to be statically configured on each host or router in the
  70.    network.  Further, it is impossible to implement a diskless host to
  71.    use ATMARP since local configuration is required.  ILMI-based Server
  72.    Discovery, hereafter referred to as "server discovery," provides a
  73.    solution to these problems.
  74.  
  75.    A brief overview of the Service Registry MIB, as defined by the ATM
  76.    Forum, is provided in this memo. The reader should consult [3] for a
  77.    complete description of this MIB, but the information contained here
  78.    is sufficient for an understanding of its use to support ATMARP
  79.    server discovery.
  80.  
  81.  
  82. 2. ILMI 4.0 Service Registry MIB
  83.  
  84.  
  85.    Server discovery utilizes the Service Registry MIB defined by the ATM
  86.    Forum in ILMI Specification Version 4.0 [3]. To support the existing
  87.    framework for IP over ATM, ATM switches must support the Service
  88.    Registry MIB.
  89.  
  90.    A row in the service registry table [3] is defined as:
  91.  
  92.       AtmfSrvcRegEntry ::= SEQUENCE {
  93.           atmfSrvcRegPort          INTEGER,
  94.           atmfSrvcRegServiceID     OBJECT IDENTIFIER,
  95.           atmfSrvcRegATMAddress    AtmAddress,
  96.           atmfSrvcRegAddressIndex  INTEGER,
  97.           atmfSrvcRegParm1         OCTET STRING
  98.       }
  99.  
  100.    The definition of each field in this structure is:
  101.  
  102.       atmfSrvcRegPort - The port number for which this entry contains
  103.           management information. The value of zero may be used to
  104.           indicate the ATM interface over which a management request
  105.           was received.
  106.  
  107.       atmfSrvcRegServiceID - This is the service identifier which
  108.           uniquely identifies the type of service at the address
  109.           provided in the table. (See Appendix for ATMARP OID.)
  110.  
  111.       atmfSrvcRegATMAddress - This is the full address of the service.
  112.  
  113.  
  114.  
  115. Davison                Expires February 21, 1998                [Page 2]
  116.  
  117.  
  118.  
  119.  
  120.  
  121. Internet Draft                                           August 21, 1997
  122.  
  123.  
  124.           The ATM client will use this address to establish a connection
  125.           with the service.
  126.  
  127.       atmfSrvcRegAddressIndex - An arbitrary integer to differentiate
  128.           multiple rows containing different ATM addresses for the same
  129.           service on the same port.
  130.  
  131.       atmfSrvcRegParm1 - An octet string whose size and meaning is
  132.           determined by the value of atmfSrvcRegServiceID.
  133.  
  134.    The service registry table is indexed by atmfSrvcRegPort,
  135.    atmfSrvcRegServiceID and atmfSrvcRegAddressIndex.
  136.  
  137.  
  138. 3. Service Parameter String
  139.  
  140.  
  141.    A generic parameter string is defined in the service registry table,
  142.    thus allowing protocol-specific parameters to be specified. To be
  143.    consistent with [1,2], the parameter string for ATMARP shall be:
  144.  
  145.        ar$pro   16 bits    Protocol type
  146.        ar$plen   8 bits    Length of protocol address (a)
  147.        ar$addr  a octets   Network address
  148.        ar$mask  a octets   Network mask
  149.  
  150.    Where
  151.  
  152.        ar$pro  - see Assigned Numbers for protocol type number for
  153.                  protocol using ATMARP. (IPv4 is 0x0800, IPv6 is 0x86DD)
  154.  
  155.        ar$plen - Length of the protocol address. (IPv4 is 4, IPv6 is 16)
  156.  
  157.        ar$addr - Network address represented in network byte order
  158.  
  159.        ar$mask - Network mask represented in network byte order
  160.  
  161.  
  162. 4. ATMARP Client Behavior
  163.  
  164.  
  165.    An ATMARP client will access the service registry table via ILMI
  166.    using the SNMP GetNext operator to "sweep" (SNMP parlance for a
  167.    linear search) beginning with {Port = 0, ServiceID = <see Appendix>,
  168.    Index = 0} while holding the port number and the serviceID constant.
  169.    (Port number 0 is used within ILMI to indicate "this port.")
  170.  
  171.    An ATMARP client with no local configuration, such as a diskless
  172.  
  173.  
  174.  
  175. Davison                Expires February 21, 1998                [Page 3]
  176.  
  177.  
  178.  
  179.  
  180.  
  181. Internet Draft                                           August 21, 1997
  182.  
  183.  
  184.    workstation, must use the row with the lowest index value if multiple
  185.    ATMARP servers, possibly for multiple networks, are listed.
  186.  
  187.    ATMARP clients that have local IP configuration must use a row that
  188.    has the appropriate IP address.  For example, consider the case where
  189.    an IP router has 3 logical interfaces defined on a single physical
  190.    interface with IP addresses 1.0.0.1/8, 128.10.0.1/16 and
  191.    171.69.150.226/24. The router will sweep the service registry table
  192.    looking for a rows that have atmfSrvcRegParm1 values as shown below:
  193.  
  194.        Network number/mask  atmfSrvcRegParm1
  195.        -------------------- --------------------------------------
  196.        1.0.0.0/8            08 00   04   01 00 00 00   ff 00 00 00
  197.        128.10.0.0/16        08 00   04   80 0a 00 00   ff ff 00 00
  198.        171.69.150.0/24      08 00   04   ab 45 96 00   ff ff ff 00
  199.  
  200.    When the correct atmfSrvcRegParm1 values are located, the router may
  201.    then establish an SVC to the selected server and perform the
  202.    appropriate protocol operations.
  203.  
  204.    Redundant ATMARP servers are supported with multiple rows in the
  205.    service registry table. This list of ATMARP servers is ordered with
  206.    the primary ATMARP server having the lowest index value. The ATMARP
  207.    client must attempt to utilize the primary ATMARP server before
  208.    utilizing a secondary ATMARP server. Administrators must ensure that
  209.    the listed ATMARP servers are synchronized via [4].
  210.  
  211.  
  212. 5. ATMARP Server Behavior
  213.  
  214.  
  215.    An ATMARP server shall be locally configured. The ATMARP server may
  216.    retrieve the ATMARP service registry data to validate the results. If
  217.    an incorrect row is retrieved the error may be flagged in a locally
  218.    significant way.
  219.  
  220.  
  221. 6. Relationship with PNNI Augmented Routing
  222.  
  223.  
  224.    An augmented version PNNI ("PNNI Augmented Routing," or PAR) [5] is
  225.    being developed by the ATM Forum. PAR could potentially distribute
  226.    data such as ATMARP server addresses. Further, the ATM Forum is
  227.    developing a proxy mechanism for PAR (Proxy PAR) [6] that would allow
  228.    a UNI-attached host or router to access PAR data without a full PAR
  229.    implementation.
  230.  
  231.    These mechanisms offer a promising way to manage the service registry
  232.  
  233.  
  234.  
  235. Davison                Expires February 21, 1998                [Page 4]
  236.  
  237.  
  238.  
  239.  
  240.  
  241. Internet Draft                                           August 21, 1997
  242.  
  243.  
  244.    tables maintained on each switch in an ATM network, yet would not
  245.    require changes to the mechanism defined in this memo. Hosts and
  246.    routers can continue to utilize ILMI-based or Proxy PAR-based server
  247.    discovery and network administrators could manage the service
  248.    registry data with local configuration or via PAR and Proxy PAR.
  249.  
  250.  
  251. 7. Security Considerations
  252.  
  253.  
  254.    The server discovery mechanism is intended for environments where a
  255.    given ATM switch and its attached hosts or routers are in the same
  256.    administrative domain, hence no authentication is required.
  257.  
  258.  
  259. Appendix - ATMARP Server Discovery MIB
  260.  
  261.  
  262.      SERVER-DISCOVERY-ATMARP DEFINITIONS ::= BEGIN
  263.  
  264.      --
  265.      -- This OID names ATMARP within the context of server discovery.
  266.      -- It does not name any managed objects.
  267.      --
  268.      serverDiscoveryATMARP   OBJECT IDENTIFIER   ::= <TBD>
  269.  
  270.      END
  271.  
  272.  
  273.  
  274. References
  275.  
  276.  
  277.       [1]  Laubach, M., "Classical IP and ARP over ATM," RFC 1577,
  278.       Hewlett-Packard Laboratories, December 1993.
  279.  
  280.       [2]  Laubach, M. Halpern, J., "Classical IP and ARP over ATM,"
  281.       draft-ietf-ion-classic2-02.txt, (update to RFC 1577), March 1997.
  282.  
  283.       [3]  ATM Forum, "Integrated Local Management Interface (ILMI)
  284.       Specification Version 4.0," af-ilmi-0065.000, September, 1996.
  285.  
  286.       [4]  Luciani, J., and Fox, B., "A distributed ATMARP Service Using
  287.       SCSP," <draft-ietf-ion-scsp-atmarp-00.txt>, April, 1997.
  288.  
  289.       [5]  Callon, R., et al., "An Overview of PNNI Augmented Routing,"
  290.       ATM-Forum 96-0354, April, 1996.
  291.  
  292.  
  293.  
  294.  
  295. Davison                Expires February 21, 1998                [Page 5]
  296.  
  297.  
  298.  
  299.  
  300.  
  301. Internet Draft                                           August 21, 1997
  302.  
  303.  
  304.       [6]  Przygienda, T., and Droz, P., "Proxy PAR," ATM-Forum 97-0495,
  305.       July, 1997.
  306.  
  307. Author's  Address
  308.  
  309.       Mike Davison
  310.       Cisco Systems
  311.       170 West Tasman Drive
  312.       San Jose, California 95134
  313.  
  314.       Phone: (408) 526-4000
  315.       EMail: mike.davison@cisco.com
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355. Davison                Expires February 21, 1998                [Page 6]
  356.  
  357.  
  358.