rfc1005.txt
来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,813 行 · 第 1/5 页
TXT
1,813 行
When used in type 0 messages, bits 65-72 are also known as the Link Field, and should contain values specified inKhanna & Malis [Page 26] RFC 1005 May 1987 Assigned Numbers [3] appropriate for the host-to-host protocol being used. Bits 77-80: Sub-type: This field is used as a modifier by message types 0, 2, 4, and 8. Bits 81-96: Unused5.2 PSN-to-Host AHIP-E Leader Format 1 4 5 8 12 16 17 20 21 22 24 25 32+--------+--------+-+-+-+--------+--------+-+------+----------------+| | FORMAT |D|T|R| | |T|LEADER| || UNUSED | FLAG |E|H|E| UNUSED | UNUSED |R|FLAGS | MESSAGE TYPE || | (15) |L|R|L| | |C| | |+--------+--------+-+-+-+--------+--------+-+------+----------------+ 33 40 41 64+----------------------+----------------------------------------------+| | || HANDLING TYPE | SOURCE HOST || | |+----------------------+----------------------------------------------+ 65 76 77 80 81 96+-------------------------+--------+----------------------------------+| | | || MESSAGE ID |SUB-TYPE| MESSAGE LENGTH || | | |+-------------------------+--------+----------------------------------+ PSN-to-Host AHIP-E Leader Format Figure 5.3Bits 1-4: Unused and set to zero.Bits 5-8: Format Flag This field is set to decimal 15 (1111 in binary).Bits 9-11: Type-of-Service Specified by the source host (see section 5.1).Bits 12-20: Unused, must be set to zero.Bit 21: Trace Bit:Khanna & Malis [Page 27] RFC 1005 May 1987 If equal to one, the source host has designated this message for tracing as it proceeds through the network. See 1822(5.5).Bits 22-24: Leader Flags: Bit 22: Available as a destination host flag. Bits 23-24: Reserved for future use, set to zero.Bits 25-32: Message Type: Type 0: Regular Message - All host-to-host communication occurs via regular messages, which have several sub- types. The sub-type field (bits 77-80) is the same as that sent in the host-to-PSN leader (see section 5.1). Type 1: Error in Leader - See 1822(3.4). Type 2: PSN Going Down - See 1822(3.4). Type 3: NDM Reply - This is a reply to the NDM host-to-PSN | message (see section 5.1). It has the same number of | entries as the NDM message to which it replies, and | each listed name is accompanied by a zero or a one | (see figure 5.2). A zero signifies that the name is | not effective, and a one means that the name is now | effective. | Type 4: NOP - The host should discard this message. It is used during initialization of the PSN/host communication. The Destination Host field will contain the physical address of the host port over which the NOP is being sent. All other fields are unused. Type 5: Ready for Next Message (RFNM) - See 1822(3.4). Type 6: Dead Host Status - See 1822(3.4). Type 7: Destination Host or PSN Dead (or unknown) - See 1822(3.4). Type 8: Error in Data - See 1822(3.4). Type 9: Incomplete Transmission - See 1822(3.4). In addition to its already defined sub-types, this message has two new sub-types: 6: Logically Addressed Host Went Down - A logically |Khanna & Malis [Page 28] RFC 1005 May 1987 addressed message was lost in the network because | the destination host to which it was being | delivered went down. The message should be | resubmitted by the source host, since there may | be another effective host port to which the | message could be delivered (see section 2.2.3). | 7: Network Not Accepting Messages at this Precedence | Level - bits 33 and 34 encode the minimum | precedence level currently being accepted by the | network. See section 4.3. Type 10: Interface Reset - See 1822(3.4). Type 11: Name Server Reply - This reply to the Name Server | Request host-to-PSN message contains, following the | leader and any leader padding, a word with the | selection policy and the number of physical addresses | to which the destination name maps, followed by five | octets per physical address: the first three octets | contain an AHIP-E address, and the last two contain a | bit signifying whether or not that particular | translation is effective and the routing distance | (expected network transmission delay, in 6.4 ms units) | to the address's PSN for the type-of-service specified | in the Name Server Request being replied to. This | type-of-service will be included in the Name Server | Reply leader. In figure 5.4, which includes the | leader without any leader padding and has type-of | -service set to 000, EFF is 1 for effective and 0 | for non-effective, the destination name is in the format | of figure 3.3, and POL is a two-bit number indicating | the selection policy for the name (see section 3.2.2): | 0: First reachable. 1: Closest physical address. | 2: Load leveling. | 3: Unused.Khanna & Malis [Page 29] RFC 1005 May 1987 1 16 17 32 33 40 +----------------+----------------+--------+ | | | | | 0F00 | 000B | 00 | | | | | +----------------+----------------+--------+ 41 64 65 80 +------------------------+-----------------+ | | | | Destination name | 0000 | | | | +------------------------+-----------------+ 81 96 97 112 +----------------+-+--------------+ | |P| | | 0000 |O| # of addrs | | |L| | +----------------+-+--------------+ 113 136 137 152 +--------------------------+-+-------------+ | |E| | | AHIP-E addr #1 |F| routing dist| | |F| | +--------------------------+-+-------------+ 153 176 177 192 +--------------------------+-+-------------+ | |E| | | AHIP-E addr #2 |F| routing dist| etc. | |F| | +--------------------------+-+-------------+ Name Server Reply Format Figure 5.4 Type 12: Port List Reply - This is the reply to the Port | List Request host-to-PSN message. It contains the | number of names that map to this physical host port, | followed by two words per name: the first word | contains a logical name that maps to this port, and | the second contains either a zero or a one, | signifying whether or not that particular translation | is effective. The format is identical to the type 3 | NDM Reply message(see figure 5.2). | Type 13: STOP -- Stop Sending on this Connection. See |Khanna & Malis [Page 30] RFC 1005 May 1987 section 4.2. | Type 14: SLOW -- maintain window size of 1 on this | connection. See section 4.2. | Type 15: Name or Address Error - This message is sent in | response to a type 0 message from a host that | contained an erroneous Destination Host field. Its | sub-types are: | 2: The Destination Host name is not authorized. | 3: The physical host to which this singly-homed | Destination Host name translated is authorized | and up, but not effective. If the host was | actually down, a type 7 message would be | returned, not a type 15. | 5: The multi-homed Destination Host name is | authorized but has no available effective | translations. | 6: A logically-addressed uncontrolled packet was sent | to a dead or non-effective host port. However, | if it is resubmitted, there may be another | effective host port to which the PSN may be able | to attempt to send the packet. | 7: Logical addressing is not in use. | The PSN has no table of mappings from logical | addresses to physical host ports. | 0, 1, 4, 8-15: Unassigned | Type 16: GO -- maintain window size of 8 on this | connection. See section 4.2. | Type 17: Network Precedence Level Cutoff Change -- bits 33 | and 34 encode the minimum precedence level currently | being accepted by the network. See section 4.3. Types 18-255: Unassigned.Bits 33-40: Handling Type: This has the value assigned by the source host (see 1822(3.1)). This field is only used in message types 0, 5- 9, and 13-16.Bits 41-64: Source Host: See 1882(3.4). For type 0 messages this contains the physical address of the source host, in the format detailed in figure 3.2. For type 4 messages, this contains the physical address of the local host. For messages of type 5-9, 11 and 13-16 which are responses to messages from theKhanna & Malis [Page 31] RFC 1005 May 1987 local host, this contains the destination name as specified in the message from the local host.Bits 65-76: Message ID: For message types 0, 5, 7-9, and 15, this is the value assigned by the source host to identify the message (see section 5.1). This field is also used by message types 2 and 6.Bits 77-80: Sub-type: This field is used as a modifier by message types 0-2, 5-7, 9, and 15.Bits 81-96: Message Length: This field is contained in type 0 messages only, and is the actual length in bits of the message (exclusive of leader, leader padding, and hardware padding) as computed by the PSN.Khanna & Malis [Page 32] RFC 1005 May 19876 AHIP-E VERSIONSThis specification provides three versions of AHIP-E and allows a hostto specify its version in bits 13-16 of the leader of the NOP. The PSNwill set the version of a host based on the value contained in the mostrecent NOP that it has received from the host. Thus, a host can changethe PSN's idea of its version by issuing a NOP containing a differentversion value. Note that the version field in all other host-to-PSNmessages will be ignored by the PSN.Version 0:A host that doesn't change its current AHIP implementation willpresumably have the version bits in the AHIP leader set to zero.Version⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?