Subject: RSVP on crossing Broadcast network segment.

From: "S.Arul Vasantha Raj" <[email-masked]>
Date: Wed, 12 Apr 2000 18:07:43 +0530

Hi RSVPians,

To introduce self, I have recently jumped in the RSVP cloud to find some 
Reservation for myself. Started Implementing RSVP protocol for PSoS based 
Router at Chennai, India.

I have a doubt.,
In Rsvp we have the mechanism to work with the Non Rsvp Cloud, We can know 
from TTL difference to conclude to Best effort traffic.
But, if we have a broadcast technology based network Segment (Ex. CSMA/CD) 
in the route (Thick Ethernet Backbone) which is shared with few routers, 
How to deal with on reserving for a specific QoS (like Bandwidth). How will 
the next RSVP enabled routers know this kind of bandwidth sharing is in 
place.

It may be said it is opaque to RSVP. O.K But still in the above scenario, 
even the best probability vanishes as unnoticed. The lower layer technology 
has no support (?)  to reserve in a shared medium. I think atleast the 
information need to be taken over by RSVP.

The same case can be related to Token Ring backbone too, If the QoS is 
requested with Minimum delay traffic. Holding of token will be out of 
control, where as the RSVP assumes that the requested QoS (Ex. Min Delay) 
is in place.

I think, the intermediate routers or the receiver are need to be informed, 
like the same as the Non RSVP cloud existence.

Comments on the above is most welcomed. If anything misunderstood, please 
correct me.

Thanks and Regards,
Arul.

S.Arul Vasantha Raj, M.Tech.
F S P.L,
280, Anna Salai, Nandanam,
Chennai - 600035.
Ph. +91-44-4330550 Extn. 412.

Mail: 	[email-masked] (Official)
	[email-masked] (Personal)

I deeply regret for bouncing of any mails if you reply from any free mail 
server accounts.(Hot mail/ usa.net etc.)
A worst! narrow minded!! policy is in place in our server. In this case 
please use the second mail address. Thanks.

---

From: David Charlap <[email-masked]>
Date: Wed, 12 Apr 2000 11:16:57 -0400

"S.Arul Vasantha Raj" wrote:
> 
> Hi RSVPians,
> 
> To introduce self, I have recently jumped in the RSVP cloud to find
> some Reservation for myself. Started Implementing RSVP protocol for
> PSoS based Router at Chennai, India.
> 
> I have a doubt.,
> In Rsvp we have the mechanism to work with the Non Rsvp Cloud, We can
> know from TTL difference to conclude to Best effort traffic.  But, if
> we have a broadcast technology based network Segment (Ex. CSMA/CD)
> in the route (Thick Ethernet Backbone) which is shared with few
> routers, How to deal with on reserving for a specific QoS (like
> Bandwidth). How will the next RSVP enabled routers know this kind of
> bandwidth sharing is in place.

You're right that there's no IP-layer mechanism to detect this, because
TTL values are not affected by the medium the packet goes through.

On the other hand, a router attached to a bradcast medium knows that it
is, given its choice of interface.  The only real decision the switch
needs to make here is whether its broadcast (say, Ethernet) interface is
connected point-to-point to another switch, or if it's connected to a
segment with more than two nodes on it.  I think the switch can learn
this by snooping the interface for packets to/from unknown MAC
addresses.

Regardless of the mechanism used to detect a shared network segment, I
think RSVP can signal this by setting appropriate break bits in the
ADSPEC parameters.  Note that it doesn't have to set them all - certain
parameters (like MTU) can still be determined.

> It may be said it is opaque to RSVP. O.K But still in the above
> scenario, even the best probability vanishes as unnoticed. The lower
> layer technology has no support (?)  to reserve in a shared medium. I
> think atleast the information need to be taken over by RSVP.

You're right.  There can be no reservations on a shared medium. 
Parameters like bandwidth and delay characteristics are meaningless on a
non-switched network segment.  Setting the break bits on those ADSPEC
parameters should indicate to the receiver(s) and downstream routers
that no end-to-end reservations can be made for those parameters.

-- David