NOT MEASUREMENT MILITARY STAND-

NOT MEASUREMENTSENSITIVE

NOTICE OFcHANGE

MIL-STD-2045-44500NOTICE 129 July 1994 .

MILITARY STAND-TACTICAL COM~I@TIONS PROTOCOL 2(TAC02)FOR THE NATIONAL IMAGERYTIUWSMISSION FORMAT ST~m

TO: ALL HOLDERS OF MIL-S~-2045-44500:

1. THE FOLLOWING PAGES OF MIL-STD-2045-44500HAVE BEEN REVISED AND SUPERSEDE THE PAGESLISTED :

SUPERSEDED PAGE DATE

29 July 1994

DATE

18 June 1994

NEW PAGE

ix ix

x RXPRINTEDWITHO~ CHANGE

18 June 1994x

REPRINTEDWITHOUT CHANGE13 18 June 1994 13

29 July 199414

29

18 June 1994

18 June 1994

14REPRINTED

WITHOUT CHANGE29

29 July 199430

37

18 June 1994

18 June 1994

30

37REPRINTED

WITHO~ CHANGE

29 July 199438

49

50

18 June 1994

18 June 1994

18 June 1994

38

49

50

29 July 1994

REPRINTEDWITHOUT CHANGE

REPRINTEDWITHOUT CHANGE

6318 June 199463

AREA DCPSAMSC N/AI)ISTRIB~ ION STATEMENT A Approved for public release; distributionis unlimited.

Downloaded from http://www.everyspec.com

NOTICE OF CHANGE

NEW PAGE DATE

64 18 June 1994

81 18 June 1994

82 18 June 1994

99 18 June 1994

100 18 June 1994

101 18 June 1994

102 18 June 1994

2. RETAIN THIS NOTICE AND INSERT

MIL-STD-2045-44500

SUPERSEDED PAGE DATE

64 29 July 1994

81 REPRINTEDWITHOUT CHANGE

82 29 July 1994


100 29 July 994


102 29 July 1994

BEFORE TABLE OF CONTENTS.

3. Holders of MIL-STD-2045-44500 will verify that page change

and additions indicated above have been entered.This notice

page will be retained as a check sheet.This Issuance, togeth

with appended pages, is a separate publication. Each notice isbe retained by stocking points until the military standard is

completely revised or canceled.

s

erto

Custodians:DISA: DC

Army : ScAir Force: 90Navy: OMDIA: D1NSA : NSUSMC: MCDLA : DH

PreparingActivity:

DISA

Other:Joint Staff/Architecture & IntegrationUSSPACECOM

Reviewing Activity:Army Sc Navy EC, CH, ND, TD, OM

Air Force 02, 13, 17, 29, 90USMC MC, CG

DLA DHDMA MPDIA DIDOT OSTOASD IQ, DO, MA, IR0DISC4 ACSTRXCOM PT (Project I)CPS-008)


MIL-STD-2M5-’$45OONOTICE 1

CONTENTS

PARAGRAPHEAQE

66.16.26.36.46.4.16.4.26.4.36,4.46.4.56.4.66.4.6.16.4.6.26.4.6.2.16.4.6.2.26.4.6.2.36.4,6.2.46.4.6.2.56.4.6.2.66.4.6.2.76.4.6.2.86.4.6.2.96.4.6.2.106.4.6.36.56.5.16.5.26.5.36.5.46.5.56.5.66.5.76.6

E!wRE

1.2.3.4.5.

71NOTES . . . . . . . . . . . . . . . . . . . ...” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~1

Example TAC02pukct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :., . . . . .TAC02NETBLT compaed~WC998 NETBLT . . . . . . . . . . . . . . . . . . . . . . . ~~SLIP drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Notes on FEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,5General notes on FED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,5Discussion ofFEC~pliqucs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Discussion of FEC-Imd FEC-ll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~~lnterprc~tion ofBERTresul~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76performance comiderations . . . . . . . . . . . - . . . .”....-.- ----- 79Selection of FEC coding options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79General disc~sion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,9Descriptions ofcirctits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7916 kbps UHF SITCOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792.4 kbps UHF SATCOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 kbps UHF SATCOMwith FEC applique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792.4 kbps UHF S.ATCOMwiti FEC applique . . . . . . . . . . . . . . . . . . . . . . . . . . 7980I-IFcircuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . goHFcirctits witihtidwme FEC... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80TRT-TAC . . . . ..-. -..-” “ ‘“-”’””’ 80Telephone circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . goTelephone circuit witiemorcon@ol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80DADA . . . . . . . . . . . . . . . . . . . . . ” . . . . . . ” . . .”.....’” ~~~~ 80Recommended modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...” 81Effectivi~ smmq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Effectivity l- FECIad Bit Emor Ratio Test (BERT) . . . . . . . . . . . . . . . . . . . . 81Effectivity 2- Fec al . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~~Effectivity 3- Hcder abbreviation and ciicnt<ontiolled flow . . . . . . . . . . . . . .Effectivity 4- Ptivs. pub...... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~~Effectivity 5- Mdticmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Effectivity 6- Medium Access Con@ol layer.. . . . . . . . . . . . . . . . . . . . . . . . . . 82

Effkctivi~ 8- Defense Information SystemS Network (DISN) . . . . . . . . . . . . . . . 82Subjed&rm (key word) tasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

The TAC02mcssage &mferrefcrence model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Possible ~sitioning oftic FECwitiin the da~liti layer . . . . . . . . . . . . . . . . . . . . . . . . 16Transmission orderofb~s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

17

Significant ofbi6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23TAc02NRTS com~tion cstibiis@ent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Supersedes page ix of MIL-STD-2045-44500 ix18Junc 1993


MIL-STD-2045-44500

cONTENTS

PARAGRApH

6.7.8.9.10.

11.12.13.14.15.16.17.18.19.20.21.22.

23.

TABLE

I11.

APPENDIX

.

I

I

11

Appendix AAppendix BAppendix C

rAC02 NRTS data transfer25 -,.. . . . . . . . . . . . . ‘“”

rAC02NRTS connation tcmination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2926

Zxample ofchccbumming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30$enderopen titediagm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SO~eceivcropcns~cdiagm... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34bnxiingbuffer~~tia~.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Receiving bufierstitediagrm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . q,Receiver successful closcstitediagm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Sender wccessful close State diag~ . . . . . . ~~~~~~~~~~ ~~~ ~~~~ 38Quit state dia~m ...,.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Abort state dia~m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . solntemet da~~am header... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~~Abbreviate hetier TAC02 packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63FEC-Iforrnat . . . . . . . . . . . . . . . . . . ~~ ;: 64Encoding a450bwp~ket ~ . . . .

BERTfiarnefomat.. . . . . .66. . . .. . . . . . . .

ExamplcTAC02 packet71. . .,.. . . .. . . . ...

BERvs. relative tioughput. . . . . . . . . . . . . . . . . . . . . . . . .. . 78

20Metarncssage component . . . . . . . . . . . . . . . . . . . . - 80Recommended notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Rcprintedwihout change


MIL-STD-2045-44500

4 GENERAL REQUIREMENTS

41 Oven’iel$ To exchange \ ITFS messages between systems, the participants must agree on themechanism and protocois to be used 10 support the exchange. in some cases, connectivity ~d transferprotocols already may exist; for instance, Defense Information Systems Network (DISN)-connected hostscan use File Transfer Protocol [FTp ) for moving standard format files. In other cases, connectivity isavailable, but common tram fe[ promcois are not, or the available protocols me intolerabley inefficient; forinstance, DISN protocols run \ en slos~ly over slow-turnaround half-duplex circuh, and cannot run at allover simplex circuits. TAC02 prm Ides efficient NITFS message transfer across point-to-point andpoint-to-muhipoint links (tacucaJ radio circuits) where neither DISN nor other current GOSIP protocolsare suitable

4.1. ] ADproach. TAC02 uses a Ia!’ered model, similar in philosophy to the ISO Open SystemsInterconnection Reference Model The TAC02 model is shown on figure 1; the components are describedin the following subparagraphs

Reprinted without change 13 18 .lune 1993


hill.-S’l”[l-2[145-4450(tNOTICE 1

-- ‘7’I—— ——— —— —

m---=-

U-JI—— ——— —— —

Header Abbrcwlat]on

———— ——

Application/Rescntaw “scam Layers

—— —— — ——

-n Laya

———— ——

Nemrk Layer

———— —— —

1Header Abbretitim Sublaya

—— —— —1—————————–

FEC I FEcSublayer

1 J——

—— —— —— ————

?

HDLC Framing SLIP _ ~bkyer

.

.

FIGURE 1. The TAC02 messwze transfer referen~ model.

4.1.2 NITFS reliable transfer server for TAC02 (TAC02 NRTS). The TAC02 NRTS controls the

commmicatiom semice to be used, exchmges the mess~e and associatd infomtion with i~ and acts asa session layer to allow resumption of intempted transtem.

4.1.3 NETBLT. NETwork BLock Transfer (NETBLT) shall provide the reliable, flow-controlledtranspofi level protocol designed to achieve high thro@put across a wide variety of networb. It allowsthe sending client (the NRTS) to break the message being sent into a series of Imff’em,and to pass thosebuffers to NETBLT as information or space availabfli~ permits. B~ers are broken into pack~ for.~~~rnission. The critical element for perfomce is multiple buffefig, so that new buffers can be sent

Supersedes pfl~C 14 of hllL-STD-2045-44500° 14


MIL-STD-2045-44500

4 GENERAL REQUIREMENTS

4 1 Overview To exchange \ JTFS messages between systems, the participants must agree on themechanism and protocols to be used to suppofi the exchange. h some cases, connectivity ~d transferprotocols already may exist, for instance. Defense hformahon Systems Network (DISN)-connected hostscan use File Transfer Protocol (FTp ) for moving standard format files. ln other cases, connectivity isavailable, but common transfer ptotocols are not or tie avtilable protocols are intolerably inefficient; forinstance, DISN protocols run \ co slo~~ly over slow-tumaroud half-duplex circuits, and cannot run at allover simplex circuits. TAC02 pro~ ides efficient NITFS message transfer across point-to-point andpoint-to-rnultipoint links (tact~cd radio circuits) where neither DISN nor other current GOSIP protocolsare suitabie

4.1.1 Approach TAC02 uses a layered model, similar in philosophy to the 1S0 Open Systemsinterconnection Reference Model The TAC02 model is shown on figure 1; the components are describedin the following subparagraphs

Reprinted without change 1.3


!MJ1,-S 11.)-204$-44s{1(1No”rlcE 1

————— ———— —— — —e Applicatim/

TAC02 NRTSPrtscntationl “Sessian Layem

———— —— —— —.—— —— —

NETBLT Transport by=

—— —— —— —— ———— —— —r

1P Network Layer

k———— —— ——— —— — —

?

Header Abbreviation

6

-1

Header Abbmviatia Sublaym

———— —— ———— —— — —

FEC FEC Subhym Data Link LflyCr

/—. —— ——

i J

———— — ——

HDLC Framing SLIP _ ~bhyer

—— —— — ———— —— ——

Physical Laym

FIGURE 1. The TAC02 mess~e transfer reference model.

4.1.2 NITFS reliable transfer sener for TAC02 (TAC02 NR.TS]. The TAC02 NRTS controls the

comrnuniatiom service to be used, exchang= the message and associatd information with i~ and acts asa session layer to allow resumption of inter’mpti transfen.

4.1.3 NETBLT. NE1’work BLock Transfer (NETBLT) shall provide the reliable, flow-controlled

transport level protoal designd to achieve high throughput across a wide variety of networks. It allowsthe sending client (the NRTS) to break the message being sent into a series of buffers, and to pass thoseb~ers to NETBLT as information or space availability permits. Buffers are broken into packets for.transmission. The critical element for performmce is multiple buffering, so that new buffers can be sent

Supersedes page 14 of MIL-STD-2045-4450[J” 14


MIL-STD-2045-44500

5.2.3.4 FIOWcontrol tmrameterr enecoliabon. The burst size and burst inter~ra.1also may bere-negotiated afier =ch buffer transmission to adj mt the transfer rate according to the performanceobsenwd from tmnsfernng the previous buffer. The receiving end shall send burst size and burst intervalvalues in its OK messages (described in 5.2.5.2.1). The sender shall compare these values with thevalues it can support. It then may modify either of the parameters, but only by making them morerestrictive. The modified parameters shall then be communicated to the receiver in DATA LDATA, orNULL-ACK packets.

5.2.3.5 Client-controlled flow. (Effectivity 3). A burst interval value of zero shall have a specialmeaning: internal flow control shall be turned off, so that only client ievel flOW control shw be in effect.In this case, the sending NETBLT shall transmit packets without regard for the rate control mechanism.When using client-controlled flow, the receiver shall use an alternative method for data timer estimation(see 5.2.5.2.4.3).

5.2.4 Checksumming. NETBLT shall use checksums to validate the contents of packets and packetheaders unless packet integrity is assured by the data link layer. The checksum value shall be the bitwisenegation of the ones-complement sum of the 16-bit words being checksummed. On twos-complementmachines. the ones-complement sum can be computed by means of an “end around camy”; that is. anyoverflows from the most significant bit are added into the least significant bits. See figure 8 for anexample. If the quanti~ to be checksummed has an odd number of bytes, it shall be padded with a finalnull byte (binary O1s)to make the number of bytes even for the purpose of checksum calculation. Theextra byte shal[ not be transmitted as pm of the packet, but its existence shall be assumed at thereceiving end for checksum verification.

Word 1 0001 (Note: all numbers are in hexadecimal)Word 2 F203

Word 3 F4F5

word 4 F6F7

Sum showing carry: 2DDF0

Sum without carry: t)DFO

Carry: 2Ones-complement sum: DDF2

Complement for checksum: 2200

FIGURE 8. Examde of checksummin~.

5.2.5 NET’BLT txotocoI o~eration. Each ?WT’BLT transfer shall have three stages: connection setup,data transfer, and connection close. The stages are described in detail below, along with methods for -ensuring that each stage compietes reliably. State diagrams are provided at the end of the description foreach stage of the transfertmnsitio~ and optionally,

Reprinted without change

Each transition in the diagrams is iabeled with the event that causes thein parentheses, actions that occur at the time of the transition.

29 18 June 1993


5.2.5,1 Connection setup.between the sending NETBLT

MIL-STD-204544500NOTICE 1

A NETBLT connection shaJl be set up by anand the receiving NETE3LT The sending end

exchange of two packetsshall send an OPEN packet;

the receiving end shall acknowledge the OPEN packet in one of two wavs- it shall either send aREFUSED packe~ indicating that the comection cannot be completed for some reason, or it shallcomplete the connection setup by sending a RESPONSE packet Afler a successfd connection setup, the

tmnsfer can begin. Figure 9 illustrates the opening of a connection by a sender, and figure 10 shows thesame process for a receiver !

Open Timer timeout & 2 rnax # ‘PENS ‘ent

\

REFU/ S;nd request from client

SED received

Open Timer timeout & < maxstart Open T]mer

I

# OPENS sent

)

RESPONSE received(clear Open Timer)

&FIGURE 9. Sender open state dimm.rn.

1

Supersedes page 30 of MIL-S~-204544500 30

.


MIL-STD-2045-44500

9Connected(receiver)

Last buffer received &all buffers disposed of &

all messages acked(Send DONE)

&Inactive

.

FIGURE 13. Receiver successful close state diajmun.

5.253.1.2 Sender successful close. The sender shall recognize that the transfer has completed whenthe following are true: (1) it has transmitted DATA packets with a “last-btier” flag set and (2) it hasreceived OK messages for all its buffers. At that point, it shall “dally” for a predetermined period of time

before closing its half of the connection. If the NULL-ACK packet acknowledging the receiver’s last OK

message was 10SLthe receiver has time to retransmit the OK message, receive a new NULL-AC~ andrecognize a successful transfer. The dally timer value shall be based on the receiver’s control timer value.

it shall be long enough to allow the receiver’s control timer to expire so that the OK message can beresent. The sender shall use the receiver’s cument control timer value to compute its dally timer value. Avalue of twice the receiver’s control timer value is suitable for the dally timer. When the sender receivesa DONE packet, it shall clear its dally timer and close its half of the connection. Figure 14 illustrates thissequence.

All buffers flushed(Send NULL-ACK: met DallY Timer)

1OK message received

(Send NULL-ACK; wet Dally Timer)

IDONE received or Dally timeout

&FIGURE 14.


Sender successful close state diagram.

37


MIL-STD-2045-44500NOTICE 1

5.2.5.3.2 Client Q UIT Dunn~ a NEl13LT transfer, one client may send a QUIT packet to the other, .

to terminate the tiansfer prematurcl \ Since the QUIT occurs at a client Ievei, the QUIT trmmsslon -

. .

shll OCCUIonly between buffer uansmissionsThe NETBLT receiving the QUIT packet shall take no

action other than imrnediatel} nollf~ Ing its client and tmnsrniting a QUITACK packet. The QUIT sender

.

shall time out and retransmit unul a QUITACK has been received or its death timer expires-. The senderof the QUITACK shall dall! Wore quitting,

so that it can respond to a retrmsfi~ed QUIT. Figure 15

iliustrties this sequence.

Quit request from cl]ent

(\rr, d tJVIT-ACK) (Send QUIT; Set Quit T]mer)

QUIT recel~cdQUIT Timer timeout

(Send Q~IT-A~K)

FIGURE 15. Quit state dia~rm.

5.2.5.3.3 NETBLT ABORT. An ABORT shall take piace when an unrecoverable malfunction occurs.Since the ABORT originates in the NETBLT layer, it may be sent at any time.

The ABORT implies that

the NETBLT layer is malfunctioning, so no transmit reliabflit)’ is expected, and the sender shallimrntXii*ly close its connection, Figue 16 ilh.s= this sequence.

\

MOJZT receiredIntern-1 m~lfunction

Supersedes page 38 of MIL-S~-2045-44500


MIL-STD-2045-44500

5.2.9.5 REFUSED rockets

5.2.951 Reason for QUIT .%flORTNFUSE The80 characters long. suitable for dlsplai to the recipientconnection cannot be completed (or some reason

@OTE: Strings used may include

reason shall be an appropriate ASCII string up toThe use of REFUSED indicates that the

.

“no sewice listening on pofl \.- u here x is the unacceptable port number. )

5.2.9.6 DATA and LDATA P~Ck~.

5.2.9.6.1 Packet number The first data packet in each b~er shall be numbered O.

5.2.9.6.2 Data area checksum ~due All TAC02 DATA and LDATA packets shall be checksummed.

~~ 97 Timer precision Tlmcr precision in NETBLT shall be no worse than *200 milliseconds(msec).

5.2.9.8 Open timer value The open timer shall initially be set to no less than two seconds. Inhalf-duplex and full duplex, the \alue of the open timer shall be increased by two seconds tier eachtimeout.

5.2.99 Quit timer value. The quit timer shall be set to no less than five seconds.

5.2.9.10 Death timer value. The death timer should be set to no less than two minutes.

5.3 Network layer - 1P.

5.3.1 Overview. The DOD 1P forms the nehvork layer of the TAC02 protocol suite. 1P provides amechanism for transmitting blocks of data (datagrarns) from sources to destinations, which are specifiedby 32-bit addresses. it is a “best-effort” mechanisq which provides no assurance that a da.tagrarn isdelivered, but takes appropriate steps when possible to move a datagram toward its destination. 1P isspecified in Internet RFC 791, as amended by WC 950 (IP Subnet Extension), RFC 919 (IP BroadcastDatagrams), and RFC 922(IP Broadcast Datagrarns with Subnets). It usually also includes the InternetControl Message Protocol (ICMP), specified in RFC 792, which provides a mechanism forcommunicating control and error information between hosts and other hosts or gateways. Although ICMPis an integral part of 1P, it uses the support of 1P as if it (ICMP) were a higher level protocol. 1P is alsospecified in MIL-STD- 1777, which forrrudly specifies a protocol consistent with RFC 791.

5.3.1. I ?P au~mentations. As used in TAC02, 1P may be augmented by the revised 1P SecurityOption (RFC 1108), and by the Host Extensions for 1P Muiticasting (RFC 11 12). These augmentationsare not required in this version of TAC02, but they may be necessary for operation in certain

.—

Supersedes page 49 of MIL-STIl-2045-44500 49


MIL-STD-2045-44500

environments TAC02 supports a limited form of multicasting by allowing simplex receivers to “listenin” on simple~ half-duplex, or fu!l-duplex transmissions (Effecbvitv 5 later versions of TAC02 may.support acknowledged multicast).

. —

5.3.2 Required 1P components. Because TAC02 uses 1P outside its normal intemetworkedenvironment, some componen~ of 1P are unnecess~ or inappropriate in some cm=. This Sectionidentifies the required components for each major case.

5.3.2.1 Simplex. Simplex transmission may be used to support point-to-point or broadcastcommunication in TAC02. The Internet Header format shall be as specified in 5.3.3. The followingfields shall be correctly filled in and interpreted for simplex operation:

a-

b.

c.

d.

e.

f.

g

h.

i.

Version

Internet Header Length

Total Length

Fragment Offset (must be 0)

Protocol (30 for NETBLT)

Header Checksum

Source Address

Destination Address

1P Security Option, if required

The remaining fields shall be disregarded by a receiver in simplex operatio~ but shall be provided by atmnsmitter for the sake of consistency. Datagmms shall not be fragmented. Subletting support is notrequired. ICMP shaIl not be used in simplex communications.

.

Reprinted without change 50


MIL-STD-2045-44500

Received fieids shall be filled in ~~’itiwdues computed by combining the abbreviated header wdue of thecorresponding field and the receiver’s comection state variable value. For the Last Buffer Touched and

High Consecutive Sequence Number Received fields, the computed value shall conttin the *breviatedheader value for the low-order portion, and the smallest value such that the result is no less ti~ the oldcomection stale variable value for the high-order portion. For the Buffer Number field, the computed

value shall use the abbreviated header value for the low-order potion, and a value that causes minimalchange between the old comection state variable value and the new computed value for the high-orderportion. The connection state variable value shaJl be changed to correspond to the new computed value.The NETBLT Packet Number field shall be filled in with the abbreviated header Packet Number field,padded with zeros on the left. The NETBLT “L” bit shall be set according to the “LB” bit in theabbreviated header, and the NETBLT Type field shall be DATA or LDATA according to the “LP” bit inthe abbreviated header. Burst Size and Bust interval shall be find in according to tie vtiable values.The remaining NETBLT fields shall be fdled in accordance with 5.2. The reconsmcted NETBLT packetshall be passed directly to the NETBLT layer (bypassing the 1P layer) for norrnd processing.

5.4.2 FEC sublayer. Using the FEC sublayer is optional; the inclusion of FEC-I in any compliantimplementation of TAC02 is mandatory.

5.4.2.1 FEC-I code. The FEC-I encoding process takes each 1P datagram to be transmitted, addsReed-Solomon redundancy, and passes the encoded datagram to the link layer for encapsulation, generallyas an HDLC frame as specified in 5.4.3.1 As a result, the HDLC implementation shall (T’BR) aliowreceived packets to be processed by the FEC sublayer even if the HDLC checksum is in error. Theencoded datagram also may be encapsulated as a SLIP frame, as specified in 54.3.2. If the unencodeddatagram contains K bytes where K is not greater than 152, the encoded damgram contains a singleReed-Solomon codeword containing K + 10 bytes. For purposes of Reed-Solomon code definition, thesebytes are numbered from O to K + 9 as shown on figure 19 (where the left end of the figure representsthe begiming of the datagram if viewed in time-sequence).

I K+9 10 0 9

Message Bytes Reecl-Solomon CheckMi , loLiLK+9 Bytes

Cj , 0<j<9

, I

FIGURE 19. FEC-I format.


11

63

II

1-


The FEC-I code uses arithmetic in the

5.25” WORM disk coding. This fieid

MIL-STD-2045-4450()NOTICE 1

Galois field GF(256), as specified in the standard 1S0 9171 forhas 256 elements, which are represented by 8-bit symbols (“octets”

or simply “bytes”), using the generator polynomial X*+ X5+ X3+ x? + 1. The primitive element a hashexadecimal value OX02. The Reed-Solomon check bytes Cj are defined by the following:

cj=

5.4.2.1.1 Correction caability.correctable with up to five independent

K+9

EMi

ai+~”i-lo

Each codeword asbyte-errors. FEC-I

.

9 ● = 0...9J

defined in 5.4.2.1 has distance 11 and is fullycan fully correct all patterns of five or fewer

enormous bytes in any codeword. Note that the content and sequence of the message bytes Mi remainsunchanged by the encoding process.

5.4.2.1.2 Long datwrarns. If the length of the datagram to be encoded is greater than 152 bytesbut does not exceed 752 bytes, encoding is performed by including up to five separate concatenatedReed-Solomon codewords in the encoded datagram. The maximum encoded length is 802 bytes. As anexample, figure 20 shows how a datagram with an unencoded length of 450 b-ytes would be encoded,giving a datagrarn 480 bytes long.

152 152 146message bytes message bytes message bytes

J

w10 10 10

check bytes check bytes check bytes

FIGURE 20. Encoding a 450 byte uacket.

& shown on figure 20, only the final codeword in a multkmdeword encoded datagrarn may be truncatedto fewer than 152 message bytes. The time sequence of the message bytes is unchanged by the encodingprocess. FEC-I encoding is presently not specified for datagrams whose unencoded length is greater than752 bytes. Should a FEC-I encoder be presented with such a datagram, the correct action is to transmitit

without any encoding. .

—

Supersedes page 64 of MIL-STD-2045-44500 64

.


M[L-STD-2045-44500

65 Effectl\~it~.summ arY Some of the capabilities specified in this document are notrequired as of the issue date of the document All such capabilities are marked with effectivity

numbers, for example, (Effectivity 1). Each effecti ~ri~tnmber will be replaced by a specific datein subsequent releases of this document. .

65 I E&ti~~j N 1 - FEC I and Bit Error Ratio Test (BERT).

a. 4.1.6 FEC. Fommrd Error Correction (FEC) is a mandatory component of theT.AC02 protocol stack whose use in a particular circuit is user selectable(Effectivity 1). ...

6.5.2 Effectivity 2- FEC II.

a APPENDIX C FEC-11 CODE. (The contents of this section are (Effectivity 2)pending ftier implementation and testing of the proposed FEC code.)

b 5.4.2.2.3 FEC-11. FEC-11 is applied to a SLIP and/or HDLC encapsulated datalinkas described in appendix C (Effectivity 2).

6.53 EffectiviN 3- Header abbreviation and client-controlled flow.

a- 4.1.5 Header Abbreviation sublaver. TAC02 provides a mechanism for headerabbreviation across point-to-point links. Use of the header abbreviation sublayer isoptional: its inclusion in any compliant implementation of TAC02 shall bemandatory (Effectivity 3).

b 5.2.3.5 Client-controlled flow. (Effectivity 3)

c. 5.4.1 Header Abbreviation subla}’er. TAC02 provides a mechanism for headerabbreviation across point-to-point links. Use of the header abbreviation sublayer isoptional: its inclusion in any compliant implementation of TAC02 shall bemandatory (Effectivity 3).

6.5.4 Effectivity 4- PuII vs. tmsh.

a 5.1 NITFS reliable transfer semer for TAC02 (TAC02 NRTS). The TAC02NRTS described here assumes an active sender and a passive receiver (“push”operation); as of the effectivity date (Effectivity 4) the TAC02 NRTS shall alsosupport an active receiver and passive sender (“pull” operation).

b. 5.2.9.2.5 Direction. (Effectivity 4) Until the effectivity date, operation of TAC02 isdefined only for “M” set to 1; that is, TAC02 aIlows only active sending and passivereceiving. Following that date, operation with “M” set to O is also permissible.

Reprinted without change 81


M1L-STD-2045-44500NOTICE 1

6.5.5

a 5.3.1 1 IF’ our,rnentations ... “TAC02 supports a limited form of mulhcasting by

allowing simplm receivers to “listen in” on simplex, half-duplex, or full-duplex

transmissions (Effectivity 5: later versions of TAC02 may support acknowledgedmuhicasl]

6.5.6 Effectivity 6 - \l ed Iurn Access Control laver.

a. 54 Data linkliner. The Data Link layer in TAC02 is divided into threesublayers t{cadcr Abbreviation, FEC, and Framing. (Effectivi~ 6: a MediumAccess Conuol Layer, just below the Framing Sublayer, is under consideration.)

6.5.7 Wfectivi~ 8- Defense Information Svstems Network (D[SN].

a DISA/JIEO Clrcu!ar 9008

b DISA/JIEO Specification 9137

c. DISA/JIEO Specification 9138

d. DISMJiEO Specification 9139

e. DISWJIEO Specification 9140

6.6 Subiect term (kev word) listing.

Error detectionFonvard error correction (FEC)FramesHDLClCMP1PMessage Transfer FacilityNETBLTPacketsSecondary Imagery Dissemination SystemsSIDSSLIP

Supersedes page 82 of MIL-STD-2045-44500 g2

u rnn navuor


MIL-STD-2045-44500

APPENDIX C

FEC-11 CODE

(The contents of this section are (Effectivit~ 2) pending further implementation and testing of theproposed FEC code.)

10. Scope. This appendixintended for guidance only.

20. A~r)licable documents

30. FEC-11 Code. FEC-11

is not a mandatory part of the standard. The information it contains is

This section is not applicable to this appendix.

encoding applies both Reed-Solomon and BCH coding for operation inhigh error environments. Fufier, FEC-11 encodes a single datagrarn or section of a datagram into a

group of “fiagrnents,” or small packets of 12 bytes each. The BCH coding protects each fragment.

and using the Reed-Solomon coding, up tn eight fragments may be lost in transmission v’bile still

allowing the receiver to recover the datagrarns.

(The ten-n framncnt used in his section, is unrelated to ~C fiagmenf-s defined b!’ ~c lnteme~

Protocol.) *

The individual fiagrnents shall be encapsdated by tie data link layer, generally ei~er as a SL1p frameas specified in 5.4.3.2, or as an HDLC fkune as specified in 5.4.3.1. If a FEC-1] tiagment isencapsulated as an HDLC frame, the 2-byte HDLC frame opening sequence, as well as the 2-byteCRC, shall not be included in the b.rne.

Datag-rams up to length 382 bytes may be encoded by the FEC-11 coding process The first stepshaU be to represent the data.gram by either one or WO “sections.” If the datagram is of length L,where L is 191 bytes or less, it shall be represented by a single “section” containing L + onebzytes as follows: an initial b-yte containing the byte count L, followed by the L bytes contained inthe datagram. If the datagram is of length L, where L is 192 through 382 bytes inclusive, it shall

be represented by two seetions. The first section shall consist of an initial byte with value 255

(decimal), followed by the fust 191 bytes contained in the datagrarn. The second section shall

consist of an initial byte with value (L - 191), followed by the remaining bytes of the datagram.

First we W specifi the format of a single fragmen~ md then describe how the input bytes used

to form the fragments are derived from the unermded section.

Each 12-byte fkagment is formed horn an 8-byte sub-block, which is made up of the “input bytes”on figure C-1.



STANDARDIZATION DOCUMENT IMPROVEMENT PROPOSAL

INSTRUCTIONS

1.

2.

3.

The preparing activity must complete blocks 1,2, 3, and 8. In block 1, both the document number

revision letter should be given.

The submitter of this form must complete blocks 4, 5, 6, and 7.

The preparing activity must provide a reply within 30 days from receipt of the form.

NOTE: This form may not be used to request copies of documents, nor to request waivers, or clarification of

requirements on current contracts. Comments submitted on this form do not constitute or imply authorization to

waive any portion of the referenced documents) or to amend contractual requirements.

I RECOMMEND A CHANGE:1. DOCUMENT NUMBER 2 DOCUMENT OATE (YYMMDD)

MIL4TD-2045U500, 930618NOTICE 1, 29 July 1994

3 00CUMENT TITLE Tactical Communications Protocol 2 (TAC02) for the Nat!onal Imagery Transmtsston Format Standard

4 NATURE OF (2+ANGE (fden!dy pamgraph nwnoer wd mcfude p~d mwn?e i pas.wble Aflxt! eslfa sheets ● s needed)

S REASON FOR RECOMMEN13ATION

6. W8MTTER

● UAW (L84 %s( A4ddk hinO

c AIXYRESS(lndula * Code)

b 0RGwUAT40N

d TELEFWNE (hdudah -) 7 Q4TE WWITTED (WMUDD}

(1) Commercial

[2) DSN(Ifapplfcabk)

8 ‘-R- ‘mm DEFENSE INFORMATION SYSTEMS AGENCY (DISA)

‘ ‘W Director, Joint Interoperability and EngineeringOrganiztition

c ADDRESS (-Ado Z@ Code)

ATTN TBBF

Building 283, Squter Hal!Ft Monmouth, NJ 07703

I+ev

b TEtfPHOWflmAde Au Cadu)

(1) Commercial 908-532-7732 (2) DSN 992-7732

IF YOU DO NOT RECEIVE A REPLY WITHIN 45 DAYS,CONTACT:

Defense Quality and Standard~zationOffice5203 Leestwg Pike, Sutte 1403, Falls Church, VA 22041-3466Telephone (703) 756-2340 DSN 289-2340

US ~jt;ms are obso/ete. 1 98-290


STANDARDIZATION DOCUMENT IMPROVEMENT PROPOSAL

INSTRUCTIONS

1. The preparing activity must complete blocks 1,2, 3, and 8. In block 1, both the document number and

revision letter should be gwen..

2. The submitter of this form must complete blocks 4, 5, 6, and 7.

3. The preparing activity must provide a reply within 30 days from receipt of the form.

NOTE: This form may not be used to request copies of documents, nor to request waivers, or clarification of

requirements on current contracts. Comments submitted on this form do not constitute or imply authorization to

waive any portion of the referenced document(s) or to amend contractual requirements.

I RECOMMEND A CHANGE:1 DOCUWMT NUMBER 2 00CUMENT DATE (YYMMDD)

MIL-STD-2045U500, 930618NOTICE 1, 29 Jul)/ 1994

3 OOCUMENT TITLETadcal Commumcatwns Protocol 2 (TAC02) for the Natlona( Imagery Transmsslon Format Standard

4 MATURE OF CHANGE (Jden@ pomgmph number ●d mcluoe ~ mwnfe tf pxsb~ Am exh dheets as needed)

5 REASON WR RECOMMENOATKIN

6 SU8MTTER

e NAME Ost %4 Mdde JJwboQI

b 0RGA?UZATM3F4

c N30RESS flndLI& ZIP Code) d TEIEPMOkJE(hc4de AM m) 7 Q4TE SUOAWWO ~MhfDD)

(1) Commercial(2) DSN

(If applicable)

* ‘=AR’W ‘mm DEFENSE INFORMATION SYSTEMS AGENCY (DISA)

“ ‘ME Director, Joint Interoperabifity and Engineeringb TE15WWE@oWeAmaCde)

Organization (1) Commercial 908-S32-7732 (2) DSN 992-7732

c AOORESS (?ndde ZIP Code)IF YOU DO NOT RECEIVE A REPLY WITHIN 45 DAYS,

AITN TBBF CONTACT:Building 283, Squw HallFt Monmouth, NJ 07703

Defense Quality and Standardlzatlon Office

5203 Leestwrg Pike, Su~te 1403, Falls Church, VA 22041-3466Telephone [7031 756-2340 DSN 289-2340

* . . ,.14Zb, UC I tvevtous edmons are obsolete. 1Ylj-zYu


NOT MEASUREMENT MILITARY STAND-

Documents

Transcript of NOT MEASUREMENT MILITARY STAND-