Cell Relay Archive

[albert.e.manfredi@boeing.com]

In article <805aee$g3k$1@news.cs.tu-berlin.de>,
  "Thomas Wolfram" <no-answer@wolfram.net> wrote:

> This would mean of course that a implementation has to use different
> VCs for ATMARP/InATMARP (for which LLC/SNAP is required by 2225) and
> IP -- perhaps even to the same target.
> But I don't really understand either how that would work with PVCs or
> SVCs. RFC2225 states on different paragraphs that InATMARPs must
> only be sent over a PVC/SVC if that VC uses LLC/SNAP encapsulation (of
> course). But as far as I understand it doesn't say clearly what has
> to be done if someone wants to use null or another encapsulation
> for IP.
> However, I think everybody uses only LLC/SNAP for Classical IP
anyway...

If you actually work through a network design, I think the problem
becomes very obvious. All you have to have is a situation in which a
PVC or long-lived SVC might send to the destination device a packet
that destination can't identify. So in any case where the destination
is _not_ involved in signaling for that particular VC, using null
encapsulation is risky business. I think that's the simplest way to
determine whether or not you can use it.

> >By the way, there's a new number for RFC 1483.
> > It's been updated. But I'm too lazy this minute to find the new =
> number.

> It is RFC2684. Updates, clarifications and support for VPNs. It also
> lists some applications of the encapsulations it defines (PVCs,
> Classical IP, LANE, NHRP, MPOA, MARS and PPP-over-AAL5).

That's it. Thanks.

--
Bert
manfredi@arl.bna.boeing.com


Sent via Deja.com http://www.deja.com/
Before you buy.