A note on LMP/G.7714 (long)

[Greg Bernstein <gregbern@yahoo.com>]

With the working group draft on transport-lmp that
details the functionality of
LMP and G.7714 (and .1) side by side it seems like its
about time to try putting
these two together in some way.  The reasoning for
this that its been six years
since a number of vendors (okay at least a couple)
implemented pre-standard
GMPLS/G.ASON functionality and neither LMP nor
G.7714.1 currently provide all 
the basic functionality that these early
implementations (which are currently 
running in many carrier networks) provide for
SONET/SDH.
Namely,
(1) Automatic discovery of link endpoints with no
manual provision
(2) Bi-directional connectivity verification (checking
for mis-wired fiber
pairs)
(3) Integration with routing protocols.

These early implementations were limited to a single
layer (as opposed to
G.7714.1 that applies to all SDH/OTN layers) and
utilized an IGP hello protocol
running over either the line (Multiplex Section) or
section (Regenerator
Section) DCC.  Note that the hello protocol running
over the DCC would also
provide the bi-directional connectivity verification.
Since the hello protocol
was already integrated with the routing protocol no
extra integration was
required.  Hence a nice neighbor discovery,
verification, and topology/resource
discovery functionality was delivered in relatively
short time by vendors that
took this approach.
Besides working at only one layer this approach didn't
deal well with cases
where there was a requirement for true data/control
plane separation, i.e., the
DCC wasn't usable for some reason. In addition such an
approach doesn't take
into account link bundling which can be important in
many but not all cases.

Here's a simple single layer use case where I try to
utilize both G.7714.1 and
LMP/LMP-Sonet-Test.
As a simplifiying assumption I'm assuming all
unnumbered links and IPv4
addresses for the various entities.
I'll assume that the Discovery Agent of G.7714.1 and
LMP entity on the same
system use the same IP address.
Let's assume SONET line terminating equipment (ADM or
Xconnects).
(1) Use G.7714.1 messages over the SONET line DCC
(either LAPD or PPP format),
with the DCN DA Address format.
(2) From the DCN DA address (equal to the LMP entity
IP addresses) we can bring
up an LMP control channel.
(3) As sugggested in Appendix III of G.7714.1 I could
use the TraceMonitor
(along with the TraceMonitorAck) message to convey
back received information to
the sender for bi-directional connectivity
verification. TraceMonitor messages
from draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
(4) With preconfigured rules such as "bundle all" or
"bundle none") one side or
the other can initiate the link summary procedures of
LMP to determine the
bundling.  I'm assuming that bundling can be
re-negotiated at a later time if
desired, e.g., some one from a management systems
decides to change the
bundling.
Effort required: 1 procedure from G.7714.1, 3 from
LMP: Control channel config,
TraceMonitor (for bi-directional connectivity), and
Summary for bundling.

Here's a simple two layer use case.  Suppose the two
switches above are
interconnected by 20 OC-192 signals via a WDM system
that looks like section
terminating equipment (STE).  Suppose that the WDM
takes 10 of the OC-192 and 
multiplexes them onto 1 fiber pair for transport and
takes the other 10 and
places them on another diversely routed fiber pair.
How can discovery and LMP
help us bundle the OC-192 links correctly at the line
layer?  Line layer 
discovery won't tell us any more than we learned in
the previous example.
Here's how:
(1B) In addition to discovery at the line layer lets
do discovery at the section
layer. Recall that the switches also operate at the
section layer as well as the
line layer.  In this case the switches will be
discoverying the WDM systems and
not each other.  Using the DCN DA Address format
G.7714.1 with either the J0 or
section DCC we can learn the address of the LMP
entity.
(2B) Bring up a LMP control channel between the switch
and the LMP system. Make
sure to assign it (a different CC ID could be helpful
if not strictly
necessary).
(3B) Perform bidirectional connectivity verification
like above (this time
between switches and WDM equipment).
(4B) Since the WDM system knows which OC-192 signals
are multiplexed onto which
fiber pairs. It can set the bundling correctly, i.e.,
bundle at most into two
TE links but not one.
(5B) With the information obtained on link bundling
from the WDM system the
switches can renegotiate their bundles into the
appropriate TE links.

Note that in this situation the WDM system
(particularly if its a fixed
mux/demux) doesn't need to run a routing protocol just
G.7714.1 at a particular
layer and a small subset of LMP.  At this point we're
talking about nice added
value functionality over previous proprietary
implementations.  Some might
suggest that in step (4B) that the WDM system should
just assign appropriate
SRLG ID's to the (LMP) "data links" that are carried
over the two diversely
routed fiber pairs.  There currently isn't a mechanism
for this so I used what
was available and let the lowest layer start with the
bundling rules.

I'm sure the LMP and G.7714 experts will let us know
if the above can work. If
so it might be handy to put in the LMP-transport
document (suitably cleaned up).

Greg B.

Greg Bernstein
Grotto Networking




		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush