Browse Prior Art Database

Unified Routing Requirements for IPng (RFC1668)

IP.com Disclosure Number: IPCOM000002504D
Original Publication Date: 1994-Aug-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 3 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Estrin: AUTHOR [+3]

Abstract

This document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list.

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

Network Working Group D. Estrin

Request for Comments: 1668 USC

Category: Informational T. Li

Cisco Systems

Y. Rekhter

T.J. Watson Research Center, IBM Corp.

August 1994

Unified Routing Requirements for IPng

Status of this Memo

This memo provides information for the Internet community. This memo

does not specify an Internet standard of any kind. Distribution of

this memo is unlimited.

Abstract

This document was submitted to the IETF IPng area in response to RFC

1550. Publication of this document does not imply acceptance by the

IPng area of any ideas expressed within. Comments should be

submitted to the big-internet@munnari.oz.au mailing list.

1. IPng Requirements

The following list provides requirements on the IPng from the

perspective of the Unified Routing Architecture, as describe in RFC

1322.

1. To provide scalable routing, IPng addressing must provide support

for topologically significant address assignment.

2. Since it is hard to predict how routing information will be

aggregated, the IPng addressing structure should impose as few

preconditions as possible on the number of levels in the hierarchy.

Specifically, the number of levels must be allowed to be different

at different parts in the hierarchy. Further, the levels must not

be statically tied to particular parts (fields) in the addressing

information.

3. Hop-by-hop forwarding algorithm requires IPng to carry enough

information in the Network Layer header to unambiguously determine

a particular next hop. Unless mechanisms to compute

context-sensitive forwarding tables and provide consistent

forwarding are defined, the requirement assumes the presence of

full hierarchical addresses. Therefore, IPng packet format must

provide efficient determination of the full hierarchical

destination address.

4. Hierarchical address assignment should not imply strictly

hierarchical routing. Therefore, IPng should carry enough

information to provide forwarding along both hierarchical and

non-hierarchical routes.

5. The IPng packet header should accommodate a "routing label" or

"route ID". This label will be used to identify a particular FIB

to be used for packet forwarding by each router.

Two types of routing labels should be supported: "strong" and

"weak".

When a packet carries a "strong" routing label and a router does

not have a FIB with this label, the packet is discarded (and an

error message is sent back to the source).

When a packet carries a "weak" routing label and a router does not

have a FI...