Dismiss
InnovationQ/InnovationQ Plus content will be updated on Sunday, June 25, 10am ET, with new patent and non-patent literature collections. Click here to learn more.
Browse Prior Art Database

IP Router Alert Option (RFC2113)

IP.com Disclosure Number: IPCOM000002666D
Original Publication Date: 1997-Feb-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 3 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Katz: AUTHOR

Abstract

This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. This is useful for, but not limited to, new protocols that are addressed to a destination but require relatively complex processing in routers along the path.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 40% of the total text.

Network Working Group D. Katz

Request for Comments: 2113 cisco Systems

Category: Standards Track February 1997

IP Router Alert Option

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 memo describes a new IP Option type that alerts transit routers

to more closely examine the contents of an IP packet. This is useful

for, but not limited to, new protocols that are addressed to a

destination but require relatively complex processing in routers

along the path.

1.0 Introduction

A recent trend in routing protocols is to loosely couple new routing

functionality to existing unicast routing. The motivation for this

is simple and elegant -- it allows deployment of new routing

functionality without having to reinvent all of the basic routing

protocol functions, greatly reducing specification and implementation

complexity.

The downside of this is that the new functionality can only depend on

the least common denominator in unicast routing, the next hop toward

the destination. No assumptions can be made about the existence of

more richly detailed information (such as a link state database).

It is also desirable to be able to gradually deploy the new

technology, specifically to avoid having to upgrade all routers in

the path between source and destination. This goal is somewhat at

odds with the least common denominator information available, since a

router that is not immediately adjacent to another router supporting

the new protocol has no way of determining the location or identity

of other such routers (unless something like a flooding algorithm is

implemented over unicast forwarding, which conflicts with the

simplicity goal).

One obvious approach to leveraging unicast routing is to do hop-by-

hop forwarding of the new protocol packets along the path toward the

ultimate destination. Each system that implements the new protocol

would be responsible for addressing the packet to the next system in

the path that understood it. As noted above, however, it is

difficult to know the next system implementing the protocol. The

simple, degenerate case is to assume that every system along the path

implements the protocol. This is a barrier to phased deployment of

the new protocol, however.

RSVP [1] finesses the problem by instead putting the address of the

ultimate destination in the IP Destination Address field, and then

asking that every RSVP router make a "small change in its ...

forwarding path" to look for the specific RSVP packet t...