📄 rfc2835.txt
字号:
In other replies it SHALL contain the requester's
IP address.
Payload Format for HARP/InHARP PDUs:
|31 |23 |15 |7 0|
+---------------+---------------+---------------+---------------+-----
0 | |
| D_ULA +-------------------------------+HIPPI
1 | | |6400
+-------------------------------+ S_ULA |MAC
2 | |hdr
+---------------------------------------------------------------+
3 | M_len |
+---------------+---------------+---------------+---------------+-----
4 | AA | AA | 03 | 00 |IEEE
+---------------+---------------+---------------+---------------+802
5 | 00 | 00 | Ethertype = 0x0800 = 2048 |LLC/
+------------+------------------+-------------------------------+SNAP
6 | hrd (28) | pro (2048) |
+---------------+---------------+---------------+---------------+
7 | op (ar$op) | pln (6) | shl (q) |
+<><><><><><><><+><><><><><><><>+<><><><><><><><+><><><><><><><>+
8 | thl (x) | Source IP Address upper (24 bits) |
+---------------------------------------------------------------+
9 | Src. IP lower | Target IP Address upper (24 bits) |
+---------------+-----------------------------------------------+
10 | Tgt. IP lower | Source HW Address bytes 0 - 2 |
+---------------+-------------------------------+---------------+
11 | Source HW Address bytes 3 - q | Tgt HW byte 0 |
+-----------------------------------------------+---------------+
12 | Target Hardware Address bytes 1 - 4 |
+---------------+-----------------------------------------------+
13 |Tgt HW byte 5-x|
+---------------+
HARP - InHARP Message
6.2.1 Example Message encodings:
Assume for the following example that the HARP server is in the
HIPPI-6400 side and the clients, X and Y are on the HIPPI-800 side of
the non-broadcast capable network.
Pittet Standards Track [Page 23]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
HARP_REQUEST message
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPy HARP ar$tpa = IPx
HARP ar$rha = SWy ULAy HARP ar$tha = **
** is what we would like to find out
HARP_REPLY message format
HARP ar$op = 2 (HARP_REPLY)
HARP ar$rpa = IPx HARP ar$tpa = IPy
HARP ar$rha = SWx ULAx * HARP ar$tha = SWy ULAy
* answer we were looking for
InHARP_REQUEST message format
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy HARP ar$tpa = 0 **
HARP ar$rha = SWy ULAy HARP ar$tha = SWx ULAx
** is what we would like to find out
InHARP_REPLY message format
HARP ar$op = 9 (InHARP_REPLY)
HARP ar$rpa = IPx * HARP ar$tpa = IPy
HARP ar$rha = SWx ULAx HARP ar$tha = SWy ULAy
* answer we were looking for
6.2.2 HARP_NAK message format
The HARP_NAK message format is the same as the received HARP_REQUEST
message format with the operation code set to HARP_NAK; i.e. the
HARP_REQUEST message data is copied for transmission with the
HARP_REQUEST operation code changed to the HARP_NAK value. HARP
makes use of an additional operation code for HARP_NAK and MUST be
implemented.
7 Broadcast and Multicast
HIPPI-6400-SC requires compliant systems to support broadcast.
Initial HIPPI-6400-SC systems MAY defer broadcast capability to a
broadcast server rather than support it directly in the switching
mechanism. A centralized HARP server architecture meets two of the
three major duties of a broadcast server.
A central entity serving the whole LIS solves the coordination
problem of a distributed approach. The registration requirement
solves the second problem of determining which addresses make up the
set loosely called "everyone". The last duty of a broadcast server is
to replicate an incoming packet and send it to "everyone".
Pittet Standards Track [Page 24]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
During its registration phase, every port , including HARP server(s),
discover if the underlying medium is capable of broadcast (see
section 5.1.1). Should this not be the case, then the HARP server(s)
MUST emulate broadcast through an IP broadcast emulation server.
A HIPPI IP broadcast server (PIBES) is an extension to the HARP
server and only makes sense when the LIS does not inherently support
broadcast. The PIBES allows common upper layer networking protocols
(RIP, TCP, UDP, etc.)to access IP LIS broadcast.
7.1 Protocol for an IP Broadcast Emulation Server - PIBES
To emulate broadcast within an LIS, a PIBES SHALL use the currently
valid HARP table of the HARP server as a list of addresses called the
target list. The broadcast server SHALL validate that all incoming
messages have a source address which corresponds to an address in the
target list. Only messages addressed to the IP LIS broadcast
addresses, multicast address or 255.255.255.255 are considered valid
messages for broadcasting. Invalid messages MUST be dropped. All
valid incoming messages shall be forwarded to all addresses in the
target list.
It is RECOMMENDED that the broadcast server run on the same port as
the HARP server since this memo does not define the protocol for
exchanging the valid HARP table. The default address to use for the
broadcast address is the operational HARP server address.
7.2 IP Broadcast Address
This memo only defines IP broadcast. It is independent of the
underlying hardware addressing and broadcast capabilities. Any port
can differentiate between IP traffic directed to itself and a
broadcast message sent to it by looking at the IP address. All IP
broadcast messages SHALL use the IP LIS broadcast address.
It is RECOMMENDED that the PIBES run on the same port as the HARP
server. In that case, the PIBES SHALL use the same address as the
HARP server.
7.3 IP Multicast Address
HIPPI-6400 does not directly support multicast address, therefore
there are no mappings available from IP multicast addresses to HIPPI
multicast services. Current IP multicast implementations (i.e. MBONE
and IP tunneling, see [7]) will continue to operate over HIPPI-based
logical IP subnets if all IP multicast packets are sent using the
same algorithm as if the packet were being sent to 255.255.255.255.
Pittet Standards Track [Page 25]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
7.4 A Note on Broadcast Emulation Performance
It is obvious that a broadcast emulation service (as defined in
section 7.1) has an inherent performance limit. In an LIS with n
ports, the upper bound on the bandwidth that such a service can
broadcast is:
(total bandwidth)/(n+1)
since each message must first enter the broadcast server, accounting
for the additional 1, and then be sent to all n ports. The broadcast
server could forward the message destined to the port on which it
runs internally, thus reducing (n+1) to (n) in a first optimization.
This service is adequate for the standard networking protocols such
as RIP, OSPF, NIS, etc. since they usually use a small fraction of
the network bandwidth for broadcast. For these purposes, the
broadcast emulation server as defined in this memo allows the HIPPI-
6400 network to look similar to an Ethernet network to the higher
layers.
It is further obvious that such an emulation cannot be used to
broadcast high bandwidth traffic. For such a solution, hardware
support for true broadcast is required.
8 HARP for Scheduled Transfer
This RFC also applies for resolving addresses used with Scheduled
Transfer (ST) over HIPPI-6400 instead of IP. This RFC's message types
and algorithms can be used for ST (since ST uses Internet Addresses)
as long as there is also an IP over HIPPI-6400 implementation on all
the ports.
9 Security Consierations
There are known security issues relating to port impersonation via
the address resolution protocols used in the Internet [6]. No
special security mechanisms have been added to the address resolution
mechanism defined here for use with networks using HARP.
Not all of the security issues relating to ARP over HIPPI-6400 are
clearly understood at this time, due to the fluid state of HIPPI-6400
specifications, newness of the technology, and other factors.
However, given the security hole ARP allows, other concerns are
probably minor.
Pittet Standards Track [Page 26]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
10 Open Issues
Synchronization and coordination of multiple HARP servers and
multiple broadcast servers are left for further study.
11 HARP Examples
Assume a HIPPI-6400-SC switch is installed with three connected
ports: x, y, and a. Each port has a unique hardware address that
consists unique ULA (ULAx, ULAy and UlAa, respectively). There is a
HARP server connected to a switch port that is mapped to the address
HWa, this address is the authoritative HIPPI hardware address in the
HRAL (HARP Request Address List).
The HARP server's table is empty. Ports X and Y each know their own
hardware address. Eventually they want to talk to each other; each
knows the other's IP address (from the port database) but neither
knows the other's ULA. Both ports X and Y have their interfaces
configured DOWN.
NOTE: The LLC, SNAP, Ethertype, ar$hrd, ar$pro, ar$pln fields are
left out from the examples below since they are constant. As well as
ar$rhl = ar$thl = 6 since these are all HIPPI-6400 examples.
11.1 Registration Phase of Client Y on Non-broadcast Hardware
Port Y starts: its HARP table entry state for the server: PENDING
1. Port Y initiates its interface and sends an InHARP_REQUEST to the
HWa after starting a table entry for the HWa.
HIPPI-6400-PH D_ULA = ULAa
HIPPI-6400-PH S_ULA = ULAy
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy
HARP ar$tpa = 0 **
HARP ar$rha = ULAy
HARP ar$tha = ULAa
** is what we would like to find out
2. HARP server receives Y's InHARP_REQUEST, it examines the source
addresses and scans its tables for a match. Since this is the
first time Y connects to this server there is no entry and one
will be created and time stamped with the information from the
InHARP_REQUEST. The HARP server will then send a InHARP_REPLY
including its IP address.
Pittet Standards Track [Page 27]
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
HIPPI-6400-PH D_ULA = ULAy
HIPPI-6400-PH S_ULA = ULAa
HARP ar$op = 9 (InHARP_REPLY)
HARP ar$rpa = IPs *
HARP ar$tpa = IPy
HARP ar$rha = ULAa
HARP ar$tha = ULAy
* answer we were looking for
3. Port Y examines the incoming InHARP_REPLY and completes its table
entry for the HARP server. The client's HARP table entry for the
server now passes into the VALID state and is usable for regular
HARP traffic. Receiving this reply ensures that the HARP server
has properly registered the client.
11.2 Registration Phase of Client Y on Broadcast Capable Hardware
If port Y is connected to a broadcast-capable network then the
authoritative address is the broadcast address, HWb = SWb, ULAb
(FF:FF:FF:FF:FF:FF).
Port Y starts: its HARP table entry state for HWa: PENDING
1. Port Y initiates its interface and sends an InHARP_REQUEST to HWa,
in this example the broadcast address, after starting a table
entry.
HIPPI-6400-PH D_ULA = ULAb
HIPPI-6400-PH S_ULA = ULAy
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy
HARP ar$tpa ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -