One document matched: draft-fredette-lmp-wdm-00.txt
Network Working Group A. Fredette, E. Snyder, J. Shantigram
Internet Draft (PhotonEx Corp)
Expiration Date: June 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)
December 2000
Link Management Protocol (LMP) for WDM Transmission Systems
draft-fredette-lmp-wdm-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 [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
crossconnects (OXCs), routers, switches, DWDM transmission systems,
Fredette et. al. [Page 1]
Internet Draft draft-fredette-lmp-wdm-00.txt December 2000
and optical add-drop multiplexors (OADMs) to use an MPLS control
plane to dynamically provision resources and to provide network
survivability using protection and restoration techniques. As part
of this suite, the Link Management Protocol (LMP) [LMD00] 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, [LMD00] focuses on OXC-to-OXC
communications. 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 MPLS 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. [LMD00]
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, [LMD00] focuses on OXC-to-OXC communications 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 [LMD00].
+------+ +------+ +------+ +------+
| | ----- | | | | ----- | |
| 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 enhance
fault detection and recovery. Fault detection is particularly an
issue when the network is using all-optical photonic switches or
photonic crossconnects (PXCs). 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
Fredette et. al. [Page 2]
Internet Draft draft-fredette-lmp-wdm-00.txt December 2000
systems typically terminate channels electrically, then regenerates
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 establishes LMP sessions with neighboring
transmission systems as well as with its neighboring OXCs. The
OXC-OXC LMP sessions are managed essentially the same as described
in [LMD00]. Although there are many similarities between OXC-OXC
LMP and OXC-WDM LMP, 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. The OXC-OXC links
provide the basis for routing circuits at the optical layer. The
information exchanged over LMP sessions between an OXC and WDM
transmission system is used to augment knowledge about the links
between OXCs.
The organization of link bundles must be the same for the OXC-OXC
LMP session as well as for the OXC-WDM LMP sessions. Note that a
side-effect of this requirement is that a link bundle can span at
most one WDM system if LMP is being used. In order for the
information exchanged over the OXC-WDM LMP sessions to be used by
the OXC-OXC session and vice-versa, a relationship must be
maintained between the sessions. For a given OXC-OXC LMP session,
there are one or more related (child) OXC-WDM LMP sessions (at least
one per WDM transmission system connecting the OXCs). The LMP
session on the OXC is responsible for maintaining the relationship
between the parent session and its children. It may be possible for
the OXC to use the same CCid for OXC-OXC communications as well as
OXC-WDM communications, but this needs some further thought. The
OXC must also provide a session ID for the parent LMP session to the
WDM system so that it can be knowledgeable about this relationship.
Fredette et. al. [Page 3]
Internet Draft draft-fredette-lmp-wdm-00.txt December 2000
The session ID can be created by concatenating the CCids from the
two OXCs.
It should be possible for the LMP sessions to come up in any order
and synchronize as new sessions come up. In particular, it should
be possible for the OXC-OXC session to come up without a WDM session
as LMP is defined today. In case of control channel failure, one or
both of the control channels may fail, and the failures may be
unrelated to each other. In case of component link failure, failure
of OXC-WDM link should imply failure of OXC-OXC link, and vice versa.
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
Extended LMP has these same basic functional categories with the
addition of performance summarization/notification as follows:
1. Control Channel Management
2. Link Verification
3. Link Summarization
4. Performance Summarization
5. Fault Localization
The first two functions, control channel management and link
verification, are concerned with OXC-WDM links, and are nearly the
same as those for OXC-OXC links.
It is very important to understand the subtle distinctions between
the different types of links being considered in the extended LMP.
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 these "component links" (or a bundle thereof) that
are advertised in the routing protocols and used for the purposes of
connection setup. The verify 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 component links. The verify serves two functions. The
first is to verify connectivity. The second is to agree upon
handles by which to refer to each component link (the LinkID). So,
although the OXC-WDM verify only runs over the shorter link, the
LinkID is used to refer to the larger end-to-end component link. In
Fredette et. al. [Page 4]
Internet Draft draft-fredette-lmp-wdm-00.txt December 2000
particular, the WDM system uses the LinkID to report on the
end-to-end component link in Link Summarization, Performance
Summarization, and Fault Localization.
Once a control channel has been established and its associated
WDM-OXC links are verified, the OXC and WDM transmission system may
exchange information regarding link configuration and/or performance
characteristics (link/performance summarization). An OXC may also
receive notifications from a WDM transmission system
(performance/fault notification). It is noted again that these
functions are concerned with the associated OXC-OXC links, not the
OXC-WDM links themselves.
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 [LMD00]. It may be useful to include
a "node type" or "protocol sub-type" identifier in the initial
HelloConfig messages so that an OXC may differentiate between
another OXC and a WDM transmission system.
2.2. Link Verification
The basic test procedure used with WDM transmission systems is the
same as described in [LMD00]. The VerifyTransportMechanism and
possibly the VerifyID parameters are added to the protocol as
described below.
[LMD00] requires that "a free (unallocated) component link must be
opaque (i.e., able to be terminated)". While this requirement may
be reasonable for cross-connects, it is not practical for most
transmission systems. When used with SONET or SDH access equipment,
the Section Trace (J0) overhead is used for the purpose of link
verification. For both SONET and SDH, the section trace message
consists of a string of 7-bit characters (i.e., ASCII) terminated by
a frame delimiter. SONET uses a 64 octet string (62 octets of data
with a CR-LF frame delimiter) [SONET], while SDH uses a 16 octet
string (15 octets of data with a CRC-7 frame delimiter) [SDH]. It
is proposed that 15 octets or fewer be used for the Test message so
that the same basic format is used for both SONET and SDH links.
A VerifyTransportMechanism is added to the BeginVerify and
BeginVerifyAck messages. The purpose for this new parameter is to
allow nodes to negotiate a link verification method. In particular,
it allows a transmission system to tell an OXC to use the section
trace overhead instead of a terminated link. Additional
VerifyTransportMechanism types may be added for new types of
Fredette et. al. [Page 5]
Internet Draft draft-fredette-lmp-wdm-00.txt December 2000
connections in the future, if necessary. The verifying node
includes the VerifyTransportMechanism parameter in the BeginVerify
message to indicate all supported methods (e.g., link termination,
SONET Section Trace, or SDH Section Trace).
In the verify protocol of the current LMP, information including the
CCid is included in the the test message that allows the node being
verified to uniquely identify the source of each test message. It
needs to be determined whether this information can be encoded in
the limited payload space available in the SDH section trace message
(15 7-bit characters).
An alternate solution may be for the remote node provides a VerifyID
to the local node in the BeginVerifyAck Message. The Test message
can then be created by concatenating the VerifyID and the LinkID.
The VerifyID allows a node to differentiate test messages from
different LMP peers in the absence of the CCid.
2.3. Link Summarization
The LinkSummary message is extended to advertise link
characteristics. The specific link characteristics to be advertised
is still TBD; however, they should, in general, be 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
below.
For the purpose of discussion, the following characteristics are
listed as potential candidates. In general these characteristics
are advertised on a per component link basis. However, it may also
be useful to advertise per fiber, per bundle, or per component link.
Also some make sense for the case of transparent all-optical
wavelength routing and some make sense for opaque channels that are
terminated electrically at the transmission system.
Potential Link Characteristics:
1. Wavelength Channel Count:
Number of independent wavelengths Carried
2. Total wavelengths carried (Information is carried on a
per-channel basis.):
Table of all wavelengths which can be supported. For each
wavelength, information should include:
Fredette et. al. [Page 6]
Internet Draft draft-fredette-lmp-wdm-00.txt December 2000
- Allocated or Free
- Port
- Section trace or ID (J0)
- Timing source/quality (S1)
- Wavelength
- Wavelength Band (C- L- or S-Band)
- Bit rate. For multiple rate cards list all possible bit
rates. For transparent optical card, list "transparent"
- Protocol/framing (SONET, 10GigE, OCh)
- FEC if any
- BER estimate (quality of the link)
- Drop side interface type.
- Laser output power on drop side.
- Laser output power on line side.
- Receiver sensitivity (dynamic range) on drop side.
- Receiver sensitivity on line side.
- Availability of protection, i.e. Is SONET APS possible on
this wavelength? Protection type and QoS (e.g. None, SONET
1+1, SONET 1:1, Optical layer switching, pre-emptable
lightpath, etc.)
3. Transparent optical span length:
Distance of fiber between Tx and Rx. Used to make estimates of
attenuation and dispersion until next regen. Note that this
parameter applies to all wavelengths.
4. Span Loss:
Span loss between Tx and Rx in dB Tx power, span attenuation,
and Rx sensitivity is used in constraint-based routing on
physical layer. Note that this parameter applies to all
wavelengths.
5. Fiber Type:
Type of the fiber used in the span (DCF or not etc.) Fiber type
and span length is used to estimate dispersion penalty. Note
that this parameter applies to all wavelengths.
6. Fiber characteristics:
PMD, Dispersion, Loss etc. Theoretically used to estimate
penalty for constraint-based routing. It is possible that the
service providers have no accurate data for this field.
7. Optical amplifier data for link/span:
Type and number of amplifiers Used to estimate OSNR over link.
Fredette et. al. [Page 7]
Internet Draft draft-fredette-lmp-wdm-00.txt December 2000
8. Performance Monitoring Capability:
Whether OPM is used and if so, what is monitored and can the
information be shared with other network elements.
9. OEO Regenerator Data for link/span
Number and type of regenerators present in the link/span Used to
estimate optical quality of link.
10. Regen and Amp Spacing/Locations
How far apart are the Regens and Amps
11. Signaling Format:
RZ, NRZ
12. Shared Risk Link Group Identifier:
What shared risk link groups exist (manually configured on the
DWDM systems by the service providers) Used for diverse path
computation.
13. Channel Spacing,
14. Spectral Bandwidth of Each Channel
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. PM information is different from link
characteristics in that it is more dynamic in nature.
PM information should be advertised for one of several 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. (E.g., exceeding an uncorrected BER
threshold even though the corrected BER is adequate.)
- To quickly detect a failed link.
This information can be used to allow the system to reroute
connections proactively to avert potential failures, and so that
problems can be diagnosed.
As in the case of link characteristics, specific items still require
further investigation. Some of the performance measures under
Fredette et. al. [Page 8]
Internet Draft draft-fredette-lmp-wdm-00.txt December 2000
consideration for Optical Performance Monitoring are listed below:
1. Dispersion (chromatic and polarization mode):
The distortion or spreading of bits due to variations in
propagation velocity of different wavelengths and polarization
modes in the fiber and other network elements.
2. Optical signal-to-noise ratio (OSNR):
The ratio of optical power in a primary data channel to the
power in optical background noise accumulated during
transmission and switching. This ratio is usually specified
within some optical bandwidth of a receiver filter. The OSNR of
a channel at the destination receiver will set the limit of the
final detected SNR.
3. Bit-rate:
The data rate of the channel in a transparent system will be
necessary to make decisions on other performance metrics.
4. Q-Factor:
A measure of the signal-to-noise ratio (SNR) assuming Gaussian
noise statistics.
5. Wavelength registration:
The determination of which wavelengths are present on a given
fiber.
6. Wavelength selective component drift:
The drift of a laser, filter, mux or other wavelength selective
component relative to the ITU grid.
7. Optical cross talk:
Two types of cross talk are of interest, in-band and
out-of-band. In-band cross talk is seen as at the same
wavelength as the primary channel and appears as cross talk in
the electronic domain. Out-of-band cross talk appears as a
different wavelength in the presence of the primary wavelength
and appears as cross talk in the optical domain.
8. Optical power transients:
Changes in the optical powers that are not due to normal bit
Fredette et. al. [Page 9]
Internet Draft draft-fredette-lmp-wdm-00.txt December 2000
transitions. May be due to optical amplifier gain transients or
other transient non-linearity in the system.
9. Bit-error-rate:
In a SONET environment BER can be directly measured on the
channel using means to look at bits within the data stream.
However, in a purely photonic network there will typically not
be access to the data streams carried over the channel. However,
by interpreting the other optical parameters, the system should
be able to estimate the BER with relatively good accuracy, as
well as guarantee bit error rate performance to the users of the
channel.
10. Jitter:
Random fluctuations in the location of rising and falling edges
of bits relative to a local or recovered clock reference. As
line speeds continue to increase, jitter will become a critical
performance parameter.
11. Insertion loss:
Indicates the input to output loss of a network element. When
examining excessive power loss along the path of a channel the
ability to measure insertion loss of individual network elements
is very useful, specifically when compared against an archival
database.
12. Optical power level
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.
The following parameters should be reported on a per-component link
basis:
1. BER
Collected via B1 error count
Fredette et. al. [Page 10]
Internet Draft draft-fredette-lmp-wdm-00.txt December 2000
2. SES
Severely errored seconds. Collected via B1 error count. Used to
collect statistics on burst errors.
3. Protection switch counts
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.
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.
2.5. Fault Localization
Fault localization consists of three major functions:
1. Fault Detection
2. Fault Notification
3. Fault Localization
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 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 [LMD00].
Fredette et. al. [Page 11]
Internet Draft draft-fredette-lmp-wdm-00.txt December 2000
4. References
[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.
[LMD00] Lang, J., Mitra, K., Drake, J., Kompella, K., Rekhter,
Y., Berger, L., Saha, D., Basak, D., Sandick, H., "Link
Management Protocol (LMP)", Internet Draft,
draft-ietf-mpls-lmp-00.txt, (work in progress), September
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 12]
Internet Draft draft-fredette-lmp-wdm-00.txt December 2000
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
Fredette et. al. [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 01:57:38 |