Subject: [Fwd: new draft Proxy PAR <draft-droz-proxypar-arch-00.txt>]

From: Antoni Przygienda <[email-masked]>
Date: Fri, 28 Nov 1997 09:44:56 -0500

Subject: new draft Proxy PAR <draft-droz-proxypar-arch-00.txt>
From: Antoni Przygienda <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 19 Nov 1997 16:28:50 -0500

new draft draft-droz-proxypar-arch-00.txt

thank you for processing.

                                                        --- tony

Internet Engineering Task Force                    P. Droz/T. Przygienda
INTERNET DRAFT                                     IBM/Bell Labs, Lucent
                                                        19 November 1997

                               Proxy PAR
                   <draft-droz-proxypar-arch-00.txt>

Status of This Memo

   This document is an Internet Draft, and can be found as
   draft-droz-proxypar-arch-00.txt in any standard internet drafts
   repository.  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.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material, or to cite them other than as a
   ``working draft'' or ``work in progress.''

   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.

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 where the client side is much simpler
   than the server side to allow for 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 registered in the network.  The mechanisms
   are protocol independent but in first version support for IPv4
   services mainly has been specified.  In addition, Proxy PAR server
   capable nodes provide filtering based on IP protocols and address
   prefixes.  This makes, e.g.  possible for router running OSPF to find

Droz, Przygienda              Expires 25 May 1998               [Page i]

Internet Draft                Proxy PAR                 19 November 1997

   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 1996, the ATM Forum accepted the Proxy PAR contribution
   [CPS96] as minimal subset of PAR [Ca96], a current work item of the
   PNNI working group [AF96b].  The latest version of the specification
   [PD97b] provides a detailed description of the protocol including
   state machines and packet formats.

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

   Proxy PAR is a protocol allowing for different ATM attached devices
   (ATM and non-ATM devices) to interact with PAR capable switches
   and obtain 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 and should allow for easy implementation in, for example,
   existing IP routers.  Additionally, clients can use Proxy PAR to
   register different non ATM services and protocols they support.  The
   protocol has deliberately not been included as part of ILMI due to
   the complexity of PAR information passed in the protocol and the fact
   that it is intended for 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 normally will be the
   case.  The context or reference model is therefore aligned with the
   one included in [AF96a].

   The protocol does not specify how a client should make use of the
   obtained information, e.g.  OSPF routers finding themselves through
   Proxy PAR could use this information in RFC1577 [Lau94] fashion,
   forming a full mesh of P2P VCs or use RFC1793 [Moy95] to interact
   with each other.  For the same purpose LANE [AF95] or MARS [Arm96]
   could be used.  It is expected that the guidelines how a certain
   protocol can make use of Proxy PAR should come out of the appropriate
   working group or standardization body that is responsible for the
   particular protocol.  Currently, work in progress exists to address
   the operation of OSPF in the context of ATM and Proxy PAR [PD97a].
   Further work will address other protocols such as BGP-4.

Droz, Przygienda              Expires 25 May 1998               [Page 1]

Internet Draft                Proxy PAR                 19 November 1997

   The protocol has the ability to provide ATM address resolution for IP
   attached devices as well, but such resolution can also be achieved by
   other protocols under specification in IETF, e.g.  [CH97b, CH97a].
   Again, the main purpose of the protocol is to allow the automatic
   detection of devices over an ATM cloud in a distributed fashion,
   ommitting 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 ongoing work in the IETF on server
   detection via ILMI extensions [Dav97a, Dav97b, Dav97c].

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
   communications between adjacent clients and servers.  The registra-
   tion and update part execute after a Proxy PAR adjacency has been
   established.  The client can register its own services by sending
   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 it's 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.  It is
   assumed that services advertised by Proxy PAR will be advertised by a
   relatively small number of clients and will 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 a PNNI routing level
   (scope) with the service that restricts the flooding of the service
   definition within the PNNI network.  Nodes within the PNNI network
   take into account the associated scope of the information when

Droz, Przygienda              Expires 25 May 1998               [Page 2]

Internet Draft                Proxy PAR                 19 November 1997

 +-+
 | | 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)

   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 increase the scalability and flexibility of
   Proxy PAR service.  Figure 1 helps to visualize such a scenario.  In
   this topology following registrations are issued:

    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

Droz, Przygienda              Expires 25 May 1998               [Page 3]

Internet Draft                Proxy PAR                 19 November 1997

    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

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

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

   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
   building of necessary adjacencies and sessions the overlying IP
   topology is visualized in Figure 2.

   Expressing the said above 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

          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)

Droz, Przygienda              Expires 25 May 1998               [Page 4]

Internet Draft                Proxy PAR                 19 November 1997

           Reg# |1. |2. |3. |4. |5. |6.
     ___Router#_|___|___|___|___|___|____   R  registered
        R1      |R  |U  |   |   |R  |U      Q  seen through query
        R2      |U  |R  |   |   |Q  |Q      U  used (implies Q)
        R3      |   |   |R  |U  |R  |U
        R4      |   |   |U  |R  |Q  |Q

          Table 1:  Flooding Scopes of Proxy PAR Registrations

   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 NSAPs are not assumed to be aligned with them
   in any respect such as encapsulation or functional mapping), such
   information cannot be summarised.  This makes a careful handling
   of scopes necessary to preserve the scalability of the approach as
   described above.

3. Proxy PAR Protocols

3.1. The Hello Protocol

   The Proxy PAR Hello Protocol is closely related to the Hello protocol
   specified in [AF96b].  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
   bring up and maintain a Proxy PAR relation 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 different communication instances.  Proxy PAR
   can be run in the same granularity as ILMI [AF96a] 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 and set its refresh interval to a value

Droz, Przygienda              Expires 25 May 1998               [Page 5]

Internet Draft                Proxy PAR                 19 November 1997

   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
   and 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 an IP instance, IP address, subnet
   mask, and IP protocol family.  In this context, each IP instance
   refers to a completely separate IP address space.  For example <A,
   194.191.1.01, 255.255.255.0, OSPF> describes an OSPF interface in the
   IP instance A. In addition to the IP scope further information can be
   registered that includes 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
   only takes the ATM and IP specific information into account in query
   descriptions.  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
   specific NSAP and scope in the PNNI hierarchy.  As the default scope,
   implementations should choose the local scope of the PNNI peer group.
   In this way, manual configuration can be avoided unless information
   has to cross PNNI peergroup boundaries.  PNNI is responsible for
   the correct flooding either in the local peer group or across the
   hierarchy.

Droz, Przygienda              Expires 25 May 1998               [Page 6]

Internet Draft                Proxy PAR                 19 November 1997

   The registration protocol is aligned with the standard initial
   topology database exchange protocol used in link-state routing
   protocols as far as possible.  It uses a window size of one.  A
   single information element is registered at a time and must be
   acknowledged before a new registration packet can be sent.  The
   protocol uses 'initialization' and 'more' bits in the same manner
   PNNI and OSPF do.  Any registration on a link unconditionally
   overwrites all registration data previously received on the same
   link.

3.2.2. Query Protocol

   The client uses the query protocol to obtain information about
   services registered by other clients.  The client requests services
   registered within a specific PNNI routing level, IP instance and
   IP address prefix.  It is always the client's task to request
   information, the server never makes any attempt to push information
   to the client.  If the client needs to filter the returned data based
   on service specific information, such as BGP AS, it must parse and
   interpret the received information.  The server never looks beyond
   the IP scope.

4. Supported Protocols

   Currently the protocols indicated in Table 2 have been included.
   Furthermore, for protocols marked with a 'yes' additional information
   has been specified that is beneficial for their operation.  Many of
   the protocol do not need additional information, it is sufficient to
   know that they are supported and to know to which addresses they are
   bound.

   In order to include other information in an experimental manner a
   generic information element exists that can be used to carry such
   information.

5. Proxy PAR Detection

   Since Proxy PAR is envisioned as being used by non-ATM devices
   such as IP routers that implement UNI functionality to interact
   with native ATM networks, an appropriate detection of Proxy PAR
   capabilities on the network as well as user side is crucial.  The

Droz, Przygienda              Expires 25 May 1998               [Page 7]

Internet Draft                Proxy PAR                 19 November 1997

                       Protocol   | Additional Info
                    ______________|__________________

                       OSPF       |       yes
                       RIP        |
                       RIPv2      |
                       BGP3       |
                       BGP4       |       yes
                       EGP        |
                       IDPR       |
                       MOSPF      |       yes
                       DVMRP      |
                       CBT        |
                       PIMS       |
                       IGRP       |
                       IS-IS      |
                       ES-IS      |
                       ICMP       |
                       GGP        |
                       BBN SPF IGP|
                       MARS       |
                       NHRP       |
                       ATMARP     |
                       DHCP       |
                       DNS        |       yes

     Table 2:  Additional Protocol Information Carried in Proxy PAR

   necessary extensions to ILMI to perform this detection in an
   automatic manner have been introduced in [Prz97].

6. Security Consideration

   Security aspects are not addressed in this memo.

7. Conclusion

   This I-D describes the basic functions of Proxy PAR being specified
   within the ATM-Forum body.  The main purpose of the protocol is to

Droz, Przygienda              Expires 25 May 1998               [Page 8]

Internet Draft                Proxy PAR                 19 November 1997

   provide automatic detection and configuration of non ATM devices over
   an ATM cloud.

   In the future support for further protocols and address families may
   be added to widen the scope of applicability of Proxy PAR.

References

   [AF95]   ATM-Forum.  LAN Emulation over ATM 1.0.  ATM Forum
            af-lane-0021.000, January 1995.

   [AF96a]  ATM-Forum.  Interim Local Management Interface (ILMI)
            Specification 4.0.  ATM Forum 95-0417R8, June 1996.

   [AF96b]  ATM-Forum.  Private Network-Network Interface Specification
            Version 1.0.  ATM Forum af-pnni-0055.000, March 1996.

   [Arm96]  G. Armitage.  Support for Multicast over UNI 3.0/3.1 based
            ATM Networks, RFC 2022.  Internet Engineering Task Force,
            November 1996.

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

   [CH97a]  R. Coltun and J. Heinanen.  Opaque LSA in OSPF.  Internet
            Draft, 1997.

   [CH97b]  R. Coltun and J. Heinanen.  The OSPF Address Resolution
            Advertisement Option.  Internet Draft, 1997.

   [CPS96]  R. Coltun, T. Przygienda, and S. Shew.  MIPAR: Minimal PNNI
            Augmented Routing.  ATM Forum 96-0838, June 1996.

   [Dav97a] M. Davison.  ILMI-Based Server Discovery for ATMARP.
            Internet Draft, 1997.

   [Dav97b] M. Davison.  ILMI-Based Server Discovery for MARS.  Internet
            Draft, 1997.

   [Dav97c] M. Davison.  ILMI-Based Server Discovery for NHRP.  Internet
            Draft, 1997.

Droz, Przygienda              Expires 25 May 1998               [Page 9]

Internet Draft                Proxy PAR                 19 November 1997

   [Lau94]  M. Laubach.  Classical IP and ARP over ATM, RFC 1577.
            Internet Engineering Task Force, January 1994.

   [Moy95]  J. Moy.  Extending OSPF to Support Demand Circuits, RFC
            1793.  Internet Engineering Task Force, April 1995.

   [PD97a]  T. Przygienda and P. Droz.  OSPF over ATM and Proxy PAR.
            Internet Draft, 1997.

   [PD97b]  T. Przygienda and P. Droz.  Proxy PAR.  ATM Forum 97-0495,
            97-0705, 97-0882, July 1997.

   [Prz97]  T. Przygienda.  User- and Network Side Proxy PAR Capable
            Devices. Detection and Configuration.  ATM Forum 97-0555,
            July 1997.

Authors' Addresses

Tony Przygienda
Bell Labs, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
[email-masked]

Patrick Droz
IBM Research Division
Zurich Research Laboratory
Saumerstrasse 4
8803 Ruschlikon
Switzerland
[email-masked]

Droz, Przygienda              Expires 25 May 1998              [Page 10]