Internet Draft G. Malkin/Xylogics Updates RFC 1058 and RFC 1288 C. Huitema/INRIA March 1993 SIP-RIP Abstract This document specifies a routing protocol, based on the Routing Information Protocol (RIP), as defined in [1,2], for the Simple Internet Protocol (SIP), as defined in [3]. A companion document will define the SNMP MIB objects for SIP-RIP (TBD). Status of this Memo 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." 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. It is intended that this document will be submitted to the IESG for consideration as a standards document. Distribution of this document is unlimited. Acknowledgements Thanks to those whose contributions to RIP-2 have been propogated into SIP-RIP. Malkin, Huitema Expires: 9Sep93 [Page 1] Internet Draft SIP-RIP March 1993 Table of Contents 1. Justification . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2 Prefered Route Determination . . . . . . . . . . . . . . . . 5 3.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 Appendicies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Justification SIP is the Simple Internet Protocol. It stands to reason that the simplest, and best understood, routing protocol should be modified to support it. At the same time, SIP-RIP will make use of many of the RIP-2 extensions. 2. Overview SIP-RIP is not a new version of IP RIP. It is a new protocol which will be run over its own UDP port. Despite that, the changes are only to the format of the routing entries within a routing packet, the basic manipulation of routes and the routing table remains unchanged. SIP-RIP makes use of most of the RIP-2 enhancements; only the route tag field has been omitted. The subnet mask has been replaced by a single byte which specifies the number of bits in the subnet mask, which therefore disallows the use of discontiguous subnet masks. The metric has been reduced to a single byte, but the maximum number of hops permitted is now 32 instead of 16. A new field, throughput class, has been added to characterize the links which are used by a route. The most important change, however, is the increase in the size of the address fields from 32 bits to 64 bits. Since the overall size of a route entry is unchanged, the maximum number of routes per routing packets will also remain unchanged. Malkin, Huitema Expires: 9Sep93 [Page 2] Internet Draft SIP-RIP March 1993 3. Protocol Design SIP-RIP will be run on UDP port ???. Periodic SIP-RIP responses will be sent to the SIP "all routers on this link" multicast address, 7F02:0000:0000:0002. 3.1 Packet Format The SIP-RIP datagram format is: 0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command (1) | Version (1) | Routing Domain (2) | +---------------+---------------+-------------------------------+ | Type | Mask Length(1)| TP Class (1) | Metric (1) | +-------------------------------+-------------------------------+ | SIP Address (8) | | | +---------------------------------------------------------------+ | Next Hop (8) | | | +---------------------------------------------------------------+ All fields are coded in SIP network byte order (big-endian). Command: 1 - request 2 - response Version: 1 - SIP-RIP version 1 Routing Domain: The Routing Domain (RD) number is the number of the routing process to which this update belongs. This field is used to associate the routing update to a specific routing process on the receiving router. The RD is needed to allow multiple, independent RIP "clouds" to co-exist on the same physical wire. This gives administrators the ability to run multiple, possibly parallel, instances of RIP in order to implement simple policy. This means that a router operating within one routing domain, or a set of routing domains, should ignore RIP packets which belong to another routing domain. RD 0 is the default routing domain. Malkin, Huitema Expires: 9Sep93 [Page 3] Internet Draft SIP-RIP March 1993 Type: 1 - Packet Authentication (see section 3.3) 2 - SIP Route Mask Length: The number of one bits in the address/subnet mask, moving left to right. The mask, when applied to the SIP address, yields the non-host portion of the address. Use of a mask length, rather than a complete mask, allows the SIP route entries to be smaller. The drawback, is that discontiguous masks cannot be specified. TP Class: The Throughput Class allows information about the bandwidth of the route to be propogated between routers. The throughput would be encoded with the following formula: INT(10 * log10(datarate_in_Kbps)) There will be no negative classes, so datarates under 1Kbps will be class 0. The following table shows the throughput classes for a few common datarates: Datarate TP Class Datarate TP Class 1200bps 0 4Mbps 36 9600bps 9 10Mbps 40 19.2Kbps 12 16Mbps 42 56Kbps 17 45Mbps 46 115.2Kbps 20 100Mbps 50 1.544Mbps 31 1Gbps 60 Of course, the maximum datarate that can be encoded in one byte is only 3,162,277,000,000,000,000Tbps. Metric: The number of hops to the destination. Infinity is 32. SIP Address: The SIP address of this routes destination. Next Hop: The immediate next hop IP address to which packets to the destination specified by this route entry should be forwarded. Malkin, Huitema Expires: 9Sep93 [Page 4] Internet Draft SIP-RIP March 1993 Specifying a value of 0 in this field indicates that routing should be via the originator of the packet. An address specified as a next hop must, per force, be directly reachable on the logical subnet over which the advertisement is made. The Next Hop field has two purposes. The first purpose is to eliminate packets being routed through extra hops in the system. It is particularly useful when SIP-RIP is not being run on all of the routers on a network, as exampled in Appendix A. The second purpose is to enable the efficient creation of "reverse trees" for the routing of SIP multicast packets, as described in Appendix B. 3.2 Prefered Route Determination The prefered route is determined by taking into account both the Throughput Class and the Metric according to the following rules. 1- When a route is received through a subnet, the Metric is incremented by 1 and the Throughput Class is set to the minimum of the received value and the subnet's Throughput Class. 2- If the Metric has reached infinity, the route shall not be used. 3- When two routes have different Throughput Classes, the route with the larger Throughput Class value is considered to be the shorter, prefered route. 4- When two routes have equal Throughput Classes, the route with the lesser Metric is the shorter, prefered route. 3.3 Authentication The authentication mechanism is similar to that used in RIP-2. If the Type field of the first (and ONLY the first) entry in the packet is type 1, then the remainder of the 20 byte entry is interpreted as a packet authentication. This means that there can be, at most, 24 RIP entries in the remainder of the packet. If authentication is not in use, then no entries in the packet should have an Type field value of 1. The beginning of a packet with an authentication entry has the following format: Malkin, Huitema Expires: 9Sep93 [Page 5] Internet Draft SIP-RIP March 1993 0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command (1) | Version (1) | Routing Domain (2) | +---------------+---------------+-------------------------------+ | Type = 1 | Authtype (1) | reserved (2) | +-------------------------------+-------------------------------+ ~ Authentication (16) ~ +---------------------------------------------------------------+ Currently, the only Authentication Type is simple password and it is type 2. The Authentication field contains the plain text password. If the password is under 16 bytes, it must be left-justified and padded to the right with nulls (0x00). A password is not null terminated; it is 16 bytes long. 4. Security Considerations SIP-RIP uses the same authentication mechanism as RIP-2. The authentication types are described in section 3.3 Malkin, Huitema Expires: 9Sep93 [Page 6] Internet Draft SIP-RIP March 1993 Appendix A Use of SIP-RIP Next Hop to eliminate extra hops ----- ----- ----- ----- ----- ----- |IR1| |IR2| |IR3| |XR1| |XR2| |XR3| --+-- --+-- --+-- --+-- --+-- --+-- | | | | | | --+-------+-------+---------------+-------+-------+-- ^------------SIP-RIP------------^ Assume that IR1, IR2, and IR3 are all "internal" routers which are under one administration (e.g. a campus) which has elected to use SIP RIP as its IGP. XR1, XR2, and XR3, on the other hand, are under separate administration (e.g. a regional network, of which the campus is a member) and are using some other routing protocol (e.g. OSPF). XR1, XR2, and XR3 exchange routing information among themselves such that they know that the best routes to networks N1 and N2 are via XR1, to N3, N4, and N5 are via XR2, and to N6 and N7 are via XR3. By setting the Next Hop field correctly (to XR2 for N3/N4/N5, to XR3 for N6/N7), only XR1 need exchange RIP-2 routes with IR1/IR2/IR3 for routing to occur without additional hops through XR1. Without the Next Hop it would be necessary for XR2 and XR3 to also participate in the SIP-RIP protocol to eliminate extra hops. Malkin, Huitema Expires: 9Sep93 [Page 7] Internet Draft SIP-RIP March 1993 Appendix B Use of SIP-RIP Next Hop for multicast routing Multicast routing is based on "reverse routes". A multicast packet from originator "O" received from subnet "S1" should only be propagated on subnet "S2" if: 1- The scope of the multicast address authorizes this relaying [3], 2- The information obtained through SGMP [4] mentions that the multicast address is "of interest" on subnet "S2", and 3- A packet bound for the address "O" would have been routed through subnet "S1". The route calculated by SIP-RIP can be used to implement the third condition. However, this condition is not sufficient to prevent duplicate delivery when several routers are present on subnet "S2"; one must also analyze the "next hop" information received from these routers. 1- If the local router would not advertise on "S2" a null next hop for the route leading to "O" through "S2", it should not propagate the multicast packet. 2- If several routers advertise a null next hop for the route leading to "O" on "S2", only the router with the lesser SIP address shall propagate the multicast packet. Malkin, Huitema Expires: 9Sep93 [Page 8] Internet Draft SIP-RIP March 1993 References [1] Hedrick, C., Routing Information Protocol, Request For Comments (RFC) 1058, Rutgers University, June 1988. [2] Malkin, G., RIP Version 2 - Carrying Additional Information, Request For Comments (RFC) 1388, Xylogics, Inc., January, 1993. [3] Deering, S., Simple Internet Protocol (SIP) Specification, draft-deering-sip-00.txt, Xerox PARC, November 1992. [4] Davin, J.; Case, J.D.; Fedor, M.; Schoffstall, M.L., Simple Gateway Monitoring Protocol, Request For Comments (RFC) 1028, November 1987. Authors' Addresses Gary Scott Malkin Xylogics, Inc. 53 Third Avenue Burlington, MA 01803 Phone: (617) 272-8140 EMail: gmalkin@Xylogics.COM Christian Huitema INRIA 2004 Route des Lucioles BP 93 06902 Sophia-Antipolis France Phone: +33 93 65 77 15 EMail: Christian.Huitema@sophia.inria.fr Malkin, Huitema Expires: 9Sep93 [Page 9]