idnits 2.17.1 draft-ietf-udlr-ospf-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 5 longer pages, the longest (page 2) being 110 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. 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 (March 1996) is 10269 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) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Emmanuel Duros 4 Internet-Draft INRIA Sophia-Antipolis 6 March 1996 8 Handling of unidirectional links with OSPF 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 To learn the current status of any Internet-Draft, please check the 32 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 34 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 36 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 38 ftp.isi.edu (US West Coast). 40 Abstract 42 This document defines the modifications which can be applied to OSPF 43 [rfc1583] which make the communication over asymmetric links 44 feasible. 46 1. Introduction 48 OSPF is a dynamic routing protocols used in the internet known as 50 Internal Gateway Protocol. It was designed to work on networks where 52 adjacent gateways communicate using the same link in both directions. 54 Links may be asymmetric, e.g., have different delays and throughputs 56 in different directions, but they have to be duplex. 58 2. Overcoming OSPF restrictions 59 A satellite network comprises two sets of stations, feeds that can 61 both send and receive packets, and receivers that can only receive 63 packets. 65 Feeds must be allowed to forward over the satellite links the packets 67 which are bound to subnets accessible through other feeds or through 69 receivers. 71 Receivers will never send any packet via the satellite link. They 73 must however communicate with the designated router to indicate that 75 they are ready to receive packets and are synchronized with their 77 neighbors. 79 If the network included only feeds, OSPF could be used almost 81 unchanged. Usage by a mix of receivers and feeds requires some 83 extensions. 85 3. Proposed solution 87 In our example we assume that G1 and G2 (Gateways) are connected to 89 symmetric and asymmetric networks (See Figure 1). Using OSPF, G1 will 91 never consider G2 as a neighbor because the link is unidirectional 93 and therefore will send packets to the regular connections (route 95 N3). 97 route N1 99 N2 ---- ---- N5 101 ---========>|G1| ===================> |G2|<==========--- 103 ---- update msg ---- 105 /\ /\ 107 || ------------------ || 109 ====| regular |==== 111 N3 | connections | N4 113 ------------------ 115 Figure 1 117 To avoid such behavior, G1 should consider G2 as a neighbor. OSPF 119 should be modified to take into account unidirectional links. 121 3.1. Authentication scheme 123 All OSPF protocol packets (Hello, Database description, etc.) share a 125 common header of 24 bytes. The OSPF packet header includes an 127 authentication type field (8 bits), and 64 bits of data used by the 128 appropriate authentication scheme (determined by the type field). 130 We suggest that all packets sent over the satellite channel should be 132 authenticated, using either type 1 authentication (simple password) 134 or, preferably, a stronger type of authentication. The 136 authentication code will be specific to the satellite network 138 stations. 140 Protocol packets sent over the satellite network will be 142 authenticated and their process will be different as they are 144 received by routers. 146 3.2. The Hello protocol 148 We set up the feeds to the highest Router priority on the network in 150 order to they become designated routers of their area. 152 The Hello protocol normally ensures that communication between 154 directly-connected routers is bidirectional. This should be modified 156 to allow the Hello protocol to work asymmetrically between feeds and 158 receivers connected to the satellite network. 160 When sending Hello protocol packets over the satellite network, feeds 162 authenticate them as "satellite packet" (set a type field and add a 164 specific authentication field). 166 Upon reception of these Hello packets, receivers examine the 168 authentication code. They note that this packet was sent by a 170 satellite feed. They add the packet [IP source] to a list of 172 "potential neighbors". 174 At pseudo-interval receveirs send Hello packets to the potential 176 neighbors. These packets, however, are not sent to the multicast 178 address "to all OSPF routers". A copy is sent to the unicast address 180 of each potential neighbor. These packets are also authenticated as 182 "satellite packet". 184 When receiving these Hello packets which are authenticated as 186 "satellite packet", feeds will process them even if they are routed 188 by another interface. 190 3.3. Network link record 192 The first step of the formation of the shortest path tree is done by 194 considering links between routers and transit networks. The network 196 links advertisement describes all the routers that are attached to a 197 transit network. 199 We suggest to extend the network link record to supply further 201 information concerning the connected routers. Instead of having just 203 a list of connected routers, we may have a list of routers which can 205 only send or receive packets (See Figure 2). 207 0 32 209 |-------------------------------| 211 | Network Mask | 213 |-------------------------------| 215 | Number of Attached Routers | 217 |-------------------------------|- Repeated for 219 | Attached Router | each attached 221 |-------------------------------|- router 223 | . | 225 | . | 227 |-------------------------------| 229 | Number of Senders only | 231 |-------------------------------|- Repeated for 233 | Attached Sender | each attached 235 |-------------------------------|- sender 237 | . | 239 | . | 241 |-------------------------------| 243 | Number of Receivers only | 245 |-------------------------------|- Repeated for 247 | Attached Receiver | each attached 249 |-------------------------------|- receiver 251 | . | 253 | . | 255 |-------------------------------| 257 Figure 2 259 Network Mask: The IP network mask for the network. 261 Number of Attached Routers: represents the number of routers 263 connected to the transit network which can send and receive 265 packets. This field is followed by the list of router's ID. 267 Number of Senders only: represents the number of routers connected to 269 the transit network which can only send packets. This field is 271 followed by the list of router's ID. 273 Number of Receivers only: represents the number of routers connected 274 to the transit network which can only receive packets. This field 276 is followed by the list of router's ID. 278 Senders and receivers only are detected when a router notices that a 280 packet is authenticated as "satellite packet" and also depends on 282 which interface it receives it from. 284 As implemented in OSPF, a graph is built with the information found 286 in the network link record and the router link record. Unidirectional 288 communications are represented by a single vertices and thus the 290 shortest path tree can de determined handling unidirectional links. 292 3.4. Processing protocol packets 294 All protocol packets (Hello, link state request/update, etc) sent by 296 the feeds via the multicast link are authenticated (See section 3.1). 298 From the list of "potential neighbors", receivers can find feed's IP 300 addresses. They send packet protocols to the unicast address of each 302 feed through the regular connection. These packets are also 304 authenticated as "satellite packet". 306 When receiving these packets which are authenticated as "satellite 308 packet", feeds will process them even if they are routed by another 310 interface. 312 References 314 [rfc1583] J. Moy,"OSPF Version 2", Request For Comments (RFC) 1583, 316 Proteon, Inc., March 1994. 318 Author's address 320 Emmanuel Duros 322 INRIA Sophia Antipolis 324 2004, Route des Lucioles BP 93 326 06902 Sophia Antipolis CEDEX France 328 Email : Emmanuel.Duros@sophia.inria.fr 330 Phone : +33 93 65 78 15