Subject: how is hybrid ISP routing done

From: Matthew Halsey <[email-masked]>
Date: Wed, 15 Nov 2000 15:38:48 -0000

I have been trying to figure out exactly how hybrid satellite ISP routing is
actually done?
If a user has a terrestrial ISP connection for making requests, how is it
that the responses are routed back via a satellite uplink facility rather
than back via the terrestrial ISP?
I have seen it explained as IP in IP encapsulation, proxy servers or BGP
routing.  Can someone please explain?

Thanks Matt

=========================
Matthew Halsey
Sales Support Manager, Internet Services
Kingston MediaStream
Tel :     +44 (0) 1494 878608
Fax :    +44 (0) 1494 874433
Mobile : +44 (0) 7879 405 880
mailto:[email-masked]
http://www.kingston-mediastream.com
=========================

*****************************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please
notify [email-masked] and delete the original email.
*****************************************************************************

---

From: Dr G Fairhurst <[email-masked]>
Date: Wed, 15 Nov 2000 17:33:49 +0000

This is asymmetric link routing.

Here is a brief summary of the topic:

IP assumes very little about the under-lying network and therefore may operate
over v
irtually any type of link.  Most links provide duplex communications with the
same
characteristics in both directions.  Asymmetry however does occur in various
forms:
Asymmetric capacity (forward and return links operate at different speeds, or
under
different loading), asymmetric loss (forward and return links exhibit different
error
environments), and asymmetric routing (using two different paths). A DVB
Satellite
link with terrestrial return introduces all three forms of asymmetry.

No changes are required to the IP protocol headers for asymmetric routing.
However
when additional services are provided within the network and a boundary router
(at
the edge of a subnetwork) receives a packet from a path which is not the route
to
the packet’s source address, several issues may arise including:

(i) If the boundary router employs ingress source address filtering (e.g. to
prevent
address spoofing), the packet may be filtered and discarded.
(ii) If the up-stream networking nodes use a routing protocol (Unicast or
multicast)
routing protocol advertisement may be confused by the asymmetry.
(iii) If policy-based routing or accounting is used, the packet may be assigned
a wrong
service class.

Three approaches have been suggested to overcome these limitations: the oldest
approach
uses an IP source-route option, (each IP packet carries a list of addresses of
routers
along the path to be taken).  This can expensive to implement in routers.

A second approach uses IP-in-IP tunnelling (encapsulating an IP packet with
another
IP header, adding 20 B overhead).  This approach is used in the Multicast
Backbone (MBone)
and to provide virtual networks.   In the DVB case, a packet from a client is
encapsulated with
an IP header with a destination address of the tunnel end router (e.g. the hub
router in figure 1).
The remote router extracts the encapsulated packet and forwards it to either a
local (hub) server
or onwards to the Internet, as if the client was connected via a full-duplex
connection terminated
at the tunnel end.  The tunnel end must also validate the addresses of received
packets to
prevent spoofing.

A third approach resembles the former, but uses Generic Routing Encapsulation
(GRE)
which also adds an additional 8 B header between the outer and inner IP
headers.  This
allows more sophisticated control of the tunnel and supports a range of
protocols (including
transparent Ethernet bridging).

Both IP-in-IP and GRE allow asymmetric routing. A new problem arises, in that to
establish a
tunnel between two end-systems requires manual configuration of addresses (and
also any
multicast group membership).  An automatic tunnel setup protocol is therefore
highly
desirable (in which the out-bound satellite link sends the appropriate
information to allow
all clients to configure their tunnels). Such a protocol (for bridging using
GRE) is currently
under development within the Internet Engineering Task Force (IETF)
Uni-Directional Link
Routing (UDLR) working group.

BGP can be used in some cases between routers - and is more common in delivering
content
to ISPs rather than to corporate / home users.

Gorry Fairhurst

--
------------------------------
http://www.erg.abdn.ac.uk/users/gorry

---

From: "Barry Raveendran Greene" <[email-masked]>
Date: Wed, 15 Nov 2000 13:20:12 -0800

Hello Matt,

The following URL has Geoff Huston's orginal work documented and the
follow-up work to have this work within one AS.

http://www.cisco.com/public/cons/isp/documents/Trans-Oceanic_Systems-BGP.pdf

Barry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Matthew Halsey
> Sent: Wednesday, November 15, 2000 7:39 AM
> To: [email-masked]'; [email-masked]'
> Subject: how is hybrid ISP routing done
>
>