idnits 2.17.1 draft-bush-ncp-config-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-26) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- The document date (January 16, 1997) is 9962 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Stephen Bush 2 Expires in June 1997 Sunil Jagannath 3 ITTC 4 January 16, 1997 6 Network Control Protocol for the Configuration of Mobile Wireless Beam- 7 formed GPS-Based Networks 9 Status of this Memo 11 This document is a submission by the Information and Telecommunica- 12 tions Technologies Center (ITTC) at the University of Kansas. Com- 13 ments should be submitted to sbush@tisl.ukans.edu. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are working doc- 18 uments of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute work- 20 ing documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference mate- 25 rial or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 29 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Abstract 35 The Network Control Protocol (NCP) facilitates the configuration and 36 rapid reconfiguration of mobile wireless beam-formed networks. It 37 controls the operation of a network of omni-directional packet radios 38 (orderwire) that overlays the mobile wireless network. Each network 39 element in this network uses Global Positioning System (GPS) informa- 40 tion to control a beamforming antenna subsystem which provides for 41 spatial reuse. The GPS information is shared among the network ele- 42 ments over the orderwire and an optimal topology for the beam-formed 43 links is determined. 45 Network Control Protocol Description 46 Network Control Protocol Terminology 48 This section defines some of the terminology used in the Description 49 of the NCP operation. 51 o "AX.25" 53 Asynchronous X.25 Protocol (See [1]). 55 o "Callsign" 57 The packet radio callsign is assigned by the FCC and 58 identifies the packet radio operator. 60 o "Edge Switch" (ES) 62 A node which either resides within the wireless 63 network or at the edge of the fixed and 64 wireless network and which serves as a base station. 66 o "Global Positioning System" (GPS) 68 Satellite system which provides location and time. 70 o "Remote Node" (RN) 72 A host with the ability to connect via a beamforming 73 antenna to an edge switch (ES). 75 Network Control Protocol Operation 77 At the physical level we will be using the orderwire to exchange 78 position, time and link quality information and to setup the wireless 79 connections. The process of setting up the wireless connections 80 involves setting up links between ESs and between ESs and RNs. 82 The network will have one master ES, which will run a topology con- 83 figuration algorithm and distribute the resulting topology informa- 84 tion to all the connected ESs over point-to-point orderwire packet 85 radio links. The point-to-point link layer for the orderwire uses 86 AX.25 [1]. The master ES is initially the first active ES, and any 87 ES has the capability of playing the role of the master. 89 The first ES to become active initially broadcasts its callsign and 90 start-up-time in a MYCALL packet, and listens for responses from any 91 other ESs. In this prototype system, the packet radio callsign is 92 assigned by the FCC and identifies the radio operator. Since it is 93 the first active ES, there would be no responses in a given time 94 period, say T. At the end of T seconds, the ES rebroadcasts its 95 MYCALL packet and waits another T seconds. At the end of 2T seconds, 96 if there are still no responses from other ESs, the ES assumes that 97 it is the first ES active and takes on the role of the master. If the 98 first two or more ESs start up within T seconds of each other, at the 99 end of the interval T, the ESs compare the start-up times in all the 100 received MYCALL packets and the ES with the oldest start-up time 101 becomes the master. In this system, accurate time stamps are provided 102 by the GPS. 104 Each successive ES that becomes active initially broadcasts its call- 105 sign in a MYCALL packet. The master on receipt of a MYCALL packet 106 extracts the callsign of the source, establishes a point-to-point 107 link to the new ES and sends it a NEWSWITCH packet. The new ES on 108 receipt of the NEWSWITCH packet over a point-to-point orderwire link, 109 obtains its position from its GPS receiver and sends its position to 110 the master as a SWITCHPOS packet over the point-to-point orderwire 111 link. On receipt of a SWITCHPOS packet, the master records the posi- 112 tion of the new ES in its switch position table, which is a table of 113 ES positions, and runs the topology configuration algorithm to deter- 114 mine the best possible interconnection of all the ESs. The master 115 then distributes the resulting information to all the ESs in the form 116 of a TOPOLOGY packet over the point-to-point orderwire links. Each ES 117 then uses this information to setup the inter-ES links as specified 118 by the topology algorithm. The master also distributes a copy of its 119 switch position table to all the ESs over the point-to-point order- 120 wire links, which they can use in configuring RNs as discussed below. 121 Also, the ES then uses the callsign information in the switch posi- 122 tion table to setup any additional point-to-point orderwire packet 123 radio links corresponding to the inter ES links required to exchange 124 any link quality information. Thus this scheme results in a point-to- 125 point star network of orderwire links with the master at the center 126 of the star and also point-to-point orderwire links between those ESs 127 that have a corresponding inter ES link. 129 In the event of failure of the master node which can be detected by 130 listening for the AX-25 messages generated on node failure, the 131 remaining ESs exchange MYCALL packets, elect a new master node, and 132 the network of ESs is reconfigured. 134 Each RN that becomes active obtains its position from its GPS 135 receiver and broadcasts its position as a USER_POS packet over the 136 orderwire network. This packet is received by all the nearby ESs. 138 Each candidate ES then computes the distance between the RN and all 139 the candidate ESs which is possible since each ES has the positions 140 of all the other ESs from the switch position table. An initial guess 141 at the best ES to handle the RN is the closest ES. This ES then feeds 142 the new RN's position information along with the positions of all its 143 other connected RNs to a beamforming algorithm that returns the 144 steering angles for each of the beams on the ES so that all the RNs 145 can be configured. If the beamforming algorithm determines that a 146 beam and TDMA time slot are available to support the new RN, the ES 147 steers its beams so that all its connected RNs and the new RN are 148 configured. It also records the new RN's position in its user posi- 149 tion table which contains positions of connected RNs, establishes a 150 point-to-point orderwire link to the new RN and sends it a HANDOFF 151 packet with link setup information indicating that the RN is con- 152 nected to it. If the new RN cannot be accommodated, the ES sends it a 153 HANDOFF packet with the callsign of the next closest ES, to which the 154 RN sends another USER_POS packet over a point-to-point orderwire 155 link. This ES then uses the beamform algorithm to determine if it can 156 handle the RN. 158 This scheme uses feedback from the beamforming algorithm together 159 with the distance information to configure the RN. It should be noted 160 that the underlying AX.25 protocol [3] provides error free transmis- 161 sions over point-to-point orderwire links. Also the point-to-point 162 orderwire link can be established from either end and the handshake 163 mechanism for setting up such a link is handled by AX.25. If the RN 164 does not receive a HANDOFF packet within a given time it uses a retry 165 mechanism to ensure successful broadcast of its USER_POS packet. 167 A point-to-point orderwire link is retained as long as a RN is con- 168 nected to a particular ES and a corresponding high-speed link exists 169 between them to enable exchange of link quality information. The link 170 can be torn down when the mobile RN migrates to another ES in case of 171 a hand-off. Thus at the end of this network configuration process, 172 three overlaid networks are setup, namely, an orderwire network, an 173 RN to ES network and an inter-ES network. The orderwire network has 174 links between the master ES and every other active ES in a star con- 175 figuration, links between ESs connected by inter-ES links as well as 176 links between RNs and the ESs to which they are connected. Raw pipes 177 for the user data links between RNs and appropriate ESs as well as 178 for the user data links between ESs are also set up. 180 Finally, see [2] and [3] for the definition of managed objects for 181 the NCP and Virtual Network Configuration (VNC). 183 Network Control Protocol Packet Types 184 The network control protocol uses the following packet types shown 185 below. 187 ----------------------------------------------------------------------- 188 |MYCALL | Callsign, Boot-Time | 189 ----------------------------------------------------------------------- 190 |NEWSWITCH | empty packet | 191 ----------------------------------------------------------------------- 192 |SWITCHPOS | GPS Time, GPS Position | 193 ----------------------------------------------------------------------- 194 |TOPOLOGY | Callsign and Position of each node with inter-connections | 195 ----------------------------------------------------------------------- 196 |USER_POS | Callsign, GPS Time, GPS Position | 197 ----------------------------------------------------------------------- 198 |HANDOFF | Frequency, Time Slot, ES GPS Position | 199 ----------------------------------------------------------------------- 201 The MYCALL packet contains the ES identifier (packet radio Callsign) 202 and the time it powered-up. 204 The NEWSWITCH packet is an empty packet which serves as an acknowl- 205 edgment and completes the handshake between the ES and RN. 207 The SWITCHPOS packet contains the current ES time and location. 209 The TOPOLOGY packet contains packet radio callsigns and positions of 210 all nodes and the beamformed links to be established between them. 212 The USER_POS packet contains the callsign, current time, and position 213 of an RN. 215 The HANDOFF packet contains the frequency, time slot, and ES posi- 216 tion. It is sent by an ES to a RN indicating handoff to this ES. 218 Security Considerations 220 All orderwire packets are DES encrypted. 222 References 224 [1] AX.25 Amateur Packet Radio Link-Layer Protocol, IEEE October 225 (1984). 227 [2] The Definition of Managed Objects for the Configuration of Mobile 228 Wireless Beamformed GPS-Based Networks, draft-bush-rdrn- 229 mib-00.txt, 230 Stephen F. Bush, Sunil Jagannath. 232 [3] The Definition of Managed Objects for Virtual Network Configura- 233 tion, 234 draft-bush-vnc-mib-00.txt, Stephen F. Bush, Sunil Jagannath. 236 Author's Address 238 Stephen F. Bush 239 Sunil Jagannath 240 Information and Telecommunications Technologies Center (ITTC) 241 University of Kansas 242 Lawrence, Kansas 66045 244 Phone: (913) 864-7761 246 EMail: sbush@tisl.ukans.edu