idnits 2.17.1 draft-rfced-info-buddenberg-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1188 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES MARCH 1998 INTERNET DRAFT 3 Rex Buddenberg 4 Editor 6 Automated Digital Network System Description 7 9 Status of This Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 Contributing Authors 31 The following are the authors of the description. This work compiled 32 and digested internal notes, in-house training materials and several 33 conversations with the NRaD engineers. The material of this memo was 34 used as a chapter in each of these students' theses: 36 Brian Rehard, Lt, US Navy 37 Jim Sullivan, Lt, US Navy 38 Eric Andalis, Lt, US Navy 39 Mark Witzel, Maj, US Marine Corps 41 Editors' Note This memo is a first attempt at publicly documenting 42 internal Navy laboratory work aimed at encapsulating a variety of 43 connectivity options inside a radio-WAN shell that fits into the 44 internet structure. 46 I. Introduction 47 A. What is ADNS? 48 B. What is ADNS good for? 49 1. Mobile Platforms 50 2. Alternative to Wire/Fiber Transmission 51 C. Why invest in ADNS? 52 1. Quality of Service 53 2. Cost Effective Bandwidth 54 3. Leverages the existing Internet 55 4. Flexibility 56 D. How does ADNS work? 57 E. ADNS Advantages 58 1. Removing Humans From the Loop 59 2. Load Sharing 60 3. Optimal Use of Bandwidth 61 4. Communications Agility 62 5. Transparency of Installation and Use 63 6. Ease of Upgrade 64 7. Single Point for Communications Management 65 8. Ability to Transmit All Types of Data 66 F. ADNS Disadvantages 67 1. Cost of Installation 69 II. ADNS Operational Description 70 A. Overview 71 B. Network Features 72 1. Routing Protocols 73 a. OSPF 74 b. BGP4 75 2. Logical Organization 76 C. Key Features/Functions 77 1. Priority 78 a. Priority Tables 79 b. Determining Message Priority 80 c. Message Transmission 81 2. Load Balancing 82 3. Congestion Control 83 a. Load Sharing 84 1) Restrictions 85 2) Implementation 86 b. Source Quench 87 4. TCP Duplicate Packet Transmission Problems 88 a. TCP Duplicate Packet Rejection 89 D. Integrated Network Management 90 1. Overview 91 a. Local Control Center 92 1) Network Manager 93 2) Distributed Manager 94 3) Communication Automation Manager 95 i) Communication Manager 96 ii) Site Manager 97 iii) Equipment Manager 98 b. Autonomous System Control Center 99 c. Network Operations Center 100 2. Network Management Tools 101 a. Network Management System Software 102 b. Third Party Applications 104 III. Hardware 105 A. LAN 106 B. Router 107 C. CRIU 108 D. CAP 109 E. Cryptographic Device 110 F. Modem 111 G. Connectivity Media 113 IV. Acknowledgements and addresses 115 I. Introduction 117 A. What is ADNS? 119 The Navy's Automated Digital Network System (ADNS) provides a means 120 for ship's to centralize and automate the operation of multiple 121 independent radio communications systems into an efficient 122 communications network. 124 ADNS provides connectivity for transmitting bits (which may represent 125 voice, video or data) creating a seamless ship to ship and ship to 126 shore communications network. By managing all of the radio assets 127 within one system, ADNS creates a reliable multiple path 128 communications network. This network is essentially a radio-based 129 Wide Area Network (Radio-WAN). What constitutes the internals of the 130 Radio-WAN are those radio systems configured to support ADNS. 132 Media Dependent Layer 133 |---------------------------------------------------------| 134 | Media Independent Layer | 135 | |-------------------------| | 136 | | | | 137 ---| | ________ | (MilSat) | ________ | 138 |--- 139 ---| | | | | (Commercial) | | | | 140 |--- 141 ---|----| Router |----| (Satellites) |----| Router 142 |----|--- 143 ---| | |________| | | |________| | 144 |--- 145 ---| | | (HF) | | 146 |--- 147 | |-------------------------| | 148 LAN | Radio-WAN | 149 LAN 150 |---------------------------------------------------------| 152 Although currently a Navy specific installation, ADNS is like any 153 other LAN/WAN Internet connection utilizing commercial products. 154 Applications need only adhere to the established Internet protocols 155 that ADNS has adopted. This allows a sense of transparency of 156 applications to ADNS. It is also an open-ended system that allows for 157 future expansion. ADNS allows a plug and play like addition of radio 158 links in a process completely transparent to the user. 160 B. What is ADNS good for? 162 A group of platforms, linked by ADNS, create a radio-based 163 packet-switched WAN. By using existing Internet technology and open 164 standards users of ADNS have seamless transparent access to the 165 Internet. Using a load balancing concept ADNS spreads traffic equally 166 across the appropriate radio links such that the available capacity is 167 the sum of all the links. ADNS does not provide additional bandwidth 168 instead it multiplexes the bandwidth that is already available. 170 There has recently been an insatiable demand for Internet access in 171 areas never previously deemed necessary and although Internet 172 technologies are relatively new, limitations are being experienced on 173 traditional wire/fiber transmission paths. The primary purpose of 174 wireless data transfer is for communications with mobile platforms. 175 This capability already exists in various forms. However, ADNS 176 provides a robust means of choosing the most efficient set of paths to 177 transfer data in a way that is transparent to the user. It allows 178 existing stovepipe systems to be integrated into one common data 179 transmission network. When linked with a fixed shore site, to provide 180 wire/fiber connectivity, this network becomes, in essence, a mobile 181 extension of the Internet. 183 1. Mobile Platforms 185 Although ADNS was specifically designed for the Navy, it's commercial 186 potential is great. The easiest technology transfer can be applied to 187 maritime platforms. Commercial and research ships have similar needs 188 as the Navy for transferring data to and from shore sites. Imagery 189 (such as weather) transfer, e-mail, Internet access, and file transfer 190 capability are becoming essential tools necessary to accomplish 191 everyday tasks. Commercial aircraft crew and passengers can also 192 benefit from these same capabilities. Cellular phones in automobiles 193 are commonplace. Some cars already receive one way satellite position 194 information using the Global Positioning System (GPS). Currently there 195 is even auto industry research into providing cars with Internet 196 access. The field of mobile communications has become increasingly 197 complex and will continue to grow. However, what should be avoided is 198 a spaghetti-like architecture of different transmission paths linked 199 to different applications. 201 The traditional way to adopt new data transfer technologies is to 202 implement a stovepipe system with its own dedicated transmission path. 203 Mobile platforms, especially large ones like ships, typically have 204 more than one transmission path for data transfer. However, if data 205 is to be transferred, a dedicated radio link has to be assigned to a 206 specific application. An application can not share different links or 207 be distributed. The same is true for aircraft. Although more limited 208 in space, aircraft too have different radio links which transmit data 209 in a stovepipe fashion. The requirement for data transfer capability 210 in autos is a relatively new concept. However, the reality of cellular 211 phones and GPS combined with the possibility of Internet access 212 already points to multiple transmission paths. Wireless communications 213 do not have to be limited to just mobile platforms. It can also be a 214 viable alternative to traditional shore links especially if they are 215 saturated or can not be established, for example, in remote areas 216 where the infrastructure just doesn't exist. 218 2. Alternative to Wire/Fiber Transmission 220 Traditional shore transmission paths have been saturated with the 221 increasing number of Internet users. Although much research has been 222 done in alternative technologies to alleviate this congestion, such as 223 installing optical fiber, these solutions often require investing in a 224 whole new and different infrastructure. However, ADNS does not 225 provide the same high capacity data transfer capability as shore 226 backbones but instead allows an alternative to traditional mediums for 227 transmitting data without worrying about infrastructure changes. 228 Wireless data transfer could also be an attractive short term solution 229 for areas where the infrastructure doesn't exist or is temporary such 230 as in remote regions. A parallel to this can be seen in many 231 lesser-developed countries where cellular telephones have proliferated 232 because of inadequate landline telephone networks. 234 C. What Does ADNS Do? 236 A mobile platform can be thought of as a roaming Local Area Network 237 (LAN). What existed onboard U.S. Navy ships prior to ADNS was a 238 potpourri of different LANs and radio systems. If data was to be 239 transferred to and from a ship, a different radio system was used for 240 each application. ADNS allows platforms with more than one 241 transmission path to integrate these different systems via one black 242 box (ADNS), which then distributes data throughout the different paths 243 in the most efficient manner. This method is desirable for several 244 reasons. 246 1. Load Sharing 248 If one or more transmission paths fail or are congested, ADNS can 249 redirect data flow to open channels, which leads to an increased 250 quality of service (QoS). ADNS can distribute data flow much more 251 efficiently than the present stovepipe system. For example, a video 252 teleconference (VTC) often inundates bandwidth, leaving other 253 applications looking for an open transmission path. Other 254 applications such as e-mail can be redirected to less congested 255 channels instead of being stacked in a queue, waiting for 256 transmission. 258 2. Cost Effective Bandwidth 260 ADNS can direct data from different applications through desired 261 transmission paths. This can be done to preferentially use the most 262 cost-effective means for data transfer. 264 3. Leverages the existing Internet 266 Another big appeal for ADNS, and one of the main reasons why the Navy 267 has developed it, is that ADNS ties together the existing stovepipe 268 communications architecture. There is no need to create a brand new 269 infrastructure. Existing organizational LANs can be connected to ADNS 270 and have access to the full range of communications assets available 271 to that unit. 273 4. Flexibility 275 The use of open protocols and Commercial off the Shelf (COTS) hardware 276 creates a very flexible system. Modifications or additions to the 277 shipboard LAN have no effect on ADNS. By using IP routers as the 278 interface between ADNS and the shipboard LAN modifications on one side 279 of the router are transparent to the other. Adding a new radio system 280 is not much more complicated than adding a new circuit card. 282 D. How does ADNS work? 284 The easiest way to visualize how the system works is through an 285 example. The following is a high level block diagram of ADNS and 286 general description of operation. 288 |---------------------------------| 289 |---------------------------------| 290 | | | 291 | 292 | _____ ________ ______ | Radio- | ______ ________ 293 _____ | 294 | | | | | | | | WAN | | | | | 295 | | | 296 | | LAN |---| Router |---| ADNS | |----------| | ADNS |---| Router 297 |---| LAN | | 298 | |_____| |________| |______| | | |______| |________| 299 |_____| | 300 | | | 301 | 302 | -------------------- -----------| 303 |---------------------------------| 304 Mobile Platform Mobile 305 Platform 307 Suppose that a user on a ship at sea wished to transfer a file to 308 another user on a different ship. Let us also assume that both users' 309 computers are connected to their respective shipboard LANs. When the 310 originating user is ready to send the message he simply clicks on the 311 appropriate button to send the message on its way via the ship's LAN. 313 The size of most data files will necessitate their being broken into 314 multiple IP datagrams. The router, processing each datagram 315 independently, uses the Open Shortest Path First (OSPF) protocol to 316 determine the best path(s) to reach the destination. If there are 317 multiple equal cost paths the router will balance the load amongst 318 them. Similar to a packet switched network a single message may be 319 routed via multiple paths. The router then forwards the datagrams to 320 ADNS. 322 ADNS prioritizes, queues and transmits the datagrams on the selected 323 radio system. The transmitted datagrams transit the Radio-WAN much 324 the same way as in a packet switched network. At the destination there 325 is a mirror image of the transmitting site. Arriving IP datagrams 326 pass back through ADNS to the router and onto the LAN where they are 327 received and reassembled at the destination host. 329 This example described the transmission of one message to one 330 destination via a single RF path. To understand the system's true 331 potential, envision multiple ADNS capable platforms communicating 332 simultaneously from multiple applications via multiple RF paths. 334 E. ADNS Advantages 336 1. Removing humans from the loop 338 In current naval communication systems, messages are generated on 339 personal computers or workstations. These messages are transmitted 340 via LAN, (or by use of magnetic media such as floppy disks where no 341 LAN exists), to the communication center. The messages are then 342 processed by technicians and transmitted. This process introduces 343 time delays ranging from minutes to hours. ADNS eliminates the need 344 for human processing of messages by establishing a direct connection 345 from any node on the LAN, through the transmitter, to the receiver at 346 the intended destination. The result is complete automation of the 347 transmission process, with total elimination of any handling delays 348 caused by human interaction. 350 2. Load Sharing 352 Most naval vessels maintain at least two operational communication 353 channels at all times. The reason for multiple channels is a legacy 354 one - systems were developed such that only certain types of 355 information could be transmitted and received over each channel. This 356 frequently results in one or more channels being completely silent, 357 while another is backlogged with traffic. The Load Sharing Feature of 358 ADNS was specifically designed to alleviate these backlogs by making 359 more efficient use of all operational communication channels. This is 360 accomplished assigning a "cost" value to each network. Message queues 361 in each CAP are monitored and messages are routed evenly across equal 362 cost circuits. 364 3. Optimal use of bandwidth 366 Network costs are assigned such that higher capacity circuits are 367 assigned lower cost values. ADNS maximizes throughput by finding the 368 lowest cost path for a message to reach its destination. The 369 combination of removing humans from the loop, load sharing and using 370 the lowest cost paths discussed above results in a four-fold increase 371 in throughput during peak traffic times. This is a direct increase in 372 the bottom line throughput of the communications system without 373 purchasing additional transmitters. 375 4. Communications Agility 377 ADNS provides the capability for two units that do not share a common 378 communication channel to maintain communications. As long as each 379 unit is operating at least one communication channel and at least one 380 node on the network is operating both channels simultaneously, 381 communications can occur. This process is completely transparent to 382 the users, and occurs with no human intervention. This is analogous 383 to Internet packet delivery. Few end systems share a common 384 communications channel (that is, they are on the same network 385 segment). 387 5. Transparency of installation and use 389 The installation of ADNS is totally transparent to the end users. It 390 merely appears that a new router has been added to the LAN with links 391 to many other LANs. There is no major LAN or transmitter 392 reconfiguration that is required. Additionally, there are no major 393 infrastructure modifications (cooling, ventilation, etc.) required and 394 power requirements are modest. 396 6. Logistics 398 The entire installation is small and lightweight, allowing it to be 399 installed in any unused space without impacting shipboard weight and 400 balance. 402 7. Ease of upgrade 404 Following initial installation, upgrading of ADNS is quite simple. 405 Addition of new communication channels can be accomplished through the 406 installation of the appropriate CAP cards. Adding capabilities to 407 ADNS itself, such as installing successive builds as they become 408 available, is as simple as downloading the new software. Router 409 reconfiguration is a relatively simple matter as well. 411 8. Single point for Communications Management 413 ADNS provides a single point for monitoring all communications, both 414 incoming and outgoing. Prior to ADNS, monitoring all communications 415 was much more difficult due to the lack of interconnection between 416 stovepipe systems. Each of these systems had to be monitored 417 separately. This monitoring capability is available locally via the 418 local net manager's workstation, or remotely from the Network 419 Operations Center. 421 9. Ability to transmit all types of data 423 Essentially, ADNS transmits Internet Protocol (IP) datagrams from one 424 router to another. It is the applications on these LANs that decode 425 the datagrams and put the information contained in them to use. 426 Therefore, ADNS can transmit text, graphics, voice, or video 427 applications over existing channels, without the need for developing 428 expensive new stovepipe systems to support each new application. 430 F. ADNS Disadvantages 432 1. Cost of installation 434 The high initial cost of an ADNS installation is a large obstacle to 435 its widespread use. However, new technology, innovation, and mass 436 production of ADNS should continue to drive costs down. The hardware 437 used in an ADNS installation is COTS equipment but it is very 438 implementation specific. It is unlikely that a unit will already 439 possess equipment that can be modified for ADNS in order to save money 440 on an initial installation. However, future builds of ADNS are 441 planned that will incorporate more readily available hardware. 443 II. ADNS Operational Description 445 A. Overview 447 The behavior of the Radio-WAN created by ADNS is the same as a 448 terrestrial WAN. The router on one platform still "talks" to routers 449 on other platforms, but at a slower rate than if they were connected 450 by wire or fiber. Some of the circuits used in the Navy's ADNS 451 program, such as HF and UHF have transmission rates in the 2.4Kbps 452 range. The insertion of the ADNS hardware and the RF transmission 453 path is simply a conduit for creating a router based network. ADNS 454 deals strictly with IP datagrams. Although some encapsulation occurs 455 as a result of the handling process the underlying packets are not 456 altered and thus the path between destinations is in essence 457 transparent to the routers. 459 The diagram below shows the relative position of each component in a 460 typical ADNS setup. The minimum component mix needed for a complete 461 ADNS installation consists of: LAN-Router-CRIU-CAP-Cryptographic 462 Device-Modem-RF System. From the Channel Access Protocol (CAP) to 463 Router Interface Unit (CRIU) back (to the left) there will be only one 464 of each for a given installation. From the CAP forward (to the right) 465 there will be one chain for each radio system that is part of the 466 system (i.e. there may be a UHF SATCOM chain, a UHF LOS chain, an SHF 467 chain, an HF chain, etc.). In this particular configuration there are 468 three RF paths connected to ADNS. 470 _____ _______ _______ 471 ______ 472 | | | | | | | 473 | 474 |-| CAP |---|CRYPTO |---|MODEM 475 |---|RADIO | 476 | |_____| |_______| |_______| 477 |______| 478 _____ ________ ______ | _____ ______ _______ 479 ______ 480 | | | | | | | | | | | | | | 481 | 482 | LAN |---| Router |---| CRIU |---| CAP |---|CRYPTO |---|MODEM 483 |---|RADIO | 484 |_____| |________| |______| | |_____| |_______| |_______| 485 |______| 486 | _____ _______ _______ 487 ______ 488 | | | | | | | | 489 | 490 |-| CAP |---|CRYPTO |---|MODEM 491 |---|RADIO | 492 |_____| |_______| |_______| 493 |______| 495 As discussed earlier, the router accepts outbound datagrams from the 496 LAN and selects the best path for reaching the destination. The CRIU, 497 which interfaces between the router and CAP, assigns a priority to 498 outbound IP datagrams. Priority is inferred based on both the source 499 application (logical port number) and the host (IP address) from which 500 the message originated. At the CAP the message is placed in a queue 501 to await transmission. Messages in the CAP queue are sorted by the 502 priority assigned by the CRIU. 504 When the message leaves the CAP it passes through a cryptographic 505 device. The standard Navy ADNS configuration operates at the secret 506 high level of classification, thus all information entering the RF 507 network is link encrypted. This: 1. Conforms to existing practice. 508 2. Provides resistance to AS spoofing. 3. Provides limited content 509 confidentiality/authenticity protection (because this layer of 510 encryption is stripped off at each routing point). Although this 511 provides protection during transmission it does not provide content 512 security once the information passes through the cryptographic device 513 at the receiving end. 4. Provides opportunities for secure tunnels 514 such as Unix Secure Shell (SSH) or Network Encryption System (NES), 515 which deal with IP datagram encapsulation (IP datagrams inside other 516 datagrams). These encapsulated IP datagrams are transmitted by ADNS 517 in the same manner as any other IP datagrams. 5. Does not affect 518 applications that offer end-to-end security (e.g. secure e-mail). 519 Similar to secure tunnels, end system encrypted datagrams are 520 unaffected by the presence of ADNS in the system. 522 After leaving the Cryptographic device the datagram passes through a 523 modem and then enters the transmitter. Once it leaves the ship the 524 message begins traveling via the predetermined path to its 525 destination. Upon arrival at its destination the datagram, traveling 526 through a mirror image of the originating system, terminates at the 527 host specified in the IP header. 529 B. Network Features 531 1. Routing Protocols 533 ADNS uses three different routing protocols. The primary reason for 534 using these algorithms was that the specifications for all three are 535 in the public domain. 537 a. Open Shortest Path First (OSPF)/Multicast OSPF (MOSPF) 539 OSPF is used as the Internal Gateway Protocol (IGP) for routing within 540 an AS. The specification for OSPF Version 2 is contained in Request 541 For Comments (RFC) 2178. It is a dynamic protocol in that each router 542 maintains a continuously updated database containing the status of all 543 other routers in the same system. OSPF uses a lowest cost algorithm to 544 determine the best path to send a message to its destination. Costs 545 are determined based on metrics values assigned to the various 546 transmission paths. 548 Multicast OSPF (MOSPF) is used for multicast within an AS. The 549 specification for MOSPF is contained in RFC 1584. MOSPF uses the same 550 lowest cost concept as OSPF except the lowest cost is determined with 551 respect to the group. 553 b. Border Gateway Protocol Version 4 (BGP4) 555 BGP4 is used as the External Gateway Protocol (EGP) for routing 556 between ASs. Specifics for BGP4 can be found in RFC 1771. BGP4 is 557 not as dynamic as OSPF and makes its routing decisions based on 558 predetermined routes. In ADNS, BGP4 will typically reside at the 559 shore station in a system. Since BGP4 requires a more stable 560 environment than OSPF the shore station is the logical choice. 562 2. Logical Organization 564 The naming and logical grouping of the elements in an ADNS network are 565 based on the concepts established by the routing protocols used by 566 ADNS. 568 The basic unit of an OSPF network is an area. For ADNS a ship is 569 typically considered an area. Certain shore installations will also be 570 areas since the ships need an interface point with other shore based 571 establishments. 573 A number of ships grouped together using OSPF create an Autonomous 574 System (AS). A typical AS consists of a group of Navy ships with some 575 logical connection, such as a common mission. A Battle Group is a 576 typical AS. The emphasis in AS establishment is on mission and not 577 location. The units do not have to be in the same geographic region 578 to be in the same AS. At least one and possibly two or more shore 579 communications establishments will also be a part of an AS to act as 580 the gateway to other navy networks such as SIPRNET (Secret IP Router 581 Network) or the Internet. 583 The combined network of RF systems creates the subnet backbone of the 584 AS. Each subnet is a different RF system such as UHF Satcom, SHF 585 Satcom or INMARSAT B. The router on each ship that interfaces with 586 ADNS is established as an Area Border Router (ABR). Each ABR operates 587 OSPF. Part of the data that is maintained in the OSPF routing tables 588 are metrics for each subnet in the AS. In current ADNS installations, 589 metrics values are assigned based on subnet capacity or bandwidth. 590 Higher capacity subnets are assigned lower metric values. The values 591 chosen for these metrics determine how the system performs load 592 balancing and load sharing, as discussed below. Obviously since each 593 router must maintain a dynamically updated table of every other router 594 in the AS there is a limit to the number of routers which can be 595 managed effectively. This is what drives the upper limit to the size 596 of an AS. 598 The router that acts as the gateway between an AS and other ASs, WANs, 599 or the Internet uses BGP4. The shore establishment usually performs 600 this function since BGP4 needs a stable environment. The OSPF to BGP4 601 transition acts to hide the internals of the AS from the outside. 602 Routers outside the AS don't need to know the specifics of all the 603 routers inside the AS. They only need to know where the BGP4 gateway 604 into the AS is. Changing missions will prompt changes to an AS. 605 Ships may need to transfer from one AS to another to support 606 operational or training objectives. This dynamic reorganization 607 requirement reinforces the need to shield the internal routing issues 608 of each AS from the outside. 610 This illustration shows the relationship between routers within a 611 simple Autonomous System. 613 To other 614 Autonomous Systems 615 or 616 Wide Area Networks 617 | 618 ___ 619 / \ 620 / \ 621 / BGP4 \ 622 (-(Shore)-) 623 \ OSPF /| 624 |\ / | 625 | \___/ | 626 | | | 627 | | | 628 ___ +-)---)----)--+ ___ 629 / \ ------------|-)--EHF---)--|-------------/ \ 630 / \ | | | | / \ 631 / OSPF \-----------|-HF-------)--|-----------/ OSPF \ 632 ( router ) | | | ( router ) 633 \(Ship) /-----------|---------UHF-|-----------\(Ship) / 634 \ / +-------------+ \ / 635 \___/ Backbone Networks \___/ 637 The third party routing feature of this type of network can be seen in 638 the illustration below. If the originating and destination ships are 639 not operating a common circuit ADNS will route traffic through a third 640 platform which has connectivity on both source and destination 641 circuits. By maintaining the status of other ships in the AS, ADNS 642 can determine the best path to ensure delivery of each message. The 643 diagram shows how the sending ship's router (R1) will send via either 644 EHF or UHF (or both, depending on the metric values assigned to each 645 RF path) to R3. R3 will then forward via HF to the destination ship, 646 R2. 648 ___ 649 / \ 650 / \ 651 / \ 652 ( R3 ) 653 \ /| 654 |\ / | 655 | \___/ | 656 v | ^ 657 | ^ | 658 ___ +-)---)----)--+ ___ 659 / \------->-----|-)--EHF ) | / \ 660 / \ | | | | / \ 661 / R1 \ | HF-------)--|--->-------/ R2 \ 662 ( Origin ) | | | ( Dest. ) 663 \ /------>----|---------UHF | \ / 664 \ / +-------------+ \ / 665 \___/ \___/ 667 C. Key Features/Functions of ADNS 669 1. Priority 671 Several different methods for assigning priority to outgoing messages 672 were evaluated during the ADNS implementation process. One obvious 673 method, using the built-in precedence field in the IP header, was 674 briefly considered. This idea was quickly discarded since no relevant 675 applications currently use this feature of the IP header. Eventually, 676 a priority scheme was implemented which assigned priorities of 0 677 (lowest) to 15 (highest). The two methods which proved most useful 678 for assigning priority were based on source IP address (Host), or port 679 number (Application). 681 This approach has the same advantages and drawbacks of a firewall that 682 uses the same data to make its filtering decisions. The advantage is 683 its practicality. The disadvantage is that it's rather crude and, at 684 the moment requires manual configuration of the router's routing 685 table. 687 a. Priority Tables 689 The CRIU maintains two priority tables. The Source IP table contains 690 the IP addresses of hosts on the associated LAN and the priority which 691 they have been assigned. There are no default settings for this 692 table. If a host is to have an associated priority it must be entered 693 into the table. This table is filled in manually by the local ADNS 694 Manager during initial system configuration and can be updated at any 695 time. The Source IP table contains space for up to 40 entries. 697 The second table maintained by the CRIU is the Port priority table. 698 It contains the dedicated port numbers used by certain applications 699 and the priority that has been assigned to that particular 700 application. Just as with the Source IP table above, there are no 701 default values, priorities must be entered manually, and it contains 702 space for up to 40 entries. 704 b. Determining Message Priority 706 The CRIU receives datagrams from the router. The CRIU determines the 707 port number and originating IP address for each datagram and assigns 708 priority based on entries in the Source IP and Port priority tables. 709 Here, a conflict may arise. If the Source IP priority table assigns a 710 certain priority to a particular datagram and the Port priority table 711 indicates a different priority for the same datagram, priority 712 assignment will be made on the basis of Source IP address. This 713 allows priority based primarily on host, and secondarily on 714 application should the host have no assigned priority. If neither the 715 host nor the application have an assigned priority, the CRIU assigns a 716 default value of priority 4. Once assigned, the priority is placed in 717 the IP datagram header and the entire IP datagram is passed to the 718 CAP. 720 c. Message Transmission 722 Following Assignment of priority, the IP datagram is forwarded to the 723 appropriate CAP, where it is entered into one of 16 queues based on 724 priority. Datagrams are assembled into transmission units, each of 725 which can contain up to 64 IP datagrams. The size of the transmission 726 unit depends on the capacity of the link. Lower capacity links will 727 have to utilize lower transmission unit sizes. The CAP builds a 728 transmission unit by removing datagrams from the queues in order of 729 priority. Datagrams are removed from the highest priority queue 730 first, until it is empty. Datagrams are removed in sequence, 731 continuing down the priority queues until the transmission unit is 732 complete or all queues are empty. The transmission unit is sent from 733 the CAP to the corresponding RF transmitter and the process is 734 repeated. 736 2. Load Balancing 738 Load balancing is the sharing of transmission load equally among 739 different subnets. When the router selects a transmission path it does 740 so based on the metrics assigned to that RF system. OSPF metrics are 741 based on link capacity, with links having similar capacity being 742 assigned identical metric values. If multiple CAPs have the same 743 metrics values then the router will balance the load evenly by 744 alternating between those CAPs. For load balancing to work 745 effectively the sharing must be done among systems of equivalent 746 capacity. Consequently, when assigning metric values to RF systems it 747 is important that only networks of like capacity be assigned the same 748 values. For example, if a ship is operating two active subnets, HF 749 (which operates at about 2.4Kbps) and SHF (which operates at about 750 64Kbps) assigning the same metric values to each would overload the HF 751 circuit. The router would divide the load equally between the two, 752 not proportionally. During periods of high traffic density the SHF 753 link could handle the load more effectively than the HF link, which 754 would become backlogged with data. 756 3. Congestion Control 758 As described above, each CAP maintains separate queues for each 759 priority (0-15). Should one of these queues become full, the CAP does 760 not provide any overflow queue so additional datagrams with this same 761 priority will be dropped. In order to prevent this situation from 762 occurring, the CRIU monitors the CAP queues and either starts load 763 sharing or issues a Source Quench command. 765 Each queue in a CAP is allocated a certain queue size to store IP 766 datagrams prior to transmission. The CAP manages this queue space. 767 The CRIU sets a queue threshold, slightly smaller than the queue size, 768 to use as a benchmark to determine if congestion of the queue exists. 769 The gap between the queue threshold and the maximum queue size 770 provides a buffer to allow action to be taken before the queue becomes 771 full and datagrams start being discarded. These queue thresholds are 772 pre-determined and entered into the CRIU by the local ADNS Manager. 773 The congestion identification function operates in the following 774 sequence. The CAP generates a queue report, at intervals specified by 775 the queue report threshold. This report captures the actual queue 776 levels and sends them to the CRIU. These levels are compared to the 777 queue threshold for each queue. If any queue level is greater than 778 the queue threshold, then a congestion condition exists in that queue. 779 The macro behavior of this arrangement is very similar to congested 780 routers in a conventional Internet so TCP, including the Karn and 781 Nagel algorithms, will work without change. 783 a. Load Sharing 785 One of the key features of ADNS is its ability to share the traffic 786 load over available subnets. In current Navy circuits a situation 787 frequently occurs in which one communication channel is overloaded 788 while another is completely idle. The load sharing feature of ADNS 789 alleviates this problem by shifting some of the congestion to the idle 790 channel, thereby increasing throughput and shortening communication 791 system delays. This differs from load balancing in that balancing 792 distributes traffic over channels with similar metric values before 793 congestion occurs. Sharing distributes traffic over similar cost 794 channels because a congestion condition exists. 796 1) Restrictions 798 There are two restrictions on the use of load sharing. First, the 799 traffic being shifted to an alternate channel must be unicast traffic 800 only. Multicast applications introduce a level of complexity that 801 causes diminished returns, making it not worth the effort to attempt 802 to load share using multicast applications. Second, load sharing is 803 only feasible between subnets whose bandwidths are in the same range, 804 meaning they share a similar time delay. Thus, possible opportunities 805 for a load sharing situation are between UHF and EHF, or between SHF 806 and Challenge Athena. 808 2) Implementation 810 The load sharing process begins when the CRIU determines that a 811 congestion condition exists on a subnet in one of its associated CAPs. 812 The CRIU then scans all other compatible (those with similar delay 813 times) subnets to determine if a path from origin to destination 814 exists. If another subnet does exist with a path from origin to 815 destination and no congestion condition exists on this subnet, load 816 sharing commences. 818 b. Source Quench 820 When congestion is determined to exist in the CAP queue for priority 821 n, the CRIU issues a Source Quench ICMP command. This command stops 822 the generation of message packets for all applications and hosts with 823 priority n or less. Assuming compliant TCPs this Source Quench 824 command has been pre-set to remain in force for five seconds. At the 825 end of five seconds, transmission from the affected hosts and 826 applications resumes automatically unless or until another Source 827 Quench command is issued. It should be noted that all applications 828 and hosts require some sort of flow control to ensure that during 829 Source Quench conditions, packets are not discarded but rather stored 830 for transmission when the Source Quench has timed-out. 832 4. Transmission Control Protocol (TCP) Duplicate Packet Transmission 833 Problems 835 One of the major early setbacks to implementing the ADNS architecture 836 was solving the problem of TCP duplicate transmissions when initially 837 establishing a TCP connection. ADNS causes the LAN gateway router to 838 act as if it is hard-wired to other routers on other LANs. Thus the 839 router expects to encounter minimal delays (less than 0.5 seconds) in 840 receiving acknowledgments to its TCP packets being sent. In reality, 841 these TCP packets are being transmitted over RF links to distant LANs. 842 The minimum acknowledgment time for a 1500 byte packet over a 2400 BPS 843 connection is in the neighborhood of 5 seconds. When TCP hasn't 844 received packet acknowledgment after 0.5 seconds, it re-transmits the 845 packet. If acknowledgement is still not received after an additional 846 1 second, TCP retransmits the packet again, and again after 2 seconds, 847 4 seconds, 8 seconds, and so on. Under optimal conditions, a 1500 848 byte packet will be sent 4 times over a 2400 BPS connection. The end 849 result is the use of 6000 bytes to transmit 1500, an efficiency of 850 25%. 852 a. TCP Duplicate Packet Rejection 854 A practical solution, and the one implemented in ADNS, is to design 855 the CRIU to discard duplicate TCP packets before they are transmitted 856 over the RF link. This is accomplished by the use of a table for each 857 subnet that contains the TCP sequence number and time-stamp indicating 858 when the packet was received by the CRIU for transmitting. A TCP 859 original packet and each duplicate packet sent will have the same TCP 860 sequence number. When a TCP packet is received by the CRIU for 861 transmitting, its TCP sequence number is examined. If this number 862 already exists in the table, the packet is rejected. If this number 863 does not exist in the table, it is added to the table along with its 864 time-stamp, and the packet is passed along for transmission. Each 865 subnet is assigned a TCP duplicate rejection time. If a TCP sequence 866 number has been in the table for longer than the TCP duplicate 867 rejection time, it is deleted from the table. The TCP duplicate 868 rejection time has a default value of 10 seconds. This provides for 869 transmission of the original TCP packet followed by a 10 second delay 870 for acknowledgment. If none is received, the packet is allowed to be 871 retransmitted followed by another 10 second delay. This time delay 872 can be modified by the Local ADNS Manager, based on the latency of the 873 link, for optimum performance. 875 D. ADNS INTEGRATED NETWORK MANAGEMENT 877 1. Overview 879 Network management of ADNS is based on SNMPv1 standards. There are no 880 proprietary Navy protocols to confront, thus allowing the use of 881 standard network management tools and practices. Most of the objects 882 to be managed (hosts, routers, etc) will have agents attached and MIBs 883 will be written for any unique objects. The Navy will adopt a 884 standard, commercial Network Management System (NMS) to provide the 885 foundation for network management. However, there are Navy-specific 886 concerns, such as command and control relationships, which impact 887 network management. For these special requirements, the Navy will 888 create special applications and concepts to the NMS. This section 889 gives a broad description of how the Navy intends to manage ADNS. 891 Network management of naval nodes is similar to managing shore-based 892 nodes. The fundamental concepts are the same. However, the mobile 893 nature of the nodes makes managing shipboard nodes more difficult. 894 The fact that they are warships makes management more important. Just 895 as there is a military hierarchy there is one for network management 896 in ADNS, where each level has different responsibilities. Network 897 management is a vital portion of ADNS because the consequences of 898 system errors or failures can directly affect combat effectiveness. 900 Integrated network management describes how the Navy will manage 901 networks on a distributed basis all the way down to individual 902 objects. They include, but are not limited to: general monitoring, 903 statistic collection, status monitoring, traffic monitoring, trend 904 analysis, network loading, network optimization, configuration 905 control, system configuration, maintenance, problem identification, 906 problem reporting, trouble documentation, system administration, and 907 emissions control [INM Technical Approach]. 909 Network management of ADNS contains three different levels: the Local 910 Control Center (LCC), Autonomous System Control Center (ASCC), and the 911 Navy Operations Center (NOC). The LCC will be responsible for 912 networks at the local level, e.g. within an area (usually a ship). 913 The ASCC will be in charge of networks on a regional level, having 914 several subordinate Autonomous Systems. The NOC will be responsible 915 for all ASCCs in a certain geographic area. This arrangement is 916 consistent with the Navy's organization and its doctrine regarding 917 distribution of authority. 919 a. Local Control Center (LCC) 921 The LCC is the network management center at every unit level. There 922 is a local responsibility to monitor and maintain the status of all 923 subnets at that unit. There are three components of an LCC: a Network 924 Manager, Distributed Manager and a Communication Automation Manager. 926 i) Network Manager 928 The Network Manager is network management system software that is 929 obtained commercially. The purpose of the network manager is 930 basically to give the status of the network and individual objects. 931 An example is the popular HP Open View Network Node Manager product 932 (OV-NNM) which has been in the Navy Tactical Advanced Computer (TAC) 933 contracts since 1991. It provides a topological map representation of 934 a unit's network and shows the status of each object with the use of 935 colors and shapes. However, human interaction is required to 936 interface with the ASCC and the NOC for troubleshooting or 937 maintenance. The specific functions of a Network Manager will be: 939 * Human machine interface 940 * Performance management 941 * Fault management 942 * Accounting management 943 * Security management 944 * Configuration management 946 The Network Manager will be used as the foundation for the Navy's 947 Integrated Network Management System, where specific applications can 948 then be added on to provide other management functions. 950 ii) Distributed Manager 952 Distributed Management is an application that determines what is to be 953 reported locally and what is to be reported to the ASCC and NOC. The 954 Distributed Manager has two mechanisms for discovering if any 955 conditions exist that meet the criteria of its policy rules: 957 * Notification from the Network manager 958 * Query from Distributed Manager to Network Manager 960 The specific functions of the Distributed Manager will be: 961 * Interpretation and implementation of policy 962 * Filtering of management information 964 Although commercial products can provide these functions, the 965 distributed manager in the Navy context specifically describes the 966 policy rules for the communication relationships between the LCC and 967 ASCC. 969 iii) Communication Automation Manager (CAM) 971 The Communication Automation Manager is in charge of the physical 972 communication hardware and their related requirements. On a ship, 973 they are functions typically related to the radio room. Duties 974 include a communication plan implementation, circuit building, and 975 circuit management. Three areas make up the Communication Automation 976 Manager: the Communication Manager, Site Manager, and Equipment 977 Manager. The specific functions of the Communication Automation 978 Manager will be: 980 * Security management 981 * Log Control 982 * Alarm reporting 983 * Summarization 984 * Attributes for representing relationships 985 * Objects and attributes for access control 986 * Usage Metering 987 * Test Management 988 * Event Report Management 989 * State Management 990 * Security alarm reporting 991 * Object management 992 * Bandwidth management 993 * Communication plan management 994 * Equipment control 995 * Site configuration management 997 The Navy specific application for these functions is the use of a 998 remote management tool called the Communications Plan (COMMPLAN). The 999 COMMPLAN will used to direct certain network management functions as 1000 described above. This is still mainly accomplished manually by a 1001 technician after receiving the COMMPLAN via hardcopy message. However 1002 ADNS will allow many of these requirements to be accomplished remotely 1003 and automatically via the COMMPLAN transmitted to the Communication 1004 Automation Manager. This concept can be applied to commercial 1005 industries where it is not cost effective to have the necessary 1006 network management expertise at every local site but can instead be 1007 centralized at one remote center. 1009 b. Autonomous System Control Center (ASCC) 1011 An ASCC monitors the operation of several LCCs. The Navy's 1012 configuration will use its regional shore communications master 1013 stations (NCTAMS) as ASCCs. The ASCC will receive summary reports 1014 from subordinate LCCs. The exact nature of reporting from an LCC to an 1015 ASCC is still to be determined but will contain mission relevant 1016 information. Such reporting requirements can include: 1018 * Readiness of communication to support the mission. 1019 * Status of communication services. 1020 * Status of hardware and software. 1021 * Information about usage and reliability. 1023 ASCCs can also give direction to LCCs regarding communications 1024 posture. This could include such items as prioritization of resources 1025 or equipment configuration changes. 1027 c. Network Operations Center (NOC) 1029 The NOC is the next level above an ASCC for reporting network 1030 management information. The NOC would basically monitor all nodes in 1031 a certain geographic location. For example the Navy has established a 1032 NOC in the Pacific and Atlantic regions. Although capable of 1033 monitoring detailed network management information, a NOC would be 1034 more interested on the overall status of ASCCs and LCCs. 1036 2. NETWORK MANAGEMENT TOOLS 1038 To achieve the above network management requirements, a vast array of 1039 tools are available to all levels of management and maintenance 1040 personnel. However, each tool comes with their own training 1041 requirement. Therefore the total cost of ownership must be taken into 1042 consideration against their utility. The basic tool for monitoring 1043 the network is commercially available Network Management System 1044 software. Another tool available for the goal of transparent and 1045 affordable network management is software that is capable of remote 1046 monitoring and maintenance. These can also be available commercially 1047 or can be developed to be mission specific. There are always emerging 1048 tools on the horizon for new technologies. However, one of the 1049 primary reasons why network management techniques lag behind new 1050 network technologies is that time is needed to see which technologies 1051 will become established as industry standards. ADNS will manage 1052 objects primarily through SNMPv1 standards. That is not to say that 1053 ADNS can not adapt any emerging technologies that become industry 1054 standards, such as SNMPv2. However, SNMP has proved that it will be 1055 around for a long time. 1057 a. Network Management System Software (NMS) 1059 A commercial Network Management System software has been adopted for 1060 the foundation of the INM. Network Management System software allows 1061 for the basic functions of monitoring nodes and network status. As 1062 described earlier, many different types of enterprise management 1063 software are available commercially, such as the popular HP Open View 1064 Network Node Manager (OV-NNM). Although commercial software provides 1065 excellent monitoring tools, proprietary software is often required to 1066 achieve other network management requirements. Commercial Network 1067 Management System software offers a fairly inexpensive solution that 1068 provides a solid foundation of network management tools. 1069 Additionally, to provide the flexibility desired throughout ADNS a 1070 COTS product is appropriate. 1072 b. Third Party Applications 1074 An attractive feature of a Network Management System such as OV-NNM is 1075 that third party applications can be integrated into it. Especially 1076 for organizations like the Navy, solutions to mission specific 1077 requirements can not be obtained off the shelf. These mission specific 1078 add-ons must be developed independently and then integrated into the 1079 existing NMS. Proprietary equipment also requires some kind of 1080 integration with the NMS. Such things as configuration management 1081 software for specific objects must be obtained from the vendor. For 1082 example, companies offer software that can be integrated with an NMS 1083 to allow managers to remotely configure their hardware. Third party 1084 applications offer remote management capability. This is the whole 1085 purpose of enterprise management. It is very cost effective to 1086 centrally manage nodes rather than paying for the necessary expertise 1087 at every local level. Although there needs to be some human 1088 interaction at every level, full management capabilities are not 1089 required down to the local level. 1091 ADNS is a good example of the need for remote management. 1092 Implementation of remote management over ADNS will allow managers to 1093 configure and manage mobile platforms from a central management 1094 location. This, in turn, allows the assignment of minimal personnel 1095 at the local level, thus saving on personnel costs. With such 1096 standards as RMON and SNMPv2, remote managers can access remote 1097 networks in a secure manner and troubleshoot or reconfigure the 1098 network. For example, if one transmission path fails, a remote 1099 manager can gain access to the system via a second transmission path 1100 and troubleshoot the system. The use of more than one transmission 1101 path allows the ability to continually manage LCCs and even ASCCs 1102 remotely through just one open path. Although ADNS has not adopted 1103 such standards as RMON or SNMPv2 yet, the technologies currently exist 1104 and can be readily integrated into ADNS. 1106 III. Hardware 1108 A. LAN 1110 The LAN will typically be the existing shipboard Ethernet or FDDI 1111 network. Hosts on the network will run a wide variety of 1112 applications. 1114 B. Router 1116 The router is an IP router that acts as a gateway to the ADNS network. 1117 The router can be any commercial router capable of running OSPF. 1118 Currently the ADNS program uses the CNX 600 Proteon router. 1120 C. CRIU (Channel Access Protocol to Router Interface Unit) 1122 The CRIU is implemented on a single board computer installed in a VME 1123 chassis. 1125 D. CAP (Channel Access Protocol) 1127 A CAP is also implemented on a single board computer mounted in the 1128 same VME chassis as the CRIU. 1130 E. Cryptographic Device 1132 Navy ADNS installations use the KG-84 for link encryption. 1134 F. Modem 1136 For each CAP there is a corresponding Modem that performs the analog 1137 to digital (inbound) or digital to analog (outbound) conversion of 1138 data passing through ADNS. 1140 G. Connectivity Media 1142 Each RF system (e.g. UHF Satcom, EHF Satcom or INMARSAT B) constitutes 1143 one network when considering all assets in one ADNS Autonomous System. 1145 IV. Acknowledgements. The engineers at NRaD, Code 82 working on 1146 ADNS. 1148 Authors addresses. 1150 Rex A Buddenberg 1151 Naval Postgraduate School 1152 Code SM/Bu 1153 Monterey, Ca 93943 1154 budden@nps.navy.mil 1156 The masters students have graduated and moved to new assignments in 1157 the military. With new e-mail addresses; reach them through the 1158 above. Complete copies of theses available at 1159 http://web.nps.navy.mil/~seanet. 1161 INTERNET DRAFT EXPIRES MARCH 1997 INTERNET DRAFT