Browse Prior Art Database

Triggered Extensions to RIP to Support Demand Circuits (RFC2091)

IP.com Disclosure Number: IPCOM000002643D
Original Publication Date: 1997-Jan-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 17 page(s) / 41K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

G. Meyer: AUTHOR [+2]

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 text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 7% of the total text.

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.

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 ................