idnits 2.17.1 draft-bush-ncp-config-01.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-18) 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 57 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([4,5], [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 9954 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' -- Unexpected draft version: The latest known version of draft-bush-rdrn-mib is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. '2' -- Unexpected draft version: The latest known version of draft-bush-vnc-mib is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 9 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 ATM 7 Beamformed 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@ittc.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 Shadow 29 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) is used in support of an ATM-based 36 wireless communication system [4,5] that will be adaptive at both the 37 link and network levels to allow for rapid deployment and response to 38 a changing environment. The objective of the architecture is to use 39 adaptive point-to-point topology to gain the advantages of ATM for 40 wireless networks. A prototype of this system has been implemented 41 and will be demonstrated over a wide area network. The system adapts 42 to its environment and can automatically arrange itself into a high 43 capacity, fault tolerant, and reliable network. The network archi- 44 tecture is composed of two overlaid networks: 46 1. A low bandwidth, low power omni-directional network for location 47 dissemination, switch coordination, and management which is the 48 orderwire network described in this section, 50 2. A ``cellular-like'' system for multiple end-user access to the 51 switch using directional antennas for spatial reuse, and and a high 52 capacity, highly directional, multiple beam network for switch-to- 53 switch communication. 55 The network currently consists of two types of nodes, ENs and RNs. 56 ENs were designed to reside on the edge of a wired network and pro- 57 vide access to the wireless network; however, ENs also have wireless 58 links. The EN components include ESs and optionally an ATM switch, a 59 radio handling the ATM-based communications, a packet radio for the 60 low speed orderwire running a protocol based on X.25 [1], GPS 61 receiver, and a processor. Host nodes or remote nodes (RN) consist of 62 the above, but do not contain an ATM switch. The ENs and RNs also 63 include a phased array steerable antenna. The network uses position 64 information from the GPS for steering antenna beams toward nearby 65 nodes and nulls toward interferers, thus establishing the high capac- 66 ity links. Note that multiple RNs may share the same beam from the 67 ES. The decision involving which beams to establish and which fre- 68 quencies to use is made by the NCP which is discussed in the next 69 section. 71 The ES has the capability of switching ATM cells among connected RNs 72 or passing the cells on to an ATM switch to wire-based nodes. Note 73 that the differences between an ES and RN are that the ES performs 74 switching and has the capability of higher speed radio links with 75 other Edge Switches as well as connections to wired ATM networks. 77 The orderwire network uses a low power, omni-directional channel, 78 operating at 19200 bps, for signaling, control, and communicating 79 node locations to other network elements. The orderwire aids link 80 establishment between the ESs and between the RNs and ESs, tracking 81 remote nodes and determining link quality. The orderwire operates 82 over packet radios and is part of the NCP. The protocol stack for 83 this network is shown in Table 1. 85 Network Control Protocol Description 87 Network Control Protocol Terminology 89 This section defines some of the terminology used in the Description 90 of the NCP operation. 92 o "AX.25" 94 Asynchronous X.25 Protocol (See [1]). 96 o "Callsign" 98 The packet radio callsign is assigned by the FCC and 99 identifies the packet radio operator. 101 o "Edge Switch" (ES) 103 A node which either resides within the wireless 104 network or at the edge of the fixed and 105 wireless network and which serves as a base station. 107 o "Global Positioning System" (GPS) 109 Satellite system which provides location and time. 111 o "Remote Node" (RN) 113 A host with the ability to connect via a beamforming 114 antenna to an edge switch (ES). 116 Network Control Protocol Operation 118 The protocol stack for the wireless system [4,5] is shown in Table 1. 119 At the physical level we will be using the orderwire to exchange 120 position, time and link quality information and to setup the wireless 121 connections. The process of setting up the wireless connections 122 involves setting up links between ESs and between ESs and RNs. 124 ------------------------------------------------------------------------- 125 | Wireless Link Protocol | Signaling Protocol | Band | 126 ------------------------------------------------------------------------- 127 | TCP/UDP | | In-Band | 128 ------------------------------------------------------------------------- 129 | Mobile IP | | In-Band | 130 ------------------------------------------------------------------------- 131 | IP over ATM | | In-Band | 132 ------------------------------------------------------------------------- 133 | AAL 5 | | In-Band | 134 ------------------------------------------------------------------------- 135 | ATM | Q.2931 | In-Band | 136 ------------------------------------------------------------------------- 137 | Adaptive HDLC | | In-Band | 138 ------------------------------------------------------------------------- 139 | Virtual Fiber (Radio Link) | NCP | Out-of-Band | 140 ------------------------------------------------------------------------- 142 Table 1: Protocol Stack 144 The network will have one Master ES, which will run the topology con- 145 figuration algorithm and distribute the resulting topology informa- 146 tion to all the connected ESs over point-to-point orderwire packet 147 radio links. In the current prototype the point-to-point link layer 148 for the orderwire uses AX.25 [1]. The Master ES is initially the 149 first active ES, and any ES has the capability of becomming a Master 150 ES. 152 The following description of the RDRN Orderwire operation references 153 the state transitions labeled in Table 2. The first ES to become 154 active initially broadcasts its callsign and start-up-time in a 155 MYCALL packet and listens for responses from any other ESs (Label I1 156 in Table 2). In this prototype system, the packet radio callsign is 157 assigned by the FCC and identifies the radio operator. Since it is 158 assumed that this is the first active ES, there is no response within 159 the given time period, T. At the end of T seconds, the ES rebroad- 160 casts its MYCALL packet and waits another T seconds. At the end of 2T 161 seconds, if there are still no responses from other ESs, the ES acti- 162 vates and takes on the role of the Master ES (Label I4 in Table 2). 163 If the first two or more ESs start up within T seconds of each other, 164 at the end of the interval T, the ESs compare the start-up times in 165 all the received MYCALL packets and the ES with the oldest start-up 166 time becomes the Master ES. In this system, accurate time stamps are 167 provided by the GPS receiver. 169 Each successive ES that becomes active broadcasts its callsign in a 170 MYCALL packet (Label I1 in Table 2). Upon receipt of a MYCALL packet, 171 the Master ES extracts the callsign of the source, establishes an 172 AX.25 point-to-point link to the new ES and sends it a NEWSWITCH 173 packet (Label I2 in Table 2). On receipt of the NEWSWITCH packet 174 over a point-to-point orderwire link, the ES obtains its position 175 from its GPS receiver and sends its position to the Master ES as a 176 SWITCHPOS packet over the point-to-point orderwire link (Label I3 in 177 Table 2). On receipt of a SWITCHPOS packet, the Master ES records the 178 position of the new ES in its switch position table and runs the 179 topology configuration algorithm to determine the best possible 180 interconnection of all the ESs. The master then distributes the 181 resulting information to all the ESs in the form of a TOPOLOGY packet 182 over the point-to-point orderwire links (Label I4 in Table 2). Each 183 ES then uses this information to setup the ES links as specified by 184 the topology algorithm. The Master ES also distributes a copy of its 185 switch position table to all the ESs over the AX.25 point-to-point 186 orderwire links which they can use in configuring RNs as discussed 187 below. The ES then uses the callsign information in the switch posi- 188 tion table to setup any additional point-to-point orderwire packet 189 radio links corresponding to the ES links required to exchange any 190 link quality information. Thus, this scheme results in a point-to- 191 point star network of orderwire links with the Master ES at the cen- 192 ter of the star and the point-to-point orderwire links between those 193 ESs which have a corresponding ES links. In the event of failure of 194 the master node which can be detected by listening for the AX-25 mes- 195 sages generated on node failure, the remaining ESs exchange MYCALL 196 packets (Label I1-I3 in Table 2), elect a new master node, and the 197 network of ESs is reconfigured using the topology configuration algo- 198 rithm (I4). 200 The ES/RN operation is described by Tables 2 and 3. The packet con- 201 tents are shown in Table 4. Each RN that becomes active obtains its 202 position from its GPS receiver and broadcasts its position as a 203 USER_POS packet over the orderwire network (Label A1 in Table 3). The 204 timeout value in Table 3 is the USER_POS update period. The USER_POS 205 packet is received by all ESs within range (Label A2 in Table 3). 206 Each ES then computes the distance between the RN which originated 207 the USER_POS message and all ESs within range. This is possible since 208 each ES has the positions of all the other ESs from the switch posi- 209 tion table. An initial guess at the best ES to handle the RN is the 210 closest ES. This ES then feeds the new RN's position information 211 along with the positions of all its other connected RNs to the beam- 212 forming algorithm. The beamforming algorithm returns the steering 213 angles for each of the beams originating from the ES so that all the 214 RNs are covered. If the beamforming algorithm determines that a beam 215 and TDMA time slot are available to support the new RN, the ES steers 216 its beams so that all its connected RNs and the new RN are covered 217 (Label R1 in Table 3). The ES also records the new RN's position in 218 its user position table, establishes a point-to-point orderwire link 219 to the new RN, and sends the new RN a HANDOFF packet with link setup 220 information indicating that the RN is associated with it (Label R2 in 221 Table 3). If the new RN cannot be accommodated, the ES sends it a 222 HANDOFF packet with the callsign of the next closest ES, to which the 223 RN sends another USER_POS packet over a point-to-point orderwire 224 link. This ES then uses the beamform algorithm to determine if it 225 can handle the RN. 227 This scheme uses feedback from the beamforming algorithm together 228 with the distance information to configure the RN. It should be noted 229 that the underlying AX.25 protocol [1] provides error free transmis- 230 sions over point-to-point orderwire links. Also the point-to-point 231 orderwire link can be established from either end and the handshake 232 mechanism for setting up such a link is handled by AX.25. If the RN 233 does not receive a HANDOFF packet within a given time it uses a retry 234 mechanism to ensure successful broadcast of its USER_POS packet. 236 A point-to-point orderwire link is retained as long as a RN is con- 237 nected to a particular ES and a corresponding high-speed link exists 238 between them to enable exchange of link quality information. The link 239 can be torn down when the mobile RN migrates to another ES in case of 240 a hand-off. Thus at the end of this network configuration process, 241 three overlaid networks are established; an orderwire network, an RN 242 to ES network, and an ES to ES network. The orderwire network has 243 links between the Master ES and every other active ES in a star con- 244 figuration, links between ESs connected by ES links as well as links 245 between RNs and the ESs to which they are connected. Raw pipes for 246 the user data links between RNs and appropriate ESs as well as for 247 the user data links between ESs are also established. Finally, see 248 [2, 3] for the definition of managed objects for the NCP and Virtual 249 Network Configuration (VNC). 251 ------------------------------------------------------------------------ 252 |State | Input | Output | Next State | Label | 253 ------------------------------------------------------------------------ 254 |Init. | None | MYCALL | Init. | I1 | 255 | | MYCALL | NEWSWITCH | Init. | I2 | 256 | | NEWSWITCH | None | Init. | I3 | 257 ------------------------------------------------------------------------ 258 |master only | Timeout (T) | TOPOLOGY | Active | I4 | 259 ------------------------------------------------------------------------ 260 | | TOPOLOGY | None | Active | I4 | 261 ------------------------------------------------------------------------ 262 |Active | USER_POS | None | RnUpdate | A1 | 263 | | TOPOLOGY | None | Active | A2 | 264 | | MYCALL | None | Init. | A3 | 265 | | SWITCHPOS | None | Init. | A4 | 266 ------------------------------------------------------------------------ 267 |RnUpdate | None | None | Active | R1 | 268 | | None | HANDOFF | Active | R2 | 269 ------------------------------------------------------------------------ 271 Table 2: ES Finite State Machine 273 ------------------------------------------------------------------------ 274 |State | Input | Output | Next State | Label | 275 ------------------------------------------------------------------------ 276 |Init. | None | None | Active | C1 | 277 ------------------------------------------------------------------------ 278 |Active | timeout | USER_POS | Active | A1 | 279 | | HANDOFF | None | Init. | A2 | 280 ------------------------------------------------------------------------ 282 Table 3: RN Finite State Machine 284 Network Control Protocol Packet Types 286 The network control protocol uses the following packet types shown 287 below. 289 ------------------------------------------------------------------------- 290 |MYCALL | Callsign, Boot-Time | 291 ------------------------------------------------------------------------- 292 |NEWSWITCH | empty packet | 293 ------------------------------------------------------------------------- 294 |SWITCHPOS | GPS Time, GPS Position | 295 ------------------------------------------------------------------------- 296 |TOPOLOGY | Callsign and Position of each node with inter-connections | 297 ------------------------------------------------------------------------- 298 |USER_POS | Callsign, GPS Time, GPS Position | 299 ------------------------------------------------------------------------- 300 |HANDOFF | Frequency, Time Slot, ES GPS Position | 301 ------------------------------------------------------------------------- 303 Table 4: NCP Packet Contents 305 The MYCALL packet contains the ES identifier (packet radio Callsign) 306 and the time it powered-up. 308 The NEWSWITCH packet is an empty packet which serves as an acknowl- 309 edgment and completes the handshake between the ES and RN. 311 The SWITCHPOS packet contains the current ES time and location. 313 The TOPOLOGY packet contains packet radio callsigns and positions of 314 all nodes and the beamformed links to be established between them. 316 The USER_POS packet contains the callsign, current time, and position 317 of an RN. 319 The HANDOFF packet contains the frequency, time slot, and ES posi- 320 tion. It is sent by an ES to a RN indicating handoff to this ES. 322 Security Considerations 324 All orderwire packets are DES encrypted. 326 References 328 [1] AX.25 Amateur Packet Radio Link-Layer Protocol, IEEE October 329 (1984). 331 [2] The Definition of Managed Objects for the Configuration of 332 Mobile Wireless Beamformed GPS-Based Networks, 333 draft-bush-rdrn-mib-01.txt, Stephen F. Bush, Sunil Jagannath. 335 [3] The Definition of Managed Objects for Virtual Network 336 Configuration, draft-bush-vnc-mib-01.txt, Stephen F. Bush, 337 Sunil Jagannath. 339 [4] The Design and Analysis of Virtual Network Configuration for a 340 Wireless Mobile ATM Network, Stephen F. Bush, PhD Thesis, 341 University of Kansas, August, 1997. 343 [5] A Control and Management Network for Wireless ATM Systems, 344 Stephen F. Bush and Sunil Jagannath and Joseph B. Evans, 345 and Victor Frost and Gary Minden and K. Sam Shanmugan, August, 346 1997, ACM-Baltzer Wireless Networks (WINET), 347 http://www.ittc.ukans.edu/~sbush. 349 Author's Address 351 Stephen F. Bush 352 Sunil Jagannath 353 Information and Telecommunications Technologies Center (ITTC) 354 University of Kansas 355 Lawrence, Kansas 66045 357 Phone: (913) 864-7761 359 EMail: sbush@ittc.ukans.edu