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