📄 rfc2835.txt
字号:
The HRAL MUST contain at least two HIPPI HW addresses identifying the
individual HARP service(s) that have authoritative responsibility for
resolving HARP requests of all IP members located within the LIS. By
default the first address MUST be the reserved address for broadcast,
i.e. FF:FF:FF:FF:FF:FF.
The second address MUST be the standard HW address for the HARP
server 00:10:3B:FF:FF:E0.
Therefore, the HRAL entries are sorted in the following order:
1st : broadcast address (FF:FF:FF:FF:FF:FF) REQUIRED
2nd : official HARP server address (00:10:3B:FF:FF:E0) REQUIRED
3rd & on: any additional HARP server addresses will be OPTIONAL
sorted in decreasing order.
Manual configuration of the addresses and address lists presented in
this section is implementation dependent and beyond the scope of this
memo. However, prior to use by any service or operation detailed in
this memo, clients MUST have HRAL address(es) configured as
appropriate for their LIS.
Pittet Standards Track [Page 6]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
4. Internet Protocol
4.1 Packet format
The HIPPI-6400 packet format for Internet datagrams [15] shall
conform to the HIPPI-6400-PH standard [1]. The length of a HIPPI-
6400-PH packet, including headers and trailing fill, shall be a
multiple of 32 bytes as required by HIPPI-6400-PH.
All IP Datagrams shall be carried on HIPPI-6400-PH Virtual Channel 1
(VC1). Since HIPPI-6400-PH has a 32-byte granularity, IP Datagrams
MUST be padded to a 32-byte granularity prior to sending. Added
padding is transparent to IP and is not reflected in the length field
of the IP header.
D_ULA Destination ULA SHALL be the ULA of the destination port.
S_ULA Source ULA SHALL be the ULA of the requesting port.
M_len Set to the IEEE 802 packet (e.g. IP or HARP message)
length + 8 Bytes to account for the LLC/SNAP header length.
The HIPPI-6400-PH [1] length parameter shall not include
the pad.
4.1.1 IEEE 802.2 LLC
The IEEE 802.2 LLC Header SHALL begin in the first byte after M_len.
The LLC values (in hexadecimal and decimal) SHALL be
SSAP 0xAA 170 (8 bits)
DSAP 0xAA 170 (8 bits)
CTL 0x03 3 (8 bits)
for a total length of 3 bytes. The 0x03 CTL value indicates the
presence of a SNAP header.
4.1.2 SNAP
The OUI value for Organization Code SHALL be 0x00-00-00 (3 bytes)
indicating that the following two-bytes is an Ethertype.
The Ethertype value SHALL be set as defined in Assigned Numbers [18]:
IP 0x0800 2048 (16 bits)
HARP = ARP = 0x0806 2054 (16 bits)
The total size of the LLC/SNAP header is fixed at 8 bytes.
Pittet Standards Track [Page 7]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
4.1.3 HIPPI-6400 802 Packet diagrams
The following diagram shows a HIPPI-6400 message carrying IEEE 802
data.
|31 |23 |15 |7 0|
+------------+------------+------------+------------+ -------------
0 | |
| D_ULA +-------------------------+ HIPPI-6400
1 | | |
+-------------------------+ S_ULA | MAC
2 | |
+---------------------------------------------------+ header
3 | M_len |
+------------+------------+------------+------------+ -------------
4 | DSAP | SSAP | Ctl | Org | IEEE 802
+------------+------------+------------+------------+ LLC/SNAP
5 | Org | Org | Ethertype | header
+============+============+============+============+ =============
6 | Msg byte 0 | Msg byte 1 | Msg byte 2 | . . . | IEEE 802
+---------------------------------------------------+ Data
Generic 802.1 data packet diagram
The following diagram shows an IP datagram of length n with the FILL
bytes ( value: 0x0 ). "<><>" indicates the micropacket separation. A
HIPPI-6400-PH [1] micropacket is 32 bytes long.
All IP (v4) [15] packets will always span two or more micropackets.
The first micropacket has a TYPE = header. The second and any further
micropackets have a TYPE = Data (see [1]).
Pittet Standards Track [Page 8]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
|31 |23 |15 |7 0|
+------------+------------+------------+------------+ -------------
0 | |
| D_ULA +-------------------------+ HIPPI-6400
1 | | |
+-------------------------+ S_ULA | MAC
2 | |
+---------------------------------------------------+ header
3 | M_len |
+------------+------------+------------+------------+ -------------
4 | AA | AA | 03 | 00 | IEEE 802
+------------+------------+------------+------------+ LLC/SNAP
5 | 00 | 00 | Ethertype = 0x0800=2048 | header
+============+============+============+============+ =============
6 | VER | HLEN | TOS | Total Length |
+-----+------+------------+-----+-------------------+
7 | ID | FLG | Frag Offset |
+<><><><><><>+<><><><><><>+<><><><><><>+<><><><><><>+ IPv4 Header
8 | TTL | PROTO | Header Checksum |
+------------+------------+-------------------------+
9 | Source IP Address |
+---------------------------------------------------+
10 | Destination IP Address |
+---------------------------------------------------+
11 | . . . |
+---------------------------------------------------+
| . . . | byte (n-2) | byte (n-1) | FILL |
+------------+------------+------------+------------+
| FILL | FILL | FILL | FILL |
+------------+------------+------------+------------+
M-1| FILL | FILL | FILL | FILL |
+<><><><><><>+<><><><><><>+<><><><><><>+<><><><><><>+
IP v4 data packet diagram
As shown in above figure the first eight bytes of the IP Datagram
occupy the last eight bytes of the HIPPI-6400-PH [1] Header
micropacket.
4.2 HIPPI-6400 Hardware address: Universal LAN MAC address (ULA)
HIPPI-6400 uses Universal LAN MAC Addresses specified in IEEE
Standard 802.1A [10] or a subset as defined in HIPPI-6400-SC [2].
The globally unique part of the 48 bit space is administered by the
IEEE. Each port on a HIPPI-6400-SC LAN MUST be assigned a ULA.
Multiple ULAs may be used if a node contains more than one IEEE 802.2
LLC protocol entity.
Pittet Standards Track [Page 9]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
This memo assumes the use of "Logical Addressing" as described in
Annex A.2 of HIPPI-6400-SC[2].
The format of the address within its 48 bit HIPPI-6400-PH fields
follows IEEE 802.1A canonical bit order and HIPPI-6400-PH bit and
byte order:
31 23 15 7 0
+---------------+---------------+---------------+---------------+
|ULA byte 0 |L|G| ULA byte 1 | ULA byte 2 | ULA byte 3 |
+---------------+---------------+---------------+---------------+
| ULA byte 4 | ULA byte 5 | (not used for ULA) |
+---------------+---------------+---------------+---------------+
Universal LAN MAC Address Format
L (U/L bit) = 1 for Locally administered addresses, 0 for Universal.
G (I/G bit) = 1 for Group addresses, 0 for Individual.
4.3 Maximum Transmission Unit - MTU
Maximum Transmission Unit (MTU) is defined as the maximum length of
the IP packet, including IP header, but not including any overhead
below IP, i.e., HIPPI-6400 MAC header and IEEE 802 LLC/SNAP header.
Conventional LANs have MTU sizes determined by physical layer
specification. MTUs may be required simply because the chosen medium
won't work with larger packets, or they may serve to limit the amount
of time a node must wait for an opportunity to send a packet.
HIPPI-6400-PH [1] limits packets to about 4 gigabytes (on VC 3) which
imposes no practical limit for networking purposes. HIPPI-6400-PH VC
1, which was chosen for IP and ARP traffic, limits messages to about
128 Kbytes which is still larger than the HIPPI-800 MTU [17].
The MTU for HIPPI-6400 LANs SHALL be 65280 (decimal) bytes.
This value is backwards compatible with HIPPI-800. It allows the IP
packet to fit in one 64K byte buffer with up to 256 bytes of
overhead. The IP v4 overhead is 24 bytes for HIPPI-6400 and 40 bytes
for HIPPI-800.
Pittet Standards Track [Page 10]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
For HIPPI-6400 the byte accounting is:
HIPPI-6400-PH Header 16 bytes
IEEE 802.2 LLC/SNAP Headers 8 bytes
Maximum IP packet size (MTU) 65280 bytes
Unused expansion room 232 bytes
------------
Total 65536 bytes (64K)
In contrast, the HIPPI-800 accounting is:
HIPPI-800-FP Header 8 bytes
HIPPI-800-LE Header 24 bytes
IEEE 802.2 LLC/SNAP Headers 8 bytes
Unused expansion room 216 bytes
Maximum IP packet size (MTU) 65280 bytes
------------
Total 65536 bytes (64K)
5. HIPPI Address Resolution Protocol - HARP
Address resolution within the HIPPI-6400 LIS SHALL make use of the
HIPPI Address Resolution Protocol (HARP) and the Inverse HIPPI
Address Resolution Protocol (InHARP). HARP provides the same
functionality as the Internet Address Resolution Protocol (ARP).
HARP is based on ARP which is defined in RFC-826 [14] except the
HIPPI-6400 specific packet format. Knowing the Internet address,
conventional networks use ARP to discover another node's hardware
address. HARP presented in this section further specifies the
combination of the original protocol definitions to form a coherent
address resolution service that is independent of the hardware's
broadcast capability. InHARP is the same protocol as the original
Inverse ARP (InARP) protocol presented in [5] except the HIPPI-6400
specific packet format. Knowing its hardware address, InARP is used
to discover the other party's Internet address.
This memo further REQUIRES the PIBES (see section 7) extension to the
HARP protocol, guaranteeing broadcast service to upper layer
protocols like IP.
Internet addresses are assigned independent of ULAs. Before using
HARP, each node MUST know its IP and its HW addresses. The ULA is
optional but is RECOMMENDED if interoperability with conventional
networks is desired.
Pittet Standards Track [Page 11]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -