As per Relevance of the word associated, we have this rfc below:
Network Working Group J.
Request for Comments: 1223
May 1991
OSI CLNS and LLC1 Protocols on Network Systems
Status of this
The intent of this document is to provide a complete discussion
the protocols and techniques used to transmit OSI CLNS and LLC
datagrams (and any associated higher level protocols) on
Systems Corporation's HYPERchannel equipment. This document
intended for network planners and implementers who are
familiar with the OSI protocol suite and the techniques used to
OSI traffic on standard networks such as 802.3.
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
Table of
Goals of this Document . . . . . . . . . . . . . . . . . . . . . 1
HYPERchannel Network Messages . . . . . . . . . . . . . . . . . . 2
Message Proper Header . . . . . . . . . . . . . . . . . . . . . 3
TO Addresses and Open Driver Architecture . . . . . . . . . . . 8
Broadcasting . . . . . . . . . . . . . . . . . . . . . . . . . . 9
ES-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Security Considerations . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
Goals of this
In this document, we have three major technical objectives
1. To standardize the encapsulation of LLC1 packets
HYPERchannel. The format will be used for OSI CLNS and
any other protocols using LLC1 over HYPERchannel. (
that if one desires to use the LLC1/SNAP combination
TCP/IP, this is the format to use. This represents
alternative to the native mode for TCP/IP over HYPERchannel
allowing for sharing the medium at the LLC1 layer.)
Halpern [Page 1]
RFC 1223 OSI and LLC1 on HYPERchannel May 1991
2. To describe how multicast protocols such as ES-IS and IS-IS
operate over HYPERchannel. As a medium, HYPERchannel does
support either broadcast or multicast. Therefore,
techniques are needed to handle these protocols. Note that
techniques do not allow general multicast, although any
problem may be solved by a generalization of these methods
3. To make use of a standardized "message type" field in
8 and 9 of the HYPERchannel network message. To permit
interoperability, NSC maintains a "network protocol registry
where any interested party may obtain a unique value in byte 8
(or bytes 8 and 9) for their own public, private, commercial
proprietary protocol. Lists of assigned protocol type
and their "owners" would be periodically published by NSC
are available to interested parties
HYPERchannel Network
Unlike most datagram delivery systems, the HYPERchannel
message consists of two parts
Message
+--------------------+
| |
| |
| |
| 16-64 bytes |
| |
| |
| |
+--------------------+
Associated
+----------------------------------------------------+
| |
| |
| |
| |
| |
| |
| Unlimited length |
| |
| |
| |
| |
| |
| |
+----------------------------------------------------+
Halpern [Page 2]
RFC 1223 OSI and LLC1 on HYPERchannel May 1991
The first part is a message header that can be up to 64 bytes
length. The first 16 bytes contain information required for
delivery of the entire message, and the remainder can be used
higher level protocols. The second part of the message,
"Associated Data," can be optionally included with the
proper. In most cases (transmission over HYPERchannel-50 trunks)
length of the associated data is literally unlimited. Others (
as HYPERchannel-10 or transmission within a local HYPERchannel-50
A400 adapter) limit the size of the Associated Data to 4K bytes.
the information sent can be contained within the Message Proper,
the Associated Data need not be sent
HYPERchannel lower link protocols treat messages with and
Associated Data quite differently; "Message only" transmissions
sent using abbreviated protocols and can be queued in the
network adapter, thus minimizing the elapsed time needed to send
receive the messages. When associated data is provided,
HYPERchannel-50 adapters free their logical resources towards
the host interface and coaxial trunks at maximum speed, so that
can flow through the transmitting channel, the coaxial cable, and
receiving channel concurrently. Thus HYPERchannel-50 can
the nominal burst speed of the computer host interface when
large data blocks over an extended period
Message Proper
The first 16 bytes of the network Message Proper are examined by
network adapters to control delivery of the network message.
message format is as follows
Halpern [Page 3]
RFC 1223 OSI and LLC1 on HYPERchannel May 1991
byte Message
+------------------------------------------------------------+
0 | Trunks to Try | Message Flags |
| TO trunks | FROM trunks | |A/D
+--------------+---------------+-------------------------+---+
2 | TO Domain # | TO Network # |
| | |
+------------------------------+-----------------------------+
4 | TO Unit # | Logical To |
| | (port number) |
+------------------------------+-----------------------------+
6 | From Unit # | Logical From |
| | (port number) |
+------------------------------+-----------------------------+
8 | Message type |
| 0x0B01 |
+------------------------------+-----------------------------+
10 | FROM Domain # | FROM Network # |
| | |
+------------------------------+-----------------------------+
12 | True Unit | age count |
| | |
+------------------------------+-----------------------------+
14 | Header End Offset | Next Header Offset |
| (16) | (16) |
+------------------------------+-----------------------------+
16 | LLC1 destination SAP | LLC1 source SAP |
| (0xFE for CLNP) | (0xFE for CLNP) |
+------------------------------+-----------------------------+
18 | LLC1 function code | |
| (0x03 for normal data) |Start of upper layer protocol
+------------------------------+ +
20 | from bytes 19-63 of the message proper |
| and continuing in the associated data |
| (For OSI this is CLNP, then transport etc.) |
+------------------------------+-----------------------------+
Trunks to
Consists of two four bit masks indicating which of four
HYPERchannel-50 coaxial data trunks are to be used to transmit
message and to return it. If a bit in the mask is ON, then
adapter firmware will logically AND it with the mask of
trunk interfaces and use the result as a candidate list
interfaces
Whenever one of the internal "frames" are sent to communicate
Halpern [Page 4]
RFC 1223 OSI and LLC1 on HYPERchannel May 1991
the destination adapter, the transmission hardware
selects the first non-busy trunk out of the list of candidates.
selection of a data trunk is best performed by the adapter
rather than by the host. Dedicating trunks to specific
only makes sense in very critical real time applications such
streaming data directly from high speed overrunable peripherals
A second Trunk mask is provided for the receiving adapter when
sends frames back to the transmitter, as it is possible to
asymmetric configurations of data trunks where trunk 1 on one box
connected to the trunk 3 interface of a second. Such
are strongly discouraged, but the addressing structure supports it
needed
The "trunks to try" field is only used by HYPERchannel-50. To
maximum interoperability, a value of 0xFF should be placed in
field to assure delivery over any technology. The newer DX
units determine the trunk mask on their own, but this field
preserved for use with A series equipment
Message
Contains options in message delivery. There are several bits
by the hardware. However, only the A/D bit will be described here
Other bits are used only for special diagnostic or
purposes. If there is a need to set them, check the specific
Systems manuals on their meanings. In the absence of such need,
bits other than A/D shall be set to zero on transmission, and
examined upon receipt of a message
ASSOCIATED DATA PRESENT (A/D) is ON if an Associated Data
follows the Message Proper. 0 if only a message proper is present
the network message. The value of this bit is enforced by
network adapter firmware
TO Domain
This is the most significant byte of the four byte
address. It selects an NSC addressing domain, among a set
domains. If this and the network number both refer to the
domain and network, they may be set to 0.
TO Network
This is the destination network number. It identifies the
within the selected domain, where the destination unit resides.
the destination is in the local domain and network, both the
domain and TO network numbers may be set to zero
Halpern [Page 5]
RFC 1223 OSI and LLC1 on HYPERchannel May 1991
TO
Upon arrival at the destination domain and network, this is the
number of the destination HYPERchannel adapter. The combination
Domain, Network, and Unit uniquely identify a single adapter in
HYPERchannel network. For compatibility with existing
equipment, when sending a message to a destination outside the
domain and network, set this byte to 0, and store the
destination unit number in the True Unit field
Logical
This field further identifies which process the message is
for. With some hardware, the bottom bits select a machine from
several. When sending a message to an N400, the bottom two bits
this field select which of four attached hosts the message
destined for. Within a host, the logical to field selects
destination process. This is used in conjunction with the
Type field to insure that messages are delivered to the
place. The Logical TO field identifies a process, which then
the Message Type to insure that it understands the message.
also allows for running two processes, both of which understand
same protocol
From
This identifies the Unit number from which this message was sent
Logical
This identifies the host and process who originated this message
Message
The following two bytes are reserved for NSC. Users have
encouraged to put a zero in byte 8 and anything at all in byte 9
as to not conflict with internal processing of messages by
firmware. In the past, this field has been loosely defined
carrying information of interest to NSC equipment carrying
message and not as a formal protocol type field. For example,
0xFF00 in bytes 8 and 9 of the message will cause the
adapter to loop back the message without delivering it to
attached host
NSC now uses both bytes 8 and 9 as a formal "protocol type
designator. Major protocols will be assigned a unique value in
8 that will (among good citizens) not duplicate a value generated
a different protocol. Minor protocols will have 16 bit
Halpern [Page 6]
RFC 1223 OSI and LLC1 on HYPERchannel May 1991
assigned to them so that we won't run out when 256 protocols turn up
Any interested party could obtain a protocol number or numbers
application to NSC. In this document, protocol types specific to
LLC1 are assigned. Specifically, the sixteen bit value 0x0B01
bytes 8 and 9 shall identify LLC1 packets
True
This field is used to handle addressing outside of the local
and network. For compatibility with previous NSC hardware, one
not put the destination unit number in the TO Unit field if
destination domain or network are not the local ones. In that case
one puts zero in the TO Unit field, and puts the destination
number into the TRUE unit field. NSC Link devices will adjust
message when it arrives at the destination domain and network so
the destination unit number appears in the TO Unit field
Age
This field serves as a "time to live" in that it prevents
from endlessly circulating about in an improperly configured network
Each time a message with this format passes through a bridge, the
Count is decremented by one. When the result is zero, the message
discarded by the bridge. Therefore, this byte should be set to 255
when a message is originated, and ignored when a message is received
Next Header Offset and Header End
These fields are used by the hardware to determine if any
addressing is present. No special addressing forms are permitted
conjunction with LLC1. Therefore, these fields shall always be
to 16. Receivers may count on the LLC1 information beginning
offset 16 in the message proper
LLC1
The LLC1 Information begins at byte 16 of the message, for 3 bytes
The contains the LLC1 destination and source SAPs, followed by
LLC1 type identifier (usually 03 for unnumbered information.)
Higher Layer Protocol
Higher layer protocol information follows immediately after the LLC
header in the message proper, and flows into the associated data
For purposes of this document, this is OSI CLNP, but it may be
protocol which uses LLC1.
Halpern [Page 7]
RFC 1223 OSI and LLC1 on HYPERchannel May 1991
TO Addresses and Open Driver
Since not all 16 bits of the TO address are used for the
delivery of the network message, the remainder are
"logical" in that their meaning is physically determined by
computer software or (in cases such as the FIPS data channel)
hardware in the host interface
Since HYPERchannel is and will be used to support a large variety
general and special purpose protocols, it is desirable that
independent protocol servers be able to independently share
HYPERchannel network interface. The implementation of many of NSC'
device drivers as well as those of other parties (such as
Research) support this service. Each protocol server that wishes
send or receive HYPERchannel network messages logically connects to
HYPERchannel device driver by specifying the complete 16 bit
address it will own in the sense that any network message with
TO address will be delivered to that protocol server
The logical TO field serves a function similar to the TYPE byte
the Ethernet message header, but differs from it in that the width
the logical TO field varies from host to host, and that no values
the logical TO address are reserved for particular protocols. On
other hand, it is possible to have several "identical"
(such as two independent copies of OSI with different
addresses) sharing the same physical HYPERchannel interface.
makes NSC's addressing approach identical to the OSI concept that
protocol server to reach is embedded within the address, rather
the IP notion of addressing a "host" and identifying a server
a message type
Since the HYPERchannel header also has a "message type" field,
is some ambiguity concerning the respective roles of the message
and logical TO fields
o The logical TO field is always used to identify the protocol
which will receive the message. Once a server has specified
complete TO address for the messages it wishes to receive,
message will not be delivered to a different protocol
regardless of the contents of the message type field
o Although the type field cannot change the protocol server at
final destination of the message, the type field can be used
intermediate processes on the network to process the
before it reaches the server destination. An obvious
is the 0xFF00 message loopback type function, where
processing to loop back the message results in nondelivery
the TO address. In the future, intermediate nodes may
Halpern [Page 8]
RFC 1223 OSI and LLC1 on HYPERchannel May 1991
in transit messages based on the message type only for
such as security validation, aging of certain datagrams,
network management
NSC message forwarding protocols use low level link protocols
negotiate transmission of a message to its next destination on
network. Furthermore, NSC network boxes often fan out so
several hosts share the same network transmission equipment as in
A400 adapter. Both these characteristics mean that providing
genuine broadcast capability is not a trivial task, and in fact
NSC technology supports a broadcast capability
However, the OSI ES-IS and IS-IS protocols require a
capability to operate. Therefore, in order to support
protocols, some form of broadcast emulation must be used
ES-
The End System to Intermediate System routing protocol is used by
systems to decide where to send packets. In the specified protocol
multicast messages are used so that end systems learn
intermediate systems, and intermediate systems learn about
systems. End systems normally then transmit any packets,
correct mac destination is unknown, to a random intermediate
which then forwards the packet and tells the originator where to
future packets
There are two situations which are distinct but related for
of this protocol over HYPERchannel. These are distinguished
whether or not there are any real intermediate systems on
HYPERchannel network
ES-IS with Intermediate
If there are one or more intermediate systems on the HYPERchannel
then the behavior is simply to emulate multicast
END SYSTEM SUPPORT Each end system is profiled with a list
intermediate systems on the HYPERchannel. It is desirable but
necessary that this list be complete, as the future support
IS-IS will forward the necessary information to all
intermediate systems. Given the profiled list, whenever the
system wishes to originate an ESH packet (End System Hello),
will send individual copies to each intermediate system it
about
Halpern [Page 9]
RFC 1223 OSI and LLC1 on HYPERchannel May 1991
On most systems, these individual packets should be spaced out
time so as not to interfere with the normal transmission of
and other HYPERchannel messages. For end systems, an inter-
time of 0.1 seconds is probably appropriate
Note that if the End System receives ISH packets (
System Hello) from an IS on HYPERchannel not in its static list
it should add that to the list of systems it will send ESH
to. The address of the new intermediate system should
remembered for the holding time in the ISH, just as with
normal operation of ES-IS
INTERMEDIATE SYSTEMS Intermediate systems on the
shall also be profiled with the addresses of all the
intermediate systems on the HYPERchannel. This list is used
and in the IS-IS protocol. For the IS-IS protocol operation,
is important that the list be complete
The list of intermediate systems is used, with ES-IS, by
intermediate system only in that it probably is also an
system. As such, it must send ESH packets to all the
intermediate systems. (The presumption that an IS is also an
is driven by the long term requirements for network management
If you have an upper layer stack, such as is required for CMIP
you are an end system.)
Each intermediate system will keep a list of the end systems
knows about. These are the systems it has received ESH
from. Whenever the IS sends ISH packets, it sends
individually to each ES it has heard from. In addition, it
the ISH to any end systems which it believes, on the basis of IS
IS or other methods, are on the HYPERchannel
Note that these packets must also be spread out in time to
causing congestion. However, given that the number of these
much higher than the number generated by End Systems, the
between transmissions should be selected by the IS developer
fit the sustainable I/O rates of the system. Make sure you
get at the very least one, and preferably two or three,
packets in between each ISH copy being sent
ES-IS without an Intermediate
When there is no intermediate system, one or more systems
serve as address managers. These are referred to in draft ISO
documents as SNARE, for SubNetwork Address Resolution Entities
END SYSTEM SUPPORT As in the previous case, each end system
Halpern [Page 10]
RFC 1223 OSI and LLC1 on HYPERchannel May 1991
be profiled with a list of intermediate systems. This list
contain all of the systems which will be serving as
managers on this network. The reason for this is that, since
address managers are not true intermediate systems, they are
running IS-IS and will not be exchanging lists of end systems
know about. There may well be several systems for redundancy
reliability
SNARE The systems selected as address managers must appear, to
other end systems, as intermediate systems. This means that
one must send out ISH packets to all the end systems which
hears from. Each of these systems must record all the
from the ESH packets they receive. When a packet for an
System is received at a SNARE, it must behave as an IS
Specifically, it must forward the packet to the
destination end system, and send a redirect message back to
originator, informing the originator of the correct
(HYPERchannel address) for the end system
Note that these systems are certainly end systems as well,
must send ESH packets to all the intermediate systems on the
list, which must be complete
ES-IS FORMAT
All ES-IS PDUS shall be formatted as specified in ISO 9542.
are then sent using LLC1 and the encapsulation specified
in this document for transmitting LLC1 over HYPERchannel
RD PDUS When generating Redirect pdus, which contain
SNPAs (addresses), the SNPA shall be represented in four bytes
This shall be used even on a small HYPERchannel network
only one domain and one network number
QC FUNCTION There is no support for the ES-IS query
capability when using HYPERchannel. All systems must have
least one configured intermediate system, which shall be either
true IS or a SNARE
IS-
The proposed IS-IS protocol for OSI (DP 10589) when run on a
requires broadcast capability. Because of the nature of the
for nominating the designated IS on a LAN, and other special
of this protocol, it is important never to partition the set
intermediate systems on a HYPERchannel network
The implementation therefore is very simple. An intermediate
Halpern [Page 11]
RFC 1223 OSI and LLC1 on HYPERchannel May 1991
on HYPERchannel runs the IS-IS protocol directly. However, when
goes to send a message, it consults the profiled list of all level 1
ISs on the HYPERchannel or of all level 2 ISs on the HYPERchannel
and then sends individual copies of the message to each destination
This multiple transmission should be transparent to the IS-
protocol itself
Note that as with ES-IS on an intermediate system, it is important
space out the individual message transmissions. On most networks
spacing of 0.1 seconds will work well
+1+ ISO IS 9542 - End system to intermediate system
exchange
+2+ ISO DP 10589 - Intermediate system to Intermediate
Infra-Domain routing exchange
Security
Security issues are not discussed in this memo
Author's
Joel M.
Principal
Network Systems Corporation MS033
7600 Boone Avenue
Brooklyn Park, AN 55428
Phone: (612) 424-1606
Email: jmh@anubis.network.
Halpern [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
