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

TCP Processing of the IPv4 Precedence Field (RFC2873)

IP.com Disclosure Number: IPCOM000003474D
Original Publication Date: 2000-Jun-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 6 page(s) / 14K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

X. Xiao: AUTHOR [+4]

Abstract

This memo describes a conflict between TCP [RFC793] and DiffServ [RFC2475] on the use of the three leftmost bits in the TOS octet of an IPv4 header [RFC791]. In a network that contains DiffServ-capable nodes, such a conflict can cause failures in establishing TCP connections or can cause some established TCP connections to be reset undesirably. This memo proposes a modification to TCP for resolving the conflict.

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

Network Working Group X. Xiao

Request for Comments: 2873 Global Crossing

Category: Standards Track A. Hannan

iVMG

V. Paxson

ACIRI/ICSI

E. Crabbe

Exodus Communications

June 2000

TCP Processing of the IPv4 Precedence Field

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.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

This memo describes a conflict between TCP [RFC793] and DiffServ

[RFC2475] on the use of the three leftmost bits in the TOS octet of

an IPv4 header [RFC791]. In a network that contains DiffServ-capable

nodes, such a conflict can cause failures in establishing TCP

connections or can cause some established TCP connections to be reset

undesirably. This memo proposes a modification to TCP for resolving

the conflict.

Because the IPv6 [RFC2460] traffic class octet does not have any

defined meaning except what is defined in RFC 2474, and in particular

does not define precedence or security parameter bits, there is no

conflict between TCP and DiffServ on the use of any bits in the IPv6

traffic class octet.

1. Introduction

In TCP, each connection has a set of states associated with it. Such

states are reflected by a set of variables stored in the TCP Control

Block (TCB) of both ends. Such variables may include the local and

remote socket number, precedence of the connection, security level

and compartment, etc. Both ends must agree on the setting of the

precedence and security parameters in order to establish a connection

and keep it open.

There is no field in the TCP header that indicates the precedence of

a segment. Instead, the precedence field in the header of the IP

packet is used as the indication. The security level and compartment

are likewise carried in the IP header, but as IP options rather than

a fixed header field. Because of this difference, the problem with

precedence discussed in this memo does not apply to them.

TCP requires that the precedence (and security parameters) of a

connection must remain unchanged during the lifetime of the

connection. Therefore, for an established TCP connection with

precedence, the receipt of a segment with di...