📄 rfc2091.txt
字号:
Network Working Group G. Meyer
Request for Comments: 2091 Shiva
Category: Standards Track S. Sherry
Xyplex
January 1997
Triggered Extensions to RIP to Support Demand Circuits
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document defines a modification which can be applied to
Bellman-Ford (distance vector) algorithm information broadcasting
protocols - for example IP RIP, Netware RIP or Netware SAP - which
makes it feasible to run them on connection oriented Public Data
Networks.
This proposal has a number of efficiency advantages over the Demand
RIP proposal (RFC 1582).
Acknowledgements
The authors wish to thank Richard Edmonstone of Shiva, Joahanna
Kruger of Xyplex, Steve Waters of DEC and Guenter Roeck of Conware
for many comments and suggestions which improved this effort.
Conventions
The following language conventions are used in the items of
specification in this document:
o MUST -- the item is an absolute requirement of the specification.
MUST is only used where it is actually required for
interoperation, not to try to impose a particular method on
implementors where not required for interoperability.
o SHOULD -- the item should be followed for all but exceptional
circumstances.
Meyer & Sherry Standards Track [Page 1]
RFC 2091 Trigger RIP January 1997
o MAY or optional -- the item is truly optional and may be followed
or ignored according to the needs of the implementor.
The words "should" and "may" are also used, in lower case, in
their more ordinary senses.
Table of Contents
1. Introduction ........................................... 2
2. Overview ............................................... 3
3. The Routing Database ................................... 5
3.1. Presumption of Reachability ...................... 6
3.2. Alternative Routes ............................... 6
3.3. Split Horizon with Poisoned Reverse .............. 7
3.4. Managing Updates ................................. 7
3.5. Retransmissions .................................. 7
4. New Packet Types ....................................... 8
4.1. Update Request (9) ............................... 9
4.2. Update Response (10) ............................. 9
4.3. Update Acknowledge (11) .......................... 10
5. Packet Formats ......................................... 10
5.1. Update Header .................................... 10
5.2. IP Routing Information Protocol Version 1 ........ 11
5.3. IP Routing Information Protocol Version 2 ........ 11
5.4. Netware Routing Information Protocol ............. 12
5.5. Netware Service Advertising Protocol ............. 12
6. Timers ................................................. 17
6.1. Database Timer ................................... 17
6.2. Hold Down Timer .................................. 17
6.3. Retransmission Timer ............................. 18
6.4. Over-subscription Timer .......................... 18
7. Security Considerations ................................ 19
Appendix A - Implementation Suggestion .................... 20
References ................................................ 21
Authors' Addresses ........................................ 22
1. Introduction
Routers are used on connection oriented networks, such as X.25 packet
switched networks and ISDN networks, to allow potential connectivity
to a large number of remote destinations. Circuits on the Wide Area
Network (WAN) are established on demand and are relinquished when the
traffic subsides. Depending on the application, the connection
between any two sites for user data might actually be short and
relatively infrequent.
Meyer & Sherry Standards Track [Page 2]
RFC 2091 Trigger RIP January 1997
Periodic broadcasting by Bellman-Ford (distance vector) algorithm
information broadcasting protocols IP RIP [1], IP RIP V2 [2] or
Netware RIP and SAP [3] generally prevents WAN circuits from being
closed. Even on fixed point-to-point links the overhead of periodic
transmission of RIP - and even more so SAP broadcasts - can seriously
interrupt normal data transfer simply through the quantity of
information which hits the line every 30 or 60 seconds.
To overcome these limitations, this specification modifies the
distance vector protocols so as to send information on the WAN only
when there has been an update to the routing database OR a change in
the reachability of a next hop router is indicated by the task which
manages connections on the WAN.
Because datagrams are not guaranteed to get through on all WAN media,
an acknowledgement and retransmission system is required to provide
reliability.
The protocols run unmodified on Local Area Networks (LANs) and so
interoperate transparently with implementations adhering to the
original specifications.
This proposal differs from Demand RIP [4] conceptually as follows:
o If a router has exchanged all routing information with its partner
and some routing information subsequently changes only the changed
information is sent to the partner.
o The receiver of routes is able to apply all changes immediately
upon receiving information from a partner.
These differences lead to further reduced routing traffic and also
require less memory than Demand RIP [4]. Demand RIP also has an
upper limit of 255 fragments in an update which is lifted in
Triggered RIP (which does not use fragmentation).
2. Overview
Multiprotocol routers are used on connection oriented Wide Area
Networks (WANs), such as X.25 packet switched networks and ISDN
networks, to interconnect LANs. By using the multiplexing properties
of the underlying WAN technology, several LANs can be interconnected
simultaneously through a single physical interface on the router.
Meyer & Sherry Standards Track [Page 3]
RFC 2091 Trigger RIP January 1997
A circuit manager provides an interface between the connectionless
network layers, IP and IPX, and the connection oriented WAN, X.25,
ISDN etc. Figure 1 shows a schematic representative stack showing
the relationship between routing protocols, the network layers, the
circuit manager and the connection oriented WAN.
-------------- --------- ---------
| RIP | | RIP | | SAP |
-------------- --------- ---------
| | |
-------------- | |
| UDP | | |
-------------- | |
| | |
-------------- ----------------
| IP | | IPX |
-------------- ----------------
| |
-------------------------------------------
| Circuit Manager |
-------------------------------------------
||||||||||
||||||||||
---------------------------
| Connection Oriented |
| WAN stack |
---------------------------
A WAN circuit manager will support a variety of network
layer protocols, on its upper interface. On its lower interface,
it may support one or more subnetworks. A subnetwork may support
a number of Virtual Circuits.
Figure 1. Representative Multiprotocol Router stack
The router has a translation table which relates the network layer
address of the next hop router to the physical address used to
establish a Virtual Circuit (VC) to it.
The circuit manager takes datagrams from the connectionless network
layer protocols and (if one is not currently available) opens a VC to
the next hop router. A VC can carry all traffic between two end-
point routers for a given network layer protocol (or with appropriate
encapsulation all network layer protocols). An idle timer (or some
other mechanism) is used to close the VC when the datagrams stop
arriving at the circuit manager.
Meyer & Sherry Standards Track [Page 4]
RFC 2091 Trigger RIP January 1997
If the circuit manager has data to forward (whether user data OR a
routing update) and fails to obtain a VC it informs the routing
application that the destination is unreachable (circuit down). The
circuit manager is then expected to perform whatever is necessary to
recover the link. Once successful, it informs the routing
application (circuit up).
In Triggered RIP, routing updates are only transmitted on the WAN
when required:
1 When a specific request for a routing update has been received.
2 When the routing database is modified by new information from
another interface.
3 When the circuit manager indicates that a destination has changed
from an unreachable (circuit down) to a reachable (circuit up)
state.
4 And also when a unit is first powered on to ensure that at least
one update is sent. This can be thought of as a transition from
circuit down to circuit up. It MAY contain no routes or services,
and is used to flush routes or services from the peer's database.
In cases 1,3 and 4 the full contents of the database is sent. In
case 2 only the latest changes are sent.
Because of the inherent unreliability of a datagram based system,
both routing requests and routing responses require acknowledgement,
and retransmission in the event of NOT receiving an acknowledgement.
3. The Routing Database
Entries in the routing database can either be permanent or temporary.
Entries learned from broadcasts on LANs are temporary. They will
expire if not periodically refreshed by further broadcasts.
Entries learned from a triggered response on the WAN are 'permanent'.
They MUST not time out in the normal course of events. Certain
events can cause these routes to time out.
Meyer & Sherry Standards Track [Page 5]
RFC 2091 Trigger RIP January 1997
3.1 Presumption of Reachability
If a routing update is received from a next hop router on the WAN,
entries in the update are thereafter always considered to be
reachable, unless proven otherwise:
o If in the normal course of routing datagrams, the circuit manager
fails to establish a connection to the next hop router, it
notifies the routing application that the next hop router is not
reachable through an internal circuit down message.
The database entries are first marked as temporary and aged
normally; Some implementations may choose to omit this initial
aging step. The routing application then marks the appropriate
database entries as unreachable for a hold down period (the normal
120 second RIP hold down timer).
o If the circuit manager is subsequently able to establish a
connection to the next hop router, it will notify the routing
application that the next hop router is reachable through an
internal circuit up message.
The routing application will then exchange messages with the next
hop router so as to re-prime their respective routing databases
with up-to-date information.
The next hop router may also be marked as unreachable if an excessive
number of retransmissions of an update go unacknowledged (see section
6.3).
Handling of circuit up and circuit down messages requires that the
circuit manager takes responsibility for establishing (or re-
establishing) the connection in the event of a next hop router
becoming unreachable. A description of the processes the circuit
manager adopts to perform this task is outside the scope of this
document.
3.2 Alternative Routes
A requirement of using Triggered RIP for propagating routing
information is that NO routing information ever gets LOST or
DISCARDED. This means that all alternative routes SHOULD be
retained.
It MAY be possible to operate with a sub-set of all alternative
routes, but this adds complexity to the protocol - which is NOT
covered in this document.
Meyer & Sherry Standards Track [Page 6]
RFC 2091 Trigger RIP January 1997
3.3 Split Horizon with Poisoned Reverse
The rules for Split Horizon with Poisoned Reverse MUST be used to
determine whether and/or how a route is advertised on an interface
running this protocol.
Split Horizon consists of omitting routes learned from a peer when
sending updates back to that peer. With Poisoned Reverse instead of
omitting those routes, they are advertised as unreachable (setting
the metric to infinity).
A route is only poisoned if it is the best route (rather than an
inferior alternative route) in the database.
Poison Reverse is necessary because a router may be advertising a
route to a network to its partner and then later learn a better route
for the same network from the partner. Without Poison Reverse the
partner will not know to discard the inferior route learned from the
first router.
3.4 Managing Routing Updates
The routing database SHOULD be considered to be a sequence of
elements ordered by the time it was last updated. If there is a
change in the best route (i.e. a new route is added or a route's
metric has changed), the route is reordered and given a new highest
sequence number.
Sending updates to a peer consists of running through the database
from the oldest entry to the newest entry. Once an entry has been
sent and acknowledged it is generally never resent. As new routing
information arrives, only the new information is sent.
3.5 Retransmissions
Handling retransmission of updates is simplest if updates are
restricted to never having more than one un-acknowledged update
outstanding - "one packet in flight". A copy of the update packet
can be kept and retransmitted until acknowledged - and then
subsequent update packets are sent in turn until the full database
(to date) has been sent and acknowledged.
Meyer & Sherry Standards Track [Page 7]
RFC 2091 Trigger RIP January 1997
Things become more complicated if several packets are sent in quick
succession without waiting for an acknowledgements between packets -
"several packets in flight":
o If packets arrive out of order they could corrupt the peer's
database. If the underlying datalink layer bundles several VCs,
it MUST guarantee to NOT reorder datagrams.
o If the elements making up a packet requiring retransmission change
because of an alteration in the database, stale incorrect
information could be sent (again new information could overtake
old information).
To guard against this when 'retransmitting' a packet when the
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -