Internet Draft J. Crowcroft
Expires in six months UCL CS
Oct 15 1998
Internet Architecture Considerations for
Assymetric and Unidirectional Broadcast Links
<draft-ietf-udlr-assym-broadcast-links-00.txt>
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, <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-
00.txt>,
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-
dvmrp-00.txt>,
5) Handling of unidirectional links with OSPF, <draft-ietf-udlr-
ospf-00.txt>,
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.
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
<draft-ietf-udlr-vipre-00.txt>
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]
