idnits 2.17.1 draft-ietf-udlr-general-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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 577 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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.) -- The document date (November 1997) is 9659 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. 'ASBD' -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Emmanuel Duros 3 Internet-Draft Walid Dabbous 4 INRIA Sophia-Antipolis 5 November 1997 7 Supporting Unidirectional Paths in the Internet 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.nTermet (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 1. Introduction 31 Many distributed applications may benefit from a high bandwidth 32 connection to the Internet. However, this requires high bandwidth 33 links between remotes sites. 35 A low-cost solution to deliver high bandwidth services over wide 36 geographical areas via the use of broadcast satellite networks has 37 been proposed by [ASBD]. 39 However, this solution is based on low cost receivers with zero 40 bandwidth return. Connection over the satellite link is therefore 41 unidirectional. The integration of these satellite networks with the 42 Internet requires changes in common routing protocols. 44 2. A new architecture 46 The advantage of a satellite network is to provide high bandwidth 48 services independent of the user's location over a large geographical 50 area. 52 A satellite network comprises two types of stations: feeds, which can 54 both send and receive packets, and receivers, which can only receive 56 packets. 58 Every receiver is composed of a satellite dish oriented toward a 60 geostationary satellite, connected via an interface either to a user 62 station (in this case the access method is referred to as basic 64 access) or to a router (in this case the access method is referred to 66 as subnetwork access). The user station has another interface, and 68 the router has one or more extra interfaces, connected to the 70 Internet. Note that the cost of the hardware is made up of the cost 72 of the satellite dish and of the reception card. 74 Information is sent from feeds to satellites and then broadcast to 76 all the receivers that belong to the satellite coverage. 78 Installing feeds in strategic positions over the Internet will create 80 shorter paths and packets will be routed via the satellite network 82 that offers a higher bandwidth. 84 2.1 Basic access 86 Basic access corresponds to the case when each receiver has a 88 satellite dish. The user's station is also connected to the Internet 90 via a telephone/modem (e.g. PPP connection). This station has 92 therefore two IP addresses, one belonging to the satellite subnet 94 (SAT.x) and the other to the regular connection subnet (INT.y). See 96 Figure 1. 98 ___ ___ 100 \__\OO\__\ Satellite 102 ^^ vv Network 104 / \ 106 uplink / \ 108 / \ 110 / \ 112 Feed / \ 114 ---- / SAT.x V ---- User's 116 ---======>|R1| |H1| station 118 ---- ---- 120 /\ /\ INT.y 122 || || 124 Server \/ || (PPP connection) 126 ---- ------------------------- || 128 |S1|<==>| regular |<==/ 130 ---- | connections | 132 ------------------------- 134 Figure 1: Basic access 136 All requests to a remote server are sent via the phone line and 138 responses from the server should be routed by a feed on the satellite 140 network. 142 2.2 Subnetwork access 144 Subnetwork access corresponds to the case when a subnet router has a 146 satellite dish. See Figure 2. This router is then interconnected to 148 the Internet via regular connections and to a subnetwork (such as R2 150 in Figure 2). 152 ___ ___ 154 \__\OO\__\ Satellite 156 R1: Feed ^^ vv Network 158 R2: Receiver / \ 160 / \ 162 uplink / \ 164 / \ 166 / \ 168 ---- / V ---- ------------- 170 ---======>|R1| |R2|<===>| Subnetwork|<===--- 172 ---- ---- ------------- 174 /\ /\ 176 || || 178 Server \/ || 180 ---- ------------------------- || 182 |S1|<==>| regular |<==/ 184 ---- | connections | 186 ------------------------- 188 Figure 2: Subnetwork access 190 In that configuration only one satellite dish is required in order to 192 serve a whole subnetwork. The management is also located in only one 194 place, namely in the router. 196 3. Solutions 198 For the basic access and the subnetwork access we propose solutions 200 in order to handle unidirectional links. 202 3.1 A dynamic routing 204 Satellite networks are able to cover nationwide areas and therefore 206 address very important sets of receivers. 208 That 'expandable topology' due to the potential increasing number of 210 receivers (simple host or routers) leads us to consider dynamic 212 routing solutions. 214 Some modifications should be applied to protocols in order to handle 216 unidirectional links. For example, the protocol ARP [rfc826] assumes 218 that links are bidirectional, and it expects a communication between 220 directly connected host. In the same way, routing protocols assume 222 that communication between neighbor routers is bidirectional to 224 exchange routing information. The configuration in Figure 2 is 226 therefore not supported. 228 3.2 Basic Access 230 The ARP protocol can not work properly, an ARP request sent by a feed 232 to a host that belongs to the satellite network can not expect a 234 response from receivers. 236 Routing for that type of user's station is different from classical 238 routing. Indeed, the station has two IP addresses : SAT.x (belongs to 240 the satellite network) and INT.y (e.g. PPP connection to an Internet 242 service provider), as depicted in Figure 1. 244 Users send packets via the interface INT.y, incoming packets should 246 be routed to the default address SAT.x. 248 3.3 Subnetwork access 250 We consider here feeds and receivers as IP routers (R1 and R2 in 252 Figure 3). The general problem is : how can a receiver announce 254 routes to feeds since it can not communicate directly with them ? 256 Our work is mainly based on the study of the most common routing 258 protocols that will be used by feeds and receivers such as RIP 260 [rfc1723] and OSPF [rfc1583] and DVMRP [rfc1075] for multicast 262 routing. 264 Unlike receivers, feeds can broadcast routing messages via the 266 satellite network. A feed will expect to receive messages (e.g. a 268 response to a request on a specific interface) from all its 270 interfaces. Since a feed can not receive messages from the satellite 272 network, routing protocols will consider that there is no reachable 274 networks beyond it. 276 In order to announce routes to feeds by receivers routing messages 278 must be sent to the unicast address of each feed. This assumes that 280 receivers can communicate with feeds via regular connections (See 282 Figure 3). 284 ___ ___ 286 \__\OO\__\ Satellite 288 R1: Feed ^^ vv Network 290 R2: Receiver ~/ \ 292 / \ 294 uplink / \ 296 / \ 298 / \ 300 ---- / V ---- 302 ---======>|R1| |R2|<=======--- 304 ---- ---- 306 /\ /\ 308 || ----------------- || 310 ====| regular |==== 312 | connections | 314 ----------------- 316 Figure 3 318 Moreover, both the feed's and receiver's interfaces connected to the 320 Internet (regular connection) hardly ever belong to the same 322 subnetwork (due to long distances between feeds and receivers). 324 Routing protocol daemons check, in order to ensure security, that the 326 sender's address of a message belongs to the same subnetwork as the 328 interface which received it. Therefore routing information will not 330 be taken into account since the packet will be rejected. 332 We have just described some problems that occur when trying to handle 334 unidirectional links by common routing protocols. Specific problems 336 related to RIP [1], OSPF [2] and DVMRP [3] are described in other 338 documents. They are available at ftp://zenon.inria.fr/rodeo/udlr/ 340 4. Conclusion 342 Improving user connectivity to the Internet at low cost seems 344 possible, e.g. both for basic access or subntework access. 346 However handling unidirectional links by standard routing protocols 348 (RIP, OSPF, DVMRP) is not trivial and currently not supported. It 350 requires changes in the current protocol specifications. Fortunately 352 these changes should not lead to new versions of routing protocols 354 (RIP and DVMRP) and should be transparent for routers not connected 356 to satellite networks. 358 References 360 [ASBD] V. Arora, N. Suphasindhu, J.S. Baras, D. Dillon, Asymmetric 362 Internet Access over Satellite-Terrestrial Networks, 364 http://www.isr.umd.edu/CCDS/research/AIA/sld001.htm 366 [1] C. Huitema, E. Duros, ftp://zenon.inria.fr/rodeo/udlr/draft- 368 ietf-rip-unidirectional-link-00.txt, March 96 370 [2] E. Duros, ftp://zenon.inria.fr/rodeo/udlr/draft-ietf-ospf- 372 unidirectional-link-00.txt, March 96 374 [3] W. Dabbous, E. Duros, ftp://zenon.inria.fr/rodeo/udlr/draft- 376 ietf-dvmrp-unidirectional-link-00.txt, March 96 378 [rfc823] David C. Plummer, "An Ethernet Address Resolution Protocol", 380 Request For Comments (RFC) 826, November 1982. 382 [rfc1723] Malkin, G., "RIP Version 2 - Carrying Additional 384 Information", Request For Comments (RFC) 1723, Xylogics, Inc., 386 November,1994. 388 [rfc1583] J. Moy,"OSPF Version 2", Request For Comments (RFC) 1583, 390 Proteon, Inc., March 1994. 392 [rfc1075] S. Deering, C. Partridge, D. Waitzman, "Distance Vector 394 Multicast Routing Protocol", November 1988. 396 Author's address 398 Emmanuel Duros 400 INRIA Sophia Antipolis 402 2004, Route des Lucioles BP 93 404 06902 Sophia Antipolis CEDEX France 406 Email : Emmanuel.Duros@sophia.inria.fr 408 Phone : +33 4 93 65 78 15 410 Walid Dabbous 412 INRIA Sophia Antipolis 414 2004, Route des Lucioles BP 93 416 06902 Sophia Antipolis CEDEX France 418 Email : Walid.Dabbous@sophia.inria.fr 420 Phone : +33 4 93 65 77 18