naive generalization of udlr problem...

[Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>]

comments welcome - i only skippedthru all the UDLR material again
recently, so this may be a big repeat of soemthign thats been done
already...

-----------------------------
COnvergence of Internet, ATM and Satellite.

Internet Architecture Considerations for Assymetric and Unidirectional Broadcast Links

Jon Crowcroft (UCL)
and
Patrick Cocquet (Dassault)

The upper layer protocol architecture for COIAS is the familiar
Internet one, with the now emerging IP/ATM technologies of choice for
high performance backbones.

Eessentially, the protocol stack is like this:


------------------------------
	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?	?

------------------------------

Of coruse there is also a management stack.

Now, the architecture makes use of the protocols - how?

Well, in our case, we have an unusual set of topological constraints -
we have assymetric, and unidirectional links (the 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 concept (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 "neghbours" in some
subnetwork technology-dependent sense - we can also use it to help
design solutions to the lack of reverse path connectivity, 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 channel 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.

The goal of the model is to allow us to solve several problems caused
by the symmetry assumption in some Internet Control protocols.
These shortcomings include:

Routing "exchanges"
Signaling "exchanges"
Multicast based on "Reverse Path" computations
Clock Synchronisation (NTP/DTS) Problems

You may find it helpful to picture all the uplink capable routers as
being located "in the satellite" (or the satellite space segment 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
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.

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].

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 an OSPF area for the
LIF. Largest scale could choose an AS for the LIF< and run BGP between
LIFI and LIFE]

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 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 timestampes on the outward
path).

Of course, if the satellite explicitly provides a clock, or assuming
that it is geosynchronous orbit is good enough, we could simpoly
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



Reference

Seen just after writing this!

James Stepanek stepanek@aero.org The Aerospace Corporation 
Stephen Schwab schwab@aero.org Twin Sun Inc

VIPRE -- Virtual Internet Packet Relay
An Encapsulation Architecture for Unidirectional Links
<draft-ietf-udlr-vipre-00.txt>