互联网主机通信层要求：RFC1122规范解读

RFC793

需积分: 10 63 浏览量更新于2024-07-18 收藏 157KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"Network Working Group 发布的 RFC1122 是互联网社区的官方规范，它涉及了互联网主机通信层协议的要求。这份文档是对 RFC793 的补充和修正，涵盖了链路层、网络层和传输层的标准。此外，RFC1123 负责讨论应用和支持协议的要求。" 在互联网工程任务组 (Internet Engineering Task Force, IETF) 的“请求评论”(Request for Comments, RFC) 文档系列中，RFC1122 是一份关键的规范，由 R.Braden 编辑，发布于1989年10月。这份文档的核心目的是定义并讨论互联网主机软件在通信层面上的需求。 1. **互联网架构**：文档首先介绍了互联网的基本结构，包括互联网主机的角色，它们是互联网服务的提供者和使用者。接着，文档概述了架构的基本假设，如分层设计和协议的独立性。互联网协议套件，即TCP/IP协议栈，由链路层、网络层（IPlayer，这里可能是笔误，应为Internet Layer，即网络层，如IP协议）、传输层（如TCP和UDP）等组成。 2. **嵌入式网关代码**：文档还涉及了在网络边缘设备（如路由器）中嵌入的网关代码，这些代码处理不同网络间的通信，确保数据包正确路由。 3. **一般考虑**：这部分探讨了互联网持续演进的重要性，强调了设计的健壮性原则，即“应尽可能容忍错误”。此外，文档提到了错误日志记录，以便于故障排查，以及配置管理，确保主机能适应不同的网络环境。 4. **阅读指南**：文档组织有序，包含需求部分，用于明确必须遵循的规范；术语定义，帮助读者理解专业词汇；以及如何解读文档的指导。 5. **协议层要求**：RFC1122专注于通信协议层，具体包括链路层（如以太网、PPP等）、网络层（IP协议，处理数据包路由）和传输层（TCP和UDP，负责端到端的数据传输）。这些层次的设计和实现必须满足一定的功能性和性能要求，以确保网络的可靠性和效率。 6. **应用和支持协议**：虽然RFC1122不直接涵盖应用和支持协议，但其伴生的RFC1123则专门讨论了这些内容，如FTP、SMTP、DNS等，以及时间同步和其他支持服务。 RFC1122为互联网主机的底层通信提供了基础性的规范，确保了网络层协议的正确实施和互操作性，对构建和维护互联网基础设施至关重要。

资源详情

资源推荐

RFC1122 INTRODUCTION October 1989

implied by these calls, but need not literally implement the

calls themselves. For example, many implementations reflect

the coupling between the transport layer and the IP layer by

giving them shared access to common data structures. These

data structures, rather than explicit procedure calls, are then

the agency for passing much of the information that is

required.

In general, each major section of this document is organized

into the following subsections:

(1) Introduction

(2) Protocol Walk-Through -- considers the protocol

specification documents section-by-section, correcting

errors, stating requirements that may be ambiguous or

ill-defined, and providing further clarification or

explanation.

(3) Specific Issues -- discusses protocol design and

implementation issues that were not included in the walk-

through.

(4) Interfaces -- discusses the service interface to the next

higher layer.

(5) Summary -- contains a summary of the requirements of the

section.

Under many of the individual topics in this document, there is

parenthetical material labeled "DISCUSSION" or

"IMPLEMENTATION". This material is intended to give

clarification and explanation of the preceding requirements

text. It also includes some suggestions on possible future

directions or developments. The implementation material

contains suggested approaches that an implementor may want to

consider.

The summary sections are intended to be guides and indexes to

the text, but are necessarily cryptic and incomplete. The

summaries should never be used or referenced separately from

the complete RFC.

1.3.2 Requirements

In this document, the words that are used to define the

significance of each particular requirement are capitalized.

Internet Engineering Task Force [Page 16]

RFC1122 INTRODUCTION October 1989

These words are:

* "MUST"

This word or the adjective "REQUIRED" means that the item

is an absolute requirement of the specification.

* "SHOULD"

This word or the adjective "RECOMMENDED" means that there

may exist valid reasons in particular circumstances to

ignore this item, but the full implications should be

understood and the case carefully weighed before choosing

a different course.

* "MAY"

This word or the adjective "OPTIONAL" means that this item

is truly optional. One vendor may choose to include the

item because a particular marketplace requires it or

because it enhances the product, for example; another

vendor may omit the same item.

An implementation is not compliant if it fails to satisfy one

or more of the MUST requirements for the protocols it

implements. An implementation that satisfies all the MUST and

all the SHOULD requirements for its protocols is said to be

"unconditionally compliant"; one that satisfies all the MUST

requirements but not all the SHOULD requirements for its

protocols is said to be "conditionally compliant".

1.3.3 Terminology

This document uses the following technical terms:

Segment

A segment is the unit of end-to-end transmission in the

TCP protocol. A segment consists of a TCP header followed

by application data. A segment is transmitted by

encapsulation inside an IP datagram.

Message

In this description of the lower-layer protocols, a

message is the unit of transmission in a transport layer

protocol. In particular, a TCP segment is a message. A

message consists of a transport protocol header followed

by application protocol data. To be transmitted end-to-

Internet Engineering Task Force [Page 17]

RFC1122 INTRODUCTION October 1989

end through the Internet, a message must be encapsulated

inside a datagram.

IP Datagram

An IP datagram is the unit of end-to-end transmission in

the IP protocol. An IP datagram consists of an IP header

followed by transport layer data, i.e., of an IP header

followed by a message.

In the description of the internet layer (Section 3), the

unqualified term "datagram" should be understood to refer

to an IP datagram.

Packet

A packet is the unit of data passed across the interface

between the internet layer and the link layer. It

includes an IP header and data. A packet may be a

complete IP datagram or a fragment of an IP datagram.

Frame

A frame is the unit of transmission in a link layer

protocol, and consists of a link-layer header followed by

a packet.

Connected Network

A network to which a host is interfaced is often known as

the "local network" or the "subnetwork" relative to that

host. However, these terms can cause confusion, and

therefore we use the term "connected network" in this

document.

Multihomed

A host is said to be multihomed if it has multiple IP

addresses. For a discussion of multihoming, see Section

3.3.4 below.

Physical network interface

This is a physical interface to a connected network and

has a (possibly unique) link-layer address. Multiple

physical network interfaces on a single host may share the

same link-layer address, but the address must be unique

for different hosts on the same physical network.

Logical [network] interface

We define a logical [network] interface to be a logical

path, distinguished by a unique IP address, to a connected

network. See Section 3.3.4.

Internet Engineering Task Force [Page 18]

RFC1122 INTRODUCTION October 1989

Specific-destination address

This is the effective destination address of a datagram,

even if it is broadcast or multicast; see Section 3.2.1.3.

Path

At a given moment, all the IP datagrams from a particular

source host to a particular destination host will

typically traverse the same sequence of gateways. We use

the term "path" for this sequence. Note that a path is

uni-directional; it is not unusual to have different paths

in the two directions between a given host pair.

MTU

The maximum transmission unit, i.e., the size of the

largest packet that can be transmitted.

The terms frame, packet, datagram, message, and segment are

illustrated by the following schematic diagrams:

A. Transmission on connected network:

_______________________________________________

| LL hdr | IP hdr | (data) |

|________|________|_____________________________|

<---------- Frame ----------------------------->

<----------Packet -------------------->

B. Before IP fragmentation or after IP reassembly:

______________________________________

| IP hdr | transport| Application Data |

|________|____hdr___|__________________|

<-------- Datagram ------------------>

<-------- Message ----------->

or, for TCP:

______________________________________

| IP hdr | TCP hdr | Application Data |

|________|__________|__________________|

<-------- Datagram ------------------>

<-------- Segment ----------->

Internet Engineering Task Force [Page 19]

RFC1122 INTRODUCTION October 1989

1.4 Acknowledgments

This document incorporates contributions and comments from a large

group of Internet protocol experts, including representatives of

university and research labs, vendors, and government agencies.

It was assembled primarily by the Host Requirements Working Group

of the Internet Engineering Task Force (IETF).

The Editor would especially like to acknowledge the tireless

dedication of the following people, who attended many long

meetings and generated 3 million bytes of electronic mail over the

past 18 months in pursuit of this document: Philip Almquist, Dave

Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve

Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),

John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),

Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge

(BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).

In addition, the following people made major contributions to the

effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia

(BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),

Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),

John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill

Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul

(DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue

Technology), and Mike StJohns (DCA). The following also made

significant contributions to particular areas: Eric Allman

(Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic

(Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn

(IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann

(Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun

Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen

(Toronto).

We are grateful to all, including any contributors who may have

been inadvertently omitted from this list.

Internet Engineering Task Force [Page 20]

剩余115页未读，继续阅读

fxlyxxg

粉丝: 0
资源: 1

互联网主机通信层要求：RFC1122规范解读

RFC937_邮局协议( 版本 2).doc

rfc全部文档离线下载rfc1-rfc8505

射频放大器rfc电感怎么选

rfc 1035 规范

rfc文档1一3093

The valid characters are defined in RFC 7230 and RFC 3986什么意思

rfc viewer

计算机网络中RFC指的是什么

RFC3339Nano和RFC 3339日期以及UNIX时间戳区别

RFC MARA、MARC、QMAT、MARA类型

关于udp协议的rfc文档

rfc9000文档下载

有效字符在RFC 7230和RFC 3986中定义

The valid characters are defined in RFC 7230 and RFC 3986

rfc 文档大全 下载

rfc3261中文版 pdf 下载

confd rfc中文pdf

最新资源

rfc 文档大全下载