Network Working Group A. Fredette, Ed.
Request for Comments: 4209 Hatteras Networks
Category: Standards Track J. Lang, Ed.
Sonos Inc.
October 2005
Link Management Protocol (LMP) for
Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Link Management Protocol (LMP) is defined to manage traffic
engineering (TE) links. In its present form, LMP focuses on peer
nodes, i.e., nodes that peer in signaling and/or routing. This
document proposes extensions to LMP to allow it to be used between a
peer node and an adjacent optical line system (OLS). These
extensions are intended to satisfy the "Optical Link Interface
Requirements" described in a companion document.
1. Introduction
Networks are being developed with routers, switches, optical cross-
connects (OXCs), dense wavelength division multiplexing (DWDM)
optical line systems (OLSes), and add-drop multiplexors (ADMs) that
use a common control plane (e.g., Generalized MPLS (GMPLS)) to
dynamically provision resources and to provide network survivability
using protection and restoration techniques.
The Link Management Protocol (LMP) is being developed as part of the
GMPLS protocol suite to manage traffic engineering (TE) links
[RFC4204]. In its present form, LMP focuses on peer nodes, i.e.,
nodes that peer in signaling and/or routing (e.g., OXC-to-OXC, as
illustrated in Figure 1). In this document, extensions to LMP are
proposed to allow it to be used between a peer node and an adjacent
optical line system (OLS). These extensions are intended to satisfy
Fredette & Lang Standards Track [Page 1]RFC 4209 LMP for DWDM Optical Line Systems October 2005
the "Optical Link Interface Requirements" described in [OLI]. It is
assumed that the reader is familiar with LMP, as defined in
[RFC4204].
+------+ +------+ +------+ +------+
| | ----- | | | | ----- | |
| OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
| | ----- | | | | ----- | |
+------+ +------+ +------+ +------+
^ ^
| |
+---------------------LMP---------------------+
Figure 1: LMP Model
Consider two peer nodes (e.g., two OXCs) interconnected by a
wavelength-multiplexed link, i.e., a DWDM optical link (see Figure 1
above). Information about the configuration of this link and its
current state is known by the two OLSes (OLS1 and OLS2). Allowing
them to communicate this information to the corresponding peer nodes
(OXC1 and OXC2) via LMP can improve network usability by reducing
required manual configuration and by enhancing fault detection and
recovery.
Information about the state of LSPs using the DWDM optical link is
known by the peer nodes (OXC1 and OXC2), and allowing them to
communicate this information to the corresponding OLSes (OLS1 and
OLS2) is useful for alarm management and link monitoring. Alarm
management is important because the administrative state of an LSP,
known to the peer nodes (e.g., via the Admin Status object of GMPLS
signaling [RFC3471]), can be used to suppress spurious alarm
reporting from the OLSes.
The model for extending LMP to OLSes is shown in Figure 2.
+------+ +------+ +------+ +------+
| | ----- | | | | ----- | |
| OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
| | ----- | | | | ----- | |
+------+ +------+ +------+ +------+
^ ^ ^ ^ ^ ^
| | | | | |
| +-----LMP-----+ +-----LMP-----+ |
| |
+----------------------LMP-----------------------+
datatracker.ietf.org