RE: Multicast/Sattelite Problem, Anyone who want's to take this

From: Mark Mahan (mmahan@caprock.com)
Date: Mon Oct 08 2007 - 11:59:07 ART


Are you using a TDM/TDMA, SCPC or Asymmetrical topology?

As you are talking about Cisco routers on the endpoints, and the hub is
also a vessel, I think that probably rules out TDM/TDMA since these
systems are a modem and router integrated into one box (though we
commonly hang routers off a TDMA modem for voice gateway, CCME, IP
services, etc.) and the hub is usually quite involved and expensive.
The TDMA boxes that I've seen have built in multicast support.

Assuming this traffic will be the only traffic on the link-
You could try setting it up as an asymmetrical circuit (note- this gets
quite involved) where you have the hub router connected to a satellite
modem. Use FR encapsulation on the physical interface. Turn keepalives
off as this will not be a point to point connection between two devices
sending and receiving LMI status polls and replies). To keep the router
interface up, you need DCD from the modem and you'll also want to watch
the status of your outbound satellite link so the modem will most likely
be in a satellite loopback (RX and TX freqs the same) so you'll need to
clip the RX pins on the cable so you don't receive your own traffic and
rebroadcast. Create a transmit-to-spokes PVC.
To receive from the remotes, you need one satellite modem (can use demod
only modems and save money) connected to the hub router for each remote.
FR encap with keeps off. Create a PVC on each interface to receive that
remote's traffic. Use static routing pointed at the interface as these
are stubs anyway.

Set the remotes up for FR encapsulation with keeps off. Create one RX
sub-interface using the hub's TX PVC and create a TX sub-interface
matching the hub RX PVC for this site. Static default pointing at the
TX sun-interface is all you need on the remotes.

Due to the broadcast nature of satellite, if the hub TX freq is the same
as the remotes' RX freqs, then what he sends will be received by all.
The remotes will have individual TX freqs that the hub will receive on
individual modems so these are one way point to point. In this case you
don't need multicast as the topology itself will take care of
replication. If you have other traffic that needs to be sent from the
hub just to one remote or the other this would have to change some but
to me this sounds like SCADA or something similar.

If these are all SCPC, then it's no different than any other hub and
spoke other than the delay of the 22,300 mile high satellite. This is
about 230ms one direction (460ms or so round trip ping time).

HTH

Mark Mahan
Network Engineer
-------------------------------
CapRock Communications
4400 S. Sam Houston Parkway E.
Houston, Texas 77048
Office: 832 668 2528
mmahan@caprock.com
www.caprock.com

--------------------------------------------------------
NOTICE OF CONFIDENTIALITY: This e-mail message may contain confidential information and is intended only for the person(s) named above. Any review, use, disclosure or distribution by any other person is prohibited. If you are not the intended recipient, please contact the sender by e-mail and destroy all copies of this message.

-----Original Message-----

From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Scott Morris
Sent: Monday, October 08, 2007 7:02 AM
To: 'Joseph Brunner'; slammer@broadpark.no; ccielab@groupstudy.com
Subject: RE: Multicast/Sattelite Problem, Anyone who want's to take this
on !!!!!!

I'd also take a look at PGM if your multicast traffic is critical for
reception. But wouldn't your initial interest or discovery be on the
application-side? I'm going to assume that you're looking at some
fairly
customized stuff as well, so it may be in your best interest to develop
the
server-side application to handle multiple TCP streams unless we're
talking
about thousands of receiving devices.

But otherwise, Joseph has the right idea...

 
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
JNCIE-M
#153, CISSP, et al.
CCSI/JNCI-M/JNCI-ER
VP - Technical Training - IPexpert, Inc.
IPexpert Sr. Technical Instructor
 
A Cisco Learning Partner - We Accept Learning Credits!
 
smorris@ipexpert.com
 
Telephone: +1.810.326.1444
Fax: +1.810.454.0130
http://www.ipexpert.com
 

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Joseph Brunner
Sent: Monday, October 08, 2007 3:46 AM
To: slammer@broadpark.no; ccielab@groupstudy.com
Subject: RE: Multicast/Sattelite Problem, Anyone who want's to take this
on
!!!!!!

The delay with satellite is the fact the satellites are orbiting around
the
planet 50 to 500 miles high!

Multicast traffic by nature must be UDP. So if the xcast/Gxcast is UDP
or
connection less, it could help you out over TCP. You would not have the
built in reliability of a connection oriented protocol, but given the
topology and make up of this network, you just want to sling packets
back
and forth...

Check with a satellite services firm (Iridium?) they have to have
someone
who can go to town on this for you... Hughes, Loral Spacecomm, many
other
come to mind... many people are using satellites for mission critical
data.

-Joe

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
slammer@broadpark.no
Sent: Monday, October 08, 2007 3:41 AM
To: ccielab@groupstudy.com
Subject: Multicast/Sattelite Problem, Anyone who want's to take this on
!!!!!!

The topology is like this (can be changed to full mesh)

                      ------R2--client (vessel2)
                      -
                     -
(Vessel1) server---R1---SAT------------R3--client (vessel3)
                     -
                      -
                       ------R4--client (vessel4)

Vessel 1 is master and sends data to vessel 2,3 and 4 the clients need
to
send data to vessel 1.
1.This is realtime data and delay jitter can be a problem, we are
talking
about
  max 300ms delay
2.To avoid tcp and broadcast traffic it is suggested that multicast is
implented
  in a point to multipoint topology or full mesh !!!!!!!

  There is a suggestion using xcast/Gxcast protocol but as far as I know
cisco
  doesn't support these protocols as far as I know
 
3.Ratio would be 60% transmit traffic and 40% receive traffic to and
from
the
  master.

  Any suggestion on what type of multicast to implement and does anyone
know
what
  Qos tools that can be used to mesure delay jitter etc...
  As the vsatmodem and sattelite is not my problem initialy I was
thinking
about
  setting up this in a lab

I know there's a lot of BIG brains out there, so any input will be of
great
value

Thanks in advance guys.



This archive was generated by hypermail 2.1.4 : Fri Nov 16 2007 - 13:11:12 ART