• Aucun résultat trouvé

1. INTRODUCTION

1.1 Reading this Document

1.1.1 Organization

This memo emulates the layered organization used by [INTRO:2] and [INTRO:3]. Thus, Chapter 2 describes the layers found in the Internet architecture. Chapter 3 covers the Link Layer. Chapters 4 and 5 are concerned with the Internet Layer protocols and

forwarding algorithms. Chapter 6 covers the Transport Layer.

Upper layer protocols are divided between Chapter 7, which discusses the protocols which routers use to exchange routing information with each other, Chapter 8, which discusses network management, and Chapter 9, which discusses other upper layer protocols. The final chapter covers operations and maintenance features. This organization was chosen for simplicity, clarity, and consistency with the Host Requirements RFCs. Appendices to this memo include a bibliography, a glossary, and some conjectures about future directions of router standards.

In describing the requirements, we assume that an implementation strictly mirrors the layering of the protocols. However, strict layering is an imperfect model, both for the protocol suite and for recommended implementation approaches. Protocols in different layers interact in complex and sometimes subtle ways, and

particular functions often involve multiple layers. There are many design choices in an implementation, many of which involve creative breaking of strict layering. Every implementor is urged to read [INTRO:4] and [INTRO:5].

In general, each major section of this memo 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 through.

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

parenthetical material labeled DISCUSSION or IMPLEMENTATION. This material is intended to give a justification, clarification or

explanation to the preceding requirements text. The

implementation material contains suggested approaches that an implementor may want to consider. The DISCUSSION and

IMPLEMENTATION sections are not part of the standard.

1.1.2 Requirements

In this memo, the words that are used to define the significance of each particular requirement are capitalized. These words are:

o MUST

This word means that the item is an absolute requirement of the specification.

o MUST IMPLEMENT

This phrase means that this specification requires that the item be implemented, but does not require that it be enabled by default.

o MUST NOT

This phrase means that the item is an absolute prohibition of the specification.

o SHOULD

This word 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.

o SHOULD IMPLEMENT

This phrase is similar in meaning to SHOULD, but is used when we recommend that a particular feature be provided but does not necessarily recommend that it be enabled by default.

o SHOULD NOT

This phrase means that there may exist valid reasons in particular circumstances when the described behavior is

acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

o MAY

This word 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.

1.1.3 Compliance

Some requirements are applicable to all routers. Other requirements are applicable only to those which implement

particular features or protocols. In the following paragraphs, Relevant refers to the union of the requirements applicable to all routers and the set of requirements applicable to a particular router because of the set of features and protocols it has implemented.

Note that not all Relevant requirements are stated directly in this memo. Various parts of this memo incorporate by reference sections of the Host Requirements specification, [INTRO:2] and [INTRO:3]. For purposes of determining compliance with this memo, it does not matter whether a Relevant requirement is stated

directly in this memo or merely incorporated by reference from one of those documents.

An implementation is said to be conditionally compliant if it satisfies all of the Relevant MUST, MUST IMPLEMENT, and MUST NOT requirements. An implementation is said to be unconditionally compliant if it is conditionally compliant and also satisfies all of the Relevant SHOULD, SHOULD IMPLEMENT, and SHOULD NOT

requirements. An implementation is not compliant if it is not conditionally compliant (i.e., it fails to satisfy one or more of the Relevant MUST, MUST IMPLEMENT, or MUST NOT requirements).

For any of the SHOULD and SHOULD NOT requirements, a router may provide a configuration option that will cause the router to act other than as specified by the requirement. Having such a

configuration option does not void a router’s claim to

unconditional compliance as long as the option has a default

setting, and that leaving the option at its default setting causes the router to operate in a manner which conforms to the

requirement.

Likewise, routers may provide, except where explicitly prohibited by this memo, options which cause them to violate MUST or MUST NOT requirements. A router which provides such options is compliant (either fully or conditionally) if and only if each such option has a default setting which causes the router to conform to the requirements of this memo. Please note that the authors of this memo, although aware of market realities, strongly recommend against provision of such options. Requirements are labeled MUST or MUST NOT because experts in the field have judged them to be particularly important to interoperability or proper functioning in the Internet. Vendors should weigh carefully the customer

support costs of providing options which violate those rules.

Of course, this memo is not a complete specification of an IP router, but rather is closer to what in the OSI world is called a profile. For example, this memo requires that a number of

protocols be implemented. Although most of the contents of their protocol specifications are not repeated in this memo,

implementors are nonetheless required to implement the protocols according to those specifications.