Network Working Group A. Fredette, E. Snyder, J. Shantigram
Internet Draft (PhotonEx Corp)
Expiration Date: September 2001
J. Lang, J. Drake, G. Tumuluri
(Calient Networks)
R. Goyal, S. Brorson, R. Krishnan
(Axiowave Networks)
W. L. Edwards
(iLambda Networks)
Y. Xue
(UUNET/WorldCom)
J. Yu
(Zaffire, Inc)
S. Dharanikota
(Nayna Networks, Inc)
March 2001
Link Management Protocol (LMP) for WDM Transmission Systems
draft-fredette-lmp-wdm-01.txt
STATUS OF THIS MEMO:
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [Bra96].
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.
Abstract
A suite of protocols is being developed in the IETF to allow
networks consisting of photonic switches (PXCs), optical
Fredette et. al. [Page 1]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
crossconnects (OXCs), routers, switches, DWDM transmission systems,
and optical add-drop multiplexors (OADMs) to use an MPLS-based
control plane to dynamically provision resources and to provide
network survivability using protection and restoration techniques.
As part of this protocol suite, the Link Management Protocol (LMP)
[LMP] is defined to "maintain control channel connectivity, verify
component link connectivity, and isolate link, fiber, or channel
failures within the network." In it's present form, [LMP] focuses
on peer communications (eg. OXC-to-OXC). In this document we
propose extensions to LMP for use with DWDM transmission systems.
1. Introduction
Future networks will consist of photonic switches (PXCs), optical
crossconnects (OXCs), routers, switches, DWDM transmission systems,
and optical add-drop multiplexors (OADMs) that use the GMPLS control
plane to dynamically provision resources and to provide network
survivability using protection and restoration techniques. A pair
of nodes (e.g., a PXC and a DWDM system) may be connected by
thousands of fibers. Furthermore, multiple fibers and/or multiple
wavelengths may be combined into a single bundled link. [LMP]
Defines the Link Management Protocol (LMP) to "maintain control
channel connectivity, verify component link connectivity, and
isolate link, fiber, or channel failures within the network." In
it's present form, [LMP] focuses on peer communications (eg.
OXC-to-OXC) as illustrated in Figure 1. In this document,
extensions to LMP for use with DWDM transmission systems are
proposed. It is assumed that the reader is familiar with LMP as
defined in [LMP].
+------+ +------+ +------+ +------+
| | ----- | | | | ----- | |
| OXC1 | ----- | WDM1 | ===== | WDM2 | ----- | OXC2 |
| | ----- | | | | ----- | |
+------+ +------+ +------+ +------+
^ ^
| |
+----------------------LMP----------------------+
Figure 1: Current LMP Model
A great deal of information about a link between two OXCs is known
by the DWDM transmission system. Exposing this information to the
control plane via LMP can improve network usability by further
reducing required manual configuration and also greatly enhancing
fault detection and recovery. Fault detection is particularly an
issue when the network is using all-optical photonic switches (PXC).
Once a connection is established, PXCs have only limited visibility
into the health of the connection. Even though the PXC is
all-optical, long-haul DWDM transmission systems typically terminate
Fredette et. al. [Page 2]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
channels electrically and regenerate them optically, which presents
an opportunity to monitor the health of a channel between PXCs.
The model for extending LMP to WDM transmission systems is shown in
Figure 2.
+------+ +------+ +------+ +------+
| | ----- | | | | ----- | |
| OXC1 | ----- | WDM1 | ===== | WDM2 | ----- | OXC2 |
| | ----- | | | | ----- | |
+------+ +------+ +------+ +------+
^ ^ ^ ^ ^ ^
| | | | | |
| +-----LMP-----+ +-----LMP----+ |
| |
+----------------------LMP----------------------+
Figure 2: Extended LMP Model
In this model, an OXC may have multiple LMP sessions corresponding
to multiple peering relationships. At each level, LMP provides link
management functionality (i.e., control channel management, physical
connectivity verification, link property correlation) for that
peering relationship. For example, the OXC-OXC LMP sessions in
Figure 2 are used to build traffic-engineering (TE) links for GMPLS
signaling and routing, and are managed as described in [LMP]. At the
transport level, the OXC-WDM LMP session (shown in Figure 2) is used
to augment knowledge about the links between the OXCs. The
management of these LMP sessions is discussed in this draft.
Although there are many similarities between an OXC-OXC LMP session
and an OXC-WDM LMP session, particularly for control management and
link verification, there are some significant differences as well.
These differences can primarily be attributed to the nature of an
OXC-WDM link, and the purpose of OXC-WDM LMP sessions. As
previously mentioned, the OXC-OXC links provide the basis for GMPLS
signaling and routing at the optical layer. The information
exchanged over LMP-WDM sessions is used to augment knowledge about
the links between OXCs.
In order for the information exchanged over the OXC-WDM LMP sessions
to be used by the OXC-OXC session, the information must be
coordinated by the OXC. However, the two LMP sessions are run
independently and MUST be maintained separately. One critical
requirement when running an OXC-WDM LMP session is the ability of
the WDM to make a data-bearing link transparent when not doing the
verification procedure. This is because the same data-bearing link
may be verified between OXC-WDM and between OXC-OXC. Currently, the
BeginVerify procedure is used to coordinate the Test procedure (and
hence the transparency/opaqueness of the data-bearing links) as
Fredette et. al. [Page 3]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
described in [LMP].
To maintain independence between the sessions, it MUST be possible
for the LMP sessions to come up in any order. In particular, it
MUST be possible for an OXC-OXC LMP session to come up without an
OXC-WDM LMP session being brought up, and vice-versa.
This draft focuses on extensions required for use with opaque
transmission systems. Work is ongoing in the area of completely
transparent wavelength routing; however, it is premature to identify
the necessary characteristics and performance information to
advertise. That said, the protocol described in this document
provides the necessary framework in which to advertise additional
information as it is deemed appropriate.
Additional details about the extensions required for LMP are
outlined in the next section.
2. LMP Extensions for WDM Transport Systems
As currently defined, LMP consists of four types of functions:
1. Control Channel Management
2. Link Verification
3. Link Summarization
4. Fault Localization
Extending LMP for LMP-WDM sessions requires the addition of a
performance summarization/notification function as follows:
5. Performance Summarization
It is very important to understand the subtle distinctions between
the different types of links being considered in the extended
LMP-WDM. For example, in Figure 2 when OXC1 and OXC2 complete the
verify process, the links being verified are the end-to-end links
between the OXC's. It is the TE link composed of these "ports" or
"component links" that are advertised in the routing protocols and
used for the purposes of connection setup. The verify procedure
between OXC1 and WDM1, on the other hand verifies the shorter link
between these two nodes. However, each of these shorter links is a
segment of one of the larger end-to-end links. The verify serves
two functions: to verify connectivity and exchange handles by which
each port or component link is referred. Furthermore, it is up to
the OXC to correlate the handles between the various LMP sessions.
Once a control channel has been established and the OXC-WDM
verification procedure has been completed successfully, the OXC and
WDM transmission system may exchange information regarding link
configuration and/or performance characteristics (link/performance
summarization). An OXC may also receive notification from a WDM
transmission system (performance/fault notification).
Fredette et. al. [Page 4]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
In subsequent sections, specific changes are proposed to extend LMP
to work with WDM transmission systems.
2.1. Control Channel Management
The control channel management for OXC-WDM links is the same as for
OXC-OXC links, as described in [LMP]. The LMP Capability TLV
includes a flag indicating support of an OXC-WDM LMP session as
described in this draft. Furthermore, a flag has been added to the
LMP Common Header to identify the transmitting node as a DWDM system.
2.2. Link Verification
The Test procedure used with WDM transmission systems is the same as
described in [LMP]. The VerifyTransportMechanism (included in the
BeginVerify and BeginVerifyAck messages) is used to allow nodes to
negotiate a link verification method and is essential for
transmission systems which have access to overhead bytes rather than
the payload. The VerifyId (provided by the remote node in the
BeginVerifyAck message, and used in all subsequent Test messages) is
used to differentiate Test messages from different LMP sessions.
2.3. Link Summarization
Additional type-length values (TLVs) are defined to extend the
LinkSummary message to include link characteristics. The TLVs
described in the following subsections are transmitted as Data Link
Sub-TLVs in the Data Link TLV (see [LMP]).
The link characteristics, in general, are those characteristics
needed by the control plane for constraint-based routing and
connection establishment. Additionally, the characteristics
advertised in the LinkSummary message are intended to be
more-or-less static characteristics as opposed to the more dynamic
ones advertised in the PerformanceSummary message described in
Section 2.4.
The format of the Data Link Sub-TLVs follows the LMP TLV format
given In Section 8.3 of [LMP] and shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (TLV Object) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N: 1 bit
Fredette et. al. [Page 5]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
The N flag indicates if the object is negotiable parameter
(N=1) Or a non-negotiable parameter (N=0).
Note: none of the Data Link TLVs that are defined in LMP-WDM
are negotiable and the N bit should be set to N=0.
Type: 15 bits
The Type field indicates the TLV type.
Length: 16 bits
The Length field indicates the length of the TLV object in
bytes.
The following Link Characteristics are advertised on a per component
link (or port) basis.
2.3.1 Link Group ID
A local ID assigned to a group of component links. This ID can be
used to reduce the control traffic in the case of a failure by
enabling the systems to send a single message for a group instead of
individual messages for each member of the group. A link may be a
member of multiple groups. For example, there may be a group
corresponding to a particular wavelength and another group assigned
to a physical fiber.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type = TBD | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type: 15 bits = TBD
- Length: 16 bits = 4
- Group ID: 32 bits
2.3.2 Link Descriptor
The Link Descriptor TLV represents the characteristics of the link
comprising the encoding type and bandwidth characteristics. This
information is needed for constructing a circuit. The OXC must
match the link information between incoming and outgoing interfaces
for a given path.
Fredette et. al. [Page 6]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
Note: This information may be a prerequisite for running the verify
protocol, thus it may be redundant when verify is being used.
The details for the information in this TLV are the same as those
for the link descriptor sub-TLV defined in [KRB00a].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type = TBD | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Encoding Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type: 15 bits = TBD
- Length: 16 bits = 12
- Link Encoding Type: 32 bits
Value Link Encoding Type
----- ------------------
1 Standard SONET
2 Arbitrary SONET
3 Standard SDH
4 Arbitrary SDH
5 Clear
6 GigE
7 10GigE
- Minimum Reservable Bandwidth: 32 bits
Bytes per Second represented in IEEE floating point format.
- Maximum Reservable Bandwidth: 32 bits
Bytes per Second represented in IEEE floating point format.
If the interface only supports a fixed rate, the minimum and maximum
bandwidth fields are set to the same value.
Bandwidth Values and their IEEE representation for common interfaces
are provided in the following table.
Signal Type (Bit-rate) Value (Bytes/Sec)
(IEEE Floating point)
Fredette et. al. [Page 7]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
----------- ----------- ------------
DS0 (0.064 Mbps) 0x45FA0000
DS1 (1.544 Mbps) 0x483C7A00
E1 (2.048 Mbps) 0x487A0000
DS2 (6.312 Mbps) 0x4940A080
E2 (8.448 Mbps) 0x4980E800
Ethernet (10.00 Mbps) 0x49989680
E3 (34.368 Mbps) 0x4A831A80
DS3 (44.736 Mbps) 0x4AAAA780
STS-1 (51.84 Mbps) 0x4AC5C100
Fast Ethernet (100.00 Mbps) 0x4B3EBC20
E4 (139.264 Mbps) 0x4B84D000
OC-3/STM-1 (155.52 Mbps) 0x4B9450C0
OC-12/STM-4 (622.08 Mbps) 0x4C9450C0
GigE (1000.00 Mbps) 0x4CEE6B28
OC-48 (2488.32 Mbps) 0x4D9450C0
OC-192 (9953.28 Mbps) 0x4E9450C0
10GigE-LAN (10000.00 Mbps) 0x4E9502F9
2.3.3 Shared Risk Link Group Identifier (SRLG):
SRLGs to which the link is a member. This information is manually
configured on the DWDM systems by the service providers. Used for
diverse path computation.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type = TBD | 4 * No. of SRLGs in link |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type: 15 bits = TBD
- Length: 16 bits = 4 * No. of SRLGs in link
- Shared Risk Link Group Value: 32 bits
List as many SRLGs as apply.
2.3.4 Wavelength
The wavelength being used by the WDM system to transport the
component link. Note: this is needed for a transparent system, but
Fredette et. al. [Page 8]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
of questionable use for an opaque system.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type = TBD | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type: 15 bits = TBD
- Length: 16 bits = 4
- Wavelength: 32 bits
Local identifier for wavelength on which the WDM system will
transmit the signal from the link.
2.3.5 Bit Error Rate (BER) Estimate
This TLV provides an estimate of the BER for the component link.
The bit error rate (BER) is the percentage of bits that have errors
relative to the total number of bits received in a transmission,
usually expressed as ten to a negative power. For example, a
transmission might have a BER of 10 to the minus 6, meaning that,
out of 1,000,000 bits transmitted, one bit was in error. The BER is
an indication of overall link quality.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type = TBD | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | BER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type: 15 bits = TBD
- Length: 16 bits = 4
- Reserved: 24 bits
Must be set to zero on transmit and ignored on receive.
- BER: 8 bits
The exponent from the BER representation described above. For
Fredette et. al. [Page 9]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
example, if the BER is 10 to the minus X, the BER field is set to
X.
2.3.6 Optical Protection
Whether the WDM system protects the link internally. This
information can be used as a measure of quality of the link. It may
be advertised by routing and used by signaling as a selection
criterion as described in [GMPLS].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type = TBD | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type: 15 bits = TBD
- Length: 16 bits = 4
- Reserved: 24 bits
Must be set to zero on transmit and ignored on receive.
- Link Flags: 6 bits
Indicates supported link protection type. These link flags are
intended to be consistent with those defined in [GMPLS].
The following flags are defined:
0x20 Enhanced
Indicates that a protection scheme that is more reliable
than Dedicated 1+1 should be used, e.g., 4 fiber
BLSR/MS-SPRING.
0x10 Dedicated 1+1
Indicates that a dedicated link layer protection scheme,
i.e., 1+1 protection, should be used to support the LSP.
0x08 Dedicated 1:1
Indicates that a dedicated link layer protection scheme,
i.e., 1:1 protection, should be used to support the LSP.
0x04 Shared
Fredette et. al. [Page 10]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
Indicates that a shared link layer protection scheme, such
as 1:N protection, should be used to support the LSP.
0x02 Unprotected
Indicates that the LSP should not use any link layer
protection.
0x01 Extra Traffic
Indicates that the LSP should use links that are protecting
other (primary) traffic. Such LSPs may be preempted when
the links carrying the (primary) traffic being protected
fail.
2.3.7 Span Length:
Distance of fiber in WDM system. May be used as a routing metric or
to estimate delay.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type = TBD | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Span Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type: 15 bits = TBD
- Length: 16 bits = 4
- Span Length: 32 bits
Length of WDM span in meters.
2.4. Performance Summarization
A new type of message is added to LMP to advertise performance
monitoring (PM) information that is available within the WDM
transmission system. The PM information either is available on
demand, or may be advertised periodically. It should also be
possible to configure the system to send PM messages upon crossing
thresholds. For example, a message might be sent if the BER exceeds
a pre-configured threshold. PM information is different from link
characteristics in that it is more dynamic in nature and tends to be
measured over a period of time.
Fredette et. al. [Page 11]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
NOTE: The following messages will be added in a future version. It
will be possible to request information on a TE Link, Group, or Data
Link basis. It will also be possible to identify which performance
information is requested.
1. Performance Summarization Request
2. Performance Summarization Advertisement
3. Performance Summarization Acknowledgement
PM information should be advertised for one of the following reasons:
- For use in ascertaining a QoS level of a link for routing purposes
- To predict likely or impending failure so that a connection can
be rerouted proactively.
This information can be used to allow the system to reroute
connections proactively to avert potential failures, and so that
problems can be diagnosed.
The following Performance Monitoring information may be advertised
on a per component link or interface basis:
2.4.1 Line-Side Bit Error Rate (BER):
This TLV provides a report of the actual BER for the component link.
This is a measure of BER within the WDM system. It is measured on
streams flowing from the WDM node to the peer Node.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type = TBD | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | BER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type: 15 bits = TBD
- Length: 16 bits = 4
- Reserved: 24 bits
Must be set to zero on transmit and ignored on receive.
- BER: 8 bits
The exponent from the BER representation as described in Section
2.3.5. For example, if the BER is 10 to the minus X, the BER
field is set to X.
Fredette et. al. [Page 12]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
2.4.2 SONET Monitoring Information
In addition to OPM measures, the transmission systems may exchange
SONET (OEO) monitoring information with the photonic switches, if
such information is available. Requirements for PM in SONET are
given in GR-253-CORE and some discussion of PM is also included in
G.874. PM parameters shall be gathered and reported over two time
intervals: 15-minute intervals and 24-hour intervals. The list given
below is a subset of the parameters listed in GR-253-CORE, and is
intended to be a minimal list required for making routing decisions.
Naturally, one also could implement the entire suite of SONET PM
parameters if one wanted to.
2.4.2.1 BER
Calculated via B1 error count
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type = TBD | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BER-24H-1 | BER-24H-2 | BER-15M-1 | BER-15M-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type: 15 bits = TBD
- Length: 16 bits = 4
- BER-24H-1: 8 bits
BER for the previous 24 hour period. Represented as the BER
exponent as described in Section 2.3.5.
- BER-24H-2: 8 bits
BER for the current 24 hour period. Represented as the BER
exponent as described in Section 2.3.5.
- BER-15M-1: 8 bits
BER for the previous 15 minute period. Represented as the BER
exponent as described in Section 2.3.5.
- BER-15M-2: 8 bits
BER for the current 15 minute period. Represented as the BER
exponent as described in Section 2.3.5.
Fredette et. al. [Page 13]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
2.4.2.2 SES
Severely errored seconds. Collected via B1 error count. Used to
collect statistics on burst errors.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type = TBD | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SES-24H-1 | SES-24H-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SES-15M-1 | SES-15M-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type: 15 bits = TBD
- Length: 16 bits = 8
- SES-24H-1: 16 bits
SES for the previous 24 hour period.
- SES-24H-2: 16 bits
SES for the current 24 hour period.
- SES-15M-1: 16 bits
SES for the previous 15 minute period.
- SES-15M-2: 16 bits
SES for the current 15 minute period.
2.4.2.3 Protection switch count
Number of protection switch events during the count interval.
Provides an indication of possible link problems. If protection
switch chattering is occurring, the link is bad.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type = TBD | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSC-24H-1 | PSC-24H-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSC-15M-1 | PSC-15M-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fredette et. al. [Page 14]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
- Type: 15 bits = TBD
- Length: 16 bits = 8
- PSC-24H-1: 16 bits
Protection switch count for the previous 24 hour period.
- PSC-24H-2: 16 bits
Protection switch count for the current 24 hour period.
- PSC-15M-1: 16 bits
Protection switch count for the previous 15 minute period.
- PSC-15M-2: 16 bits
Protection switch count for the current 15 minute period.
2.4.2.4 STS pointer justifications
Number of times the SONET SPE pointer needed to be justified.
Provides an indication of the clocking accuracy over the optical
link.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type = TBD | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PJC-24H-1 | PJC-24H-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PJC-15M-1 | PJC-15M-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type: 15 bits = TBD
- Length: 16 bits = 8
- PJC-24H-1: 16 bits
Number of times the SONET SPE pointer needed to be justified
during the previous 24 hour period.
- PJC-24H-2: 16 bits
Number of times the SONET SPE pointer needed to be justified
during the current 24 hour period.
Fredette et. al. [Page 15]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
- PJC-15M-1: 16 bits
Number of times the SONET SPE pointer needed to be justified
during the previous 15 minute period.
- PJC-15M-2: 16 bits
Number of times the SONET SPE pointer needed to be justified
during the current 15 minute period.
2.5. Fault Localization
Fault management consists of three major functions:
1. Fault Detection
2. Fault Localization
3. Fault Notification
The actual Fault Detection mechanisms are the responsibility of the
individual nodes and are not specified as part of this protocol.
Fault detection mechanisms may include such things as bit error rate
(BER) exceeding a threshold, loss of signal (LOS) and certain
SONET-level errors.
The fault notification and localization procedure is essentially the
same as in the current version of LMP, however, it is executed at
two levels in the extended OXC-WDM LMP.
OXCs continue to execute the OXC-to-OXC fault localization as
currently specified. The main difference is that the WDM system may
initiate the process (both downstream and upstream). The WDM system
will also execute its own fault localization process that may allow
it to determine the location of the fault much more specifically
than the OXCs can. For example, the WDM transmission system may be
able to pinpoint the fault to a particular amplifier along a set of
fibers that can span 1000's of kilometers.
3. Security Considerations
The security considerations will be the same as in [LMP].
Fredette et. al. [Page 16]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
4. References
[GMPLS] Berger, L., Ashwood-Smith, Peter, editors, "Generalized
MPLS - Signaling Functional Description", Internet Draft,
draft-ietf-mpls-generalized-signaling-02.txt, (work in
progress), March 2001.
[Bra96] Bradner, S., "The Internet Standards Process -- Revision
3," BCP 9, RFC 2026, October 1996.
[CBD00] Ceuppens, L., Blumenthal, D., Drake, J., Chrostowski, J.,
Edwards, W. L., "Performance Monitoring in Photonic
Networks in Support of MPL(ambda)S", Internet Draft,
draft-ceuppens-mpls-optical-00.txt, (work in progress),
March 2000.
[DBC00] Drake, J., Blumenthal, D., Ceuppens, L., et al.,
"Interworking between Photonic (Optical) Switches and
Transmission Systems over Optical Link Interface (OLI)
using Extensions to LMP", OIF Contribution oif2000.254,
(work in progress), November 2000.
[KRB00] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
MPLS Traffic Engineering," Internet Draft,
draft-kompella-mpls-bundle-02.txt, (work in progress),
July 2000.
[KRB00a] Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF
Extensions in Support of Generalized MPLS," Internet
Draft, draft-kompella-ospf-extensions-00.txt, (work in
progress), July 2000.
[LMP] Lang, J., Mitra, K., Drake, J., Kompella, K., Rekhter,
Y., Berger, L., Saha, D., Basak, D., Sandick, H., Zinin,
A., "Link Management Protocol (LMP)", Internet Draft,
draft-ietf-mpls-lmp-01.txt, (work in progress), November
2000.
[SDH] ITU-T G.707, "Network node interface for the synchronous
digital hierarchy (SDH)", 1996.
[SONET] GR-253-CORE, "Synchronous Optical Network (SONET)
Transport Systems: Common Generic Criteria", Telcordia
Technologies, Issue 3, September 2000
[T.50] ITU-T T.50, "International Reference Alphabet (IRA)
(formerly International Alphabet No. 5 or IA5)
Information technology 7-bit coded character set for
information interchange.", 1992.
Fredette et. al. [Page 17]
Internet Draft draft-fredette-lmp-wdm-01.txt March 2001
5. Author's Addresses
Andre Fredette Ed Snyder
PhotonEx Corporation PhotonEx Corporation
8C Preston Court 8C Preston Court
Bedford, MA 01730 Bedford, MA 01730
email: fredette@photonex.com email: esnyder@photonex.com
Jagan Shantigram Jonathan P. Lang
PhotonEx Corporation Calient Networks
8C Preston Court25 Castilian Drive
Bedford, MA 01730 Goleta, CA 93117
email: jagan@photonex.com email: jplang@calient.net
John Drake Gopala Tumuluri
Calient Networks Calient Networks
5853 Rue Ferrari 5853 Rue Ferrari
San Jose, CA 95138 San Jose, CA 95138
email: jdrake@calient.net email: krishna@calient.net
Rohit Goyal Stuart Brorson
Axiowave Networks Axiowave Networks
100 Nickerson Road 100 Nickerson Road
Marlborough, MA 01752 Marlborough, MA 01752
email: rgoyal@axiowave.com email: sdb@axiowave.com
Ram Krishnan W. L. Edwards
Axiowave Networks iLambda Networks
100 Nickerson Road Aspen, CO
Marlborough, MA 01752 email: texas@ilambda.com
email: ram@axiowave.com
Yong Xue John Yu
UUNET/WorldCom Zaffire, Inc
22001 Loudoun County Parkway 2630 Orchard Parkway
Ashburn, VA 20148 San Jose, CA 95134
email: yxue@uu.net email: jzyu@zaffire.com
Sudheer Dharanikota
Nayna Networks, Inc.
157 Topaz Drive,
Milpitas, CA 95035
email: sudheer@nayna.com
Fredette et. al. [Page 18]