Internet Draft J. Crowcroft Expires in six months UCL CS Oct 15 1998 Internet Architecture Considerations for Assymetric and Unidirectional Broadcast Links This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Satellite hops, the region between a basestation and a set of mobile nodes, and a number of other similar scenarios represent a challenge to providing IP connectivity at various levels due to the 1-many broadcast nature of the link. The UDLR group has addressed these problems in some limited situations. The general case, where multiple, possibly partially intersecting set of such hops are part of a general set of Internet Paths (or need to be considered in the route computation that will buld such paths) is complex. This note is an attempt to outline a framework for the general case. We include certain recent approaches to managing connectivity that also include quality of service, multiple alternate paths, and traffic engineering considerations. In this version of this note, we are discussing techniques for connectivity, so mechanisms and techniques described are applicable to routers. We would need a seperate (and hopefully much simpler) set of mechanisms to incorporate hosts that exist on a unidirectional link or path that includes such links. Introduction Essentially, the protocol stack is like this: Jon Crowcroft ^L[Page 1] draft-ietf-udlr-lifeLogical IP Footprint Explanation 15 October 1998 Applications Stack Control Stack Infrastructure Stack TCP or RTP/UDP RTSP/RTCP SIP/SAP/DNS/DHCP/Neighbour IP RSVP PIM/OSPF MPLS LDP ATM Q.2931-like I-PNNI DVB Whatever? ? and of course there is also a management stack. UDLR to date Currently, the UDLR Working Group in the IETF has defined several pieces of the architecture for incorporating uni-directional links into a general-purpose IP routing infrastructure. The present versions of these proposals are the following: 1) Supporting Unidirectional Paths in the Internet, , An IP tunnelling approach for Uni- directional Link routing, , 2) Dynamic Tunnel Configuration Protocol, , 3) Dynamic Tunnelling Path Configuration for Uni-directional Link Routing, , 4) Handling of unidirectional links with DVMRP, , 5) Handling of unidirectional links with OSPF, , 6) Handling of unidirectional links with RIP, and &) VIPRE -- Virtual Internet Packet Relay, An Encapsulation Architec- ture for Unidirectional ]. All are narrowly focussed on the case of a single Uni-directional hop within a general Internet path. Luckily, this corresponds to Jon Crowcroft ^L[Page 2] draft-ietf-udlr-lifeLogical IP Footprint Explanation 15 October 1998 likely scenarios for work within COIAS for demonstration, although we are clearly interested in the general case. To this end, we will design a more general architecture for the general case of a path with multiple unidirectional forward hops, possibly overlap- ping, possibly partially. Idea Well, in our case, we have an unusual set of topological con- straints - we have assymetric, and unidirectional links (e.g. satellite portions of connectivity). This is at odds with much of the curent Internet architecture, which is centered very much on symmetric, or at least bi-directional dedicated or shared links. On the satellite hops, we have some number of routers connected to uplinks, and some (many more) routers (and hosts) connected to down links. I propose that we have a clean, new architecture for considering this environment, and would like to introduce a new modeling con- cept (TINA style) for thinking about the problems this raises, namely the Logical IP Footprint (LIF). [Footnote: The model may be applicable in terrestrial cable TV distribution networks, e.g. HFC, too] The Logical IP Footprint is roughly analgous to the Logical IP subnet in the Non Broadcast Multiple Access networks, except that we can use it not just to model a set of routers that are "negh- bours" in some subnetwork technology-dependent sense - we can also use it to help design solutions to the lack of reverse path con- nectivity, or the lack of symmetry in a hop's "quality of route or link" parameters. A Logical IP Footprint Another way to understand the idea of a LIF is to picture the set of IP forwarding nodes which have two way connectivity, and have a subset who have forward connectivity over the same satellite chan- nel to all the set. The reverse path connectivity from the "receive only" routers may be multi-hop, and may itself traverse other LIFs - this is transparent to the model. A motivation for defining the set this way is to distinguish routers on multiple downlinks from multiple satellites, and to exclude routers that have no return path to the routers with an uplink. Jon Crowcroft ^L[Page 3] draft-ietf-udlr-lifeLogical IP Footprint Explanation 15 October 1998 The goal of the model is to allow us to solve several problems caused by the symmetry assumption in some Internet Control proto- cols. These shortcomings include: Routing "exchanges" Signaling "exchanges" Multicast based on "Reverse Path" computations Clock Synchronisation (NTP/DTS) Problems A Principle start to this mechanism is to provide a grouping or aggregation mechanism for routers so that forward path messages can summarise information necessary for many routers in a foot- print, and return path targets and routes to the target can be easily identified. You may find it helpful to picture all the uplink capable routers as being located "in the satellite" (or the satellite space seg- ment being squashed down to the ground:-). The routers in the LIF who have uplink capability are known as LIF Ingress Routers (LIFI), and the downlink as LIF Egress Routers (LIFE). Stages in Internet Connectivity The following steps may occur in setting up some user session over a network that includes LIFs: Neighbour Discovery Address assignment Reachability up/down status exchange QoS/QoR link parameter configuration and discovery Clock Synck MPLS and RSVP exchanges Multicast Jon Crowcroft ^L[Page 4] draft-ietf-udlr-lifeLogical IP Footprint Explanation 15 October 1998 Mobile Discovery In the assymetric case, then, we need to initiate neighbour discovery from the LIFI. These use broadcast packets to advertise their existence as LIFI to the candidate LIFE set. These broadcast packets may be based on LDP or DHCP or some as yet unspecified neighbour discovery and configuration protocol - this is for further study. For now, lets call this the LIFIA (Logical IP Footprint Ingress Advertisement) protocol, or LIFIA. LIFIA includes the list of all IP addresses of the LIFI, i.e. ones not on the uplink, but on the terrestrial (non-LIF) based networks - this is essential for later stages. Think of it like a combination of RARP, Neighbour discovery and an address asignment scheme. However, depending on the scale of the system, addresses might be assigned from different pools. We might alocate a prefix/subnet to the LIF or we might want a LIS, or we might want a whole net, or an AS even. Tunnels/Connectivity LIFE, on learning of the LIFI, use a tunnel protocol to estabish virtual interfaces between their own non-LIF interfaces and the LIFI addresses that are "nearest" them by normal routing metrics that do not include the current LIF path. [tunnels could use L2P, or IPinIP or virtual router techniques - this is for further study - basically, though all the proposed models in UDLR, and more, work well here - see references to work in progress there]. Addresses and route hierarchies At this point, the LIFI and LIFE have connectivity and can move on to assigning addresses, and carrying out reachability exchanges. However, we want to move on to be able to compare LIF hops with other hops based on forward (or for multicast, reverse) path metrics. To this end, the LIFE need to know the metrics used by the LIFI. [Address assignment would depend on the scale of the LIF - for small scale LIFs, we could use prefixes in the IPv6 space (or even IPv4); medium scale we could have different net numbers and have Jon Crowcroft ^L[Page 5] draft-ietf-udlr-lifeLogical IP Footprint Explanation 15 October 1998 an OSPF area for the LIF. Largest scale could choose an AS for the LIF< and run BGP between LIFI and LIFE] Basically, we have an oppportunity to map the natural broadcast, one to many nature of the LIF on to some summarisation technology - it should be possible to use any of the above summarisations/aggregation techniques - i.e. subnet/class masks or IPv6 prefixes, areas, autonomos systems, as well as in the case where the subnet technology itself does summarisation (e.g. ATM)m use MPLS summarisation techniques such as route agregation on ingress or egress router ids. Metrics For later RSVP or other path establishment to be able to use the right parameters for CAC, we also need to know the one way delay. Delay/Clock Offset Lets look at this last specific problem briefly as a simple elegant solution presents itself. LIFI and LIFE engage in NTP exchanges over the terrestrial discovered tunnel. The LIFI also transmit NTP messages to the LIFE via the LIF. On a symmetric link, NTP allows us to calculate the RTT, and the clock offsets by virtue of some pretty simple arithmetic: Src sends Sent M1 at T1 message contains timestamp with value T1 Peer Receives M1 at T2' which is T1 + Transit1 + O1 where Transit1 is the one way transmission delay and O1 is the offset of the receiver's clock from the sender's clock T1 ................ Peer transmits M2 at T3' (can be T2' if immediate) which contains T1, T2', T3' Src receivers anser M2 at T4 which is T3' + Transit2 which could be T1 +Transit1 + Transit2 + (T3'-T2') If the path is symmetric Transit1=Transit2 - we have two equations and two unknowns and can solve for transit (rtt/2) and for offset. The path over the non-LIF tunnel is symmetric (usually). So we Jon Crowcroft ^L[Page 6] draft-ietf-udlr-lifeLogical IP Footprint Explanation 15 October 1998 solve for the clock offset, and adjust the clocks accordingly. We can now do ONE WAY delay measurements from the LIFI to the LIFE (and can even use broadcast or multicast NTP to send the times- tampes on the outward path). Of course, if the satellite explicitly provides a clock, or assum- ing that it is geosynchronous orbit is good enough, we could sim- poly configure the link delay (buit there are MEO and LEO orbits too!). The link speed is taken from the LIFI configuration. Queue lengths may be advertised on the LIFI->LIFE path in the normal Link State Advertisements supported, eg., by QOSPF. We now have all the data necessary for: RPF checks Multicast tree calculation Call Admission Control MPLS Sink Tree Calculation or other functions across a normal "well characterised" multihop internet path. Discussion The goal of defining a LIF is to scope the region of assymetry for management reasons. These reasons could include: Use of assymetric unidirectional link as normal part of Internet con- nectivity infrastructure Control of address use and route complexity depending on scale (number of LIFI and LIFE routers) on such a link, through appropriate use of level of address assignment and of tunnel tech- nique for 'return path'. Control of scale of traffic generated in neighbour discovery Jon Crowcroft ^L[Page 7] draft-ietf-udlr-lifeLogical IP Footprint Explanation 15 October 1998 Control of scope of an LIF - different subsets of LIFEs might wish to appear to be in different LIFs w.r.t. different LIFIs. Scope for management of LIFEs that are in multiple LIFs to optimise return paths. References An IP tunneling approach for Uni-directional Link routing Dynamic Tunneling Path Configuration for Uni-directional Link Routing Handling of unidirectional links with RIP Handling of unidirectional links with OSPF Handling of unidirectional links with DVMRP Supporting Unidirectional Paths in the Internet VIPRE - Virtual Internet Packet Relay An Encapsulation Architecture for Unidirectional Links James Stepanek stepanek@aero.org The Aerospace Corporation Stephen Schwab schwab@aero.org Twin Sun Inc Author's Address Jon Crowcroft UCL Gower St London WC1E 6BT England Tel +44 171 380 7296 Fax +44 171 387 1397 Email: jon@cs.ucl.ac.uk Jon Crowcroft ^L[Page 8]