RE: LMP & neighbor discovery

[Jonathan Lang <jplang@calient.net>]

Michiel,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com]
> Sent: Tuesday, April 09, 2002 12:41 AM
> To: ccamp@ops.ietf.org
> Subject: LMP & neighbor discovery
> 
> 
> Hello all,
> 
> I found the concept of neighbor discovery mentioned several times in
> previous discussions on this list. However, I did not find a final
> conclusion on how this neighbor discovery is done. Correct ?
> 
> Could you please check my understanding below ?
> 
> In my mind, reading the incoming 'access point identifier' [ITU-G.707]
> and subsequent LMP 'link property correlation' form a perfect fit. By
> simply encoding the sending node's IP address and local access point
> number in the access point identifier (see e.g. [OIF.2000.159.01]), the
> receiver can discover the data link (linkConnection in ITU  terminology).
> Subsequent 'link property correlation' could then a.o. check on bi-
> directional fibering, matching data link properties and grouping of data
> links into TE links.
> 
> Example: the following figure shows 4 network elements of which 2
terminate
> the data link (TTPs, T) and two are transparent to the data link (CTPs,
C).
> E.g. NE-1 and NE-4 are SONET/SDH multiplexers; NE-2 and NE-3 are
transparent
> optical cross connects. The data link in this example is STM-N/OC-N.
> 
> +------+      +------+      +------+      +------+
> |    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    |
> |      |   A  |      |   B  |      |   C  |      |
> |      |      |      |      |      |      |      |
> | NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
> +------+      +------+      +------+      +------+
> 
> NE-2 should, when it wants to discover data link B, connect a test-set
that
> sends an access point identifier to identify the sending connection point
C
> in NE-2. This test-signal should be send long enough for NE-3 to detect
and
> read the test-signal (a fixed, agreed upon timer is needed). NE-3 will
> continuously scan all its not discovered input ports for a discovery
signal.
> At some point, it will detect the test-signal on data link B.
This is what the Link Verification procedure provides. As part of the
BeginVerify message exchange, certain Test parameters (such as
Verify_Interval, Verify_Dead_Interval, and Verify_Transport_Mechanism) are
exchanged.

> 
> +------+      +------+      +------+      +------+
> |    T-|--->--|-C  C-|--->--|-C  C-|--->--|-T    |
> |      |   A  |   /  |   B  |  \   |   C  |      |
> |      |      |  T   |      |   T  |      |      |
> | NE-1 |      | NE-2 |      | NE-3 |      | NE-4 |
> +------+      +------+      +------+      +------+
> 
> When NE-3 has read the access point identifier in the test signal, data
> link B is discovered. Subsequent link property correlation can then be
> invoked.
As part of this discovery, NE-3 sends an acknowledgment message carrying the
local (near-end) identity of link B.

> 
> Discovery of data link A is similar, except that the access point
identifier
> is continuously sent. Discovery of data link C is also similar, except
that
> the access point identifier is continuously monitored. In other words,
there
> is no need for a sending respectively monitoring 'test-set' in NE-1 and
NE-4.
This assumes that NE-1 and NE-2 (and NE-3 and NE-4) have agreed on the
verification mechanism in advance.

> 
> Data link type          Access point identifier to be used
> --------------          ----------------------------------
> STM-N, OC-N                            J0
> STS-1/3/.../VC-3/4/...                 J1
> VT-1.5/VC-11/12                        J2
> 
> 
> Notes:
> - I understand that LMP's link verification procedure is more efficient
for
>   *already discovered* data links. It does not need the continuous
scanning
>   on received access point identifiers in undiscovered CTPs (in the
example:
>   in NE-3).
> - Discovering the address of the sending access point might also go via a
'name
>   server'. This can, for example, be useful in case the address of this
access
>   point can not be encoded in the limited length of the access point
identifier.
> 
> B.t.w., could you please explain why the linkSummary and linkSummaryAck
messages
> have to go over a point-to-point control channel ? 
All LMP messages are sent over the LMP control channel; the health of which
is monitored using LMP Hello messages.

> Is it also possible to
> use the generic DCN network (MCN/SCN, can be IP-based, see ITU-G.7712) ?
> In the latter case, we could simply use the normal UDP service of that
network
> to transport the linkSummary and linkSummaryAck messages ?
You could certainly create an LMP control channel through a DCN network. In
fact, this is probably the preferred configuration.

> Is implementation of the LMP's 'control channel management' mandatory ?
yes, however you can choose not to run the Hellos by setting the
HelloInterval and HelloDeadInterval equal to zero.

> 
> 
> Thanks !
> 
> Michiel
> 
> -- 
> +------------------------------------------------------------------+
> | Michiel van Everdingen                                           |
> | Systems Engineer                                                 |
> | Lucent Technologies - Optical Networking Group                   |
> | Botterstraat 45, 1271 XL       Phone : +31 35 687 4883           |
> | P.O. Box 18, 1270 AA           Fax   : +31 35 687 5976           |
> | Huizen, The Netherlands        mailto:MvanEverdingen@lucent.com  |
> +------------------------------------------------------------------+
>