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
Matthew Halsey wrote:
> 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 protected]
> 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 protected] and delete the original email.
> *****************************************************************************
-- ------------------------------ http://www.erg.abdn.ac.uk/users/gorry
This archive was generated by hypermail 2b29 : Wed Nov 15 2000 - 13:18:57 EST