rfc2843.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 732 行 · 第 1/2 页

Network Working Group                                           P. Droz
Request for Comments: 2843                                          IBM
Category: Informational                                   T. Przygienda
                                                                  Siara
                                                               May 2000


                               Proxy-PAR

Status of this Memo

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

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   Proxy-PAR is a minimal version of PAR (PNNI Augmented Routing) that
   gives ATM-attached devices the ability to interact with PNNI devices
   without the necessity to fully support PAR. Proxy-PAR is designed as
   a client/server interaction, of which the client side is much simpler
   than the server side to allow fast implementation and deployment.

   The purpose of Proxy-PAR is to allow non-ATM devices to use the
   flooding mechanisms provided by PNNI for registration and automatic
   discovery of services offered by ATM attached devices.  The first
   version of PAR primarily addresses protocols available in IPv4. But
   it also contains a generic interface to access the flooding of PNNI.
   In addition, Proxy-PAR-capable servers provide filtering based on VPN
   IDs [1], IP protocols and address prefixes. This enables, for
   instance, routers in a certain VPN running OSPF to find OSPF
   neighbors on the same subnet. The protocol is built using a
   registration/query approach where devices can register their services
   and query for services and protocols registered by other clients.

1 Introduction

   In June of 1996, the ATM Forum accepted the "Proxy-PAR contribution
   as minimal subset of PAR" as a work item of the Routing and
   Addressing (RA) working group, which was previously called the PNNI
   working group [2].  The PAR [3] specification provides a detailed
   description of the protocol including state machines and packet
   formats.




Droz & Przygienda            Informational                      [Page 1]

RFC 2843                       Proxy-PAR                        May 2000


   The intention of this document is to provide general information
   about Proxy-PAR. For the detailed protocol description we refer the
   reader to [3].

   Proxy-PAR is a protocol that allows various ATM-attached devices (ATM
   and non-ATM devices) to interact with PAR-capable switches to
   exchange information about non-ATM services without executing PAR
   themselves. The client side is much simpler in terms of
   implementation complexity and memory requirements than a complete PAR
   instance. This should allow an easy implementation on existing IP
   devices such as IP routers. Additionally, clients can use Proxy-PAR
   to register various non-ATM services and the protocols they support.
   The protocol has deliberately been omitted from ILMI [4] because of
   the complexity of PAR information passed in the protocol and the fact
   that it is intended for the integration of non-ATM protocols and
   services only. A device executing Proxy-PAR does not necessarily need
   to execute ILMI or UNI signalling, although this will normally be the
   case.

   The protocol does not specify how a client should make use of the
   obtained information to establish connectivity. For example, OSPF
   routers finding themselves through Proxy-PAR could establish a full
   mesh of P2P VCs by means of RFC2225 [5], or use RFC1793 [6] to
   interact with each other.  LANE [7] or MARS [8] could be used for the
   same purpose. It is expected that the guidelines defining how a
   certain protocol can make use of Proxy-PAR should be produced by the
   appropriate working group or standardization body responsible for the
   particular protocol. An additional RFC [9] describing how to run OSPF
   together with Proxy-PAR is published together with this document.

   The protocol has the ability to provide ATM address resolution for
   IP-attached devices, but such resolutions can also be achieved by
   other protocols under specification in the IETF, e.g. [10]. Again,
   the main purpose of the protocol is to allow the automatic detection
   of devices over an ATM cloud in a distributed fashion, omitting the
   usual pitfalls of server-based solutions. Last but not least, it
   should be mentioned here as well that the protocol complements and
   coexists with the work done in the IETF on server detection via ILMI
   extensions [11,12,13].

2 Proxy-PAR Operation and Interaction with PNNI

   The protocol is asymmetric and consists of a discovery and
   query/registration part. The discovery is very similar to the
   existing PNNI Hello protocol and is used to initiate and maintain
   communication between adjacent clients and servers. The registration
   and update part execute after a Proxy-PAR adjacency has been
   established. The client can register its own services by sending



Droz & Przygienda            Informational                      [Page 2]

RFC 2843                       Proxy-PAR                        May 2000


   registration messages to the server. The client obtains information
   it is interested in by sending query messages to the server. When the
   client needs to change its set of registered protocols, it has to
   re-register with the server. The client can withdraw all registered
   services by registering a null set of services. It is important to
   note that the server side does not push new information to the
   client, neither does the server keep any state describing which
   information the client received. It is the responsibility of the
   client to update and refresh its information and to discover new
   clients or update its stored information about other clients by
   issuing queries and registrations at appropriate time intervals. This
   simplifies the protocol, but assumes that the client will not store
   and request large amounts of data. The main responsibility of the
   server is to flood the registered information through the PNNI cloud
   such that potential clients can discover each other. The Proxy-PAR
   server side also provides filtering functions to support VPNs and IP
   subnetting. It is assumed that services advertised by Proxy-PAR will
   be advertised by a relatively small number of clients and be fairly
   stable, so that polling and refreshing intervals can be relatively
   long.

   The Proxy-PAR extensions rely on appropriate flooding of information
   by the PNNI protocol. When the client side registers or re-registers
   a new service through Proxy-PAR, it associates an abstract membership
   scope with the service. The server side maps this membership scope
   into a PNNI routing level that restricts the flooding. This allows
   changes of the PNNI routing level without reconfiguration of the
   client. In addition, the server can set up the mapping table such
   that a client can flood information only to a certain level. Nodes
   within the PNNI network take into account the associated scope of the
   information when it is flooded.  It is thus possible to exploit the
   PNNI routing hierarchy by announcing different protocols on different
   levels of the hierarchy, e.g. OSPF could be run inside certain peer
   groups, whereas BGP could be run between the set of peer -groups
   running OSPF. Such an alignment or mapping of non-ATM protocols to
   the PNNI hierarchy can drastically enhance the scalability and
   flexibility of Proxy-PAR service. Figure 1 helps visualize such a
   scenario. For this topology the following registrations are issued:













Droz & Przygienda            Informational                      [Page 3]

RFC 2843                       Proxy-PAR                        May 2000


    +-+
    | | PNNI peer group    # PPAR capable  @ PNNI capable  * Router
    +-+                      switch          switch


                   Level 40
                   +---------------------------+
                   |                           |
                   |                           |
                   |      @ ---- @ ---- @      |
                   |      |             |      |
                   +----- | ----------- | -----+
                          |             |
           Level 60       |             |
           +------------- | ---+    +-- | --------------+
           |              |    |    |   |               |
      R1* ------#-P1------@    |    |   @---------P3-#------- * R3
           |              |    |    |   |               |
      R2* ------#-P2------+    |    |   +---------P4-#------- * R4
           |                   |    |                   |
           +-------------------+    +-------------------+

       Figure 1: OSPF and BGP scalability with Proxy-PAR autodetection
                               (ATM topology).


      1. R1 registers OSPF protocol as running on the IP interface
         1.1.1.1 and subnet 1.1.1/24 with scope 60

      2. R2 registers OSPF protocol as running on the IP interface
         1.1.1.2 and subnet 1.1.1/24 with scope 60

      3. R3 registers OSPF protocol as running on the IP interface
         1.1.2.1 and subnet 1.1.2/24 with scope 60

      4. R4 registers OSPF protocol as running on the IP interface
         1.1.2.2 and subnet 1.1.2/24 with scope 60

   and

      1. R1 registers BGP4 protocol as running on the IP interface
         1.1.3.1 and subnet 1.1/16 with scope 40 within AS101

      2. R3 registers BGP4 protocol as running on the IP interface
         1.1.3.2 and subnet 1.1/16 with scope 40 within AS100






Droz & Przygienda            Informational                      [Page 4]

RFC 2843                       Proxy-PAR                        May 2000


   For simplicity the real PNNI routing level have been specified, which
   are 60 and 40. Instead of these two values the clients would use an
   abstract membership scope "local" and "local+1". In addition, all
   registered information would be part of the same VPN ID.

   Table 1 describes the resulting distribution and visibility of
   registrations and whether the routers not only see but also utilize
   the received information. After convergence of protocols and the
   building of necessary adjacencies and sessions, the overlying IP
   topology is illustrated in Figure 2.

                     AS101         DMZ      AS100
                   #########                ##########
                           #                #
               |           #   |            #            |
               +-- R1 ---------+            #       R4 --+
               |           #   |            #            |
               |           #   | BGP4 on    #    OSPF on |
               | OSPF on   #   | subnet     #     subnet |
               | subnet    #   | 1.1/16     #   1.1.2/24 |
               | 1.1.1/24  #   |            #            |
               |           #   +------------------- R3 --+
               +-- R2      #   |            #            |
               |           #                #
                   #########                ##########

       Figure 2: OSPF and BGP scalability with Proxy-PAR autodetection
                                (IP topology).

   Expressing the above statements differently, one can say that if the
   scope of the Proxy-PAR information indicates that a distribution
   beyond the boundaries of the peer group is necessary, the leader of a
   peer group collects such information and propagates it into a higher
   layer of the PNNI hierarchy. As no assumptions except scope values
   can normally be made about the information distributed (e.g. IP
   addresses bound to AESAs are not assumed to be aligned with them in
   any respect), such information cannot be summarized. This makes a
   careful handling of scopes necessary to preserve the scalability of
   the approach as described above.












Droz & Przygienda            Informational                      [Page 5]

RFC 2843                       Proxy-PAR                        May 2000


                       Reg#   1. 2. 3. 4. 5. 6.
                      Router#
                    -----------------------------
                      R1      R  U        R  U
                      R2      U  R        Q  Q
                      R3            R  U  R  U
                      R4            U  R  Q  Q


                        R registered
                        Q seen through query
                        U used (implies Q)

        Table 1: Flooding scopes of Proxy-PAR registrations.

3 Proxy-PAR Protocols

3.1 Hello Protocol

   The Proxy-PAR Hello Protocol is closely related to the Hello protocol
   specified in [2]. It uses the same packet header and version
   negotiation methods. For the sake of simplicity, states that are
   irrelevant to Proxy-PAR have been removed from the original PNNI
   Hello protocol. The purpose of the Proxy-PAR Hello protocol is to
   establish and maintain a Proxy-PAR adjacency between the client and
   server that supports the exchange of registration and query messages.
   If the protocol is executed across multiple, parallel links between
   the same server and client pair, individual registration and query
   sessions are associated with a specific link. It is the
   responsibility of the client and server to assign registration and
   query sessions to the various communication instances. Proxy-PAR can
   be run in the same granularity as ILMI [4] to support virtual links
   and VP tunnels.

   In addition to the PNNI Hello, the Proxy-PAR Hellos travelling from
   the server to the client inform the client about the lifetime the
   server assigns to registered information. The client has to retrieve
   this interval from the Hello packet and set its refresh interval to a
   value below the obtained time interval in order to avoid the aging
   out of registered information by the server.

3.2 Registration/Query Protocol

   The registration and query protocols enable the client to announce
   and learn about protocols supported by the clients. All
   query/register operations are initiated by the clients. The server
   never tries to push information to the client. It is the client's
   responsibility to register and refresh the set of protocols supported



Droz & Przygienda            Informational                      [Page 6]

RFC 2843                       Proxy-PAR                        May 2000


   and to re-register them when changes occur. In the same sense, the
   client must query the information from the server at appropriate time
   intervals if it wishes to obtain the latest information. It is
   important to note that neither client nor server is supposed to cache
   any state information about the information stored by the other side.

   Registered information is associated with an ATM address and scope
   inside the PNNI hierarchy. From the IP point of view, all information
   is associated with a VPN ID, IP address, subnet mask, and IP protocol
   family. In this context, each VPN refers to a completely separated IP
   address space. For example <A, 194.194.1.01, 255.255.255.0, OSPF>
   describes an OSPF interface in VPN A. In addition to the IP scope
   further parameters can be registered that contain more detailed
   information about the protocol itself. In the above example this
   would be OSPF-specific information such as the area ID or router
   priority.  However, Proxy-PAR server takes only the ATM and IP-
   specific information into account when retrieving information that
   was queried. Protocol specific information is never looked at by a
   Proxy-PAR server.

3.2.1 Registration Protocol

   The registration protocol enables a client to register the protocols
   and services it supports. All protocols are associated with a