rfc1005.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,813 行 · 第 1/5 页

Bit 10:   throughput bit

            0 -- normal throughput
            1 -- high throughput

Bit 11:   reliability bit

            0 -- normal reliability
            1 -- high reliability


The values of these bits are consistent with those of IP, and bits 11,
12 and 13 of the IP header can be copied directly into bits 9, 10 and 11
of the AHIP leader.

The type-of-service bits should be considered as extensions of the
"Handling Type" field (bits 33-40 of the AHIP leader -- see 1822 (3.3)).
Messages from host A to host B using the same destination name and of
the same handling type and type-of- service will use the same
connection, while those that differ in either type-of-service,
destination name or handling type will use separate connections.  In
other words, for a given source host and destination name pair, a new
connection will be established whenever a message with a new handling-
type/type-of- service combination is received.








Khanna & Malis                                                 [Page 20]

RFC 1005                                                        May 1987


4.2  Subnet Congestion Feedback

This section describes the new messages that are part of the mechanism
used by the PSN to communicate subnetwork congestion information to the
host. Note that a host will be blocked by the PSN when its share of
buffers in the PSN is used up.  Thus, this information, which is
communicated on a connection basis, will give the host an opportunity to
selectively reduce its congesting flows, thus preventing all of its
flows from getting blocked. Currently, a host has no way of knowing
which of its flows is experiencing congestion; consequently, it is
possible that one congesting flow can result in the blocking of all the
host's flows.

Three new PSN-to-host messages have been created. These messages are:

      1.  STOP: Blocking Imminent -- Stop Sending on this
          Connection (Message type 13)

      2.  SLOW: Subnet Congestion -- Send at Slow Rate on this
          Connection (Message type 14) -- Maintain Window Size of
          1, i.e., do not send a new message to this destination
          host with this type-of-service and handling type until
          all previous messages have been acknowledged by RFNMs.

      3.  GO: Congestion Subsided -- Send at Regular Rate on this
          Connection (Message type 16) -- Maintain Window Size of
          8


These messages may be sent in any order and correspond to states, not
transitions.  A participating host should support three states with
effective windows of 8, 1 and 0.  The format of these messages can be
found in section 5.2.


4.3  Precedence Level Information

Two new messages have been created:

     1.  Network Not Accepting Messages at this Precedence Level
         (Message type 9, subtype 7).

     2.  Network Precedence Level Cutoff Change (Message type
         17).

The first message will be generated whenever the host attempts to send a
message at a precedence level lower than the cutoff.  The cutoff
represents a precedence level below which no traffic may be submitted



Khanna & Malis                                                 [Page 21]

RFC 1005                                                        May 1987


into the subnetwork; note that a cutoff set to the lowest possible
precedence level implies that no precedence restrictions are in effect.
If the host has chosen not to receive the new AHIP-E messages, then the
PSN will send a type 7, sub-type 3 message (communication with the
destination host is administratively prohibited) instead.  The second
message will be generated whenever the network precedence level cutoff
changes.  Both messages contain the network precedence cutoff value.
The format of these messages can be found in section 5.2.











































Khanna & Malis                                                 [Page 22]

RFC 1005                                                        May 1987


5  FORMATS FOR NEW AHIP-E MESSAGES

The following sections describe the formats of the leaders that precede
messages between an AHIP-E host and its PSN.  The formats are almost
identical to those of AHIP (see 1822(3.3) and 1822(3.4)). New message
types are marked by margin bars (as shown | here).

5.1  Host-to-PSN AHIP-E Leader Format

 1      4 5      8         13  16 17    20 21 22 24 25            32
+---------+--------+-+-+-+-+------+--------+-+------+----------------+
|         | FORMAT |D|T|R|U|      |        |T|LEADER|                |
| UNUSED  |  FLAG  |E|H|E|N| VERS | UNUSED |R|FLAGS |  MESSAGE TYPE  |
|         |  (15)  |L|R|L|U|      |        |C|      |                |
+---------+--------+-+-+-+-+------+--------+-+------+----------------+

 33                  40 41                                          64
+----------------------+----------------------------------------------+
|                      |                                              |
|    HANDLING TYPE     |                DESTINATION HOST              |
|                      |                                              |
+----------------------+----------------------------------------------+

 65                     76 77    80 81                              96
+-------------------------+--------+----------------------------------+
|                         |        |                                  |
|       MESSAGE ID        |SUB-TYPE|            UNUSED                |
|                         |        |                                  |
+-------------------------+--------+----------------------------------+

                    Host-to-PSN AHIP-E Leader Format
                               Figure 5.1


Bits 1-4: Unused, must be set to zero.

Bits 5-8: Format Flag
     This field is set to decimal 15 (1111 in binary).

Bits 9-11: Type-of-Service

     Bit 9: Delay Bit:
               0 -- normal delay
               1 -- low delay
     Bit 10: Throughput Bit:
               0 -- normal throughput
               1 -- high throughput
     Bit 11: Reliability Bit:



Khanna & Malis                                                 [Page 23]

RFC 1005                                                        May 1987


               0 -- normal reliability
               1 -- high reliability

Bit 12: Unused, must be set to zero.


Bits 13-16: AHIP-E Version number
     Ignored by the PSN except in the case of a NOP -- see
     chapter 6.

Bits 17-20: Unused, must be set to zero.

Bit 21: Trace Bit:
     If equal to one, this message is designated for tracing as
     it proceeds through the network.  See 1822(5.5).

Bits 22-24: Leader Flags:

     Bit 22: A flag available for use by the destination host.
          See AHIP(3.3) for a description of its use by the
          PSN's TTY Fake Host.
     Bits 23-24: Reserved for future use, must be zero.

Bits 25-32: Message Type:

     Type 0: Regular Message - All host-to-host communication
          occurs via regular messages, which have several sub-
          types, found in bits 77-80.  These sub-types are:
          0: Standard - The PSN uses its full message and error
             control facilities, and host blocking may occur.
          3: Uncontrolled Packet - The PSN will perform no
             message-control functions for this type of
             message, and network flow and congestion control
             may cause loss of the packet.  Also see
             1822(3.6). 1-2,4-15: Unassigned.

     Type 1: Error Without Message ID - See 1822(3.3).

     Type 2: Host Going Down - see 1822(3.3).

     Type 3: Name Declaration Message (NDM) - This message is         |
             used by the host to declare which of its logical names   |
             is or is not effective (see section 3.2.1), or to make   |
             all of its names non-effective.  The first 16 bits of    |
             the data portion of the NDM message, following the       |
             leader and any leader padding, contains the number of    |
             logical names contained in the message.  This is         |
             followed by the logical name entries, each 32 bits       |



Khanna & Malis                                                 [Page 24]

RFC 1005                                                        May 1987


             long, of which the first 16 bits is a logical name and   |
             the second 16 bits contains either of the integers       |
             zero or one.  Zero indicates that the name should not    |
             be effective, and one indicates that the name should be  |
             effective.  Note that only the names explicitly in the   |
             NDM will remain enabled after the NDM is processed       |
             (assuming that they are authorized).  The PSN will       |
             reply with a NDM Reply message (see section 5.2)         |
             indicating which of the names are now effective and      |
             which are not.  Pictorially, a NDM message has the       |
             following format including the leader, which is printed  |
             in hexadecimal, and without any leader padding):         |


                 1             16 17            32 33            48
                +----------------+----------------+----------------+
                |                |                |                |
                |      0F00      |      0003      |      0000      |
                |                |                |                |
                +----------------+----------------+----------------+
                 49            64 65            80 81            96
                +----------------+----------------+----------------+
                |                |                |                |
                |      0000      |      0000      |      0000      |
                |                |                |                |
                +----------------+----------------+----------------+
                 97           112 113          128 129          144
                +----------------+----------------+----------------+
                |                |                |                |
                |  # of entries  |     name #1    |     0 or 1     |
                |                |                |                |
                +----------------+----------------+----------------+
                145           160 161          176
                +----------------+----------------+
                |                |                |
                |   name #2      |     0 or 1     |       etc.
                |                |                |
                +----------------+----------------+


                           NDM Message Format
                               Figure 5.2









Khanna & Malis                                                 [Page 25]

RFC 1005                                                        May 1987


               An NDM with zero entries will cause all current
               effective names for the host to become non-effective.

          Type 4: NOP -- see 1822(3.3).  Bits 13-16 of the NOP leader   |
               are used to determine the host's AHIP-E version -- see   |
               chapter 6.                                               |

          Type 8: Error with Message ID - see 1822(3.3).

          Type 11: Name Server Request - This allows the host to use    |
               the PSN's logical addressing tables as a name server.    |
               The destination name in the AHIP-E leader is             |
               translated, and the PSN replies with a Name Server       |
               Reply message, which lists the physical host addresses   |
               to which the destination name maps.  The type-of-        |
               service bits (bits 9-11) should be set correctly by      |
               the host, as the Name Server Reply message contains      |
               information about characteristics of the subnetwork      |
               route(s) to that destination, which will depend on the   |
               type-of-service.                                         |

          Type 12: Port List Request - This allows the physical host    |
               to request the list of names that map to the host port   |
               over which this request was received by the PSN.  The    |
               PSN replies with a Port List Reply message, which        |
               lists the names that map to the port.                    |

          Types 5-7,9-10,13-255: Unassigned.

     Bits 33-40: Handling Type:
          The top two bits (33 and 34) specify the precedence of the
          connection.  There are 4 precedence levels, level 3 being
          the highest and level 0 the lowest.  Bits 35-40 are used to
          specify up to 64 separate connections at a particular
          precedence level and type-of-service.

     Bits 41-64: Destination Host:
          This field contains the name or address of the destination
          host, as described in figures 3.3 and 3.2 respectively.  If
          it contains a name, the name will be checked for
          effectiveness, with an error message returned to the source
          host if the name is not effective.

     Bits 65-76: Message ID:
          This is a host-specified identification used in all type 0
          and type 8 messages, and is also used in type 2 messages.