Network Working Group Shankar Kambat Internet Draft Venkatraman Ramalingam Expiration Date: September 2003 Pandi Chandran Wipro Technologies March 2003 BGP-4 Reference Attribute Capability Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract As the size of the routing table in the Internet grows, there is a need for routing protocols to reduce the control information and also improve time taken for route convergence. In this draft we propose a new capability in Border Gateway Protocol (BGP) to reduce the size of the UPDATE message when the same path attributes are used for consecutive UPDATE messages. This allows more number of routes to be sent in a single UPDATE message and also reduces extraction processing in the receiving router. 1. Introduction Border Gateway Protocol (BGP) [1] is used as the inter-domain routing protocol in the Internet. BGP protocol uses OPEN message for negotiating capabilities between peers [2]. UPDATE messages are sent between peers containing NLRI (Network Layer Reachability Information) with mandatory path attributes such as ORIGIN, NEXTHOP, and AS PATH information along with optional path attributes. When a route advertisement contains NLRIs with same path attributes, NLRIs may be grouped before advertising to a peer. These NLRIs may be sent in one or more UPDATE messages based on how many NLRIs could be packed in a single UPDATE message [1]. In this draft a new capability is proposed in Border Gateway Protocol (BGP) to reduce the size of the UPDATE message sent so that bandwidth usage and processing time are reduced. As a part of peering establishment, OPEN messages are sent between peers to negotiate the capabilities that the routers support. As a part of this negotiation, a new capability is added to indicate the peer that all UPDATE messages do not carry all the path attribute information. If path attributes are shared by NLRIs that are sent in multiple UPDATE messages only the first UPDATE message contains all the path attributes. The remaining UPDATE messages contain a new path attribute called Reference Attribute that allows attributes to be shared across subsequent multiple UPDATE messages. 2. Reference Attribute Capability A BGP speaker that uses Reference Attribute capability should use capability advertisement procedures [2] to determine whether the speaker could use this capability with a particular peer. The Capability Value field is defined as: ----------------------------------------- | Cap Code | Length | AFI | SAFI|... ----------------------------------------- 1 octet 1 octet 3 octets Cap Code : Code for Reference Attribute Capability Length : Length of data field AFI : set of AFI and SAFI values The capability code field is set to a new capability (which indicates Reference Attribute Capability - to be defined). The capability length field is set to the length of the data that follows. The data field contains AFI/SAFI values for which Reference Attribute capability is supported. A speaker that supports multiple tuples includes them as multiple capabilities in the capabilities optional parameter. To have a bi-directional exchange of routing information for a particular between a pair of BGP speakers, each such speaker must advertise to the other (via the capability advertisement mechanism) the capability to support the attribute for that particular routes. This capability allows a BGP speaker to send UPDATE messages with reference attribute when the UPDATE messages share the same path attributes. 3. UPDATE Message with Reference Attribute The Reference Attribute is a non-transitive optional BGP attribute, with the Type Code (to be assigned). This attribute is currently defined with only a type code, as this is a dummy attribute to indicate that path attributes are same as the one sent in the last update to a peer. 3.1 Receiving Speaker If a BGP speaker supports this capability and receives an UPDATE message without Reference attribute, it must store the received path attribute in a local buffer. If it receives an UPDATE message with reference attribute, the path attributes of the previous UPDATE message is used as the path attribute for the current update message. 3.2 Sending Speaker If a BGP speaker supports this capability and is sending an update, it must compare the path attributes to be sent with the path attributes of previous UPDATE message stored in the buffer. If all the attributes are same, add only the Reference attribute to UPDATE message with attribute length 0 and send it. 4. Implementation Considerations This feature requires the sending and the receiving speaker retain the path attributes of the last UPDATE message sent and received respectively on per peer basis. 5. IANA Considerations A new capability code for reference attribute feature and new attribute code for Reference Attribute needs to be defined by IANA. 6. Security Considerations Security issues are not discussed in this memo. 7. References 1. RFC 1771, A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li. March 1995 2. RFC 2842 Capabilities Advertisement with BGP-4. R. Chandra, J. Scudder. May 2000 8. Author's Address K A Shankar Wipro Technologies Bangalore, India Shankar.kambat@wipro.com R Venkatraman Wipro Technologies Bangalore, India Venkatraman.ramalingam@wipro.com P Pandi Chandran Wipro Technologies Bangalore, India Pandi.chandran@wipro.com Expiration Date : September 2003