ansorge-ccamp-lmp-sonet-sdh-00.txt

Internet DRAFT - draft-ansorge-ccamp-lmp-sonet-sdh

draft-ansorge-ccamp-lmp-sonet-sdh

Last Version:	draft-ansorge-ccamp-lmp-sonet-sdh-00.txt	Tracker Entry
Date:	`05-Jun-2002`
Disposition:	removed

CCAMP Working Group S. Ansorge
Document: draft-ansorge-ccamp-lmp-sonet-sdh-00.txt D. Papadimitriou
Category: Internet draft G. Grammel
Expires: May 2002 J. Jones
Alcatel

J. Lang
Calient

November 2001

LMP Extensions for Sonet and SDH

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt

1. Abstract

This memo is a companion document to [LMP] detailing Sonet and SDH
specifics. This document extends current definition of LMP with
respect to standard SDH and SONET features. It provides an overview
of different SONET/SDH interface capabilities, standard SONET/SDH
features and functions and defines LMP protocol extension to be used
with SONET/SDH interfaces. In addition, it considers a relationship
description which SONET/SDH features mentioned in this document are
supported by LMP and GMPLS signaling respectively.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].

Internet draft û Expires May 2002 1

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

2. Introduction

This memo defines the specific Sonet/SDH extension to LMP (see
[LMP]) in order to provide the operational and practical needs with
respect to some mechanisms currently covered in this protocol such
as Link Verification and Link Property Correlation.

Thereafter, in the scope of SDH/Sonet link management, this memo
proposes enhancing these functions by defining the required LMP
extension to provide:
- Enhanced Link Verification using the J0 Test Message
- Enhanced Operational Link Status request and Fault Localization
by enabling SDH/Sonet Supervision capabilities in the
ChannelStatus message
- Enhanced Link Property Correlation (Link Summarization)
procedure by enabling the exchange of the link protection
capabilities including Linear and Ring protection

For this purpose this memo first review the Sonet/SDH equipment
capabilities to be considered by the LMP extensions (Section 3) in
order to improve the Link Verification procedure using different
kind of Sonet/SDH equipment. Section 4 summarizes the Sonet/SDH
supervision capabilities in order to extend the ChannelStatus field
included in the ChannelStatus message. The next sections (Section 5
to 7) detail the mapping between the Sonet/SDH capabilities and the
LMP protocol extensions.

3. SONET/SDH Equipment capabilities

This section briefly summarizes the SONET/SDH equipment capabilities
to be considered for LMP extension purposes.

3.1 SONET/SDH layer functions

The SONET/SDH signal frame is decomposed in Section/Regenerator
Section (RS) and Line/Multiplex Section (MS) and payload. The
payload may carry multiple paths whereby each path might be subject
to pointer processing. The Section/RS, Line/MS and Path are treated
as separate layers.

Several functions are defined, in particular:
- Trail Termination (TT) function: applicable whenever the layer is
terminated and generated. Section/RS TT terminates and generates
the Section/RS trail, Line/MS_TT terminates and generates the
Line/MS trail. This function is contiguously sending out a signal.
- Adaptation function: applicable between layers to map client layer
signals into layer frame structure. If no client signal is
applicable a defined signal shall be used. The adaptation function
can coexist only with a TT function.
- Supervisory Trail Termination (STT) function: applicable when the
layer is not carrying user traffic. In this case the function
generates a valid signal that can be supervised from the other
side.

Internet Draft û Expires May 2002 2

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

- Path Overhead Monitoring (POM) function: applicable when the layer
is carrying user traffic. This function is used to monitor user
traffic and might be used to determine the path state.

3.2 Trail Trace Identifier in SONET/SDH

Basically SONET/SDH link verification is provided in-band using
Trail Trace Identifiers (TTI). At the Section/RS layer this function
is implemented by using the J0 byte, on higher order paths by using
the J1 byte and on lower order paths by using the J2 byte. When a
trace mismatch occurs an identifier (Trace Identifier Mismatch -
TIM) is generated: an alarm raised on disagreement on expected and
received TTI. See Appendix 1 for more details on TTI using J0.

3.3 Other SONET/SDH capabilities

3.3.1 Line/MS capabilities

Line/MS Terminating Equipment (LTE) equipment terminates and
generates the Section/RS and Line/MS overhead. Other equipment could
be one of the following with respect to the TTI function:
- Section Generating Equipment (SGE): As long as the link is not
allocated the SGE shall transmit a defined signal (like
supervisory unequipped signal) which includes at least J0.
Once the link is allocated the SGE function is disabled and the
section monitoring function might be enabled (non intrusive).
- AIS generating Equipment (AGE): As long as the link is not
allocated the AGE shall emit a defined AIS signal with valid
SDH/SONET frame and all ô1ö in the payload. This is a special form
of SGE without support of valid J0 generation.
- Section Monitoring Equipment (SME): As long as the link is
allocated the end to end path is monitored in both directions on
received and transmitted J0. The bi-directional function is only
mandatory on network border nodes. The unidirectional function is
optional at receiver side of intermediate nodes to determine the
path state
- SDH/SONET Extension LMP-capable nodes: such equipment is treated
like STE as either J0 or DCC bytes shall be accessible for Link
Verification purposes.

3.3.2 Multiplexing capabilities

Three types of multiplexing capabilities can be considered:
- Fixed multiplexer: In this case the adaptation function
(multiplexing) is not modifiable
- Flexible multiplexer: In this case the multiplexing scheme can be
adapted to the payload need, e.g. an AUG4 can be used for an AU4-
4c or 4 times AU4. This is done using the standard multiplexing
scheme (multiple of 4)
- Transparent multiplexer: In this case the multiplexing function
does not take care on the position and payload itself. Any
multiple of element types at any position is supported.

Internet Draft û Expires May 2002 3

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

3.3.3 Concatenation capabilities

Considerations about Contiguous Concatenation are covered in [GMPLS-
SONET-SDH] and [GMPLS-SONET-SDH-EXT].

3.3.4 Monitoring capabilities

Three monitoring types are defined for SDH/Sonet equipment:
- Supervisory: Monitors an unallocated link or path state based on
the active Supervisory TT at the other end
- Non intrusive: Monitors an allocated link or path state based on
end to end TT information
- Inherent: Monitors whether the signal can be determined and is
mainly based on the adaptation function

3.3.5 Loopback capabilities

In addition SDH/SONET ports provide loopback functions. Two loopback
types are defined:
- Line/MS loopback: provides a loopback capability closest to the
physical line. The received signal is directly looped back to the
sender via the transmit port. The transmitted signal from the
system is preempted by the loopback signal. This feature might
be used for link verification.
- Terminal loopback: provides a loopback capability closest to the
physical line back to the system. The transmit signal is directly
looped back to the system via the receive port. The line receiving
signal is preempted by the loopback signal. This feature might be
used to test a connection.

3.3.6 Protection capabilities

See ITU-T G.841 for protection capabilities.

4. Sonet/SDH Supervision Capabilities

Sonet/SDH Supervision covers Continuity, Connectivity, Signal
Quality and Alignment Supervision. These are briefly summarized in
the next paragraphs of this section.

4.1 Continuity supervision

Continuity supervision refers to the integrity of the continuity of
a channel. This is performed by monitoring the presence/absence of
the channel information. The monitoring process can check for the
whole information (e.g. LOS at the physical layer) or a specific
mandatory part of it (e.g. multiframe indication for SDH Tandem
Connection Monitoring - TCM).

At the path layer a replacement signal might be generated by an open
connection matrix (e.g. Unequipped signal for SDH). The detection of
this replacement signal indicates the loss of continuity.

Internet Draft û Expires May 2002 4

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

4.1.2 Loss Of Signal (LOS)

LOS signal supervision is used at the physical layer. Detection of
"incoming signal absent" occurs when the incoming power level at the
receiver has dropped to a level corresponding to a high error
condition.

4.1.3 Unequipped (UNEQ)

The Unequipped defect (UNEQ) shall be detected if N consecutive
frames contain the unequipped activation pattern in the unequipped
overhead. The UNEQ defect shall be cleared if in N consecutive
frames the unequipped deactivation pattern is detected in the
unequipped overhead. Note that strictly speaking Unequipped defect
is only defined for paths and not for Section/RS or Line/MS trails.

4.1.4 TC Loss of Tandem Connection (LTC)

The function shall detect for the presence/absence of the tandem
connection overhead in the TCM overhead by evaluating the multiframe
alignment signal in the TCM multiframe overhead. The loss of tandem
connection defect (LTC) shall be detected if the multiframe
alignment process is in the Out Of Multiframe (OOM) state. The LTC
shall be cleared if the multiframe alignment process is in the In
Multiframe (IM) state.

4.2 Connectivity Supervision

Connectivity supervision monitors the integrity of the routing of
the trail between sink and source. Connectivity is normally only
required if the layer provides flexible connectivity, both
automatically or manually (e.g. static configuration). The
connectivity is supervised by attaching a unique identifier at the
source. If the received identifier does not match this expected
identifier a connectivity defect has occurred.

4.2.1 Trace Identifier Mismatch (TTI) and Processing

See Section 3.3.

4.2.2 Loss of Sequence defect (SQM)

SQM shall be detected if the accepted sequence number does not match
the expected Sequence number. SQM shall be cleared if the accepted
sequence number matches the expected sequence number.

4.2.3 Loss of Alignment (LOA)

LOA shall be detected if the alignment process cannot perform the
alignment of the individual VC-4s to a common multiframe start (e.g.
LOA is activated if the differential delay exceeds the size of the
alignment buffer). Notice that LOA is the generic defect term

Internet Draft û Expires May 2002 5

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

referring to loss of frame (LOF), Loss Of Multiframe (LOM) or Loss
Of Pointer (LOP). We refer to Appendix 2 for more details on LOA.

4.3 Signal Quality supervision

Signal quality supervision enables monitoring the performance of a
trail. If the performance falls below a certain threshold this might
activate a defect. Details one excessive errors (EXC) and degraded
signal (DEG) are covered in Appendix 3.

4.4 Alignment Supervision

Alignment supervision checks that the frame and frame start can be
correctly recovered. The specific processes depend on the
signal/frame structure and may include:
û frame/multiframe alignment
û pointer processing
û alignment of several independent frames to a common frame start in
case of inverse multiplexing

If one of these processes fails a related Loss Of Alignment (LOA)
shall be activated.

4.5 Maintenance Supervision

Maintenance signal supervision is concerned with the detection of
maintenance indications in the signal.

4.5.1 Alarm Indication Signal (AIS)

If N consecutive frames contain the AIS activation pattern in the
AIS overhead, an AIS failure is detected. The AIS defect shall be
cleared if N consecutive frames contain the AIS deactivation pattern
in the AIS overhead.

For SDH MSn, the MS-AIS is transported over K2 byte while for
VC3/VC4 the AU-AIS is transported over the H1, H2 bytes.

5. Mapping SDH/SONET capabilities to LMP functions

5.1 Link Verification

5.1.1 Contiguous Link Verification

Usually, the link capabilities and activation shall be provided in
the DATA LINK objects of the Link Summary message (e.g. LTE, STE,
SGE, AGE, POM, etc). For instance, when considering STE or LTE
equipment, J0 is always inserted and monitored on both sides of the
link.

The following procedures can be defined when using J0 test message:
- LTE equipment: As J0 is contiguously transmitted on the link, the
Link Summary message shall contain the received and transmitted J0

Internet Draft û Expires May 2002 6

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

on the port. In case of agreement (capability negotiation both
sides are LTE) the standard TTI (Trail Termination Identifier)
functions are activated (monitor received J0) and raise a TIM
alarm in case of disagreement.
- SGE equipment: As J0 is contiguously transmitted on the link as
long as the link is not allocated Link Summary message shall
contain the received and transmitted SGE J0. The activated SGE
function shall be indicated in the link summary message.
- POM (Path Overhead Monitoring) equipment: As J0 is contiguously
monitored on both sides of the link as long as the link is
allocated the channel status message shall contain the received
and transmitted J0 for verification.

5.1.2 Out-of-band J0 Test Message

Capable of communicating using standard J0 byte as defined in ITU-T
G.707 for section trace monitoring. In this case, the Test message
is not transmitted using the J0 byte (i.e. over the Data Link) but
sent over the Control Channel and correlated for consistency check
to the received J0 pattern. In that case the Interface ID determines
the interface over which the standard J0 byte are transmitted in-
band. This feature is thus provided to accommodate Link Verification
when using legacy Sonet/SDH LTE equipment.

In order to get the mapping between the Interface ID over which the
J0 Test message is sent and the J0 pattern sent in-band, one must
provide the correlation between this pattern and the J0 Test
message.

5.2 Link Verification

5.2.1 LTE and STE transparent equipment (Contiguous)

The entire link verification procedure for LTE and STE is based on
standard SDH/SONET Trail Trace Identifier (TTI) functions in all
cases here contiguously generated and terminated on both link sides.
The entire link verification (BeginVerify, Test, VerifyEnd, and
corresponding acknowledgements) procedure as described in [LMP] is
replaced by exchanging transmitted and received TTI within the DATA
LINK object in the LinkSummary message.

In case of agreement as a result of Link Summary message exchange
the received/negotiated TTI is used as expected TTI and TIM alarm is
activated.

5.2.2 Fully transparent equipment (Supervisory)

Link verification for fully transparent equipment must distinguish
between equipment capable to provide Supervisory Trail Termination
function and/or path monitoring function.

For equipment providing Supervisory Trail Termination function the
same rules applies as described above (see Section 5.2.1) as long

Internet Draft û Expires May 2002 7

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

the path is not allocated for user traffic. As soon the path is
allocated for user traffic the Supervisory Trail Termination
function is deactivated and user traffic can pass. Optionally the
user traffic can be monitored for path state validation.

For equipment not capable to provide Supervisory Trail Termination
function the J0 based link verification procedure cannot be applied.
Those links can only be tested with loopback capabilities (see
Section 5.3).

5.2.3 LTE terminating equipment (Out-of-band)

An LTE exchanging within its overhead a Sonet/SDH Section/RS Trace
over the J0 byte (while Path tracing uses J1 or J2 byte). If the
trace exchanged over the out-of-band Test message does not match the
in-band Section/RS Trace message, the node report the mismatch
condition (TIM).

1. Test Message (MsgType = 10)

The Test message is transmitted over the control channel; the
matching with the Section/RS trace message is used to verify its
physical connectivity. This message is transmitted as an IP packet
with payload format as follows:

The above transmission order MUST be followed.

Note that this Test Message is sent over a control channel and NOT
over a data link and is used to request a node to extract from one
or more data links for a specific trace value at a given interface
ID.

The local (transmitting) node sends a given Test message
periodically (at least once every VerifyInterval ms) on the
corresponding data link until
(1) it receives a correlating TestStatusSuccess or TestStatusFailure
message on the control channel from the remote (receiving) node
(2) or all active control channels between the two nodes have
failed.

The remote node will send a given TestStatus message periodically
over the control channel until it receives either a correlating
TestStatusAck message or an EndVerify message is received over the
control channel.

2. TestStatusSuccess Message (MsgType = 11)

The TestStatusSuccess message is transmitted over the control
channel and is used to transmit the mapping between the local

Internet Draft û Expires May 2002 8

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

Interface Id û In-band Section/RS Trace and the Interface Id û Out-
of-band Section/RS Trace that was received in the Test message.

The above transmission order MUST be followed.

The contents of the REMOTE_INTERFACE_ID object MUST be obtained from
the corresponding Test message being positively acknowledged. The
Trace Message (received through the control channel and expected
from the data link arenÆt exchanged in case of test success)

3. TestStatusFailure Message (MsgType = 12)

The TestStatusFailure message is transmitted over the control
channel and is used to indicate that the Section/RS trace message
(exchanged over data links) was not received.

The above transmission order MUST be followed.

4. TestStatusAck Message (MsgType = 13)

The TestStatusAck message is used to acknowledge receipt of the
TestStatusSuccess or TestStatusFailure messages.

The above transmission order MUST be followed.

The contents of the MESSAGE_ID_ACK object MUST be obtained from the
TestStatusSuccess or TestStatusFailure message being acknowledged.

5. TestMismatch Message (MsgType = 21)

The TestStatusFailure message is transmitted over the control
channel and is used to indicate a Section/RS Trace Mismatch between
the in-band and the out-of-band Section/RS Trace.

The above transmission order MUST be followed.

6. TestMismatchAck Message (MsgType = 22)

The TestMismatchAck message is used to acknowledge receipt of a
TestMismatch message.

Internet Draft û Expires May 2002 9

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

The above transmission order MUST be followed.

Additional Object Class: TRACE MESSAGE Class (Class = 22) See
Section 7.1.

For bi-directional links two Trace Messages are exchanged one for
receive direction and one for the transmit direction (TRANSMIT TRACE
and RECEIVE TRACE MESSAGE, respectively).

5.3 Loopback function

5.3.1 Description

With AGE equipment, no overhead can be monitored or generated on a
Line/MS, the node must therefore provide Line/MS loopback function.
A sender is requesting a Line/MS loopback for a certain time to test
the Line/MS and reading its own generated data.

This request is used to indicate the direction of the loopback;
either towards the Line/MS or towards the system and therefore not
used for layers.

If the sender is of SGE type, it can verify its transmitted signal
with respect to the signal on the receive port. If both signals
match, the corresponding ports are wired in the right manner.

To avoid ambiguous interpretation of loopback signals a node shall
support only one loopback function at a time. Consequently, on time-
by-time basis, these capabilities are mutually exclusive. Moreover,
the loopback trigger must hence always direct to a single port.

5.3.2 Loopback Trigger

When Loopback Trigger function is used, the sender does not wait for
a test message to be received from remote side since the receiving
port internally generates the test message.

To support AGE-AGE links a test generator shall be applicable at
each node to test links. The test generator equipment must be cross-
connected to the desired port for testing.

Loopback functions can be requested on single interface base by the
LMP neighbor. This operation is based on LinkVerify message exchange
without using the Test, TestStatusSuccess, TestStatusFailed, and
TestStatusAck messages. BeginVerify objects must be extended to
invoke loopback activation on neighbor side. The VerifyEnd objects
must be extended to release the loopback function.

Internet Draft û Expires May 2002 10

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

While the loopback is active the initiator MUST verify its receiving
signal side whether it matches with the emitting side. Basis for
this validation can be standard Sonet/SDH LTE and STE function
validating the received TTI.

5.4 Contiguous Path monitoring

Even when interface (or path) is allocated for user traffic,
Sonet/SDH provides means to monitor the path by using a path
monitoring function.

Activation of path monitoring function is usually beside the
responsibility of signaling based on specific service
characteristics. It can be activated by the ChannelStatus messages.
Nevertheless once the path monitoring function is activated it can
be used for LinkVerify and ChannelStatus purposes by exchanging the
ingress and egress monitored TTI. ChannelStatus messages will
activate/deactivate SGE or AGE functions.

6. Link Property Correlation

6.1 Multiplexing Capabilities

Multiplexer alignment (except for transparent multiplexers) implies
that the payload structure of both ports must be aligned to avoid
pointer processing alarms. Therefore the multiplexing scheme and
capabilities shall be included in the DATA LINK object (Class = 17)
of the Link Summary message. In particular:
- Fixed multiplexer : Capability Min = Max
- Flexible multiplexer : Capability Min < Max
- Transparent multiplexer: Capability Min = ôinfinite valueö = Max

6.2 Protection

Link protection including Linear and Ring protection capabilities
can be exchanged between LMP neighbors by using LinkSummary message.

Linear protection can be take one (or more than one) of the
following configuration:
- Linear 1+1 dedicated protection
- Linear 1:1 dedicated protection
- Linear 1:N shared protection

Ring protection can be configured using the following capabilities
when available:
- Line/MS-DPRing : Dedicated MS/Line protection ring
- Line/MS-SPRing : 2-fiber MS/Line Shared protection ring
- Line/MS-SPRing : 4-fiber MS/Line Shared protection ring
- Path-DPRing : Dedicated Path protection ring
- Path-SPRing : Shared Path protection ring

7. LMP protocol extensions

Internet Draft û Expires May 2002 11

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

7.1 Link Verification

To support contiguous Link Verification the following new object
types are defined (here TRACE refers to TTI):

TRACE MESSAGE Class (Class = 22)

- TRANSMIT TRACE (C-Type = 1)

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trace Type | Trace Flags | Trace Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Trace Message (16 bytes) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This object is non-negotiable (N = 0).

Trace Message Type: 8 bits

Defines the type of the test message includes:
1 û Sonet Section and SDH RS Trace (J0 Byte)
2 û Sonet STS-SPE and SDH HO Path Trace (J1 Byte)
3 û Sonet VT and SDH LO Path Trace (J2 Byte)

There are no other types for SDH/Sonet

Trace Flags: 8 bits

Describe the scope of the TTI to which it applies

0x00 Unknown
0x01 Trail Termination (TT)
0x02 Supervisory Trail Termination (STT)
0x04 Path Overhead Monitor (POM)

Trace Length: 16 bits

The Length in bytes of the trace message provided.

Trace Message:

Transmitted Trace message. The valid length and
value combinations are determined by the specific technology
(e.g., Sonet or SDH). The message MUST be padded with zeros
to a 32-bit boundary, if necessary.

- RECEIVE_TRACE (C-Type = 2)

0 1 2 3

Internet Draft û Expires May 2002 12

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trace Type | Trace Flags | Trace Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Trace Message (16 bytes) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The LinkSummary Message (MsgType = 14) used to synchronize the
Interface Ids and correlate the properties of the TE link. The
format of the LinkSummary message is as follows:

<LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK>
<DATA_LINK>
[<TRANSMIT_TRACE>] [<RECEIVE_TRACE>]
[<DATA_LINK>...]

Moreover, the DATA LINK Object (Class = 17, C-Type = 1 and 2) Flags
field must include the following additional values:

0x01 Interface Type (see [LMP])
0x02 Allocated Link (see [LMP])
0x04 Contiguous Link Verification
0x08 Supervisory Link Verification
0x10 Path Monitoring

To enable the transport of the Test Message over the control
channel, the BEGIN_VERIFY object (Class = 13, C-Type = 1), the
Verify Transport Mechanism field (16 bits) must include an
additional value. More precisely,

Verify Transport Mechanism: 16 bits

This defines the transport mechanism for the Test Messages.
The scope of this bit mask is restricted to each link
encoding type. The local node will set the bits
corresponding to the various mechanisms it can support for
transmitting Test messages. The receiver chooses the
appropriate mechanism in the BeginVerifyAck message.

For Sonet/SDH Encoding Type, the following flags are
defined:

0x01 J0-16
0x02 DCCS
0x04 DCCL
0x08 J0-16 (TestMessage over Control Channel)

7.2 Loopback Verification

Internet Draft û Expires May 2002 13

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

The Flag field (16 bits) defined in the BEGIN_VERIFY_object (Class =
13, C-Type = 1) shall be extended to cover link loopback function:

Flags: 16 bits

The following flags are defined:

0x01 Verify all Links

If this bit is set, the verification process checks all
unallocated links; else it only verifies new ports or
component links that are to be added to this TE link.

0x02 Data Link Type

If set, the data links to be verified are ports,
otherwise they are component links

0x04 Loopback

If set, the data link loopback function is activated.

The loopback function is deactivated in case of following events:
a) at the end of the verify interval (VerifyDeadInterval)
b) on receipt of EndVerify message
c) when the port is allocated for user traffic

Moreover VerifyDeadInterval and Verify_Transport_Mechanism fields in
the BEGIN_VERIFY_ACK (Class = 14, C-Type = 1) fields must be
configured accordingly

7.3 Supervision

The ChannelStatus message is sent over the control channel and is
used to notify an LMP neighbor of the status of a data link.

The ChannelStatus (31-bit) field defined as the CHANNEL_STATUS
Object (Class = 18, C-Type = 1) of the ChannelStatus Message
includes the following additional values in order to include
Sonet/SDH supervision capabilities:

For Continuity Supervision purposes (see Section 4):

Value Status Condition
----- ----------------
5 Loss Of Signal (LOS)
6 Unequipped (UNEQ)
7 Unequipped Available (UNEQa)
8 Unequipped Unavailable (UNEQu)
9 Automatic Report Control (ARC)
10 Loss Of Tandem Connection (LTC)

For Connectivity Supervision purposes (see Section 4):

Internet Draft û Expires May 2002 14

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

Value Status Condition
----- ----------------
16 Trace Identifier Mismatch (TIM)
17 Loss of Sequence (SQM)
18 Loss of Alignment (LOA)
19 Loss of Frame (LOF)
20 HOVC Loss Of Multiframe (LOM)
21 Loss of Pointer (LOP)

For Maintenance Supervision purposes (see Section 4):

Value Status Condition
----- ----------------
22 MS/Line AIS (AIS)

7.4 Link Protection

As mentioned in Section 3.3, for protection purposes the standard
MSP/APS protocol (as defined in G.841) is used. In order to exchange
protection parameter during the Link Property Correlation procedure,
links must be identified by (component) Interface Ids and protection
group by Protection Group Ids.

This Protection Group Id includes the references to the links,
whether a link is to be considered primary or secondary (refer to as
the Protection Status (PS) and a Link Priority for 1:N protections
purposes.

The following object is exchange in the LinkSummary message. After
exchanging this message, the procedure described in Section 4 of
[LMP] applies.

7.4.1 LINEAR PROTECTION Class

LINEAR PROTECTION Class (Class = 23)

- C-Type = 1

Internet Draft û Expires May 2002 15

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PS | Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Protection Group ID: 32 bits

Identifies the Protection Group

Linear Protection Type: 8 bits

0x00 Unknown
0x01 Linear 1+1 dedicated protection
0x02 Linear 1:1 dedicated protection
0x04 Linear 1:N shared protection

Priority: 8 bits

Defines the priority levels of the link included in 1:N
shared protection groups. Default value is 0.

Protection Status (PS): 8 bits

0x00 Unknown
0x01 Primary (Working)
0x02 Secondary (Protecting)

Reserved fields: must be zeroed when sent and ignored when
received

7.4.2 RING PROTECTION Class

RING PROTECTION Class (Class = 24)

- East Node: C-Type = 1

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protection Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ring Protection| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| East Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PS | Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |

Internet Draft û Expires May 2002 16

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

- West Node: C-Type = 2

Protection Group ID: 32 bits

Identifies the Protection Group

Interface ID: 32 bits (see [LMP])

Ring Protection Type: 8 bits

0x00 Unknown
0x01 Line/MS-DPRing
0x02 Line/MS-SPRing (2-fiber)
0x04 Line/MS-SPRing (4-fiber)
0x08 Path-DPRing
0x10 Path-SPRing

Priority: 8 bits

Defines the priority levels of the link included in 1:N
shared protection groups. Default value is 0.

Protection Status (PS): 8 bits

0x00 Unknown

Internet Draft û Expires May 2002 17

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

0x01 Primary (Working)
0x02 Secondary (Protecting)

Reserved fields: must be zeroed when sent and ignored when
received

7.5 Multiplexing Capabilities

To be covered in a future release.

8. Security Considerations

This document does not imply additional security considerations to
the one already defined in [LMP].

9. References

1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.

2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997

3 Lang, J. et al, ôLink Management Protocol v1ö, Internet Draft,
draft-ietf-ccamp-lmp-02.txt, October 2001

10. Acknowledgments

The authors would like to thank Bernard Sales, Emmanuel Desmet, for
their constructive comments and inputs.

11. Author's Addresses
Stefan Ansorge
Alcatel SEL AG
E-mail: Stefan.ansorge@alcatel.de

Gert Grammel
Alcatel
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7060
Email: gert.grammel@netit.alcatel.it

Jim Jones
Alcatel
3400 W. Plano Parkway,
Plano, TX 75075, USA
Phone: +1 972 519-2744
Email: Jim.D.Jones1@usa.alcatel.com

Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel.be

Internet Draft û Expires May 2002 18

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

Jonathan P. Lang
Calient Networks
25 Castilian Drive
Goleta, CA 93117, USA
Email: jplang@calient.net

12. Appendix 1: Trail Trace Identifier (TTI)

A Trail Trace Identifier (TTI) is defined as a 16-byte frame
structure. The first byte is a header byte, which includes the
result of a CRC-7 calculation over the previous frame. The following
15 bytes are used for the transport of 15 T.50 characters required
for the Section Access Point Identifier (SAPI). The ones used for
the Test Message. Moreover the bit 1 of each byte (of the 16 byte
frame structure) is the trace identifier frame alignment signal
(value = 1000 0000 0000 0000).

The structure for the J0 16 byte frame:

0 1 2 3 4 5 6 7
1 1 x x x x x x x <= CRC-7
2 0 - - - - - - -
3 0 - - - - - - -
4 0 - - - - - - -
. . - - - - - - -
16 0 - - - - - - -

A TTI is generated by the trail termination functions and
supervisory trail termination functions. As mentioned before the
trail termination function is contiguously sending out a valid
signal and a stable Trail trace identifier. The supervisory trail
termination function is sending out a valid signal with a stable
trail trace identifier as long the line or path is not allocated for
user services.

Derived Management functions on TTI for the control plane are:
- Send TTI: provision the emitted TTI
- Received TTI: retrieve the received TTI
- Expected TTI: check the received TTI with an expected TTI
- Trace Identifier Mismatch (TIM): an alarm raised on disagreement
on expected and received TTI

Appendix 2 û Loss Of Alignment (LOA)

LOA is the generic defect term referring to Loss Of Frame (LOF),
Loss Of Multiframe (LOM) or Loss Of Pointer (LOP). The following
paragraphs describes each of these defects:

Loss Of Frame (LOF)

For STMn/STSn signals, if the out-of-frame state persists for 3
milliseconds, a loss of frame (LOF) state shall be declared.

Internet Draft û Expires May 2002 19

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

Once in a LOF state, this state shall be left when the in-frame
state persists continuously for 3 milliseconds.

HOVC Loss Of Multiframe (LOM)

If the multiframe alignment process is in the out-of-multiframe
state and the H4 multiframe overhead byte is not recovered
within N ms (not configurable and in the range 1 ms to 5 ms)),
a LOM defect shall be declared. Once in a LOM state, this state
shall be exited when the multiframe is recovered.

Loss of Pointer (LOP)

A LOP is declared if the pointer value cannot be interpreted in
the right manner. This might be due to illegal values (out of
range), or due to high frequency of value changes.

Appendix 3 - Excessive error (EXC) and Degraded signal (DEG)

Excessive error and degraded signal defects are to be detected
according to the following process:

- An excessive error (EXC) shall be detected if the equivalent BER

exceeds a preset threshold of 10^(-x), x = 3 , 4 or 5. The excessive
error defect shall be cleared if the equivalent BER is better than
10^(-x-1).

- A degraded signal (DEG) shall be detected if the equivalent BER
exceeds a preset threshold of 10^(-x), x = 5, 6, 7, 8 or 9. The
degraded signal defect shall be cleared if the equivalent BER is
better than 10^(-x-1). A DEG defect can be detected in æburstyÆ mode
in case N consecutive seconds the Error Rate is greater than a
provision-able threshold.

SONET uses EXC detector types, while most AU-4 based SDH uses
Alternative DEG detector types.

Internet Draft û Expires May 2002 20

draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001

Full Copyright Statement

"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into

Internet Draft û Expires May 2002 21