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: 2019-Feb-16
Document File: 22 page(s) / 26K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

G. Meyer: AUTHOR [+1]

Related Documents

10.17487/RFC2091: DOI

Abstract

This document defines a modification which can be applied to Bellman- Ford (distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 8% 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.

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

Processing...
Loading...