Re: PPP question on draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt
Jonathan Sadler <jonathan.sadler <at> tellabs.com>
2003-04-03 00:43:32 GMT
James -
James Carlson wrote:
> Jonathan Sadler writes:
> > > That doesn't read right to me. The "in-band" versus "out-of-band"
> > > distinction is purely hypothetical. In both cases, you'd be running
> > > *some* signaling bits on the DCC. Whether those bits are called
> > > "in-band" with respect to the DCC itself or "out-of-band" with respect
> > > to the actual data channels on the SONET/SDH link seems to me to be an
> > > unhelpful distinction to draw.
> >
> > In GMPLS, the control network and transport network are not required to have the
> > same topology. It is possible for two nodes (A & B) in two different locations to
> > have a transport link (ex a Lambda) between them, but not have direct control
> > plane connectivity. Consequently, the adjacency established between A & B to
> > manage the transport link may have to be carried through many IP router hops.
>
> I'm very well aware of that based on my prior SONET/SDH design work,
> and it's not the point.
Good to know the amount of explanation I should include in my responses.
> If you did LMP test messages over a raw HDLC session using the DCC,
> that would be no more or less "out of band" then a full PPP session
> over the DCC used only for management-level signaling support. The
> fact that you're using one set of protocols or another doesn't alter
> the way the signaling works on that one channel.
I think your mixing the two message flows that exist in LMP. I agree, the test messages
must run in a trace channel or traffic bearer associated with the traffic link in order
to work. However, the management messages being sent between LMP instances to control
the test process, monitor the health of the LMP association, etc. do not.
> The big difference, as below, is the scope of the signaling. LMP has
> a much wider scope. I don't see a reasonable way to modify PPP's LCP
> and LQM to operate in a way that would signal liveness of unrelated
> links.
Actually, I believe that the server layer trail's FDI/BDI is better than any out-of-band
method for relaying the state of the user plane link (traffic link). LQM in this
situation would be better used as mechanism to monitor the control channel.
As for scope, I would be interested in your opinion on what information LMP has to
handle that PPP does not.
> > For all functions in LMP, the DCC is not the link that is being described -- it is
> > just a conduit that MAY be used to carry the messaging. The link being described
> > is the SONET/SDH line/path. Consequently, the link management operations being
> > performed by LMP are really "out-of-band".
>
> OK; we're talking about different things here. If you run LMP over
> UDP/IP over PPP on the DCC, the LMP part still gives you out-of-band
> signaling. Thus, inclusion of PPP does *not* render the solution
> capable of supporting only in-band signaling.
I think we're in agreement that the use of PPP for the Data Link layer on the DCC is
actually orthoginal from the issue of how non-associated link management operations is
done for user plane link.
My original comments were made as an identification that LMP is really doing the same
things already done by PPP -- its just doing them for non-associated links.
> > Is there really more? LMP states it:
> > 1) establishes a control channel including the control channel
> > parameters
> > 2) identifies the parameters associated with a traffic bearing
> > link
> > 3) identifies mis-connection of transmit/recieve pairs
> > (this is specifically what the test-sonet-sdh spec is used for)
> > 4) identifies the grouping of traffic bearing links between neighbors
> > so that offered traffic can be carried any of the links in a group
> > 5) monitors the liveness of the control channel
> > 6) monitors the liveness of the traffic bearing link
>
> It's at least part (6) that's more. PPP does *NOT* contain any way to
> signal anything about what might be going on with any other link.
See my comment above about the use of an out-of-band channel instead of FDI/BDI to do
(6).
> It's this non-facilities associated signaling that (at least in my
> mind) makes LMP a bit different.
I tend to agree, but don't see it as too far different than what PPP can already do.
For example, one instance of PPP today can negotiate configuration parameters for links
that appear in different layer networks (ie. OSI, IPX, IPv4). It accomplishes this
through the use of different NCPs at different PPP protocol numbers.
Similarily, it should be possible to have a "non-associated link" NCP which includes the
name of the specific link being "negotiated" in each negotiation message. This would
allow for multiple instances of this NCP to exist, each tracking the status of a
different non-associated link.
> Architecturally, there are other differences. LMP is designed to look
> into MPLS as a liveness test for MPLS purposes. PPP's signaling tells
> you no more or less than that the PPP link *itself* is good. If all
> you cared about was the DCC, then PPP's liveness would be enough.
I'm unaware of where LMP states that you should look into the MPLS layer as a liveness
test. Can you provide me a reference?
> > The only difference is PPP does it for the case where the control channel is
> > carried over the traffic link (ie in-band), while LMP does it for the case where
> > the control channel and the traffic link are separate (ie out-of-band).
>
> That's a significant difference in my mind. For the in-band case, you
> don't have to name or number the "other" links. There aren't any. For
> the out-of-band case, you have to name or number those links, and you
> have to deal with issues surrounding agreement on the naming and
> agreement on link status.
The same issues exist for LMP. Currently they are using <NodeID, IfIndex>, which is
very similar to the SNPP names being defined in the ITU. Though, this shouldn't justify
the development of a completely new protocol...
> --
> James Carlson, Solaris Networking <james.d.carlson <at> east.sun.com>
> Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to
the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.
Thank you.
Tellabs
============================================================
RSS Feed