[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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).


   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

   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.


   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, <draft-ietf-
      udlr-general-00.txt>, An IP tunnelling approach for Uni-
      directional Link routing, <draft-ietf-udlr-wide-tunnel-00.txt>,

   2) Dynamic Tunnel Configuration Protocol, <draft-demizu-udlr-dtcp-

   3) Dynamic Tunnelling Path Configuration for Uni-directional Link
      Routing, <draft-ietf-udlr-dtpc-00.txt>,

   4) Handling of unidirectional links with DVMRP, <draft-ietf-udlr-

   5) Handling of unidirectional links with OSPF, <draft-ietf-udlr-

   6) Handling of unidirectional links with RIP, <draft-ietf-udlr-rip-
      00.txt> and

   &) VIPRE -- Virtual Internet Packet Relay, An Encapsulation Architec-
      ture for Unidirectional <draft-ietf-udlr-vipre-00.txt>].

      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.


      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

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

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


Jon Crowcroft                                                   ^L[Page 4]

draft-ietf-udlr-lifeLogical IP Footprint Explanation     15 October 1998



      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.


      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.


      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

      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.


      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.


   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
      Gower St
      London WC1E 6BT

      Tel +44 171 380 7296
      Fax +44 171 387 1397
      Email: jon@cs.ucl.ac.uk

Jon Crowcroft                                                   ^L[Page 8]