The IP over ATM Mailing List Archive by date

[bryang@eng.adaptec.com (Bryan Gleeson)]

Walter,

>
>>	Is there an assumption in the int-serv IPMC draft that all
>>hosts are NHRP capable ? I was wondering if there was a need for
>>an extra category of host to distinguish between NHRP-capable
>>and NHRP-incapable hosts. If a multicast router is going to
>>do short-cut routing and forward the RSVP Resv messages 
>>off-subnet it needs to know that a host which receives such
>>a short-cut Resv can ARP for off-subnet addresses. How does
>>the multicast router know this ?
>
>An interesting point... I don't think there's a problem, since I thought
>NHRP was going to be introduced as an extended version of ATMARP.  But
>maybe I misunderstood....
>

The NHRP specification will certainly exist. However the deployment of
NHRP / RSVP / Multicast support isn't all going to happen at once,
so that there may be environments with a mix of ATMARP-only and
NHRP-capable machines, and a multicast specification which requires
the use of the ATMARP / NHRP protocols needs to address that issue.

A forwarded, as against a merged, RSVP Resv message is really 
"an invitation to bypass". Following on from this I've a few
more questions for clarification

- After receiving a forwarded Resv message how does a host/router 
reject the invitation ? (Do nothing ?)

- How does a bypassed router know when the invitation is accepted,
and when rejected ? 

- After a host sets up a short-cut VCC how does the receiving end
of the VCC determine the (IP) identity of the initiating
end ? (Wait for a Path ?)

- After a short-cut VCC has been established do the Path and Resv
messages flow along the original best-effort VCCs or are they
also diverted to the short-cut VCCs ?

>There are still a lot of signalling details that need fleshing out
>around the short-cut mechanism ...

It is pretty important though as it is the only way to get away
from the MC-server model with your proposal. If there were any conclusions 
to be drawn from the long "server vs full mesh" debates it was that 
lots of people wanted MC-servers and thought full-meshes were the 
work of the devil, and vice versa. The potential range of requirements
and environments in which the protocols could be deployed did not lend
itself to standardizing on one approach.

>but I wanted to start
>simple and see if it could be made to work without changing any existing
>protocols.

Forwarding RSVP messages instead of merging them is akin to turning
a hop-by-hop protocol into an end-to-end one. While the packet 
formats remain the same I would say that the semantics are changed somewhat. 
Quite what the implications, if any, of this are I don't know at this 
point. Its a little early, at least for me, to equate always-merge-RSVP
with merge-or-forward-RSVP as being one and the same, but there's certainly
a lot I don't understand about the short-cut mechanism, and RSVP itself
for that matter.

Bryan