Subject: TTL

From: [email-masked] (Ridvan Erdogan)
Date: Wed, 19 Jun 96 17:42:09 PDT

Dear Steve Deering and Bill Fenner,

Couple of days ago, I have sent an e-mail that asking if the mrouters can be
forced to decrement ttl more than 1 and you have asked me why I wanted this.
First of all, I would like to thank you for your quick response and for the
useful information.

Please refer to the following diagram that shows our logical topology and I 
will try to explain why we want this.

We would like to have our own regional MBone over a Frame Relay cloud. Our 
goal is to be able to keep the ttl of the multicast traffic within the Frame
Relay cloud between 16 and 31. As seen on the diagram, we are connected to a 
frame relay cloud. We would like to use MBone over this cloud. But we don't 
want to be their MBone provider. Therefore we would like limit the scope of 
the MBone by using TTL. Only the multicast packets which have a ttl value of
16-31 will be allowed within this cloud. When we get a multicast packet 
through the tunnel that feeds our campus mrouter, we would like to decrement 
the ttl value of this packet to a value between 0-15 so that it will not pass 
over the frame relay router that we have and will stay local to our campus. 
If a multicast packet with a ttl of greater than 32 is originated from our 
campus, we also don't want this packet to be forwarded by the Frame Relay
router. We want this packet to be forwarded only by our campus mrouter. All 
routers within this cloud will use PIM. If we are able to control the scope by
ttl, other sites within the cloud will follow the same ttl considerations and
we will have our local, regional MBone.

Can we control the scope of the MBone in this way?

Thanks in advance.
Regards Ridvan...

           BBN Planet                    Internet (Regional K-12 Schools)
               ^                                   ^
               |                                   |
               |                         ---------------------
               |                        |   Frame Relay Cloud  |
           ___________                    ---------------------
          |           |                             |            
          | FIREWALL  |                             | No unicast packet passes
           -----------                              | Multicast Only
                |                                   | No router table
                |                                   | advertisement
                |                                   |
  ttl >32       |--------------                     |
  decrement     |              |                    |        
  by one        |              |                    |
       ^        |              |          -----------------------
   ttl |     -----------   -----------   |Frame Relay Router     |
  |    |    |Campus Main| |Main Campus|  |IP Multicast is enabled|
  |  >=32   | Mrouter   | |  Routers  |  |PIM is used            | 16-31 16-31
  |  only    -----------   -----------    -----------------------  only  only
  V              |             |                   |                |     ^
 decrement       |             |                   |            ttl |     |
 to 0-15         |             |                   |                V     |
            --------------------------             |               0-15  16-31
           |     Campus  Backbone     |-------------              only     only
            --------------------------

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 20 Jun 1996 04:08:14 +0200

> we will have our local, regional MBone.

It really sound like you would like to control which networks you announce
where. So if you announce your networks number towards the frame relay cloud
but nothing else. Then the frame relay cloud will only see your networks but
not the world that way.

Useing TTL stuff is a very rougth tool anyhow, and you would possibly create
black holes in the routeing when the routeing finds a way through you and the
frame relay cloud but the packets does not go througth... not optimal, better
avoiding the routeing to find the way.

Magnus Danielson

---

From: [email-masked] (Don Brutzman)
Date: Wed, 19 Jun 1996 20:39:02 -0700 (PDT)

Magnus Danielson writes:
> [...]

We specifically do not want any possibility of unicast routing over
our frame relay (FR) link.  Similarly we do not want any possibility of
high-ttl multicast loops or packet duplication.  Schools in the frame
relay cloud will receive standard routing and (if enabled) global MBone
connectivity through CSUNET.  NPS and some other academic sites are
connected via BBN-Planet.  Those two networks are joined over 100
miles north of here in the San Francisco Bay area.  If anyone is going
global (i.e. high ttl) there is no harm in the packets traveling the
long way around, same as other traffic.
 
> avoiding the routeing to find the way.

The big benefit of ttl is that it is user selectable.  We hope to
provide a shared regional resource that can be used by teachers and
schools, as consumers and producers, in a safe way.  As Ridvan
mentioned, whatever works for us will have to be duplicated for all
other non-CSUNET sites connected to the Frame Relay cloud.  We want zero
unicast routing to keep Internet service providers happy and avoid
the problems you describe.  Thus we do not intend to advertise unicast
routes along those paths into the FR cloud to preclude such a possibility.

We of course remain willing to consider other possible solutions.  
Thanks for your feedback.

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code UW/Br Root 200  work 408.656.2149
              Monterey California 93943-5000 USA              fax  408.656.3679
Virtual worlds/underwater robots/Internet http://www.stl.nps.navy.mil/~brutzman

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 20 Jun 1996 05:46:45 +0200

> long way around, same as other traffic.

I was talking about routeing in the multicast domain only.
That is, the net numbers being announced for the Mbone routeing domain...

Magnus

---

From: Ajit Thyagarajan <[email-masked]>
Date: Wed, 19 Jun 1996 23:47:53 -0400

>Can we control the scope of the MBone in this way?

The use of the ttl as a mechanism for achieving scope control is usually
not recommended (the one place where it is useful is in expanding-
ring-search type of applications).

It looks like what might work for you are scoped groups.  Since your
goal is to have your own private MBone, you can define a set of
addresses in the 239.x.x.x range that would be local to your MBone and
then configure the router on the other end of the frame-relay cloud and
your campus mrouter with the chosen addresses.  To ensure that your
campus is not used as the path for MBone traffic to the frame relay
cloud, you could set up a high metric between your campus backbone and
the frame relay router.

The advantage in using a scoped group is that you are free to use
whatever ttl you want within your "region" and all traffic will stay
within.  This is assuming that you know that there are no other
"backdoor~ links to the rest of the MBone from your region (if there are
then you need to configure them with the scoped addresses as well).

Hope this helps - Ajit

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 20 Jun 1996 05:55:49 +0200

> cloud, you could set up a high metric between your campus backbone and

Hmm... didn't he also say that he did NOT want to provide the Mbone feed for
the frame relay cloud but still wanted Mbone connectivity through his normal
ISP. I don't think scoped groups solves that problem at all.
The routeing would pass non-scoped addresses anyhow, rigth?

Magnus

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 20 Jun 1996 10:09:49 +0100

>high-ttl multicast loops or packet duplication.  

what you need is policy based multicast routing......soemthing IDMR
was setup to discuss, but hasn't really solved yet

if PIM runs on top of BGP, and you could duplicate unicast route
entries with a tag to say whether they are used for multicast in the
2nd entry, then yo ucould express non-transit multicast routes...
[obviously you can't just use unicast policies, since you might have
different transit rules for unicast traffic......)

mark handley and ian wakeman had soem ideas along these lines (in 
fact , HPIM was supposed to be able to do this too, but we havn't had
time to write it all down....)

cheers
jon

---

From: Subramaniam Vincent <[email-masked]>
Date: Wed, 3 Jul 1996 10:53:24 -0700 (PDT)

Ridvan, Don,

Was some solution worked out for this situation ? (frame relay cloud,
private mbone TTL scope control et al.) . i'm sorry to rake it up late,
but i have some inputs. the problem looks like :

1. you WANT private-campus mbone traffic to be injected into the frame
relay cloud. (ttl controlled).

2. you already have ISP provided unicast routing for the sites connecting
to the cloud. (i.e. the sites on the cloud already have a way to the
internet, like yours, outside of the FR cloud)

3. you DONT WANT unicast internet routes injected into the FR cloud,
(FROM the campus backbone) you DONT WANT internet Mbone traffic reaching
ur campus via the campus mrouter to make it into the FR cloud..and campus
non-private Mbone traffic to make it to internet via the FR cloud.

basically u want the FR cloud to be part of the private mbone tree, and
def not part of the Mbone internet tree . (diagram for benefit of all
who've deleted mails..!)

Q:

my question was, is the IP mcast frame relay router on your campus a cisco
box (since you say PIM). how abt just using access lists for your own
mulitcast groups (assuming ur you will have unique groups like Ajit
suggested) and limiting scope that way. since that FR router seems to be
the  ONE way from ur backbone into the FR cloud (i have Ajit's
concern about  being sure abt other entries) , setting up the access
control on that may  help. (although I think it could slow router
forwarding thruput down..)

it looks like ajit's suggsestion was on similar lines, he suggested
configured groups  on either side and metric control..i'm suggesting
another angle..

vince