Browse Prior Art Database

"Local/Remote" Forwarding Decision in Switched Data Link Subnetworks (RFC1937)

IP.com Disclosure Number: IPCOM000004242D
Original Publication Date: 1996-May-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 7 page(s) / 17K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

Y. Rekhter & D. Kandlur: AUTHOR

Abstract

The IP architecture assumes that each Data Link subnetwork is labeled with a single IP subnet number. A pair of hosts with the same subnet number communicate directly (with no routers); a pair of hosts with different subnet numbers always communicate through one or more routers. As indicated in RFC1620, these assumptions may be too restrictive for large data networks, and specifically for networks based on switched virtual circuit (SVC) based technologies (e.g. ATM, Frame Relay, X.25), as these assumptions impose constraints on communication among hosts and routers through a network. The restrictions may preclude full utilization of the capabilities provided by the underlying SVC-based Data Link subnetwork. This document describes extensions to the IP architecture that relaxes these constraints, thus enabling the full utilization of the services provided by SVC-based Data Link subnetworks.

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

Network Working Group Y. Rekhter

Request for Comments: 1937 Cisco Systems

Category: Informational D. Kandlur

T.J. Watson Research Center, IBM Corp.

May 1996

"Local/Remote" Forwarding Decision in Switched Data Link Subnetworks

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

The IP architecture assumes that each Data Link subnetwork is labeled

with a single IP subnet number. A pair of hosts with the same subnet

number communicate directly (with no routers); a pair of hosts with

different subnet numbers always communicate through one or more

routers. As indicated in RFC1620, these assumptions may be too

restrictive for large data networks, and specifically for networks

based on switched virtual circuit (SVC) based technologies (e.g. ATM,

Frame Relay, X.25), as these assumptions impose constraints on

communication among hosts and routers through a network. The

restrictions may preclude full utilization of the capabilities

provided by the underlying SVC-based Data Link subnetwork. This

document describes extensions to the IP architecture that relaxes

these constraints, thus enabling the full utilization of the services

provided by SVC-based Data Link subnetworks.

1. Background

The following briefly recaptures the concept of the IP Subnet. The

topology is assumed to be composed of hosts and routers

interconnected via links (Data Link subnetworks). An IP address of a

host with an interface attached to a particular link is a tuple

, where host number is

unique within the subnet address prefix. When a host needs to send

an IP packet to a destination, the host needs to determine whether

the destination address identifies an interface that is connected to

one of the links the host is attached to, or not. This referred to

as the "local/remote" decision. The outcome of the "local/remote"

decision is based on (a) the destination address, and (b) the address

and the prefix length associated with the the local interfaces. If

the outcome is "local", then the host resolves the IP address to a

Link Layer address (e.g. by using ARP), and then sends the packet

directly to that destination (using the Link layer services). If the

outcome is "remote", then the host uses one of its first-hop routers

(thus relying on the services provided by IP routing).

To summarize, two of the important attributes of the IP subnet model

are:

hosts with a common subnet address prefix are assumed to be

attached to a common link (subnetwork), and thus communicate with

each other directly, without any routers - "l...