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

Versions: 00 01                                                         
Internet Engineering Task Force                            T. Przygienda
INTERNET DRAFT                            Bell Labs, Lucent Technologies
                                                            5 March 1998


                      BGP-4 over ATM and Proxy PAR
                   <draft-przygienda-bgp4-atm-01.txt>


Status of This Memo

   This document is an Internet Draft, and can be found as
   draft-przygienda-bgp4-atm-01.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

   This draft specifes for BGP-4 implementors and users mechanisms
   describing how the protocol operates in ATM networks over PVC and
   SVC meshes with the presence of Proxy PAR. These recommendations
   do not require any protocol changes and allow for simpler, more
   efficient and cost-effective network designs.  Proxy PAR can help to
   distribute changes of peer relationships when BGP-4 capable routers
   are reconfigured on the ATM cloud.











Przygienda               Expires 5 September 1998               [Page 1]


Internet Draft         BGP-4 over ATM and Proxy PAR         5 March 1998


1. Introduction

1.1. Introduction to PAR

   PNNI Augmented Routing (PAR) [For98] is an extension to PNNI [AF96b]
   routing to allow information about non-ATM services to be distributed
   in an ATM network as part of the PNNI topology.  The content and
   format of the information is specified by PAR but is transparent to
   PNNI routing.  A PAR-capable device, one that implements PNNI and the
   PAR extension, is able to create PAR PTSEs that describe the non-ATM
   services located on or behind that device.  Because this information
   is flooded by PNNI routing, PAR-capable devices are also able to
   examine the PAR PTSEs in the topology database that were originated
   by other nodes to obtain information on desired services reachable
   through the ATM network.  An important example of how PAR can be used
   is provided by overlay routing on ATM backbones.  If the routers
   are PAR-capable, they can create PTSEs to advertise the routing
   protocol supported on the given interface (e.g., OSPF, RIP, or BGP),
   along with their IP address and subnet, and other protocol-specific
   details.  The PAR-capable routers can also automatically learn about
   "compatible" routers (e.g., supporting the same routing protocol,
   in the same IP subnet) active in the same ATM network.  In this
   manner the overlay routing network can be established automatically
   on an ATM backbone.  The mechanism is dynamic, and does not require
   configuration.  One potential drawback of PAR is that a device must
   implement PNNI in order to participate.  Therefore an additional set
   of optional protocols called Proxy PAR has been defined to allow a
   client that is not PAR-capable to interact with a server that is
   PAR-capable and thus obtain the PAR capabilities.  The server acts as
   a proxy for the client in the operation of PAR. The client is able to
   register its own services, and query the server to obtain information
   on compatible services available in the ATM network.  A key feature
   of PAR and Proxy PAR is the ability to provide VPN support in a
   simple yet very effective manner.  All PAR information is tagged
   with a VPN ID and can therefore be filtered on that basis.  This can
   be used for example, in a service provider network.  Each customer
   can be provided with a unique VPN ID that is part of all Proxy PAR
   registrations and queries.  Usage of the correct VPN ID can easily
   be enforced at the Proxy PAR server.  In this way the services of a
   given customer will be available only to clients in that customer's
   network.





Przygienda               Expires 5 September 1998               [Page 2]


Internet Draft         BGP-4 over ATM and Proxy PAR         5 March 1998


1.1.1. Overview of PNNI Augmented Routing (PAR)

   PNNI Augmented Routing (PAR) is an extension to PNNI to allow the
   flooding of information about non-ATM devices.  PAR uses a new PTSE
   type to carry this non-ATM-related information.  The current version
   of PAR specifies IGs for the flooding of IPv4-related protocol
   information such as OSPF or BGP. In addition PAR also allows the use
   of the System Capabilities IG, which can be used to carry proprietary
   or experimental information.

   PAR supports extensive filtering possibilities, which allow the
   implementation of virtual private networks (VPN). As PAR is a
   PNNI extension, it can reuse existing PNNI routing level scopes.
   In addition, PAR provides filtering in terms of a VPN ID, IP
   address, including a subnet mask, as well as protocol flags.  The
   correct filtering according to these parameters is part of a PAR
   implementation.


1.1.2. Overview of Proxy PAR

   Proxy PAR is a protocol that allows for different ATM attached
   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 easy
   implementation in, for example, existing IP routers.  Clients can use
   Proxy PAR to register different non-ATM services and protocols they
   support.  This protocol has deliberately not been included as part of
   ILMI [AF96a] owing 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 signaling, although this will
   normally be the case.

   The protocol does not specify how the distributed service
   registration and data delivered to the client are supposed to drive
   other protocols.  For example, OSPF routers finding themselves
   through Proxy PAR could use this information to form a full mesh of
   P2P VCs and communicate using RFC1483 [Hei93] encapsulation.  In
   terms of the discovery of other devices such as IP routers, Proxy PAR
   is an alternative to LANE [AF95] or MARS [Arm96].  It is expected
   that the guidelines defining how a certain protocol can make use of



Przygienda               Expires 5 September 1998               [Page 3]


Internet Draft         BGP-4 over ATM and Proxy PAR         5 March 1998


   Proxy PAR and PAR should come from the group or standardization body
   that is responsible for the particular protocol.

   PAR and Proxy PAR have the ability to provide ATM address resolution
   for IP attached devices, but such resolution can also be achieved by
   other protocols under specification in IETF e.g.  [CH97a, CH97b].
   However, the main purpose of the protocol is to allow the automatic
   detection of devices over an ATM cloud in a distributed fashion, not
   relying on a broadcast facility.  Finally, it should be mentioned
   that the protocol complements and coexists with server detection via
   ILMI extensions.


1.2. Introduction to BGP

   Border Gateway Protocol (BGP) is an Exterior Gateway Protocol (EGP)
   and described in [RL95, RL97] from which most of the following
   paragraphs have been taken almost literally.

   The primary function of a BGP speaking system is to exchange
   network reachability information with other BGP systems.  This
   network reachability information includes information on the
   list of Autonomous Systems (ASs) that reachability information
   traverses.  This information is sufficient to construct a graph of AS
   connectivity from which routing loops may be pruned and some policy
   decisions at the AS level may be enforced.

   BGP runs over a reliable transport protocol.  This eliminates the
   need to implement explicit update fragmentation, retransmission,
   acknowledgment, and sequencing.  Any authentication scheme used
   by the transport protocol may be used in addition to BGP's own
   authentication mechanisms.  The error notification mechanism used
   in BGP assumes that the transport protocol supports a "graceful"
   close, i.e., that all outstanding data will be delivered before the
   connection is closed.

   BGP deployments are normally configured such that that all BGP
   speakers within a single AS must be fully meshed so that any external
   routing information must be re-distributed to all other routers
   within that AS. This represents a serious scaling problem that
   has been well documented with several alternatives proposed.  The
   alternative supported in Proxy PAR are route reflectors [Bat96] due
   to their simplicity, easy migration and compatibility with existing
   BGP configurations.


Przygienda               Expires 5 September 1998               [Page 4]


Internet Draft         BGP-4 over ATM and Proxy PAR         5 March 1998


2. BGP over ATM

2.1. Model

   The model used for BGP operation over ATM in connection with
   Proxy PAR assumes that not only pre-configured peers exist but
   neighbor relationships can be formed dynamically based on discovery
   mechanisms.  Such a discovery must be provided by an underlying
   layer since BGP does not include peer auto-detection that would be
   comparable with e.g.  OSPF's hellos used to find all OSPF routers on
   a specific subnet.  To fulfill this purpose, Proxy PAR allows BGP to
   register and query the following data with the server:

    -  ATM address

    -  IP instance

    -  IP address

    -  IP mask

    -  BGP Identifier

    -  route reflector type as one of:

        *  reflector of a certain cluster or

        *  client of a certain cluster or

        *  non-client

   The motivation of such a model is to allow for a simpler maintainance
   of BGP router configuration when some router interfaces are connected
   over ATM. As an example, full mesh connectivity on a specific
   subnet does not require the configuration of peer relationsships in
   routersa priori but a router can register as providing BGP services
   on an interface and his possible peers discover it through Proxy
   PAR queries.  Figure 1 illustrates a possible BGP scenario with
   several cases of relationsships based on the following Proxy PAR
   registrations:

    -  Router R1 is configured to be BGP capable and has the interface

        *  1.1.1.1 reaching into DMZ subnet 1.1.1/255.255.255


Przygienda               Expires 5 September 1998               [Page 5]


Internet Draft         BGP-4 over ATM and Proxy PAR         5 March 1998


                               +--+
                               |R1|
                               +--+
                        1.1.1.1 | register BGP for
                                | AS101, BGP Id 1.1.1.1, no route
                                | reflector
                                |
        ======================= | ========================== AS101
         1.1.1/255.255.255.0    |
       +--------------+---------+-------------+------+ DMZ
                      |                       |
        ============= | ===================== | ============ AS100
                      |                       |
                      | 1.1.1.3               | 1.1.1.2
                      |                       |
                    +--+                     +--+
                    |R2| registers BGP for   |R3| registers BGP for
                    |  | AS100, Id 1.1.1.3,  |  | AS100, Id 1.1.1.2,
                    +--+ non-client          +--+ RR for cluster 4
                      |                       |
                      | 1.1.2.3               | 1.1.2.2
                      |                       |
       +---+----------+-----------------------+-----------+
           |                1.1.2/255.255.255.0
           |
           | 1.1.2.1     +
          +--+           |
          |R4|-----------+
          +--+ 1.1.3.1   |   1.1.3.2 +--+ registers BGP for AS100,
                         +-----------|R5| Id 1.1.2.1,
                         |           +--+ RR client cluster 4
                         +

Figure 1:  Logical IP Topology with Proxy PAR Registrations (Single ATM
                                network)



    -  Router R3 is configured to be BGP capable, is route reflector for
       cluster id 4, and has the interfaces

        *  1.1.1.2 reaching into DMZ subnet 1.1.1/255.255.255 and

        *  1.1.2.2 to the subnet 1.1.2/255.255.255 inside its AS


Przygienda               Expires 5 September 1998               [Page 6]


Internet Draft         BGP-4 over ATM and Proxy PAR         5 March 1998


    -  Router R2 is configured to be BGP capable and has the interfaces

        *  1.1.1.3 reaching into DMZ subnet 1.1.1/255.255.255 and

        *  1.1.2.3 to the subnet 1.1.2/255.255.255 inside its AS

    -  Router R5 is configured to be BGP capable, is a client of route
       reflector cluster id 4, and has the interface

        *  1.1.2.1 to a subnet 1.1.2/255.255.255 inside its AS

   It has to be stated here that the model assumes that E-BGP-multihop
   will not be supported through auto-configuration.  Based on such an
   assumption, the following queries are generated by the routers and
   conclusions drawn concerning the BGP sessions to be formed:

   Q1> Router R1 queries for all BGP capable routers on the DMZ
       subnet (1) and discovers R2 and R3 supporting interfaces 1.1.1.3
       and 1.1.1.2 and being in a different AS. Router R1 concludes to

        *  build a E-BGP connection to router R3 (shown with &'s in
           Figure 2)

        *  build a EBPG connection to router R2 (shown with #'s in
           Figure 2)

   Q2> Router R2 queries for all BGP capable routers on the DMZ subnet
       and discovers R3 and R1 on the same subnet and concludes to

        *  build a E-BGP connection to router R1 since it is in a
           different AS

        *  not to build a E-BGP connection to router R3 since it is in
           the same AS

   Q3> Router R3 issues a symmetric query to Q2 and comes to conclusions
       analogous to Q2>

   Q4> Router R2 queries for all routers supporting BGP inside of the
       same AS, detects R3 and R5 and concludes to

___________________________________________
1. since one of its interfaces is on this subnet



Przygienda               Expires 5 September 1998               [Page 7]


Internet Draft         BGP-4 over ATM and Proxy PAR         5 March 1998


                               +--+
                               |R1|
                               +--+
                        1.1.1.1 #&
                                #&
                                #&
                                #&
        ======================= #& ========================= AS101
                                #&
       +--------------###########&&&&&&&&&&&&&&------+ DMZ
                      #                       &
        ============= # ===================== & ============ AS100
                      #                       &
                      # 1.1.1.3               & 1.1.1.2
                      #                       &
                    +--+                     +--+
                    |R2|                     |R3|
                    |  |                     |  |
                    +--+                     +--+
                      %                       %@
                      % 1.1.2.3               %@ 1.1.2.2
                      %                       %@
                      %                       %@
       +--------------%%%%%%%%%%%%%%%%%%%%%%%%%@----------+
                      @@@@@@@@@@@@@@@@@@@@@@@@@@
                      @
                      @            +
                    +-@@           |
                    |R4@@@@@@@@@@@@@
                    +--+           @   1.1.3.2 +--+
                                   @@@@@@@@@@@@|R5|
                                   +           +--+


  Figure 2:  Active BGP Connections after Auto-Discovery in Figure 1.



        *  build an I-BGP connection to R3 since R3 is a reflector and
           R2 is a non-client (shown with %'s in Figure 2)

        *  not build an I-BGP connection to R5 since R5 is a client of a
           route reflector



Przygienda               Expires 5 September 1998               [Page 8]


Internet Draft         BGP-4 over ATM and Proxy PAR         5 March 1998


   Q5> Router R3 queries for all routers supporting BGP inside of the
       same AS, detects R2 and R5 and concludes to

        *  build an I-BGP connection to R2 since R3 is a reflector and
           R2 is a non-client

        *  build an I-BGP connection to R5 since R5 is a client of the
           route reflector for the same cluster (shown with @'s in
           Figure 2)

   Q6> Router R5 queries for all routers supporting BGP inside of the
       same AS, detects R2 and R3 and concludes to

        *  not build an I-BGP connection to R2 since R5 is a reflector
           client and R2 is a non-client

        *  to build an I-BGP connection to R3 since R3 is the reflector
           for the same cluster R5 is client of

   The resulting peerings are visualized in Figure 2.  Based on the
   configuration of BGP properties the network automatically set up
   valid and necessary connections between routers.  It should be
   obvious that especially for I-BGP such a mechanism faciliates the
   maintainance of many routers inside of an AS. The necessary route
   reflector and mesh connections for BGP are built correctly.  A
   carefull reader observes as well that the automatically formed full
   set of E-BGP connections between AS border routers is not always a
   good thing.  This problem will be given some special consideration.

   The intended auto-configuration behavior when registering and
   retrieving information can be split across the internal and external
   BGP functionality boundary.  Since I-BGP requires a full mesh
   configuration  (2) Proxy PAR information proves very beneficial to
   meet this necessary constraint in an automatic manner.  For E-BGP, as
   mentioned above, a full mesh between all peers on the same subnet is
   not always a good solution and therefore Proxy PAR information has to
   be treated more carefully or not used at all.

___________________________________________
2. with exceptions in presence of route reflectors, of course






Przygienda               Expires 5 September 1998               [Page 9]


Internet Draft         BGP-4 over ATM and Proxy PAR         5 March 1998


2.2. BGP Configuration Interaction with Proxy PAR

   To resolve problems with multiple IP subnets operating on top of a
   single ATM NSAP, multiple BGP instances, and possibly even multiple
   ATM clouds the router attaches to, router configuration has to define
   what information is feasible to be registered.  As default, any
   new upcoming IP interface running on top of an ATM link should be
   registered with the server on one of the ATM links interfacing with
   the same ATM cloud.  The necessary IP instance is determined by
   the BGP instance and the NSAP is equivalent to the NSAP of the ATM
   interface through which the registration is performed.


2.2.1. Registration of Information for Autoconfiguration of External BGP
   Peerings

   An implicit assumption when using Proxy PAR for autoconfiguration of
   BGP external peerings is that multihop peers are not supported.  A
   BGP router with an IP over ATM interface that attaches to a subnet
   between different AS'es registers the interface for the according IP
   instance with one of the proxy PAR servers on the same cloud.  It is
   possible, although not necessary, to omit multiple registrations in
   the case of a BGP router having multiple interfaces to the same IP
   subnet with broadcast capabilities.


2.2.2. Registration of Information for Autoconfiguration of Internal BGP
   Peerings

   For the IP over ATM interfaces on subnets being entirely inside of
   the router's AS, BGP instances should register with proxy PAR server.
   This allows for necessary sessions to be formed and consecutively
   provides full mesh connectivity between non-clients, and star
   connectivity inside route reflector clusters.  Same optimizations as
   described in section 2.2.1 are possible.


2.3. Proxy PAR Interaction with BGP Configuration

2.3.1. Autoconfiguration of Internal BGP Peerings

   Proxy PAR presence in a BGP network 'on the internal side' is helping
   to meet the requirement that all I-BGP peers have to be connected as
   full-mesh or connect to their route reflectors.  To make sure that


Przygienda              Expires 5 September 1998               [Page 10]


Internet Draft         BGP-4 over ATM and Proxy PAR         5 March 1998


   all route reflector clients and non-clients are configured correctly,
   Proxy PAR queries will present enough information to let the routers
   configure a minimal valid connectivity graph.  After being provided
   with the information about all BGP peers running in the same AS, a
   BGP router determines which peers it must initiate connections to
   based on the following criteria:

    -  looking at the other router's BGP identifier no session has been
       formed yet and

    -  the other router is in the same AS and

        *  one router is route reflector with the same cluster ID and
           the other router is a client of this cluster or

        *  one of the routers is a non-client

   The example in section 2.1 encompasses the different cases that can
   trigger initiation of connections.


2.3.2. Autoconfiguration of external BGP peerings

   Proxy PAR registration information made available can be used to
   determine which BGP routers are present to form sessions with.
   Normally, all routers on a specific DMZ subnet are interested in
   forming relationships with routers in different ASes to exchange
   route information.  However, to prevent unnecessary or insecure
   external sessions, each of the IP interfaces on a subnet reaching
   into other AS'es can filter information from query results based
   on any of the fields or combinations thereof.  The filter would
   prevent BGP from autodetecting the registration and effectively the
   possible neighbor.  Since the connection could be initiated from
   either side, the filters should be symmetrical in both BGP peers that
   try to prevent that session from forming.  If this is unenforcable,
   a peer accepting an E-BGP connection for which Proxy PAR information
   is filtered, could explicitly close it after providing appropriate
   notification.


2.4. IP to ATM Address Resolution

   Given the nature of Proxy PAR registrations that contain not only
   BGP specific information but always carry IP interface address and


Przygienda              Expires 5 September 1998               [Page 11]


Internet Draft         BGP-4 over ATM and Proxy PAR         5 March 1998


   the attached NSAP, when running BGP over IP interfaces on top of ATM
   with Proxy PAR capabilities, the information obtained in queries can
   be used to provide address resolution for the lower layers.  When
   BGP chooses to initiate a connection to a peer, lower layers of the
   TCP/IP protocol stack could use the available Proxy PAR information
   to resolve the IP address into the necessary NSAP of the registration
   point.  Such a solution however necessitates an appropriate stack
   architecture.


3. Acknowledgments

   Comments and contributions from several sources, especially Rob
   Coltun are included in this work.


4. Security Consideration

   Security issues in the context of BGP autoconfiguration in presence
   of Proxy PAR can be split into parts specific to either of the
   protocols.  BGP protocol addresses the issues in existing RFCs
   and ongoing work.  PNNI protocol in version 2 contains peer
   authentication mechanisms and Proxy PAR in itself could be extended
   to encompass the same security features in the future.  To address
   the problem of security of Proxy PAR client/server interactions,
   especially registrations that could be used for denial-of-service
   attacks is an issue not addressed so far.  Its scope is similar to
   the problem of a secure ILMI [AF96a].


5. Conclusions

   This RFC specifes for BGP implementors and users mechanisms
   describing how the protocol operates in ATM networks over PVC and
   SVC meshes with the presence of Proxy PAR. These recommendations
   do not require any protocol changes and allow for simpler, more
   efficient and cost- effective network designs.  Proxy PAR can help
   to distribute configuration changes when BGP capable routers are
   reconfigured on the ATM cloud and greatly facilitates consistence of
   I-BGP meshes and can be used for E-BGP auto-configuration as well.






Przygienda              Expires 5 September 1998               [Page 12]


Internet Draft         BGP-4 over ATM and Proxy PAR         5 March 1998


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.

   [Bat96] T. Bates.  BGP Route Reflection, RFC 1966.  Internet
           Engineering Task Force, June 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.

   [For98] ATM Forum.  PNNI Augmented Routing (PAR) Version 1.0.  ATM
           Forum PNNI-RA-PAR-01.04, 1998.

   [Hei93] J. Heinanen.  Multiprotocol Encapsulation over ATM Adaptation
           Layer 5, RFC 1483.  Internet Engineering Task Force, July
           1993.

   [RL95]  Y. Rekhter and T. Li.  A Border Gateway Protocol 4 (BGP-4),
           RFC 1771.  Internet Engineering Task Force, March 1995.

   [RL97]  Y. Rekhter and T. Li.  A Border Gateway Protocol 4 (BGP-4).
           Internet Draft, 1997.


Authors' Addresses


Tony Przygienda
Bell Labs, Lucent Technologies
101 Crawfords Corner Road


Przygienda              Expires 5 September 1998               [Page 13]


Internet Draft         BGP-4 over ATM and Proxy PAR         5 March 1998


Holmdel, NJ 07733-3030
prz@dnrc.bell-labs.com












































Przygienda              Expires 5 September 1998               [Page 14]