idnits 2.17.1 draft-ietf-udlr-assym-broadcast-links-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-24) 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 7 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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: ---------------------------------------------------------------------------- == Line 151 has weird spacing: '...routers so th...' == Line 249 has weird spacing: '...briefly as a ...' -- 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: 9 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Crowcroft 3 Expires in six months UCL CS 4 Oct 15 1998 6 Internet Architecture Considerations for 7 Assymetric and Unidirectional Broadcast Links 8 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 Satellite hops, the region between a basestation and a set of mobile 29 nodes, and a number of other similar scenarios represent a challenge 30 to providing IP connectivity at various levels due to the 1-many 31 broadcast nature of the link. The UDLR group has addressed these 32 problems in some limited situations. The general case, where 33 multiple, possibly partially intersecting set of such hops are part 34 of a general set of Internet Paths (or need to be considered in the 35 route computation that will buld such paths) is complex. This note is 36 an attempt to outline a framework for the general case. We include 37 certain recent approaches to managing connectivity that also include 38 quality of service, multiple alternate paths, and traffic engineering 39 considerations. 41 In this version of this note, we are discussing techniques for 42 connectivity, so mechanisms and techniques described are applicable 43 to routers. We would need a seperate (and hopefully much simpler) set 44 of mechanisms to incorporate hosts that exist on a unidirectional 45 link or path that includes such links. 47 Introduction 49 Essentially, the protocol stack is like this: 51 Applications Stack Control Stack Infrastructure Stack 53 TCP or RTP/UDP RTSP/RTCP SIP/SAP/DNS/DHCP/Neighbour 54 IP RSVP PIM/OSPF 55 MPLS LDP 56 ATM Q.2931-like I-PNNI 58 DVB Whatever? ? 60 and of course there is also a management stack. 62 UDLR to date Currently, the UDLR Working Group in the IETF has defined 63 several pieces of the architecture for incorporating uni-directional 64 links into a general-purpose IP routing infrastructure. The present 65 versions of these proposals are the following: 67 1) Supporting Unidirectional Paths in the Internet, , An IP tunnelling approach for Uni- 69 directional Link routing, , 71 2) Dynamic Tunnel Configuration Protocol, , 74 3) Dynamic Tunnelling Path Configuration for Uni-directional Link 75 Routing, , 77 4) Handling of unidirectional links with DVMRP, , 80 5) Handling of unidirectional links with OSPF, , 83 6) Handling of unidirectional links with RIP, and 86 &) VIPRE -- Virtual Internet Packet Relay, An Encapsulation Architec- 87 ture for Unidirectional ]. 89 All are narrowly focussed on the case of a single Uni-directional 90 hop within a general Internet path. Luckily, this corresponds to 91 likely scenarios for work within COIAS for demonstration, although 92 we are clearly interested in the general case. To this end, we 93 will design a more general architecture for the general case of a 94 path with multiple unidirectional forward hops, possibly overlap- 95 ping, possibly partially. 97 Idea 99 Well, in our case, we have an unusual set of topological con- 100 straints - we have assymetric, and unidirectional links (e.g. 101 satellite portions of connectivity). This is at odds with much of 102 the curent Internet architecture, which is centered very much on 103 symmetric, or at least bi-directional dedicated or shared links. 105 On the satellite hops, we have some number of routers connected to 106 uplinks, and some (many more) routers (and hosts) connected to 107 down links. 109 I propose that we have a clean, new architecture for considering 110 this environment, and would like to introduce a new modeling con- 111 cept (TINA style) for thinking about the problems this raises, 112 namely the Logical IP Footprint (LIF). [Footnote: The model may be 113 applicable in terrestrial cable TV distribution networks, e.g. 114 HFC, too] 116 The Logical IP Footprint is roughly analgous to the Logical IP 117 subnet in the Non Broadcast Multiple Access networks, except that 118 we can use it not just to model a set of routers that are "negh- 119 bours" in some subnetwork technology-dependent sense - we can also 120 use it to help design solutions to the lack of reverse path con- 121 nectivity, or the lack of symmetry in a hop's "quality of route or 122 link" parameters. 124 A Logical IP Footprint 126 Another way to understand the idea of a LIF is to picture the set 127 of IP forwarding nodes which have two way connectivity, and have a 128 subset who have forward connectivity over the same satellite chan- 129 nel to all the set. The reverse path connectivity from the 130 "receive only" routers may be multi-hop, and may itself traverse 131 other LIFs - this is transparent to the model. 133 A motivation for defining the set this way is to distinguish 134 routers on multiple downlinks from multiple satellites, and to 135 exclude routers that have no return path to the routers with an 136 uplink. 138 The goal of the model is to allow us to solve several problems 139 caused by the symmetry assumption in some Internet Control proto- 140 cols. These shortcomings include: 142 Routing "exchanges" 144 Signaling "exchanges" 146 Multicast based on "Reverse Path" computations 148 Clock Synchronisation (NTP/DTS) Problems 150 A Principle start to this mechanism is to provide a grouping or 151 aggregation mechanism for routers so that forward path messages 152 can summarise information necessary for many routers in a foot- 153 print, and return path targets and routes to the target can be 154 easily identified. 156 You may find it helpful to picture all the uplink capable routers 157 as being located "in the satellite" (or the satellite space seg- 158 ment being squashed down to the ground:-). 160 The routers in the LIF who have uplink capability are known as LIF 161 Ingress Routers (LIFI), and the downlink as LIF Egress Routers 162 (LIFE). 164 Stages in Internet Connectivity 166 The following steps may occur in setting up some user session over 167 a network that includes LIFs: 169 Neighbour Discovery 171 Address assignment 173 Reachability up/down status exchange 175 QoS/QoR link parameter configuration and discovery 177 Clock Synck 179 MPLS and RSVP exchanges 181 Multicast 182 Mobile 184 Discovery 186 In the assymetric case, then, we need to initiate neighbour 187 discovery from the LIFI. These use broadcast packets to advertise 188 their existence as LIFI to the candidate LIFE set. These broadcast 189 packets may be based on LDP or DHCP or some as yet unspecified 190 neighbour discovery and configuration protocol - this is for 191 further study. 193 For now, lets call this the LIFIA (Logical IP Footprint Ingress 194 Advertisement) protocol, or LIFIA. 196 LIFIA includes the list of all IP addresses of the LIFI, i.e. ones 197 not on the uplink, but on the terrestrial (non-LIF) based networks 198 - this is essential for later stages. 200 Think of it like a combination of RARP, Neighbour discovery and an 201 address asignment scheme. However, depending on the scale of the 202 system, addresses might be assigned from different pools. We might 203 alocate a prefix/subnet to the LIF or we might want a LIS, or we 204 might want a whole net, or an AS even. 206 Tunnels/Connectivity 208 LIFE, on learning of the LIFI, use a tunnel protocol to estabish 209 virtual interfaces between their own non-LIF interfaces and the 210 LIFI addresses that are "nearest" them by normal routing metrics 211 that do not include the current LIF path. 213 [tunnels could use L2P, or IPinIP or virtual router techniques - 214 this is for further study - basically, though all the proposed 215 models in UDLR, and more, work well here - see references to work 216 in progress there]. 218 Addresses and route hierarchies 220 At this point, the LIFI and LIFE have connectivity and can move on 221 to assigning addresses, and carrying out reachability exchanges. 222 However, we want to move on to be able to compare LIF hops with 223 other hops based on forward (or for multicast, reverse) path 224 metrics. To this end, the LIFE need to know the metrics used by 225 the LIFI. 227 [Address assignment would depend on the scale of the LIF - for 228 small scale LIFs, we could use prefixes in the IPv6 space (or even 229 IPv4); medium scale we could have different net numbers and have 230 an OSPF area for the LIF. Largest scale could choose an AS for the 231 LIF< and run BGP between LIFI and LIFE] 233 Basically, we have an oppportunity to map the natural broadcast, 234 one to many nature of the LIF on to some summarisation technology 235 - it should be possible to use any of the above 236 summarisations/aggregation techniques - i.e. subnet/class masks or 237 IPv6 prefixes, areas, autonomos systems, as well as in the case 238 where the subnet technology itself does summarisation (e.g. ATM)m 239 use MPLS summarisation techniques such as route agregation on 240 ingress or egress router ids. 242 Metrics 244 For later RSVP or other path establishment to be able to use the 245 right parameters for CAC, we also need to know the one way delay. 247 Delay/Clock Offset 249 Lets look at this last specific problem briefly as a simple 250 elegant solution presents itself. LIFI and LIFE engage in NTP 251 exchanges over the terrestrial discovered tunnel. The LIFI also 252 transmit NTP messages to the LIFE via the LIF. 254 On a symmetric link, NTP allows us to calculate the RTT, and the 255 clock offsets by virtue of some pretty simple arithmetic: 257 Src sends Sent M1 at T1 message contains timestamp with value T1 259 Peer Receives M1 at T2' which is T1 + Transit1 + O1 260 where Transit1 is the one way transmission delay and 261 O1 is the offset of the receiver's clock from the sender's clock 262 T1 ................ 264 Peer transmits M2 at T3' (can be T2' if immediate) 265 which contains T1, T2', T3' 267 Src receivers anser M2 at T4 268 which is T3' + Transit2 269 which could be T1 +Transit1 + Transit2 + (T3'-T2') 271 If the path is symmetric Transit1=Transit2 - we have two equations 272 and two unknowns and can solve for transit (rtt/2) and for offset. 274 The path over the non-LIF tunnel is symmetric (usually). So we 275 solve for the clock offset, and adjust the clocks accordingly. We 276 can now do ONE WAY delay measurements from the LIFI to the LIFE 277 (and can even use broadcast or multicast NTP to send the times- 278 tampes on the outward path). 280 Of course, if the satellite explicitly provides a clock, or assum- 281 ing that it is geosynchronous orbit is good enough, we could sim- 282 poly configure the link delay (buit there are MEO and LEO orbits 283 too!). 285 The link speed is taken from the LIFI configuration. Queue lengths 286 may be advertised on the LIFI->LIFE path in the normal Link State 287 Advertisements supported, eg., by QOSPF. 289 We now have all the data necessary for: 291 RPF checks 293 Multicast tree calculation 295 Call Admission Control 297 MPLS Sink Tree Calculation 299 or other functions across a normal "well characterised" multihop 300 internet path. 302 Discussion 304 The goal of defining a LIF is to scope the region of assymetry for 305 management reasons. These reasons could include: 307 Use of assymetric unidirectional link as normal part of Internet con- 308 nectivity infrastructure 310 Control of address use and route complexity depending on scale 311 (number of LIFI and LIFE routers) on such a link, through 312 appropriate use of level of address assignment and of tunnel tech- 313 nique for 'return path'. 315 Control of scale of traffic generated in neighbour discovery 316 Control of scope of an LIF - different subsets of LIFEs might wish to 317 appear to be in different LIFs w.r.t. different LIFIs. 319 Scope for management of LIFEs that are in multiple LIFs to optimise 320 return paths. 322 References 324 An IP tunneling approach for Uni-directional Link routing 326 Dynamic Tunneling Path Configuration for Uni-directional Link Routing 328 Handling of unidirectional links with RIP 330 Handling of unidirectional links with OSPF 332 Handling of unidirectional links with DVMRP 334 Supporting Unidirectional Paths in the Internet 336 VIPRE - Virtual Internet Packet Relay An Encapsulation Architecture 337 for Unidirectional Links James Stepanek stepanek@aero.org The 338 Aerospace Corporation Stephen Schwab schwab@aero.org Twin Sun Inc 339 341 Author's Address 342 Jon Crowcroft 343 UCL 344 Gower St 345 London WC1E 6BT 346 England 348 Tel +44 171 380 7296 349 Fax +44 171 387 1397 350 Email: jon@cs.ucl.ac.uk