Network Working Group Karthikeyan (Samsung Electronics) Internet Draft Srivastav (Samsung Electronics) Expiration Date: December 2003 June 2003 Auto Summarization in RIPv2 draft-karthikeyan-autosummarization-in-ripv2-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with 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. 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". 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 This document describes an extensible mechanism that allows a RIPv2 [RIP2] speaker to advertise summarized routes to its peers without changing the format of the RESPONSE message. Summarized routes are carried in RESPONSE message like normal RIPv2 routes. Summarized routes are treated as normal routes on the receiving side. No extra provisions are required to discriminate between summarized and normal routes. The mechanisms described in this document is OPTIONAL and is applicable to all RIPv2 speaking routers, with some modifications Karthikeyan, Srivastav [Page 1] INTERNET DRAFT Auto Summarization in RIPv2 June 2003 in the routing information base and output processing for storing and advertising summary routes. This mechanism cannot be applied to RIPv1 [RIP1]. 1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEY-WORDS]. 2. Overview In current scenario, due to rapid growth in the internet,large number of routes have to be handled by the routers. In order to improve scalability and efficiency in large networks, routes are summarized.This allows the neighbouring routers to reduce the routing table size and to handle more routes. Auto summarization is enabled when routes cross from classless to classful domain. Apart from reducing routing table size, auto summarization can also improve the stability of the network. If a router is only advertising a summary route to the next downstream router, then it will not advertise changes relating to specific subnets contained within the summarized range. RIPv2 routes that are learnt from the neighbours once found best after running decision process are advertised as such to neighbours. The current implementation does not summarize routes. This document modifies the route information base processing by introducing summary route in addition to the normal RIP routes. The output process of RIP is modified to advertise summary routes and to suppress child routes. 3. Operation In the following sections, "Child route" refers to a classless route or host route. "Summary route" refers to the classful route which is collection of child routes contained within the summarized routes range."Local speaker" refers to a router which is performing route summarization and advertising summary routes."Receiving speaker" refers to a router that peers with the Local speaker to accept summary routes. Auto Summarization SHOULD be enabled by default in routers running RIPv2.RIPv2 implementations should provide configuration commands to disable and enable auto summarization feature. Karthikeyan, Srivastav [Page 2] INTERNET DRAFT Auto Summarization in RIPv2 June 2003 The following section explain how Local speaker should summarize route and advertise summarized routes.Figure 1 shows RTR-B (Router-B) performing auto summarization when routes cross from classless domain to classful domain. ------------------------------ | | | +-------+ | | | | | RTR-c | | | | | /+-------+ | / 10.1.1.0/26 | / <-- |/ | +-------+ /| | | / | /| RTR-D | / | / | | / | / +-------+ --------------------- / |/ 10.1.1.64/26 classful domain | / / <-- | / /| +-------+ +-------+ / | +-------+ | |10.0.0.0/8| | / | | | |RTR-A |----------| RTR-B |/------- | RTR-E | classless domain | | <-- | |\ | | | +-------+ +-------+ \ | +-------+ | \ | 10.1.1.128/26 | <-- \| <-- --------------------- | |\ +-------+ | \ | | | \ | RTR-F | | \| | | +-------+ | 10.1.1.192/26 | <-- ----------------------------------- Karthikeyan, Srivastav [Page 3] INTERNET DRAFT Auto Summarization in RIPv2 June 2003 4. Metric manipulation in the Local speaker Summary routes are formed from the best metric of all child routes. When a new child route with best metric is learnt or when the metric of the current "best child route" changes, summary route metric SHOULD be updated. When child route with the best metric is no more active,summary route metric SHOULD be changed to the next best available metric of the child route. Section 3.9.2 of RIPv2 [RIP2] explains the processing of RESPONSE message and modification of routing information base accordingly. Summary routes are formed and installed into the routing information base as soon as new child RIP routes are inserted into the routing information base. 5. Output Processing in the Local speaker Local speaker advertises summary route and suppresses the advertisement of child routes. Section 3.10 of [RIP2] explains the output processing by traversing the routing table where child routes are stored. When auto summarization is enabled,routing information base SHOULD be traversed to advertise only summary routes. When child route with best metric is no more active, trigger update for the summary route with the next best metric SHOULD be generated. When no more child route exist,trigger update for the summary route with infinity metric MUST be generated. Trigger update SHOULD not be generated if there is a change in the metric of the child route, which does not affect the summary route. 6. Route Information Base in the Local speaker Implementers MAY store summary routes in separate routing table. Separate routing table reduces the time involved in retrieving all the summary routes during output process for sending periodic updates. Otherwise,single routing table that is used for storing both summary and child routes, need to be traversed for sending periodic updates There may be case, when Local speaker may learn a classful route. In this case the implementers SHOULD take care to differentiate between Karthikeyan, Srivastav [Page 4] INTERNET DRAFT Auto Summarization in RIPv2 June 2003 learnt summary route and summarized classful route. This case can be taken care of by having two route tables as discussed above in this section.Summarized route SHOULD have the nexthop set to the Local speaker address, which summarizes the route. 7. Timer processing in Local speaker As summarized routes are not RIP learnt route, it is not necessary to maintain route entry timeout timer for the summarized route. Garbage collection timer should be maintained for the summary routes. 8. Summary route formation in Local speaker Child routes stored in the routing table are converted into summary routes by converting subprefixes to the classful network boundary. Summary routes SHOULD not be formed in disconnected subnets. If the network is composed of disconnected subnets, auto summarization SHOULD be disabled to advertise the subnets. 9. Input Processing in Local speaker REQUEST packet in RIP is used to ask for a response containing all or part of router's routing information base. Whenever Local speaker gets request for child route, if child route is available in the routing information base. Local speaker should generate RESPONSE packet for child route with metric as in the routing table. 10. Interface down in Local speaker When RIPv2 interface is administratively put down, summary routes formed from the child routes learnt via this interface should be updated with the next best available metric from the child route which fall in this summarized range. If there are no more child routes available, summary route SHOULD be updated with infinity metric. Trigger update SHOULD be generated for the updated summary route. Karthikeyan, Srivastav [Page 5] INTERNET DRAFT Auto Summarization in RIPv2 June 2003 11. Processing of default route in Local speaker Default routes SHOULD not be summarized. Default routes are advertised without manipulating metric or nexthop unlike the summarized route.When Local speaker receives REQUEST for default route, RESPONSE should be generated. 12. Processing of host routes in Local speaker Host routes are summarized like the child routes. All the summarization rules for child routes are applicable to host routes. 13. Forwarding Information Base updation in Local speaker Local Speaker SHOULD update the Forwarding Information Base with child routes.Summary routes SHOULD not be updated in the Forwarding Information Base as auto summarization technique is used to reduce the neighbouring forwarding or routing information base size. 14. Processing in Receiving speaker Receiving speaker cannot discriminate the summary routes and child routes. The processing in the Receiving speaker remains unchanged. Receiving speaker MUST update the routes as discussed in RIPv2 specification. 15. Disabling auto summarization in Local speaker When auto summarization is disabled,Local speaker SHOULD carry out the following steps only if there is no RIP learnt route matching the summarized route. (1) Summary routes metric SHOULD be updated with infinity metric. (2) Summary routes modified in step (1) SHOULD be advertised in the form of trigger update. (3) Garbage collection of the summary route SHOULD be set. (4) The suppressed child routes should be advertised. If there is matching child route, advertise the suppressed child routes. 16. Restrictions to RIPv2 auto summarization Auto summarization SHOULD be disabled if split horizon is enabled. Karthikeyan, Srivastav [Page 6] INTERNET DRAFT Auto Summarization in RIPv2 June 2003 17. Security Considerations This document introduces no new security concerns to RIPv2 or other specifications referenced in this document. 18. References [RIP2] Malkin. G., "RIP Version 2 - Carrying Additional Information" ,RFC 1723, Xylogics, November 1994. [RIP1] Hedrick. C., "Routing Information Protocol", RFC 1058, Rutgers University, June 1988. [KEY-WORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 19. AuthorĘs Address S.Karthikeyan Network Systems Division, Samsung India Software Operations, Bangalore INDIA Email: karthiks@samsung.com Subodh Srivastava Network Systems Division, Samsung India Software Operations, Bangalore INDIA Email: subodh@samsung.com 20. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Karthikeyan, Srivastav [Page 7] INTERNET DRAFT Auto Summarization in RIPv2 June 2003 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expiration Date: December 2003