[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 04 05 rfc2601                                        
Internet-Draft                                           Mike Davison
                                                         Cisco Systems
                                                         Oct 15, 1998



                 ILMI-Based Server Discovery for ATMARP
                 <draft-ietf-ion-discov-atmarp-02.txt>




Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet Drafts shadow
   directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).

   This memo provides information for the Internet community. This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.


Abstract


   This memo defines how ILMI-based Server Discovery, which provides a
   method for ATM-attached hosts and routers to dynamically determine
   the ATM address of servers,  shall be used to locate ATMARP servers.










Davison                  Expires April 15, 1999                 [Page 1]


Internet Draft                                              Oct 15, 1998


1. Introduction


   Presently, configuring a host or router to use ATMARP [1,2] is
   cumbersome and error-prone since it requires at least one ATM
   addresses to be statically configured on each host or router in the
   network.  Further, it is impossible to implement a diskless host to
   use ATMARP since local configuration is required.  ILMI-based Server
   Discovery, hereafter referred to as "server discovery," provides a
   solution to these problems.

   A brief overview of the Service Registry MIB, as defined by the ATM
   Forum, is provided in this memo. The reader should consult [3] for a
   complete description of this MIB, but the information contained here
   is sufficient for an understanding of its use to support ATMARP
   server discovery.


2. ILMI 4.0 Service Registry MIB


   Server discovery utilizes the Service Registry MIB defined by the ATM
   Forum in ILMI Specification Version 4.0 [3]. To support the existing
   framework for IP over ATM, ATM switches must support the Service
   Registry MIB.

   A row in the service registry table [3] is defined as:

      AtmfSrvcRegEntry ::= SEQUENCE {
          atmfSrvcRegPort          INTEGER,
          atmfSrvcRegServiceID     OBJECT IDENTIFIER,
          atmfSrvcRegATMAddress    AtmAddress,
          atmfSrvcRegAddressIndex  INTEGER,
          atmfSrvcRegParm1         OCTET STRING
      }

   The definition of each field in this structure is:

      atmfSrvcRegPort - The port number for which this entry contains
          management information. The value of zero may be used to
          indicate the ATM interface over which a management request
          was received.

      atmfSrvcRegServiceID - This is the service identifier which
          uniquely identifies the type of service at the address
          provided in the table. (See Appendix for ATMARP OID.)

      atmfSrvcRegATMAddress - This is the full address of the service.



Davison                  Expires April 15, 1999                 [Page 2]


Internet Draft                                              Oct 15, 1998


          The ATM client will use this address to establish a connection
          with the service.

      atmfSrvcRegAddressIndex - An arbitrary integer to differentiate
          multiple rows containing different ATM addresses for the same
          service on the same port.

      atmfSrvcRegParm1 - An octet string whose size and meaning is
          determined by the value of atmfSrvcRegServiceID.

   The service registry table is indexed by atmfSrvcRegPort,
   atmfSrvcRegServiceID and atmfSrvcRegAddressIndex.


2.1 Service Parameter String


   A generic parameter string is defined in the service registry table,
   thus allowing protocol-specific parameters to be specified. To be
   consistent with [1,2], the parameter string for ATMARP shall be:

       ar$pro   16 bits    Protocol type
       ar$plen   8 bits    Length of protocol address (a)
       ar$addr  a octets   Network address
       ar$mask  a octets   Network mask

   Where

       ar$pro  - see Assigned Numbers for protocol type number for
                 protocol using ATMARP. (IPv4 is 0x0800, IPv6 is 0x86DD)

       ar$plen - Length of the protocol address. (IPv4 is 4, IPv6 is 16)

       ar$addr - Network address represented in network byte order

       ar$mask - Network mask represented in network byte order


2.2 Service Object Identifier



   This OID, assigned in the ATM Forum Service Registry MIB, names
   ATMARP within the context of server discovery.

      atmfSrvcRegATMARP  OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.353.1.5.3 }

   It does not name any managed objects, rather is used to locate



Davison                  Expires April 15, 1999                 [Page 3]


Internet Draft                                              Oct 15, 1998


   appropriate rows in the service registery table.



3. ATMARP Client Behavior


   An ATMARP client will access the service registry table via ILMI
   using the SNMP GetNext operator to "sweep" (SNMP parlance for a
   linear search) beginning with {Port = 0, ServiceID = <see Appendix>,
   Index = 0} while holding the port number and the serviceID constant.
   (Port number 0 is used within ILMI to indicate "this port.")

   An ATMARP client with no local configuration, such as a diskless
   workstation, must use the row with the lowest index value if multiple
   ATMARP servers, possibly for multiple networks, are listed.

   ATMARP clients that have local IP configuration must use a row that
   has the appropriate IP address.  For example, consider the case where
   an IP router has 3 logical interfaces defined on a single physical
   interface with IP addresses 1.0.0.1/8, 128.10.0.1/16 and
   171.69.150.226/24. The router will sweep the service registry table
   looking for a rows that have atmfSrvcRegParm1 values as shown below:

       Network number/mask  atmfSrvcRegParm1
       -------------------- --------------------------------------
       1.0.0.0/8            08 00   04   01 00 00 00   ff 00 00 00
       128.10.0.0/16        08 00   04   80 0a 00 00   ff ff 00 00
       171.69.150.0/24      08 00   04   ab 45 96 00   ff ff ff 00

   When the correct atmfSrvcRegParm1 values are located, the router may
   then establish an SVC to the selected server and perform the
   appropriate protocol operations.

   Redundant ATMARP servers are supported with multiple rows in the
   service registry table. This list of ATMARP servers is ordered with
   the primary ATMARP server having the lowest index value. The ATMARP
   client must attempt to utilize the primary ATMARP server before
   utilizing a secondary ATMARP server. Administrators must ensure that
   the listed ATMARP servers are synchronized via [4].


4. ATMARP Server Behavior


   An ATMARP server shall be locally configured. The ATMARP server may
   retrieve the ATMARP service registry data to validate the results. If
   an incorrect row is retrieved the error may be flagged in a locally



Davison                  Expires April 15, 1999                 [Page 4]


Internet Draft                                              Oct 15, 1998


   significant way.


5. Relationship with PNNI Augmented Routing


   An augmented version PNNI ("PNNI Augmented Routing," or PAR) [5] is
   being developed by the ATM Forum. PAR can distribute data such as
   ATMARP server addresses. Further, the ATM Forum is developing a proxy
   mechanism for PAR (Proxy PAR) [6] that would allow a UNI-attached
   host or router to access PAR data without a full PAR implementation.

   These mechanisms offer a promising way to manage the service registry
   tables maintained on each switch in an ATM network, yet would not
   require changes to the mechanism defined in this memo. Hosts and
   routers can continue to utilize ILMI-based or Proxy PAR-based server
   discovery and network administrators could manage the service
   registry data with local configuration or via PAR and Proxy PAR.


6. Security Considerations


   The server discovery mechanism is intended for environments where a
   given ATM switch and its attached hosts or routers are in the same
   administrative domain, hence the information retreived via Server
   Discovery is deemed trustworthy.


References


      [1]  Laubach, M., "Classical IP and ARP over ATM," RFC 1577,
      Hewlett-Packard Laboratories, December 1993.

      [2]  Laubach, M. Halpern, J., "Classical IP and ARP over ATM,"
      RFC 2225, Com21, Inc. and Newbridge Networks, Inc., April 1998.

      [3]  ATM Forum, "Integrated Local Management Interface (ILMI)
      Specification Version 4.0," af-ilmi-0065.000, September, 1996.

      [4]  Luciani, J., and Fox, B., "A distributed ATMARP Service Using
      SCSP," <draft-ietf-ion-scsp-atmarp-00.txt>, April, 1997.

      [5]  Callon, R., et al., "An Overview of PNNI Augmented Routing,"
      ATM-Forum 96-0354, April, 1996.

      [6]  Droz, P., Przygienda, T., "Proxy PAR,"



Davison                  Expires April 15, 1999                 [Page 5]


Internet Draft                                              Oct 15, 1998


      <draft-ietf-ion-proxypar-arch-00.txt>, March, 1998.


Author's  Address

      Mike Davison
      Cisco Systems
      170 West Tasman Drive
      San Jose, California 95134

      Phone: (408) 526-4000
      EMail: mike.davison@cisco.com







































Davison                  Expires April 15, 1999                 [Page 6]