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]