[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LMP & neighbor discovery
Hello all,
Please find below two proposed updates of the LMP draft. These
updates are based on the thoughts expressed in emails
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html
Your comments are appreciated !
Thanks,
Michiel
1. Insert an additional section on "Automatic neighbor discovery"
==============================================================
In this section, an optional LMP procedure is described to automatically
detect the identification of the other end of the data link. Basically,
automatic neighbor discovery is implemented by reading the incoming
'access point identifier' [ITU-T G.707].
A Sub-Network Point (TTP or CTP) that implements the automatic neighbor
discovery procedure MUST send its identification in the access point
identifier. The identification SHOULD be formatted into 16 bytes as
follows ([OIF 2000.159.01]):
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|CRC|Typ|Dis| Node Identifier | Port Identifier |
+---+---+---+-------------------------------+-------------------+
Figure 1: format of the access point identifier
to enable automatic neighbor discovery
The format as specified in figure 1 is in line with the specification
in [ITU-T G707]. This SDH standard places the most stringent constraints
on the contents of the access point identifiers.
All entries in the access point identifier, except for the CRC
field, are printable 7 bit encoded ASCII characters [ITU-T T.50].
CRC
The CRC-7 code of the previous frame as specified in G.707.
Typ
The "type indicator" informs the receiver of the sender's role.
values are:
"T": Trail Termination Point
"C": Connection Termination Point
Dis
The "distinguishing identifier" avoids the proposed format to be
confused with some other optional format, e.g. the format specified
in G.831, Appendix I.
value:
"@"
Node Identifier
The "node identifier" is the IPv4 address that identifies the
sending Node_Id. The IPv4 address is encoded in 8 hex characters.
Port Identifier
The "Port Identifier" identifies the sender's Interface_Id in hex
format. This gives port numbers 0-FFFFF (1,048,575) which should
be enough for all types of Network Elements.
As an example, a node with IP address 192.168.2.23 would sent out
the following access point identifier (excluding the CRC) from a TTP
with local interface id 421:
T@C0A802170001A5
A sending TTP that implements the automatic neighbor discovery scheme
will continuously send out its own identification. This is according to
ITU-T G.831, "the access point identifier should not change while the
access point remains in existence".
A sending CTP that implements the automatic neighbor discovery scheme
MUST send its identification as long as it has not received a
linkSummary message indicating that the associated receiver has
discovered this sending CTP. The CTP MAY send its identification
continuously, until it is discovered. The CTP MAY also send its
identification in intervals, until it is discovered.
Example: figure 2 shows 4 network elements (NEs) and a single data
link between these NEs. Two NEs terminate the data link on interfaces
marked with 'T' (TTP). Two other NEs are transparent to the data link
on interfaces marked with 'C' (CTP). E.g. NE-1 and NE-4 are SONET/SDH
multiplexers; NE-2 and NE-3 are transparent optical cross connects;
the data link is STM-N/OC-N.
Note that neighbor discovery is defined per datalink, so the actual
number of datalinks per NE is not relevant.
+------+ +------+ +------+ +------+
| T-|--->--|-C C-|--->--|-C C-|--->--|-T |
| | A | | B | | C | |
| | | | | | | |
| NE-1 | | NE-2 | | NE-3 | | NE-4 |
+------+ +------+ +------+ +------+
Figure 2: automatic discovery example - 1
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.
NE-3 will continuously scan all its not discovered input ports
for a discovery signal.
At some point, NE-3 will detect the test-signal on data link B.
See figure 3.
+------+ +------+ +------+ +------+
| T-|--->--|-C C-|--->--|-C C-|--->--|-T |
| | A | / | B | \ | C | |
| | | T | | T | | |
| NE-1 | | NE-2 | | NE-3 | | NE-4 |
+------+ +------+ +------+ +------+
Figure 3: automatic discovery example - 2
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.
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.
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
A Sub-Network Point (TTP or CTP) MAY also use an alternative format
for the access point identifier, e.g. the one specified in
G.831, Appendix I. In this case, discovery of the address of the
sending access point will need involvement of a 'name server'. Using
an alternative format is, for example, needed in case the address
of the access point can not be encoded in the limited length of
the access point identifier, e.g. because IPv6 is used in
the control plane.
2. Add Additional text to section 4, "Link Property Correlation"
=============================================================
Note that the verify procedure is only applicable for CTP-->--CTP
and CTP-->--TTP dataLinks. The verify procedure is not applicable
for TTP-->--CTP and TTP-->--TTP dataLinks. TTPs constantly send
out their identification; the receiver can therefore at any time
verify the connectivity of the dataLink.
--
+------------------------------------------------------------------+
| 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 |
+------------------------------------------------------------------+