home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2602.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  12.1 KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       M. Davison
  8. Request for Comments: 2602                               Cisco Systems
  9. Category: Standards Track                                    June 1999
  10.  
  11.  
  12.                   ILMI-Based Server Discovery for MARS
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Copyright Notice
  23.  
  24.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  25.  
  26. Abstract
  27.  
  28.    This memo defines how ILMI-based Server Discovery, which provides a
  29.    method for ATM-attached hosts and routers to dynamically determine
  30.    the ATM addresses of servers, shall be used to locate MARS servers.
  31.  
  32. 1. Introduction
  33.  
  34.    Presently, configuring a host or router to use MARS [1] is cumbersome
  35.    and error-prone since it requires at least one ATM address to be
  36.    statically configured on each host or router in the network.
  37.    Further, it is impossible to implement a diskless host to use MARS
  38.    since local configuration is required.  ILMI-based Server Discovery,
  39.    hereafter referred to as "server discovery," provides a solution to
  40.    these problems.
  41.  
  42.    A brief overview of the Integrated Local Management Interface (ILMI)
  43.    and the Service Registry MIB, as defined by the ATM Forum, are
  44.    provided in this memo. The reader should consult [2] for a complete
  45.    description of ILMI and this MIB, but the information contained here
  46.    is sufficient for an understanding of its use to support MARS server
  47.    discovery.
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Davison                     Standards Track                     [Page 1]
  59.  
  60. RFC 2602          ILMI-Based Server Discovery for MARS         June 1999
  61.  
  62.  
  63. 2. Integrated Local Management Interface
  64.  
  65.    The Integrated Local Management Interface (ILMI) [2] provides a
  66.    mechanism for ATM-attached devices, such as hosts, routers, and ATM
  67.    switches, to transfer management information. It is based on the
  68.    Simple Network Management Protocol (SNMP), Version 1, and supports
  69.    get, get-next, set and trap operations.
  70.  
  71.    The ILMI specification designates the switch side of the ATM link as
  72.    the 'network side' and the host/router side of the ATM link as the '
  73.    user side.' The Service Registry MIB, which is outlined in Section 3,
  74.    is implmented on the network side and is queried from the user side.
  75.  
  76. 3. ILMI 4.0 Service Registry MIB
  77.  
  78.    Server discovery utilizes the Service Registry MIB defined by the ATM
  79.    Forum in ILMI Specification Version 4.0 [2]. To support the existing
  80.    framework for IP over ATM, as embodied by ATMARP and MARS, ATM
  81.    switches must support the Service Registry MIB.
  82.  
  83.    A row in the service registry table [2] is defined as:
  84.  
  85.               AtmfSrvcRegEntry ::= SEQUENCE {
  86.                   atmfSrvcRegPort          INTEGER,
  87.                   atmfSrvcRegServiceID     OBJECT IDENTIFIER,
  88.                   atmfSrvcRegATMAddress    AtmAddress,
  89.                   atmfSrvcRegAddressIndex  INTEGER,
  90.                   atmfSrvcRegParm1         OCTET STRING
  91.               }
  92.  
  93. The definition of each field in this structure is:
  94.  
  95.       atmfSrvcRegPort - The ATM port number for which this entry
  96.           contains management information. The value of zero may be used
  97.           to indicate the ATM interface over which a management request
  98.           was received.
  99.  
  100.       atmfSrvcRegServiceID - This is the service identifier that
  101.           uniquely identifies the type of service at the address
  102.           provided in the table. (See Section 3.2 for MARS OID.)
  103.  
  104.       atmfSrvcRegATMAddress - This is the full address of the service.
  105.           The ATM client will use this address to establish a connection
  106.           with the service.
  107.  
  108.       atmfSrvcRegAddressIndex - An arbitrary integer to differentiate
  109.           multiple rows containing different ATM addresses for the same
  110.           service on the same port.
  111.  
  112.  
  113.  
  114. Davison                     Standards Track                     [Page 2]
  115.  
  116. RFC 2602          ILMI-Based Server Discovery for MARS         June 1999
  117.  
  118.  
  119.       atmfSrvcRegParm1 - An octet string whose size and meaning is
  120.           determined by the value of atmfSrvcRegServiceID.
  121.  
  122.    The service registry table is indexed by atmfSrvcRegPort,
  123.    atmfSrvcRegServiceID and atmfSrvcRegAddressIndex.
  124.  
  125. 3.1 Service Parameter String
  126.  
  127.    A generic parameter string is defined in the service registry table,
  128.    thus allowing protocol-specific parameters to be specified. To be
  129.    consistent with [1], the parameter string for MARS shall be:
  130.  
  131.        mar$pro.type   16   bits     Protocol type
  132.        mar$pro.snap   40   bits     Optional extension to protocol type
  133.        mar$plen        8   bits     Length of protocol address
  134.        mar$addr       plen octets   Network address
  135.        mar$mask       plen octets   Network mask
  136.  
  137.    Where
  138.  
  139.        mar$pro.type   - See [1]. (IPv4 is 0x0800, IPv6 is 0x86DD)
  140.  
  141.        mar$pro.snap   - See [1]. (IPv4 and IPv6 are 0)
  142.  
  143.        mar$plen       - Length of the protocol address.
  144.                         (IPv4 is 4, IPv6 is 16)
  145.  
  146.        mar$addr       - Network address represented in network byte
  147.                         order
  148.  
  149.        mar$mask       - Network mask represented in network byte order
  150.  
  151. 3.2 Service Object Identifier
  152.  
  153.    This OID, assigned in the ATM Forum Service Registry MIB, names MARS
  154.    within the context of server discovery.
  155.  
  156.      atmfSrvcRegMARS   OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.353.1.5.4 }
  157.  
  158.    It does not name any managed objects, rather is used to locate
  159.    appropriate rows in the service registery table.
  160.  
  161. 4. MARS Client Behavior
  162.  
  163.    A MARS client will access the service registry table via ILMI using
  164.    the SNMP GetNext operator to "sweep" (SNMP parlance for a linear
  165.    search) beginning with {Port = 0, ServiceID = <see Section 3.2>,
  166.    Index = 0} while holding the port number and the serviceID constant.
  167.  
  168.  
  169.  
  170. Davison                     Standards Track                     [Page 3]
  171.  
  172. RFC 2602          ILMI-Based Server Discovery for MARS         June 1999
  173.  
  174.  
  175.    (Port number 0 is used within ILMI to indicate "this port.")
  176.  
  177.    An MARS client with no local configuration, such as a diskless
  178.    workstation, must use the row with the lowest index value if multiple
  179.    MARS servers, possibly for multiple networks, are listed.
  180.  
  181.    MARS clients that have local IP configuration must use a row that has
  182.    the appropriate IP address.  For example, consider the case where an
  183.    IP router has 3 logical interfaces defined on a single physical
  184.    interface with IP addresses 1.0.0.1/8, 128.10.0.1/16 and
  185.    171.69.150.226/24. The router will sweep the service registry table
  186.    looking for rows that have atmfSrvcRegParm1 values as shown below:
  187.  
  188.      Net number/mask  atmfSrvcRegParm1
  189.      ---------------- --------------------------------------------------
  190.      1.0.0.0/8        08 00 00 00 00 00 00  04  01 00 00 00  ff 00 00 00
  191.      128.10.0.0/16    08 00 00 00 00 00 00  04  80 0a 00 00  ff ff 00 00
  192.      171.69.150.0/24  08 00 00 00 00 00 00  04  ab 45 96 00  ff ff ff 00
  193.  
  194.    When the correct atmfSrvcRegParm1 values are located, the router may
  195.    then establish an SVC to the selected server and perform the
  196.    appropriate protocol operations.
  197.  
  198.    Redundant MARS servers are supported with multiple rows in the
  199.    service registry table. This list of MARS servers is ordered with the
  200.    primary MARS server having the lowest index value. The MARS client
  201.    must attempt to utilize the primary MARS server before utilizing a
  202.    secondary MARS server. Administrators must ensure that the listed
  203.    MARS servers are synchronized.
  204.  
  205. 5. MARS Server Behavior
  206.  
  207.    An MARS server shall be locally configured. The MARS server may
  208.    retrieve the MARS service registry data to validate the results. If
  209.    an incorrect row is retrieved the error may be flagged in a locally
  210.    significant way.
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Davison                     Standards Track                     [Page 4]
  227.  
  228. RFC 2602          ILMI-Based Server Discovery for MARS         June 1999
  229.  
  230.  
  231. 6. Relationship with PNNI Augmented Routing
  232.  
  233.    An augmented version PNNI ("PNNI Augmented Routing," or PAR) [3] has
  234.    been developed by the ATM Forum. PAR can distribute data such as MARS
  235.    server addresses. Further, the ATM Forum is developing a proxy
  236.    mechanism for PAR (Proxy PAR) that would allow a UNI-attached host or
  237.    router to access PAR data without a full PAR implementation.
  238.  
  239.    These mechanisms offer a promising way to manage the service registry
  240.    tables maintained on each switch in an ATM network, yet would not
  241.    require changes to the mechanism defined in this memo. Hosts and
  242.    routers can continue to utilize ILMI-based or Proxy PAR-based server
  243.    discovery and network administrators could manage the service
  244.    registry data with local configuration or via PAR and Proxy PAR.
  245.  
  246. 7. Security Considerations
  247.  
  248.    The server discovery mechanism is built on the ILMI managment
  249.    framework and the security embodied in that framework. Access, to
  250.    user- or network-side information is controlled by MIB design rather
  251.    than protocol security mechanisms.
  252.  
  253.    The service registery MIB, the table containing information for
  254.    server discovery, is defined in [2] with read-only access. This means
  255.    that any user-side device may query the service registry, but may not
  256.    modify the service registry via ILMI. Instead, the sevice registry
  257.    table must be modified via local configuration on the ATM switch.
  258.  
  259. References
  260.  
  261.    [1]  Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
  262.         Networks", RFC 2022, November 1996.
  263.  
  264.    [2]  ATM Forum, "Integrated Local Management Interface (ILMI)
  265.         Specification Version 4.0," af-ilmi-0065.000, September 1996.
  266.  
  267.    [3]  ATM Forum, "PNNI Augmented Routing (PAR) Version 1.0," af-ra-
  268.         0104, January 1999.
  269.  
  270. Author's  Address
  271.  
  272.    Mike Davison
  273.    Cisco Systems
  274.    170 West Tasman Drive
  275.    San Jose, California 95134
  276.  
  277.    Phone: (408) 526-4000
  278.    EMail: mike.davison@cisco.com
  279.  
  280.  
  281.  
  282. Davison                     Standards Track                     [Page 5]
  283.  
  284. RFC 2602          ILMI-Based Server Discovery for MARS         June 1999
  285.  
  286.  
  287. Full Copyright Statement
  288.  
  289.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  290.  
  291.    This document and translations of it may be copied and furnished to
  292.    others, and derivative works that comment on or otherwise explain it
  293.    or assist in its implementation may be prepared, copied, published
  294.    and distributed, in whole or in part, without restriction of any
  295.    kind, provided that the above copyright notice and this paragraph are
  296.    included on all such copies and derivative works.  However, this
  297.    document itself may not be modified in any way, such as by removing
  298.    the copyright notice or references to the Internet Society or other
  299.    Internet organizations, except as needed for the purpose of
  300.    developing Internet standards in which case the procedures for
  301.    copyrights defined in the Internet Standards process must be
  302.    followed, or as required to translate it into languages other than
  303.    English.
  304.  
  305.    The limited permissions granted above are perpetual and will not be
  306.    revoked by the Internet Society or its successors or assigns.
  307.  
  308.    This document and the information contained herein is provided on an
  309.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  310.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  311.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  312.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  313.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  314.  
  315. Acknowledgement
  316.  
  317.    Funding for the RFC Editor function is currently provided by the
  318.    Internet Society.
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Davison                     Standards Track                     [Page 6]
  339.  
  340.