rfc1561.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,403 行 · 第 1/4 页

Network Working Group                                      D. Piscitello
Request for Comments: 1561                               Core Competence
Category: Experimental                                     December 1993


                  Use of ISO CLNP in TUBA Environments

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   This memo specifies a profile of the ISO/IEC 8473 Connectionless-mode
   Network Layer Protocol (CLNP, [1]) for use in conjunction with RFC
   1347, TCP/UDP over Bigger Addresses (TUBA, [2]).  It describes the
   use of CLNP to provide the lower-level service expected by
   Transmission Control Protocol (TCP, [3]) and User Datagram Protocol
   (UDP, [4]).  CLNP provides essentially the same datagram service as
   Internet Protocol (IP, [5]), but offers a means of conveying bigger
   network addresses (with additional structure, to aid routing).

   While the protocols offer nearly the same services, IP and CLNP are
   not identical. This document describes a means of preserving the
   semantics of IP information that is absent from CLNP while preserving
   consistency between the use of CLNP in Internet and OSI environments.
   This maximizes the use of already-deployed CLNP implementations.

Acknowledgments

   Many thanks to Ross Callon (Wellfleet Communications), John Curran
   (BBN), Cyndi Jung (3Com), Paul Brooks (UNSW), Brian Carpenter (CERN),
   Keith Sklower (Cal Berkeley), Dino Farinacci and Dave Katz (Cisco
   Systems), Rich Colella (NIST/CSL) and David Oran (DEC) for their
   assistance in composing this text.













Piscitello                                                      [Page 1]

RFC 1561               CLNP in TUBA Environments           December 1993


Conventions

   The following language conventions are used in the items of
   specification in this document:

         * MUST, SHALL, or MANDATORY -- the item is an absolute
           requirement of the specification.

         * SHOULD or RECOMMENDED -- the item should generally be
           followed for all but exceptional circumstances.

         * MAY or OPTIONAL -- the item is truly optional and may be
           followed or ignored according to the needs of the
           implementor.

1.  Terminology

   To the extent possible, this document is written in the language of
   the Internet. For example, packet is used rather than "protocol data
   unit", and "fragment" is used rather than "segment".  There are some
   terms that carry over from OSI; these are, for the most part, used so
   that cross-reference between this document and RFC 994 [6] or ISO/IEC
   8473 is not entirely painful.  OSI acronyms are for the most part
   avoided.

2.  Introduction

   The goal of this specification is to allow compatible and
   interoperable implementations to encapsulate TCP and UDP packets in
   CLNP data units. In a sense, it is more of a "hosts requirements"
   document for the network layer of TUBA implementations than a
   protocol specification. It is assumed that readers are familiar with
   STD 5, RFC 791, STD 5, RFC 792 [7], STD 3, RFC 1122 [8], and, to a
   lesser extent, RFC 994 and ISO/IEC 8473.  This document is compatible
   with (although more restrictive than) ISO/IEC 8473; specifically, the
   order, semantics, and processing of CLNP header fields is consistent
   between this and ISO/IEC 8473.

   [Note: RFC 994 contains the Draft International Standard version of
   ISO CLNP, in ASCII text. This is not the final version of the ISO/IEC
   protocol specification; however, it should provide sufficient
   background for the purpose of understanding the relationship of CLNP
   to IP, and the means whereby IP information is to be encoded in CLNP
   header fields. Postscript versions of ISO CLNP and associated routing
   protocols are available via anonymous FTP from merit.edu, and may be
   found in the directory /pub/ISO/IEC.





Piscitello                                                      [Page 2]

RFC 1561               CLNP in TUBA Environments           December 1993


3.  Overview of CLNP

   ISO CLNP is a datagram network protocol. It provides fundamentally
   the same underlying service to a transport layer as IP. CLNP provides
   essentially the same maximum datagram size, and for those
   circumstances where datagrams may need to traverse a network whose
   maximum packet size is smaller than the size of the datagram, CLNP
   provides mechanisms for fragmentation (data unit identification,
   fragment/total length and offset). Like IP, a checksum computed on
   the CLNP header provides a verification that the information used in
   processing the CLNP datagram has been transmitted correctly, and a
   lifetime control mechanism ("Time to Live") imposes a limit on the
   amount of time a datagram is allowed to remain in the internet
   system. As is the case in IP, a set of options provides control
   functions needed or useful in some situations but unnecessary for the
   most common communications.

   Note that the encoding of options differs between the two protocols,
   as do the means of higher level protocol identification. Note also
   that CLNP and IP differ in the way header and fragment lengths are
   represented, and that the granularity of lifetime control (time-to-
   live) is finer in CLNP.

   Some of these differences are not considered "issues", as CLNP
   provides flexibility in the way that certain options may be specified
   and encoded (this will facilitate the use and encoding of certain IP
   options without change in syntax); others, e.g., higher level
   protocol identification and timestamp, must be accommodated in a
   transparent manner in this profile for correct operation of TCP and
   UDP, and continued interoperability with OSI implementations. Section
   4 describes how header fields of CLNP must be populated to satisfy
   the needs of TCP and UDP.

   Errors detected during the processing of a CLNP datagram MAY be
   reported using CLNP Error Reports. Implementations of CLNP for TUBA
   environments MUST be capable of processing Error Reports (this is
   consistent with the 1992 edition (2)  of the ISO/IEC 8473 standard).
   Control messages (e.g., echo request/reply and redirect) are
   similarly handled in CLNP, i.e., identified as separate network layer
   packet types.  The relationship between CLNP Error and Control
   messages and Internet Control Message Protocol (ICMP, [7]), and
   issues relating to the handling of these messages is described in
   Section 5.








Piscitello                                                      [Page 3]

RFC 1561               CLNP in TUBA Environments           December 1993


   Table 1 provides a high-level comparison of CLNP to IP:

 Function              | ISO CLNP               | DOD IP
 ----------------------|------------------------|-----------------------
 Header Length         | indicated in octets    | in 32-bit words
 Version Identifier    | 1 octet                | 4 bits
 Lifetime (TTL)        | 500 msec units         | 1 sec units
 Flags                 | Fragmentation allowed, | Don't Fragment,
                       | More Fragments         | More Fragments,
                       | Suppress Error Reports | <not defined>
 Packet Type           | 5 bits                 | <not defined>
 Fragment Length       | 16 bits, in octets     | 16 bits, in octets
 Header Checksum       | 16-bit (Fletcher)      | 16-bit
 Total Length          | 16 bits, in octets     | <not defined>
 Addressing            | Variable length        | 32-bit fixed
 Data Unit Identifier  | 16 bits                | 16 bits
 Fragment offset       | 16 bits, in octets     | 13 bits, 8-octet units
 Higher Layer Protocol | Selector in address    | Protocol
 Options               | Security               | Security
                       | Priority               | TOS Precedence bits
                       | Complete Source Route  | Strict Source Route
                       | Quality of Service     | Type of Service
                       | Partial Source Route   | Loose Source Route
                       | Record Route           | Record Route
                       | Padding                | Padding
                       | <defined herein>       | Timestamp

                 Table 1. Comparison of IP to CLNP

   The composition and processing of a TCP pseudo-header when CLNP is
   used to provide the lower-level service expected by TCP and UDP is
   described in Section 6.

   [Note: This experimental RFC does not discuss multicasting.
   Presently, there are proposals for multicast extensions for CLNP in
   ISO/IEC/JTC1/SC6, and a parallel effort within TUBA. A future
   revision to this RFC will incorporate any extensions to CLNP that may
   be introduced as a result of the adoption of one of these
   alternatives.]












Piscitello                                                      [Page 4]

RFC 1561               CLNP in TUBA Environments           December 1993


4.  Proposed Internet Header using CLNP

   A summary of the contents of the CLNP header, as it is proposed for
   use in TUBA environments, is illustrated in Figure 4-1:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        ........Data Link Header........       | NLP ID        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Header Length  |     Version   | Lifetime (TTL)|Flags|  Type   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Fragment Length        |           Checksum            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Dest Addr Len |               Destination Address...          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               ... Destination Address...                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               ... Destination Address...                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               ... Destination Address...                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               ... Destination Address...                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | PROTO field   | Src  Addr Len |  Source  Address...           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               ... Source Address...                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               ... Source Address...                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               ... Source Address...                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               ... Source Address...                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Source Address |   Reserved    |       Data Unit Identifier    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Fragment Offset       |   Total Length of packet      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   Options  (see Table 1)                      |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               Data                            |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Note that each tick mark represents one bit position.

                     Figure 4-1. CLNP for TUBA



Piscitello                                                      [Page 5]

RFC 1561               CLNP in TUBA Environments           December 1993


  Note 1: For illustrative purposes, Figure 4-1 shows Destination
          and Source Addresses having a length of 19 octets,
          including the PROTO/reserved field. In general, addresses
          can be variable length, up to a maximum of 20 octets,
          including the PROTO/reserved field.

  Note 2: Due to differences in link layer protocols, it is not
          possible to ensure that the packet starts on an even
          alignment. Note, however, that many link level protocols
          over which CLNP is operated use a odd length link
          (e.g., IEEE 802.2). (In Figure 4-1, the rest of the CLNP
          packet is even-aligned.)

   The encoding of CLNP fields for use in TUBA environments is as
   follows.

4.1  Network Layer Protocol Identification (NLP ID)

   This one-octet field identifies this as the ISO/IEC 8473 protocol; it
   MUST set to binary 1000 0001.

4.2  Header Length Indication (Header Length)

   Header Length is the length of the CLNP header in octets, and thus
   points to the beginning of the data. The value 255 is reserved. The
   header length is the same for all fragments of the same (original)
   CLNP packet.

4.3  Version

   This one-octet field identifies the version of the protocol; it MUST
   be set to a binary value 0000 0001.

4.4  Lifetime (TTL)

   Like the TTL field of IP, this field indicates the maximum time the
   datagram is allowed to remain in the internet system.  If this field
   contains the value zero, then the datagram MUST be destroyed; a host,
   however, MUST NOT send a datagram with a lifetime value of zero.
   This field is modified in internet header processing.  The time is
   measured in units of 500 milliseconds, but since every module that
   processes a datagram MUST decrease the TTL by at least one even if it
   process the datagram in less than 500 millisecond, the TTL must be
   thought of only as an upper bound on the time a datagram may exist.
   The intention is to cause undeliverable datagrams to be discarded,
   and to bound the maximum CLNP datagram lifetime. [Like IP, the
   colloquial usage of TTL in CLNP is as a coarse hop-count.]




Piscitello                                                      [Page 6]

RFC 1561               CLNP in TUBA Environments           December 1993


   Unless otherwise directed, a host SHOULD use a value of 255 as the
   initial lifetime value.

4.5  Flags

   Three flags are defined. These occupy bits 0, 1, and 2 of the
   Flags/Type octet:

                          0   1   2