A note on LMP/G.7714 (long)
Greg Bernstein <gregbern@yahoo.com> Sat, 21 August 2004 00:47 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26757 for <ccamp-archive@ietf.org>; Fri, 20 Aug 2004 20:47:58 -0400 (EDT)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByK9q-0004NV-2O for ccamp-archive@ietf.org; Fri, 20 Aug 2004 20:54:58 -0400
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByJqI-000DXO-Q8 for ccamp-data@psg.com; Sat, 21 Aug 2004 00:34:46 +0000
Received: from [216.109.118.118] (helo=web60307.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1ByJq7-000DW8-9e for ccamp@ops.ietf.org; Sat, 21 Aug 2004 00:34:35 +0000
Message-ID: <20040820233433.1799.qmail@web60307.mail.yahoo.com>
Received: from [24.6.129.102] by web60307.mail.yahoo.com via HTTP; Fri, 20 Aug 2004 16:34:33 PDT
Date: Fri, 20 Aug 2004 16:34:33 -0700
From: Greg Bernstein <gregbern@yahoo.com>
Subject: A note on LMP/G.7714 (long)
To: ccamp IETF <ccamp@ops.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48
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
- A note on LMP/G.7714 (long) Greg Bernstein