Curtis Villamizar Request for Comments: DRAFT ANS Version: not yet submitted March 1994 Locating a NBMA ARP Server using BGP Status of this memo This draft is on the IETF entertainment track until it is decided whether to submit it for consideration. Once that is decided, I'll pull this nonsense out and send it to the drafts editor. This draft suggests a BGP attribute for use in carrying a the address of either a NBMA ARP Server (NAS). This attribute is applicable to any version of BGP, although discussed here in the context of BGP-4. 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. 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." Distribution of this memo is unlimited. This draft is also available in postscript. 1 Overview NBMA Address Resolution Protocol (NARP) is under consideration as a means to provide addressing translation for non-broadcast multiple access (NBMA) link layer media. Given that some destinations will be accessible directly from the NBMA, and others will not, this BGP attribute provides a means to first make this determination, and second to determine the most appropriate nearby server to direct a query. Without such an attribute, the only means of determining if a host is directly reachable is to make an ARP request and see if a positive reply is returned. This presents practical problems described in the Discussion section near the end of this document. Expiration Date: September 1994 [Page 0] RFC DRAFT March 1994 2 BGP Attribute Format Attribute Name NBMA_SERVER_LOC Attribute Code TBD Attribute Type The NBMA_SERVER_LOC attribute is an optional non- transitive attribute. Attribute Data The NBMA_SERVER_LOC attribute will carry the address of a NBMA ARP server. For IPv4, this address will be 4 bytes long. 3 Protocol Operation A router advertising BGP NLRI to an NBMA for a destination not directly reachable by the NBMA would provide it's own address as the next hop and provide a NBMA_SERVER_LOC attribute. Routers within the NBMA are free to aggregate such routes only if they are willing to provide their own address as the next hop and forward traffic to these destinations. In many cases, such NLRI will already be well aggregated and little may stand to be gained by further aggregation. Routers within the NBMA which are advertising NLRI for it's own logical Internet subnet (LIS) to other routers within the NBMA should include their own address as the next hop and generally provide a NBMA_SERVER_LOC attribute containing their own address (otherwise provide no NBMA_SERVER_LOC attribute at all as described below). In readvertising these NLRI, further aggregation may be performed, with the aggregator replacing both the next hop and address in the NBMA_SERVER_LOC attribute with it's own address. If very little traffic will be forwarded hop by hop, replacing the next hop will introduce very little inefficiency (extra hops). The aggregator will simply be required to forward NMBA ARP requests. In some cases, routers within the NBMA which are advertising NLRI for a Logical IP Subnetwork (LIS) may want to advertise a route with no NBMA_SERVER_LOC attribute to prevent direct connections to routers which could not support the number of direct connections needed for the number of NBMA hosts for which it typically communicates or to prevent use of direct connections for other reasons. NLRI which include a NBMA_SERVER_LOC attribute should generally not be aggregated with those that do not contain this attribute. Dropping the NBMA_SERVER_LOC attribute would prevent direct connection. Adding a NBMA_SERVER_LOC attribute would result in Expiration Date: September 1994 [Page 1] RFC DRAFT March 1994 unessecary NARP requests that will always fail. An end system or a router internal to the NBMA when forwarding packets should use the following procedure. First check for a route. If no route is available, drop the packet. If the route contains a NBMA_SERVER_LOC attribute make a NARP request and temporarily forward traffic to the next hop (allow one level of recursion in which the next hop for the next hop is considered in case this too is being resolved). Once a positive reply is cached, establish a direct connection and use that (or change the response to negative if the connection attempt fails). If a negative reply is cached, simply forward to the next hop (in case the destination is simply unable to support additional direct connections). This implies some state associated with a positive cache entry. Upon entering the initial state a count of remaining retries would be initialized. A connection attempt would be made (involving whatever state transitions occur for the NBMA) as long as the retry counter was not consumed. When the retry counter goes to zero (the maximum number of failed connection attempts have been made) the cache entry should be converted to a negative cache entry (perhaps with a short timeout). Routers at the periphery of the NBMA should never provide a NBMA_SERVER_LOC attribute on any NLRI advertised outside the NBMA. Routers at the periphery which do not understand this attribute will do the right thing in this regard but will forward all traffic to the next hop. The NBMA internal router used as the next hop will try to establish direct connections where appropriate. A router internal to the NBMA which does not understand the NBMA_SERVER_LOC attribute will simply forward all traffic between it adjacent LIS, since they would appear to be disconnected based on the lack of NBMA_SERVER_LOC attributes. For ATM, this is as intended by RFC 1577. 4 Discussion Carrier switched service technologies such as Frame Relay, SMDS, and ATM will provide non-broadcast multiple access when applied to a large environment where broadcast is infeasible. ATM is of particular interest. RFC 1577 provides a means by which ATM WANs may be partitioned into LIS and served by ATM ARP servers. A LIS maintained by a single entity (ie: a telephone service carrier) may actually become quite large since scaling may be accomodated by the provision for multiple cooperating ATM ARP servers. For administrative separation reasons and other reasons, LIS are not expected to span multiple service providers. Such a design, strictly using RFC1577 without NBMA ARP, would involve L3 routers at major Expiration Date: September 1994 [Page 2] RFC DRAFT March 1994 interconnection points between providers. It is also possible that a routing infrastructure may be required within very large service providers to accomodate routers which attach major non-ATM portions of the Internet and would otherwise have to maintain very large numbers of connections. This would result in partitioning into LIS within a provider. For some applications direct connections would be preferred over multiple IP hops. This is a key motivation for providing NARP. For the ATM connected end system, whether the end system is a host or router, there needs to be some means (other than manual configuration) of determining whether a destination is directly reachable over the extended NBMA. 4.1 NBMA Problems avoided by the NBMA_SERVER_LOC attribute support If there is no automated means of determining whether a destination is directly reachable, an ARP request must be made. A cache entry can be installed for such an entry if either a positive or negative response is returned. If a negative response is returned, the cache entry will prevent further ARP requests. For a negative response, the packet must still be forwarded to the next hop, since the entire network may be not local to the NBMA. Note that the next hop must be in the local LIS or same process must be repeated for the next hop. The next hop must be local, so a negative ARP reply for the next hop should result in a packet drop. An ARP cache entry corresponds to a single host. This is clearly the case for a positive response. It is also the case for a negative response. If negative cache entries are present for a host contained within a particular address prefix, NARP requests must still be made for all other hosts in that same address prefix. There is no means to distinguish a negative response due to a host number that does not exist contained within an NBMA reachable prefix from a negative response for a network that is not directly reachable on the NBMA. In either case, packets must be forwarded to the next hop. Receiving ICMP unreachable responses does not provide a means of making this determination. Therefore the prefix length on a negative cache entry cannot be shortenned to the prefix length of route covering the host entry. The negative cache entry must remain host specific. Without support for NBMA_SERVER_LOC attribute, for networks which are not directly reachable from the NBMA, a negative cache entry will have to be obtained and held for each host for which traffic is sent. As mentioned above, this case cannot be distinguished from a host number that does not exist contained within an NBMA reachable prefix. There is also no means of determining whether packets forwarded to Expiration Date: September 1994 [Page 3] RFC DRAFT March 1994 the next hop went any further. Given that a negative response would be needed for each hosts, NBMA reachable or not, and that there are already a few million hosts on the Internet, a very active router might quickly consume considerable cache space. Even if the cache could accomodate this, the unecessary requests and responses and the space to store the cache entries represents a significant inefficiency. 4.2 Flexibility provided by NBMA ARP There may be performance and economic tradeoffs associated with using direct connections within an NBMA. Attempting to use direct connections exclusively may even present feasibility problems. If the tradeoffs favor using direct connections due to cost, improved performance, or better QoS support, the addressing information is provided by NARP and can be used. If cost or performance or QoS tradeoffs favor aggregating traffic and routing hop by hop, configuration can be set to not provide, propogate or make use of the NBMA_SERVER_LOC attribute. It might be the case that for some services direct connections have advantages and for other services, hop by hop routing have advantages. As long as there exists a means for the NBMA end systems or NBMA internal routers to make the distinction between these services, the NBMA_SERVER_LOC attribute can be selectively ignored. For example, connections supported by a resource reservation protocol such as RSVP might benefit from direct connections (possibly due to better QoS support), but other services might not (possibly due to cost). In this case, it might be possible for packet forwarding of RSVP traffic to make use of a NBMA_SERVER_LOC attribute if present, and forwarding of all other traffic might ignore this attribute. Providing the information needed to use direct connections does not require that the information be used. If the tradeoffs change with time, implementations are not commited to either direct connection or hop by hop routing approach. 5 Security Considerations Security Considerations are not discussed in this memo. Acknowledgements I would like to thank Dan Quayle for his insightful comments. [Editorial note: this is a place saver]. Expiration Date: September 1994 [Page 4] RFC DRAFT March 1994 References [1] J. Heinanen and R. Govindan, "NBMA Address Resolution Protocol (NARP)", unsubmitted draft, March 14, 1994 (work in progress) [2] M. Laubach, "Classical IP and ARP over ATM", RFC-1577 [3] K. Lougheed, Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)", RFC-1267 [4] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", Internet Draft, draft-ietf-bgp-bgp4-08.txt, January 1994 (work in progress) Author's Address Curtis Villamizar Advanced Network & Services (ANS) 100 Clearbrook Road Elmsford, NY 10523 Expiration Date: September 1994 [Page 5]