1377 lines
51 KiB
Plaintext
1377 lines
51 KiB
Plaintext
|
[ netinfo/blacker.doc ]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
BLACKER INTERFACE CONTROL DOCUMENT
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
Table of Contents
|
|||
|
|
|||
|
|
|||
|
Section Subject Page
|
|||
|
|
|||
|
|
|||
|
1. Introduction 1-1
|
|||
|
|
|||
|
2. Host/Red-Side Interface 2-1
|
|||
|
|
|||
|
2.1. Physical Level 2-1
|
|||
|
|
|||
|
2.2. Link Level 2-4
|
|||
|
|
|||
|
2.3. Packet Level 2-4
|
|||
|
|
|||
|
2.4. Internet Protocol Features 2-9
|
|||
|
|
|||
|
2.5. Internet Control Message Protocol Features 2-11
|
|||
|
|
|||
|
3. Network/Black-Side Interface 3-1
|
|||
|
|
|||
|
3.1. Physical Level 3-1
|
|||
|
|
|||
|
3.2. Link Level 3-3
|
|||
|
|
|||
|
3.3. Packet Level 3-3
|
|||
|
|
|||
|
3.4. Internet Protocol Features 3-4
|
|||
|
|
|||
|
3.5. Internet Control Message Protocol Features 3-4
|
|||
|
|
|||
|
A. Initial DDN Sensitivity Labels A-1
|
|||
|
|
|||
|
B. References B-1
|
|||
|
|
|||
|
C. BLACKER Generated Diagnostic Codes C-1
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
1. INTRODUCTION
|
|||
|
|
|||
|
1.0.1 The purpose of this document is to define the interface to
|
|||
|
the BLACKER Front Ends (BFE). This document will define the
|
|||
|
services used on the network or black side where the BFE
|
|||
|
interfaces to the Defense Data Network (DDN) and will define the
|
|||
|
services offered on the host/gateway or red side.
|
|||
|
|
|||
|
Host Network
|
|||
|
Plaintext Ciphertext
|
|||
|
Red-Side Black-Side
|
|||
|
+---------+ +---------+ +---------+
|
|||
|
| HOST OR |___________| BFE |_______________| DDN |
|
|||
|
| GATEWAY | | | | PSN |
|
|||
|
+---------+ +---------+ +---------+
|
|||
|
|
|||
|
|
|||
|
1.0.2 The BFE acts as the Data Communication Equipment (DCE) of
|
|||
|
an X.25 Network to its attached host. As such, the BFE offers
|
|||
|
the host an X.25 interface. This interface is a modified version
|
|||
|
of the interface presented in the 1983 DDN X.25 Host Interface
|
|||
|
Specification. Because of the additional security functionality
|
|||
|
of the BFE, there are additional requirements on the host
|
|||
|
interface at levels above the X.25 layer. These additional
|
|||
|
requirements as well as the specific details of the X.25
|
|||
|
interface are defined in section 2 of this document.
|
|||
|
|
|||
|
1.0.3 The following terminology will be used in this document.
|
|||
|
Units of information at the link (X.25 level 2) level will be
|
|||
|
referred to as "frames". Units at the network (X.25 level 3)
|
|||
|
level will be referred to as "packets". Units at the Internet
|
|||
|
Protocol (IP) level will be referred to as "datagrams". The
|
|||
|
information contained in a datagram that is passed on to the
|
|||
|
actual destination computer will be referred to as a message,
|
|||
|
with an appropriate modifier (e.g., Mail message). A byte is a
|
|||
|
unit of data containing eight bits.
|
|||
|
|
|||
|
1.0.4 The BLACKER System on the DDN uses the X.25 interface as a
|
|||
|
local interface only. This means that the type of service
|
|||
|
offered does not provide the end-to-end services of X.25. The
|
|||
|
BFE will offer a version of the DDN X.25 Standard Service as
|
|||
|
defined in the DDN X.25 Host Interface Specification, dated Dec
|
|||
|
1983, with the restrictions and modifications defined in this
|
|||
|
document. This interface also conforms to FIPS PUB 100 (6 July
|
|||
|
1983), and CCITT Recommendation X.25 (1980), as well as the DDN
|
|||
|
Host Interface Specification. The BFE will not provide support
|
|||
|
for the ARPANET Host Interface Protocol (AHIP), also known as
|
|||
|
Bolt, Beranek, and Newman, Inc. (BBN) 1822 interface.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Page 1-1
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
1.0.5 All values for fields defined in this document, unless
|
|||
|
otherwise designated, are decimal values. The leftmost bit
|
|||
|
(byte) in any field is the high order bit (byte) of the value.
|
|||
|
|
|||
|
1.0.6 All BFE parameters are loaded via a BLACKER Initialization
|
|||
|
Carrier (BIC). These include site identification, Access Control
|
|||
|
Center (ACC) and Key Distribution Center (KDC) identification,
|
|||
|
security level, protocol parameters, and audit control values.
|
|||
|
The BIC is inserted and read when the BFE is first powered on,
|
|||
|
and then is only needed after the BFE has been reset, zeroized,
|
|||
|
or has completely lost power.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Page 1-2
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
2. RED-SIDE HOST INTERFACE
|
|||
|
|
|||
|
2.0.1 This section describes the host interface to the BLACKER
|
|||
|
Front End. This interface is based upon standards defined for
|
|||
|
the 1983 DDN X.25 interface, and requires that the Internet
|
|||
|
Protocol (IP) be used as the next layer above X.25. For hosts
|
|||
|
which already implement the current set of DDN X.25 protocols
|
|||
|
including IP, and use an RS-449 balanced interface, the changes
|
|||
|
should be minor.
|
|||
|
|
|||
|
2.1 PHYSICAL LEVEL
|
|||
|
|
|||
|
The BFE will conform to the following three specifications:
|
|||
|
|
|||
|
1. "DEFENSE DATA NETWORK X.25 HOST INTERFACE SPECIFICATION",
|
|||
|
DCA, DECEMBER 1983
|
|||
|
|
|||
|
2. EIA STANDARD RS-449, NOVEMBER 1977
|
|||
|
|
|||
|
3. MILITARY STANDARD 188-114, MARCH 1976
|
|||
|
|
|||
|
The BFE will support the signals as listed in Table B-2 of the
|
|||
|
DDN X.25 Specification. Optional signals supported will be the
|
|||
|
signals identified as CCITT numbers 141 and 142 on the host side.
|
|||
|
|
|||
|
In RS-449 terms, the BFE will support all Category I circuits in
|
|||
|
the balanced mode. The BFE will also support all type Send-
|
|||
|
Receive mandatory circuits for synchronous primary channel
|
|||
|
operation (see Fig 5.1 in Specification 2). The RS-449 37-
|
|||
|
position connector with a GLENAIR, INC., (or equal) backshell
|
|||
|
will be used on the host interface.
|
|||
|
|
|||
|
The BFE will present a DCE interface to the host.
|
|||
|
|
|||
|
The BFE will operate at speeds from 1.2 to 64 kilobits per
|
|||
|
second. Only full duplex synchronous operation will be support-
|
|||
|
ed. Data timing will originate from the network DCE to the
|
|||
|
BLACKER Data Terminal Equipment (DTE), and then from the BLACKER
|
|||
|
DCE to the host. (Note: The signal names used below refer to the
|
|||
|
RS-449 names used in the following table.) RT signal will supply
|
|||
|
the data strobe for RD, ST will supply the data request for SD,
|
|||
|
and TT will supply the data acknowledge/data strobe for SD. The
|
|||
|
DTE must use the incoming ST signal to generate the data strobe
|
|||
|
signal, TT.
|
|||
|
|
|||
|
Interface signal electrical characteristics will be as defined by
|
|||
|
MIL-STD-188-114. The single deviation from this specification is
|
|||
|
the Open Circuit Balanced Voltage Driver Output, which is 8 volts
|
|||
|
+/- 2 volts, instead of 6 volts +/- 2 volts. Interface signal
|
|||
|
|
|||
|
|
|||
|
Page 2-1
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
functions, directions, and pin assignments will be as defined in
|
|||
|
RS-449.
|
|||
|
|
|||
|
LISTING OF SIGNALS SUPPORTED BY THE BFE RED-SIDE
|
|||
|
|
|||
|
PIN RS-449 ABBREVIATION DCE IS
|
|||
|
|
|||
|
1 SHIELD NO CONNECTION
|
|||
|
2 SI +5
|
|||
|
3 SPARE
|
|||
|
4 SD BALANCED RECEIVER
|
|||
|
5 ST BALANCED GENERATOR
|
|||
|
6 RD BALANCED GENERATOR
|
|||
|
7 RS BALANCED RECEIVER
|
|||
|
8 RT BALANCED GENERATOR
|
|||
|
9 CS BALANCED GENERATOR
|
|||
|
10 LL UNBALANCED RECEIVER
|
|||
|
11 DM BALANCED GENERATOR
|
|||
|
12 TR BALANCED RECEIVER
|
|||
|
13 RR BALANCED GENERATOR
|
|||
|
14 RL IB-
|
|||
|
15 IC -5
|
|||
|
16 SF/SR IB+
|
|||
|
17 TT BALANCED RECEIVER
|
|||
|
18 TM UNBALANCED GENERATOR
|
|||
|
19 SG CIRCUIT GROUND
|
|||
|
20 RC DCE CIRCUIT GROUND
|
|||
|
21 SPARE
|
|||
|
22 SD ( see pin 4 )
|
|||
|
23 ST ( see pin 5 )
|
|||
|
24 RD ( see pin 6 )
|
|||
|
25 RS ( see pin 7 )
|
|||
|
26 RT ( see pin 8 )
|
|||
|
27 CS ( see pin 9 )
|
|||
|
28 IS IB+
|
|||
|
29 DM ( see pin 11 )
|
|||
|
30 TR ( see pin 12 )
|
|||
|
31 RR ( see pin 13 )
|
|||
|
32 SS IB-
|
|||
|
33 SQ +5
|
|||
|
34 NS IB-
|
|||
|
35 TT ( see pin 17 )
|
|||
|
36 SB -5
|
|||
|
37 SC DTE CIRCUIT GROUND
|
|||
|
|
|||
|
|
|||
|
ABBREVIATIONS OTHER THAN RS-449 SIGNAL NAMES
|
|||
|
IB- PIN IS OPEN, INTERNAL BIAS OF MINUS FIVE VOLTS (OPTIONAL)
|
|||
|
IB+ PIN IS OPEN, INTERNAL BIAS OF FIVE VOLTS (OPTIONAL)
|
|||
|
|
|||
|
|
|||
|
Page 2-2
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
2.2 LINK LEVEL
|
|||
|
|
|||
|
The BFE will conform to the following Link Level specifications:
|
|||
|
|
|||
|
1. "DEFENSE DATA NETWORK X.25 HOST INTERFACE SPECIFICATION",
|
|||
|
DCA, DECEMBER 1983
|
|||
|
|
|||
|
2. "INTERFACE BETWEEN DATA TERMINAL EQUIPMENT (DTE) AND
|
|||
|
DATA CIRCUIT TERMINATION EQUIPMENT (DCE) FOR TERMINALS
|
|||
|
OPERATING IN THE PACKET MODE ON PUBLIC DATA NETWORKS",
|
|||
|
RECOMMENDATION X.25, CCITT, 1980
|
|||
|
|
|||
|
3. "WD2512 X.25 PACKET NETWORK INTERFACE (LAPB)", WESTERN
|
|||
|
DIGITAL CORP., SEPT. 1988 (PRELIMINARY),
|
|||
|
APRIL 1989 (EXPECTED FINAL PUBLICATION).
|
|||
|
|
|||
|
At level 2, the BFE will use the DDN X.25 High Level Data Link
|
|||
|
Control, Link Access Procedure - Balanced (HDLC-LAPB) interface
|
|||
|
protocol.
|
|||
|
|
|||
|
On the host/red side the BFE will be a DCE.
|
|||
|
|
|||
|
The HDLC-LAPB interface in the BFE will be implemented using the
|
|||
|
Western Digital WD2512 Packet Network Interface Chip. This chip
|
|||
|
handles bit oriented, full duplex serial data communications on
|
|||
|
its Level 1/Level 2 interface side. The computer interface side
|
|||
|
uses direct memory access.
|
|||
|
|
|||
|
The "Transparent Modes" of the WD2512 chip, as described in
|
|||
|
specification three above, will not be used.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
2.3 PACKET LEVEL
|
|||
|
|
|||
|
2.3.1 The BFE will conform to the following Packet Level
|
|||
|
specifications. Restrictions and extensions are described below.
|
|||
|
(Note: All page and paragraph references refer to the DDN
|
|||
|
specification as number one below. Paragraph references begin
|
|||
|
with the letter 'D').
|
|||
|
|
|||
|
1. "DEFENSE DATA NETWORK X.25 HOST INTERFACE SPECIFICATION",
|
|||
|
DCA, DECEMBER 1983
|
|||
|
|
|||
|
2. "INTERFACE BETWEEN DATA TERMINAL EQUIPMENT (DTE) AND
|
|||
|
DATA CIRCUIT TERMINATING EQUIPMENT (DCE) FOR TERMINALS
|
|||
|
OPERATING IN THE PACKET MODE ON PUBLIC DATA NETWORKS",
|
|||
|
RECOMMENDATION X.25, CCITT, 1980
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Page 2-3
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
3. "INTERFACE BETWEEN DATA TERMINAL EQUIPMENT (DTE) AND
|
|||
|
DATA CIRCUIT TERMINATING EQUIPMENT (DCE) FOR OPERATIONS
|
|||
|
WITH PACKET-SWITCHED DATA COMMUNICATIONS NETWORKS",
|
|||
|
FED-STD 1041; FIPS PUB 100, 6 JULY 1983
|
|||
|
|
|||
|
2.3.2 Standard Service Restriction: Only DDN "Standard Service"
|
|||
|
X.25 will be offered on the host interface. No provisions for
|
|||
|
"Basic Service" will be made. Any call requests from the host
|
|||
|
indicating "Basic Service" will be rejected. (pg. 3)
|
|||
|
|
|||
|
2.3.3 Physical Address Restriction: Only physical addressing
|
|||
|
will be supported. All BFE ports will be assigned a physical
|
|||
|
address by the Defense Communications Agency. The address will
|
|||
|
conform to the format defined in D2.1.1.1 with the following
|
|||
|
constraints. All addresses will be 12 binary coded decimal (BCD)
|
|||
|
digits. Sub-addresses will not be supported. The 'F' flag will
|
|||
|
be set to zero. Requests for Logical Addressing facilities will
|
|||
|
result in a CLEAR INDICATION with an appropriate diagnostic code
|
|||
|
(146) being sent to the host. Early serial number BFEs may
|
|||
|
return an Invalid Called Address (68) or Invalid Calling Address
|
|||
|
(69) diagnostic code. (pg. 6)
|
|||
|
|
|||
|
2.3.4 Standard Service Restriction: In D2.1.2.1 for the Type of
|
|||
|
Service Facility on a CALL REQUEST, DDN "Standard Service" must
|
|||
|
always be selected. Failure to specify DDN "Standard Service"
|
|||
|
will result in a CLEAR INDICATION packet with a diagnostic code
|
|||
|
of (155) being sent to the host. (pg. 8)
|
|||
|
|
|||
|
2.3.5 Call User Data Restriction: In the Protocol Identifi-
|
|||
|
cation Field of a CALL REQUEST packet, as defined in D2.1.3, a
|
|||
|
DTE must indicate the use of the DoD Internet Protocol (IP). The
|
|||
|
value defined for IP (11001100 binary, CC hex) must be the first
|
|||
|
and only byte present in the Call User Data Field of the CALL
|
|||
|
REQUEST Packet. A Call User Data field that is not exactly one
|
|||
|
byte long will result in a CLEAR INDICATION with a diagnostic of
|
|||
|
either a packet too short (38) or packet too long (39). Selection
|
|||
|
of a different value will result in a CLEAR INDICATION packet
|
|||
|
with a diagnostic code of (156) being sent to the host. (pg. 10)
|
|||
|
|
|||
|
2.3.6 Packet Sizes Supported: A maximum packet sizes of 128,
|
|||
|
256, 512, or 1024 octets will be supported by the BFE. A maximum
|
|||
|
packet size of 1024 octets is required for hosts accredited to
|
|||
|
operate at multiple security levels. A maximum packet size of
|
|||
|
1024 octets is strongly recommended for all hosts, in order to
|
|||
|
allow an IP datagram to fit within a single packet. IP Datagram
|
|||
|
Size limitation is discussed in section 2.4.4 of this document.
|
|||
|
(pg. 11)
|
|||
|
|
|||
|
2.3.7 Packet Size Limitation: The maximum permissible number of
|
|||
|
data bits in a complete packet sequence must be no more than 896
|
|||
|
|
|||
|
Page 2-4
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
bytes (7168 bits). An attempt to send more than 896 bytes will
|
|||
|
result in a CLEAR INDICATION with an appropriate diagnostic code
|
|||
|
(39) being sent to the host. (pg. 11)
|
|||
|
|
|||
|
2.3.8 D and Q Bit Restriction: The D-bit and Q-bit have no
|
|||
|
significance to the BFE and are not passed to the destination.
|
|||
|
These should be set to zero by the host. (pg. A6)
|
|||
|
|
|||
|
2.3.9 Logical Addressing: There is no support for logical
|
|||
|
addressing. Requests for logical addressing facilities will
|
|||
|
receive a CLEAR INDICATION packet with an appropriate diagnostic
|
|||
|
code (146) being sent to the host. Early serial number BFEs may
|
|||
|
return an Invalid Called Address (67) or Invalid Calling Address
|
|||
|
(68) diagnostic code. (pg. A7)
|
|||
|
|
|||
|
2.3.10 Derivation of X.25 addresses in BLACKER: (pg. A9)
|
|||
|
|
|||
|
For devices directly connected to a BLACKER Front End, the IP
|
|||
|
address is a 32-bit quantity that consists of two parts, the
|
|||
|
first part defining a network, and the second being network
|
|||
|
specific. The DDN Red Virtual Network (DDN-RVN) will be a class
|
|||
|
A network, having a network identifier field eight bits wide, and
|
|||
|
a network specific portion 24 bits wide. The network number for
|
|||
|
the DDN-RVN will be 21. The 24-bit network specific part will be
|
|||
|
defined as follows. The first bit is zero. The next three bits
|
|||
|
are a port number of the BFE. The following ten bits are the
|
|||
|
domain number of the BFE, and the last ten bits are the BFE's
|
|||
|
number within its domain. This is shown graphically as:
|
|||
|
|
|||
|
IP 0 1 2
|
|||
|
ADDRESS 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| NETWORK |0|PORT | DOMAIN ID | BFE ID |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
The port field specifies a routing for the BFE. It may take on
|
|||
|
values between zero and seven. The currently defined values are:
|
|||
|
0 for the computer attached to the host port, 1 for the internal
|
|||
|
Access Control Module, and 2 for the internal Internet Control
|
|||
|
Message Protocol (ICMP) Server. The domain ID and BFE ID fields
|
|||
|
may take on the values 000 to 999, inclusive.
|
|||
|
At the X.25 level, the DDN-RVN is an X.25 network supporting the
|
|||
|
version of DDN "Standard Service" described in this section. For
|
|||
|
devices directly connected to the DDN-RVN, the X.25 address
|
|||
|
consists of 12 BCD digits in the form ZZZZ F DDDDDDD. (See
|
|||
|
D2.1.1.1.) The sub-address feature, defined in D2.1.1.1, is
|
|||
|
never used. For the DDN-RVN, ZZZZ is a value to be decided by
|
|||
|
the administration. It will initially be set to 0000. F will be
|
|||
|
zero to indicate physical addressing. DDDDDDD is directly mapped
|
|||
|
from the network specific portion of the IP address, where the
|
|||
|
|
|||
|
Page 2-5
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
first digit is the port ID, the next three digits are the domain
|
|||
|
ID, and the last three digits are the intra-domain BFE ID. The
|
|||
|
mapping is a value conversion from the binary representation to
|
|||
|
the BCD representation. This is shown graphically as:
|
|||
|
|
|||
|
0 1 2 2
|
|||
|
0 0 0 3
|
|||
|
IP: BBBBBBBBBBBBBBBBBBBBBBBB (bits)
|
|||
|
|\ /\ /\ /
|
|||
|
x | -------- --------
|
|||
|
| | |
|
|||
|
X.25: 0000 0 D DDD DDD (BCD digits)
|
|||
|
|
|||
|
|
|||
|
For example, if your host was host number 45 in domain 10, and
|
|||
|
you wish to talk to the internal ICMP echo port, you would
|
|||
|
address your message to network 21, domain 10, host 45, port 2.
|
|||
|
In graphic form this IP address is:
|
|||
|
|
|||
|
0 1 2 3
|
|||
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|0 0 0 1 0 1 0 1|0|0 1 0|0 0 0 0 0 0 1 0 1 0|0 0 0 0 1 0 1 1 0 1|
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| 21 | | 2 | 10 | 45 |
|
|||
|
|
|||
|
The X.25 address for this port would be: 0000 0 2010045.
|
|||
|
|
|||
|
2.3.11 Interrupt Restriction: INTERRUPT and INTERRUPT
|
|||
|
CONFIRMATION packets are not supported.
|
|||
|
|
|||
|
2.3.12 Datagram Restriction: DATAGRAM service as it is defined
|
|||
|
in reference two above is not supported.
|
|||
|
|
|||
|
2.3.13 Permanent Virtual Circuit Restriction: There will be no
|
|||
|
support for PERMANENT VIRTUAL CIRCUITS. All calls will need to
|
|||
|
be established via CALL REQUEST Packets.
|
|||
|
|
|||
|
2.3.14 X.25 Facilities
|
|||
|
|
|||
|
The following facilities described in reference two above WILL BE
|
|||
|
supported by the BFE:
|
|||
|
|
|||
|
1980 CCITT paragraph
|
|||
|
Nonstandard default window size 7.1.2
|
|||
|
Nonstandard default packet size 7.2.1
|
|||
|
Flow control parameter negotiation 7.2.2
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Page 2-6
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
The following facilities described in reference two above WILL
|
|||
|
NOT BE supported by the BFE:
|
|||
|
|
|||
|
1980 CCITT paragraph
|
|||
|
Extended packet sequence numbering 7.1.1
|
|||
|
Default Throughput Class Assignment 7.1.3
|
|||
|
Packet Retransmission 7.1.4
|
|||
|
Incoming Calls Barred 7.1.5
|
|||
|
Outgoing Called Barred 7.1.6
|
|||
|
One-way logical channels outgoing 7.1.7
|
|||
|
One-way logical channels incoming 7.1.8
|
|||
|
Closed user group (all varieties) 7.1.9-7.1.15
|
|||
|
Reverse charging 7.1.16
|
|||
|
Reverse charging acceptance 7.1.17
|
|||
|
RPOA selection 7.1.18
|
|||
|
Throughput class negotiation 7.2.3
|
|||
|
Fast select 7.2.4
|
|||
|
Fast select acceptance 7.2.5
|
|||
|
D-bit modification 7.2.6
|
|||
|
Datagram facilities (all varieties) 7.3
|
|||
|
|
|||
|
2.3.14.1 Packet and Window Sizes: For selection of Flow Control
|
|||
|
Parameters the BFE will default to a packet size of 128 octets
|
|||
|
and a window size of 2 packets. These default parameters may be
|
|||
|
changed if approved by the Defense Communications Agency. When
|
|||
|
requesting a BIC, a host administrator may specify non-standard
|
|||
|
defaults for packet sizes between 128 and 1024 octets, and for a
|
|||
|
window size of between 2 and 7 packets. The host administrator
|
|||
|
must also specify whether or not the BFE should negotiate these
|
|||
|
values on a call by call basis. If the host administrator
|
|||
|
chooses not to negotiate, the BFE will use the values specified
|
|||
|
by the host administrator for all calls, incoming and outgoing.
|
|||
|
If negotiation is selected, the BFE will offer a packet size of
|
|||
|
1024 and a window size of 7 for incoming calls, and the host may
|
|||
|
then respond with a smaller size if desired.
|
|||
|
|
|||
|
|
|||
|
2.3.14.2 Emergency Mode Addressing: One new facility code has
|
|||
|
been defined for use with BLACKER. It is called the Emergency
|
|||
|
Mode Addressing Facility, and is defined in section 2.3.17.3.
|
|||
|
|
|||
|
|
|||
|
2.3.15 Precedence: The BFE does not reallocate resources based
|
|||
|
on the precedence facility supplied in a call request. It does
|
|||
|
carry the precedence of a packet across the BFE to the call
|
|||
|
request on the opposite interface. If the host does not supply
|
|||
|
precedence on a CALL REQUEST packet, the BFE will assume that
|
|||
|
precedence zero is requested, and send the CALL REQUEST out to
|
|||
|
the network with precedence zero. This allows the host or
|
|||
|
network to continue to act upon the precedence of a call.
|
|||
|
|
|||
|
Page 2-7
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
2.3.16 Diagnostics Codes
|
|||
|
|
|||
|
2.3.16.1 The BFE passes certain diagnostic information back to
|
|||
|
the host to indicate status information on the communication path
|
|||
|
and to provide security related information. Diagnostic informa-
|
|||
|
tion is provided when the BFE becomes aware of a reportable
|
|||
|
event. Two examples of such reportable events are a notice that
|
|||
|
the BFE's network interface has come up, and that the BFE has
|
|||
|
lost contact with its Access Control Center. However, there is
|
|||
|
no guarantee that the BFE will be able to detect, or report,
|
|||
|
anomalous situations that occur in the underlying black network.
|
|||
|
|
|||
|
2.3.16.2 Diagnostic information is sent in the diagnostic field
|
|||
|
of an X.25 packet. For the X.25 diagnostic codes, the BFE will
|
|||
|
use the values defined in the CCITT Recommendation and in the DDN
|
|||
|
Specification with the following interpretations. DDN diagnostic
|
|||
|
code (128), PSN Unavailable, will indicate that the DDN packet
|
|||
|
switching node to which the BFE is connected is unavailable. DDN
|
|||
|
diagnostic code (137), Remote PSN dead, will indicate that the
|
|||
|
destination BFE is unreachable. See Appendix C for a full list
|
|||
|
of diagnostic codes that may be generated by BLACKER.
|
|||
|
|
|||
|
2.3.16.3 Diagnostic information related to Emergency Mode status
|
|||
|
(see section 2.3.17 below) will also be passed to the host at the
|
|||
|
X.25 level.
|
|||
|
|
|||
|
DIAGNOSTIC packets may be sent by the BFE with the following
|
|||
|
diagnostic codes:
|
|||
|
Code
|
|||
|
Entering Emergency Mode 224
|
|||
|
Leaving Emergency Mode 225
|
|||
|
Emergency Mode Window Open 226
|
|||
|
|
|||
|
|
|||
|
CLEAR INDICATION packets may be sent by the BFE with the follow-
|
|||
|
ing diagnostic codes:
|
|||
|
|
|||
|
|
|||
|
Code
|
|||
|
Call Failed--Address Translation Information Required 227
|
|||
|
Call Failed--Emergency Window Open, BFE not in Emergency Mode 228
|
|||
|
|
|||
|
|
|||
|
|
|||
|
2.3.17 EMERGENCY MODE
|
|||
|
|
|||
|
2.3.17.1 One aspect of the BLACKER System operation is the ability
|
|||
|
to communicate between BFEs in the absence of Access Control
|
|||
|
Centers (ACCs) and/or Key Distribution Centers (KDCs). This
|
|||
|
capability is referred to as Emergency Mode. The use of Emergency
|
|||
|
|
|||
|
Page 2-8
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
Mode may involve the host in some of the processing. When the
|
|||
|
conditions exist which could result in the BFE entering Emergency
|
|||
|
Mode, the BFEs action depends upon a start-up parameter contained
|
|||
|
in the BIC. This parameter specifies one of three possible courses
|
|||
|
of action. These actions are 1) remain in normal mode, i.e., not
|
|||
|
communicate with BFEs that are operating in Emergency Mode, 2)
|
|||
|
automatically enter Emergency Mode and so notify the host, or 3)
|
|||
|
notify the host that conditions exist which allow the BFE to enter
|
|||
|
Emergency Mode, but do not make the transition into Emergency Mode
|
|||
|
until directed by the host. Paragraphs 2.3.16.3 and 2.3.17.3
|
|||
|
provide further information on Emergency Mode diagnostic codes and
|
|||
|
addressing.
|
|||
|
|
|||
|
2.3.17.2 Additionally, since the address translation table
|
|||
|
contained in a BFE is maintained by the ACC, and in Emergency Mode
|
|||
|
the BFE may not be able to communicate with the ACC, a host may be
|
|||
|
limited as to what other hosts it can communicate with. In
|
|||
|
Emergency Mode, the BFE will continue to be able to communicate
|
|||
|
with all other hosts for which it has address translations,
|
|||
|
providing all other access controls are passed. The optional X.25
|
|||
|
facility defined in 2.3.17.3 allows a host to provide address
|
|||
|
translation information to its BFE, and must be used if a host
|
|||
|
requires flexibility while in Emergency Mode.
|
|||
|
|
|||
|
2.3.17.3 An additional optional user facility will be supported.
|
|||
|
This facility will allow the DTE to provide the DDN address (Black
|
|||
|
Internet Address) of the destination BFE for the address specified
|
|||
|
in the CALL REQUEST. This facility will be accepted only when
|
|||
|
Emergency Mode is enabled. The format is:
|
|||
|
|
|||
|
|
|||
|
0 1 2 3
|
|||
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|1 1 0 0 0 0 0 1|0 0 0 0 0 1 0 0| 32 bit Black |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| Internet Address |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
The first byte in the facility is the identification code, 193 for
|
|||
|
Black Internet Address. The second byte contains the length of the
|
|||
|
following parameter value field. It must always contain the value
|
|||
|
four. The remaining bytes contain the Black IP Address of the
|
|||
|
destination host for this call. This address will be stored with
|
|||
|
bits 0-7 in octet 3, bits 8-15 in octet 4, bits 16-23 in octet 5
|
|||
|
and bits 24-31 in octet 6. Bit 0 will be the leftmost bit of octet
|
|||
|
3, etc. A supplied address of all zeros is used to tell the BFE
|
|||
|
that it should enter Emergency Mode and is sent in response to the
|
|||
|
BFE message advertising the opening of the Emergency Mode Window
|
|||
|
(2.3.16.3). If it is necessary for the host to provide the enter
|
|||
|
|
|||
|
Page 2-9
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
Emergency Mode command along with address translation information,
|
|||
|
this facility must appear twice in the CALL REQUEST packet, with
|
|||
|
the enter Emergency Mode command appearing first.
|
|||
|
|
|||
|
2.3.17.4 When a host administrator has requested that his BFE
|
|||
|
never enter Emergency Mode, the host is not notified when the
|
|||
|
Emergency Mode window opens or closes. A host whose administrator
|
|||
|
has requested that his BFE always enter Emergency Mode is notified
|
|||
|
via the diagnostic codes described in 2.3.16.3 when the BFE enters
|
|||
|
and exits emergency mode. If a host administrator has requested
|
|||
|
that his host participate in the BFE's decision to enter Emergency
|
|||
|
Mode, the BFE will send the Emergency Mode Window Open diagnostic
|
|||
|
to the host when the conditions for Emergency Mode exist. If the
|
|||
|
host desires the BFE to enter Emergency Mode, it responds by using
|
|||
|
the Emergency Mode Address Facility (2.3.17.3) with the address set
|
|||
|
to all zeros. If the host does not wish to enter Emergency Mode,
|
|||
|
no response is necessary. When the BFE restores contact with its
|
|||
|
administrative nodes, it will send the host a Leaving Emergency
|
|||
|
Mode diagnostic message.
|
|||
|
|
|||
|
2.3.18 Logical Channels: The BFE will support up to 128 simul-
|
|||
|
taneous open logical channels. A logical channel for the BFE is
|
|||
|
defined as the intersection of a source X.25 address, a destination
|
|||
|
X.25 address, and an X.25 precedence.
|
|||
|
|
|||
|
|
|||
|
2.4 INTERNET PROTOCOL FEATURES
|
|||
|
|
|||
|
2.4.1 In addition to the X.25 interface, the BFE requires the use
|
|||
|
of IP as defined in MIL STD 1777. The only restrictions on the use
|
|||
|
of IP are as follows:
|
|||
|
|
|||
|
2.4.2 The IP address is a 32-bit value consisting of a network
|
|||
|
identifier and a network specific host field. There are different
|
|||
|
formats for this address. The DDN Red Virtual Network (RVN) is a
|
|||
|
class A network (net number 21) with the following format (see also
|
|||
|
2.3.10):
|
|||
|
|
|||
|
0 1 2 3
|
|||
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
| NETWORK | HOST |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
2.4.3 The host connected to the BFE will provide the Red IP
|
|||
|
destination address for the actual destination of each datagram.
|
|||
|
The host will also supply the appropriate DDN-RVN X.25 address to
|
|||
|
the BFE. In most cases, the X.25 address supplied by the host will
|
|||
|
correspond to the actual destination red IP address, but in some
|
|||
|
cases (e.g., IP devices not directly connected to a BFE) may be an
|
|||
|
|
|||
|
Page 2-10
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
X.25 address corresponding to a red gateway which is the next hop
|
|||
|
to the actual red IP destination.
|
|||
|
|
|||
|
2.4.4 The maximum BLACKER IP datagram size is 896 eight-bit bytes
|
|||
|
(octets). As required by MIL-STD 1777 (Para 9.2.2.2), IP datagrams
|
|||
|
of more than 576 octets should only be sent if there is assurance
|
|||
|
that the destination is prepared to accept the larger datagram. An
|
|||
|
IP datagram must be sent as an X.25 complete packet sequence if the
|
|||
|
datagram does not fit within a single X.25 packet. A packet or
|
|||
|
complete packet sequence must contain exactly one IP datagram. If
|
|||
|
IP datagrams are sent in multiple X.25 packets, no more than 32
|
|||
|
incomplete datagrams (unfinished packet sequences) may be sent at
|
|||
|
one time. Only single level hosts are allowed to send datagrams as
|
|||
|
packet sequences. Hosts accredited to send datagrams at multiple
|
|||
|
security levels must send and receive datagrams in single packets.
|
|||
|
Any packet received from such a host with the 'more' bit set will
|
|||
|
result in the call being CLEARed.
|
|||
|
|
|||
|
2.4.5 All IP datagrams must contain a sensitivity label as defined
|
|||
|
by the Revised IP Security Option (IPSO) described in change 1 to
|
|||
|
MIL-STD 1777. This must be the first option on all IP datagrams.
|
|||
|
BLACKER is designed to make cryptographic distinctions on up to
|
|||
|
eight hierarchical levels and sixteen non-hierarchical categories.
|
|||
|
Appendix A provides the configuration to be used for the initial
|
|||
|
BLACKER deployment on DSNET I.
|
|||
|
|
|||
|
2.4.6 The BFE has a limited amount of space available to buffer
|
|||
|
datagrams. Datagrams for which authorizations already exist in the
|
|||
|
BFE, are subject to normal flow control procedures, and are not a
|
|||
|
problem. Outgoing datagrams that require new authorizations,
|
|||
|
however, must be buffered until the proper permissions (or denials)
|
|||
|
are received from the ACC. Up to five of these datagrams can be
|
|||
|
buffered by the BFE at any time. The receipt of additional
|
|||
|
outgoing datagrams requiring communication with the ACC will
|
|||
|
overflow available buffer space, and such datagrams will be
|
|||
|
discarded without notice. In order to minimize the likelihood of
|
|||
|
such an event, a host administrator should ensure that the keys for
|
|||
|
essential and high volume destinations are marked for preplacement
|
|||
|
at the time the BIC is ordered from the ACC administrator.
|
|||
|
|
|||
|
2.4.7 The BLACKER System can support dual or multiple homing of a
|
|||
|
host. The host must have one BFE for each port that is to be
|
|||
|
connected to the network. Each BFE connected to this host must
|
|||
|
have a different network and internet addresses. It is the
|
|||
|
responsibility of two hosts to select which BFE of a multi-homed
|
|||
|
host will be used for a connection between those hosts. (BLACKER
|
|||
|
ACCs and KDCs can not be set up to have multiple addresses.)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Page 2-11
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
2.5 INTERNET CONTROL PROTOCOL FEATURES
|
|||
|
|
|||
|
2.5.1 The BFE also makes use of ICMP messages to indicate certain
|
|||
|
information to the host.
|
|||
|
|
|||
|
2.5.2 The BFE will respond to ICMP ECHO REQUEST messages with ICMP
|
|||
|
ECHO REPLY messages.
|
|||
|
|
|||
|
2.5.3 The BFE passes diagnostic information back to the host to
|
|||
|
indicate status information on the communication path and to
|
|||
|
provide security related information. Diagnostic information is
|
|||
|
provided when the BFE becomes aware of a reportable event.
|
|||
|
However, there is no guarantee that the BFE will be able to detect,
|
|||
|
or report, all anomalous situations.
|
|||
|
|
|||
|
2.5.4 Diagnostic information will be passed in ICMP messages. A
|
|||
|
DESTINATION UNREACHABLE (type 3) message will be sent when a
|
|||
|
Request Denied message is received by the BFE from the ACC. Code
|
|||
|
1, Host Unreachable, will be sent if the Request Denied message
|
|||
|
indicates that the destination BFE is down. Code 10, Communication
|
|||
|
with Destination Host Administratively Prohibited, will be sent if
|
|||
|
the Request Denied message indicates that access is denied.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Page 2-12
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
3. BLACK-SIDE NETWORK INTERFACE
|
|||
|
|
|||
|
3.0.1 This section describes the DDN interface of all BLACKER
|
|||
|
equipment connecting to the DDN. Host implementors need not
|
|||
|
concern themselves with this section, except as background, or to
|
|||
|
assist in ordering the proper type of interface line from DCA.
|
|||
|
|
|||
|
3.1 PHYSICAL LEVEL
|
|||
|
|
|||
|
The BFE will confirm to the following specifications:
|
|||
|
|
|||
|
1. "DEFENSE DATA NETWORK X.25 HOST INTERFACE SPECIFICATION",
|
|||
|
DCA, DECEMBER 1983
|
|||
|
|
|||
|
2. EIA STANDARD RS-449, NOVEMBER 1977
|
|||
|
|
|||
|
3. MILITARY STANDARD 188-114, MARCH 1976
|
|||
|
|
|||
|
The BFE will support the signals as listed in Table B-2 of the DDN
|
|||
|
X.25 Specification. No optional signals will be supported on the
|
|||
|
network side.
|
|||
|
|
|||
|
In RS-449 terms, the BFE will support all Category I circuits in
|
|||
|
the balanced mode. The BFE will also support all type Send-Receive
|
|||
|
mandatory circuits for synchronous primary channel operation (see
|
|||
|
Fig 5.1 in Specification 2). The RS-449 37-position connector with
|
|||
|
a GLENAIR, INC., (or equal) backshell will be used on the network
|
|||
|
interface.
|
|||
|
|
|||
|
The BFE will present a DTE interface to the network.
|
|||
|
|
|||
|
The BFE will operate at speeds from 1.2 to 64 kilobits per second.
|
|||
|
Only full duplex synchronous operation will be supported. Data
|
|||
|
timing will originate at the DCE. (Note: The signal names used
|
|||
|
below refer to the RS-449 names used in the following table.) RT
|
|||
|
signal will supply the data strobe for RD, ST will supply the data
|
|||
|
request for SD, and TT will supply the data acknowledge/data strobe
|
|||
|
for SD. This implies that the DCE will control data transfer rates
|
|||
|
via RT and ST, and the DTE will use ST to generate the data strobe
|
|||
|
signal, TT. The network DCE supplies timing to the BLACKER DTE and
|
|||
|
the BLACKER DCE supplies timing to the host DTE.
|
|||
|
|
|||
|
Interface signal electrical characteristics will be as defined by
|
|||
|
MIL-STD-188-114. The single deviation from this specification is
|
|||
|
the Open Circuit Balanced Voltage Driver Output, which is 8 volts
|
|||
|
+/- 2 volts, instead of 6 volts +/- 2 volts. Interface signal
|
|||
|
functions, directions, and pin assignments will be as defined in
|
|||
|
RS-449.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Page 3-1
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
LISTING OF SIGNALS SUPPORTED BY THE BFE BLACK-SIDE
|
|||
|
|
|||
|
PIN RS-449 ABBREVIATION DTE IS
|
|||
|
|
|||
|
1 SHIELD NO CONNECTION
|
|||
|
2 SI IB+
|
|||
|
3 SPARE
|
|||
|
4 SD BALANCED GENERATOR
|
|||
|
5 ST BALANCED RECEIVER
|
|||
|
6 RD BALANCED RECEIVER
|
|||
|
7 RS BALANCED GENERATOR
|
|||
|
8 RT BALANCED RECEIVER
|
|||
|
9 CS BALANCED RECEIVER
|
|||
|
10 LL -5
|
|||
|
11 DM BALANCED RECEIVER
|
|||
|
12 TR BALANCED GENERATOR
|
|||
|
13 RR BALANCED RECEIVER
|
|||
|
14 RL -5
|
|||
|
15 IC IB-
|
|||
|
16 SF/SR +5
|
|||
|
17 TT BALANCED GENERATOR
|
|||
|
18 TM IB-
|
|||
|
19 SG CIRCUIT GROUND
|
|||
|
20 RC DCE CIRCUIT GROUND
|
|||
|
21 SPARE
|
|||
|
22 SD ( see pin 4 )
|
|||
|
23 ST ( see pin 5 )
|
|||
|
24 RD ( see pin 6 )
|
|||
|
25 RS ( see pin 7 )
|
|||
|
26 RT ( see pin 8 )
|
|||
|
27 CS ( see pin 9 )
|
|||
|
28 IS +5
|
|||
|
29 DM ( see pin 11 )
|
|||
|
30 TR ( see pin 12 )
|
|||
|
31 RR ( see pin 13 )
|
|||
|
32 SS -5
|
|||
|
33 SQ IB+
|
|||
|
34 NS -5
|
|||
|
35 TT ( see pin 17 )
|
|||
|
36 SB IB-
|
|||
|
37 SC DTE CIRCUIT GROUND
|
|||
|
|
|||
|
ABBREVIATIONS OTHER THAN RS-449 SIGNAL NAMES
|
|||
|
IB- PIN IS OPEN, INTERNAL BIAS OF MINUS FIVE VOLTS (OPTIONAL)
|
|||
|
IB+ PIN IS OPEN, INTERNAL BIAS OF FIVE VOLTS (OPTIONAL)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Page 3-2
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
3.2 LINK LEVEL
|
|||
|
|
|||
|
The BFE will conform to the following Link Level specifications:
|
|||
|
|
|||
|
1. "DEFENSE DATA NETWORK X.25 HOST INTERFACE SPECIFICATION",
|
|||
|
DCA, DECEMBER 1983
|
|||
|
|
|||
|
2. "INTERFACE BETWEEN DATA TERMINAL EQUIPMENT (DTE) AND
|
|||
|
DATA CIRCUIT TERMINATION EQUIPMENT (DCE) FOR TERMINALS
|
|||
|
OPERATING IN THE PACKET MODE ON PUBLIC DATA NETWORKS",
|
|||
|
RECOMMENDATION X.25, CCITT, 1980
|
|||
|
|
|||
|
3. "WD2512 X.25 PACKET NETWORK INTERFACE (LAPB)", WESTERN
|
|||
|
DIGITAL CORP., SEPTEMBER 1988 (PRELIMINARY),
|
|||
|
APRIL 1989 (EXPECTED FINAL DATE).
|
|||
|
|
|||
|
At level 2, the BFE will use the DDN X.25 High Level Data Link
|
|||
|
Control, Link Access Procedure - Balanced (HDLC-LAPB) interface
|
|||
|
protocol.
|
|||
|
|
|||
|
On the PSN/black side the BFE will be a DTE.
|
|||
|
|
|||
|
The HDLC-LAPB interface in the BFE will be implemented using the
|
|||
|
Western Digital WD2512 Packet Network Interface Chip. This chip
|
|||
|
handles bit oriented, full duplex serial data communications on its
|
|||
|
Level 1/Level 2 interface side. The computer interface side uses
|
|||
|
direct memory access.
|
|||
|
|
|||
|
The "Transparent Modes" of the WD2512 chip, as described in
|
|||
|
specification three above, will not be used.
|
|||
|
|
|||
|
|
|||
|
3.3 PACKET LEVEL
|
|||
|
|
|||
|
3.3.1 The BFE network interface to DDN conforms to the DDN
|
|||
|
interface specification dated December 1983.
|
|||
|
|
|||
|
3.3.2 Type of Service: The BFE interface offers a DDN Standard
|
|||
|
Service interface to the network. It may operate with a DDN Basic
|
|||
|
Service interface on the network side only.
|
|||
|
|
|||
|
3.3.3 Packet Size: The BFE is designed to operate with a maximum
|
|||
|
packet size of 1024 bytes but will also operate at 128, 256, or 512
|
|||
|
bytes. Operating with a maximum packet size of less than 1024 bytes
|
|||
|
may significantly degrade performance.
|
|||
|
|
|||
|
3.3.4 The BFE does NOT make use of INTERRUPT service and does not
|
|||
|
set the D-bit or Q-bit.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Page 3-3
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
3.3.5 Call User Data Restriction: For the protocol identification
|
|||
|
information in the X.25 call, the BFE will use CC hex (11001100
|
|||
|
binary) to indicate that IP is the next higher level protocol.
|
|||
|
When IP is not used on the network interface, the value C5 hex
|
|||
|
(11000101 binary) is used to indicate that the next layer of
|
|||
|
protocol is the encryption layer. IP is only used on the black
|
|||
|
side of the BFE when the connection will have to pass through a
|
|||
|
gateway on the black network.
|
|||
|
|
|||
|
3.3.6 Call Request: The BFE supports INCOMING CALL and CALL
|
|||
|
REQUEST packets that specify either a logical or physical address.
|
|||
|
However, it has no capability to issue declarative CALL REQUEST
|
|||
|
packets which add or delete logical names.
|
|||
|
|
|||
|
|
|||
|
3.4 INTERNET PROTOCOL (IP) FEATURES
|
|||
|
|
|||
|
3.4.1 The BFE will send IP datagrams of up to 1024 bytes.
|
|||
|
|
|||
|
3.4.2 IP Header: The BFE may include or omit an IP header on the
|
|||
|
network side when sending various types of datagrams. These
|
|||
|
datagrams will be marked in accordance with section 3.3.5. The BFE
|
|||
|
will use an IP header when sending datagrams through a gateway on
|
|||
|
the black network, or when sending traffic that is not encrypted
|
|||
|
(e.g., ICMP ECHO REPLIES to a black network host).
|
|||
|
|
|||
|
3.4.3 IP Address: The BFE takes the DDN-RVN address (2.3.10) and
|
|||
|
generates the Black IP address via a table lookup. This table in
|
|||
|
the BFE contains address translations for the BFE's domain, and
|
|||
|
some interdomain BFE address translation information. This table
|
|||
|
is normally maintained by the Access Control Center (ACC) for the
|
|||
|
BFE. However, information for this table may also be provided by
|
|||
|
the host when the BFE is in Emergency mode (2.3.17.3).
|
|||
|
|
|||
|
3.4.4 X.25 Address: The Black X.25 network address is generated
|
|||
|
from the Black IP address via the algorithm defined for DDN. The
|
|||
|
BFE will support the full DDN address translation algorithm for
|
|||
|
both physical and logical addresses.
|
|||
|
|
|||
|
|
|||
|
3.5 INTERNET CONTROL MESSAGE PROTOCOL (ICMP) FEATURES
|
|||
|
|
|||
|
3.5.1 The BFE will be capable of receiving all ICMP message types
|
|||
|
and of generating at least ECHO REPLY, PARAMETER PROBLEM, and
|
|||
|
DESTINATION UNREACHABLE messages.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Page 3-4
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
A. Initial DDN Sensitivity Labels
|
|||
|
|
|||
|
Hierarchical Levels
|
|||
|
|
|||
|
Value Code Name
|
|||
|
7 0000 0001 (undefined)
|
|||
|
6 0011 1101 TOP SECRET
|
|||
|
5 0101 1010 SECRET
|
|||
|
4 1001 0110 CONFIDENTIAL
|
|||
|
3 0110 0110 (undefined)
|
|||
|
2 1100 1100 (undefined)
|
|||
|
1 1010 1011 Unclassified
|
|||
|
0 1111 0001 (undefined)
|
|||
|
|
|||
|
Non-Hierarchical Compartments
|
|||
|
|
|||
|
Value Option Type *Bit number Name
|
|||
|
0 BASIC 0 GENSER
|
|||
|
1 BASIC 1 SIOP-ESI
|
|||
|
2 BASIC 2 SCI
|
|||
|
3 BASIC 3 NSA
|
|||
|
4 - 15 (undefined) (undefined) (undefined)
|
|||
|
|
|||
|
*numbered from left to right
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Page A-1
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
B. REFERENCES
|
|||
|
|
|||
|
1. "DEFENSE DATA NETWORK X.25 HOST INTERFACE SPECIFICATION",
|
|||
|
DCA, DECEMBER 1983, available from the Defense Technical
|
|||
|
Information Center, Cameron Station, Alexandria Va 22314, (202)
|
|||
|
274-7633, order number AD-A137 427.
|
|||
|
|
|||
|
2. EIA STANDARD RS-449, NOVEMBER 1977, available from The
|
|||
|
Electronic Industries Association, 2001 Eye Street, N.W.,
|
|||
|
Washington, DC 20006.
|
|||
|
|
|||
|
3. MILITARY STANDARD 188-114, MARCH 1976, available from the
|
|||
|
Naval Publications and Forms Center, 5801 Tabor Avenue,
|
|||
|
Philadelphia, PA 19120.
|
|||
|
|
|||
|
4. "INTERFACE BETWEEN DATA TERMINAL EQUIPMENT (DTE) AND DATA
|
|||
|
CIRCUIT TERMINATING EQUIPMENT (DCE) FOR TERMINALS OPERATING IN THE
|
|||
|
PACKET MODE ON PUBLIC DATA NETWORKS", RECOMMENDATION X.25, CCITT,
|
|||
|
1980, available from the National Technical Information Center,
|
|||
|
U.S.Department of Commerce, Springfield, VA 22161, order number
|
|||
|
PB82-187766.
|
|||
|
|
|||
|
5. "INTERFACE BETWEEN DATA TERMINAL EQUIPMENT (DTE) AND DATA
|
|||
|
CIRCUIT TERMINATING EQUIPMENT (DCE) FOR OPERATIONS WITH PACKET-
|
|||
|
SWITCHED DATA COMMUNICATION NETWORKS", FED-STD 1041; FIPS PUB 100,
|
|||
|
6 JULY 1983, also available from the National Technical Information
|
|||
|
Center, U.S.Department of Commerce, Springfield, VA 22161.
|
|||
|
|
|||
|
6. "WD2512 X.25 PACKET NETWORK INTERFACE (LAPB)", WESTERN
|
|||
|
DIGITAL CORP., SEPT. 1988 (PRELIMINARY), APRIL 1989 (FINAL),
|
|||
|
available from Western Digital, 2445 McCabe Way, Irvine CA 92714,
|
|||
|
(714) 474-2033.
|
|||
|
|
|||
|
7. "REVISED INTERNET PROTOCOL SECURITY OPTION", Department of
|
|||
|
Defense, to be issued, (change 1 to MIL STD Internet Protocol / MIL
|
|||
|
STD 1777, 12 Aug 1983), available from the Naval Publications and
|
|||
|
Forms Center, 5801 Tabor Avenue, Philadelphia, PA 19120.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Page B-1
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
C. BLACKER Generated Diagnostic Codes
|
|||
|
|
|||
|
Diagnostic Code Value
|
|||
|
|
|||
|
No additional information 0
|
|||
|
Invalid P(S) 1
|
|||
|
Invalid P(R) 2
|
|||
|
|
|||
|
Packet type invalid -
|
|||
|
for state r1 17
|
|||
|
for state r3 19
|
|||
|
for state p1 20
|
|||
|
for state p3 22
|
|||
|
for state p7 26
|
|||
|
for state d1 27
|
|||
|
for state d3 29
|
|||
|
|
|||
|
Packet not allowed 32
|
|||
|
Packet too short 38
|
|||
|
Packet too long 39
|
|||
|
Restart with nonzero LCGN and LCN 41
|
|||
|
|
|||
|
Timer expired 48
|
|||
|
for incoming call 49
|
|||
|
for clear indication 50
|
|||
|
for reset indication 51
|
|||
|
for restart indication 52
|
|||
|
|
|||
|
Call set-up problem 64
|
|||
|
Facility code not allowed 65
|
|||
|
Facility parameter not allowed 66
|
|||
|
Invalid called address 67
|
|||
|
Invalid calling address 68
|
|||
|
Invalid facility length 69
|
|||
|
|
|||
|
Local PSN Unavailable 128
|
|||
|
Network side interface came up 130
|
|||
|
Remote BFE dead 131
|
|||
|
Local resources not available 133
|
|||
|
Remote resources not available 134
|
|||
|
Remote host (or red gateway) unavailable 136
|
|||
|
Remote PSN (or black gateway) unavailable 137
|
|||
|
Calling logical address not enabled 141
|
|||
|
Calling logical name incorrect for this DTE 142
|
|||
|
Called logical name not authorized 143
|
|||
|
Called logical name not enabled 144
|
|||
|
Called logical name has no DTEs 145
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Page C-1
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
March 21, 1989
|
|||
|
|
|||
|
Diagnostic Code Value
|
|||
|
|
|||
|
Logical addressing invalid for the Black network 146
|
|||
|
Standard Service not requested (see 2.3.4) 155
|
|||
|
Invalid protocol identification (see 2.3.5) 156
|
|||
|
Cleared due to higher precedence call 192
|
|||
|
Requested precedence too high 194
|
|||
|
Entering Emergency Mode (see 2.3.17) 224
|
|||
|
Leaving Emergency Mode (see 2.3.17) 225
|
|||
|
Emergency Mode Window Open (see 2.3.17) 226
|
|||
|
Address translation needed (see 2.3.17) 227
|
|||
|
Emergency Mode Window Open but not in
|
|||
|
Emergency Mode (see 2.3.17) 228
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Diagnostic Code 0 will be sent in:
|
|||
|
|
|||
|
- a CLEAR INDICATION when
|
|||
|
|
|||
|
- more than 32 calls have unfinished packet sequences.
|
|||
|
- a multilevel host uses the M bit.
|
|||
|
- BFE table resources are at full capacity.
|
|||
|
- a logical channel idle timer expires.
|
|||
|
- the host sends a non-zero CLEAR REQUEST code.
|
|||
|
|
|||
|
- a RESET INDICATION when
|
|||
|
|
|||
|
- a packet reassembly timer expires.
|
|||
|
- the host sends a non-zero RESET REQUEST code.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Page C-2
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|