Network Working Group Andre Fredette (Editor)
Internet Draft
Expiration Date: August 2002 Osama Aboul-Magd (Nortel Networks)
Curtis Brownmiller (WorldCom)
Sudheer Dharanikota (Nayna Networks)
Naganand Doraswamy (PhotonEx Corp.)
John Drake (Calient Networks)
Georgios Ellinas (Tellium)
Rohit Goyal (Axiowave Networks)
Riad Hartani (Caspian Networks)
Bilel Jamoussi (Nortel Networks)
John Labourdette (Tellium)
Jonathan Lang (Calient Networks)
Eric Mannie (Ebone (GTS))
Babu Narayanan (Nortel Networks)
Dimitri Papadimitriou (Alcatel IPO-NSG)
Bala Rajagopalan (Tellium)
Rajiv Ramaswami (Nortel Networks)
Vasant Sahay (Nortel Networks)
Ed Snyder (PhotonEx Corp.)
Yong Xue (UUNET/WorldCom)
February 2002
TITLE: Optical Link Interface Requirements
draft-ietf-ccamp-oli-reqts-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 [RFC2026].
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.
[Page 1]
Internet Draft draft-ietf-ccamp-oli-reqts-00.txt February 2002
ABSTRACT
The emergence of transparent optical switches, together with a
movement towards more dynamic, multi-vendor networks, has introduced
a need for information sharing between optical line systems and
client devices. The information that needs to be shared includes
link status and link properties. We call this interface the Optical
Link Interface (OLI). In this document, we provide high-level
requirements for the OLI.
CONTENTS
ABSTRACT...........................................................2
CONTENTS...........................................................2
1. Introduction and Overview.......................................3
2. Fault Detection and Notification for PXCs.......................5
3. Discovery of Link Properties....................................5
4. Requirements for the Optical Link Interface.....................6
4.1. OLI General Principles........................................6
4.2. General OLI Characteristics...................................7
4.3. OLI Functionality.............................................7
4.3.1. Neighbor Discovery..........................................7
4.3.2. Control Channel Maintenance.................................8
4.3.3. OLI Synchronization.........................................8
4.3.4. Connectivity Discovery......................................8
4.3.5. Fault Management............................................8
4.3.5.1. Fault Notification........................................9
4.3.5.2. Trace Monitoring..........................................9
4.3.5.3. Alarm Suppression........................................10
4.3.6. Link Property Information..................................10
5. References.....................................................12
6. Author Contact Information.....................................13
[Page 2]
Internet Draft draft-ietf-ccamp-oli-reqts-00.txt February 2002
1. Introduction and Overview
Optical networks being deployed today consist of the following three
basic types of devices: service delivery platforms (e.g., routers,
ATM switches, and SONET/SDH devices), optical switches (OXCs), and
Optical Line Systems (OLSs), as shown in Figure 1.
+-OLI-+ +-OLI-+
| | | |
| +-------------------------+ |
+----+ |+----+ OLS +----+| +----+
SONET--| |--|| | +---+ +---+ | ||--| |--SONET
ATM--|OXC1|--||DWDM|=|Amp|=|Amp|=|DWDM||--|OXC2|--ATM
Routerûû| |--|| 1 | +---+ +---+ | 2 ||--| |--Router
| +----+ |+----+ +----+| +----+ |
| | | +-------------------------+ | | |
| | | | | |
+-LMP-+ +---------------LMP---------------+ +-LMP-+
Figure 1: Optical Network
Before continuing, a few definitions are provided to describe
salient information about the above network.
. Opaque Device:
A device that terminates a connection electrically. An opaque
device is sometimes called an O-E-O device because it receives
an optical signal, converts it to an electrical signal, then
regenerates a new optical signal. It is also usually must be
aware of the type of traffic and bandwidth being carried and
has a specific physical interface for that type of traffic and
bandwidth. An example is a SONET or SDH device.
. Transparent Optical Device:
A device that transmits/propagates an optical signal without
terminating it. These devices are sometimes referred to as O-
O-O devices, because they receive an optical signal, switch it
optically, then transmit the same optical signal without ever
converting it to an electrical signal. An example is a MEMS-
based photonic switch in which both the interfaces and
switching fabric are transparent. Transparent devices, in
theory, can operate independent of traffic type and bandwidth.
. Optical Cross Connect (OXC):
A cross connect that switches optical connections. The term
OXC is used as a generic term that may apply to both opaque and
transparent devices. Whenever the material applies to both
opaque and transparent devices, we use the term OXC, as opposed
to the more specific PXC term defined below.
[Page 3]
Internet Draft draft-ietf-ccamp-oli-reqts-00.txt February 2002
. Photonic Cross Connect (PXC):
A transparent OXC. An example is a MEMS-based photonic switch
in which both the interfaces and switching fabric are
transparent. Whenever the material in this document applies
specifically to transparent devices, we used the term PXC, as
opposed to the more generic term OXC defined above.
. Optical Line System (OLS):
An optical line system is used to transmit data over long
distances. There are various classes including long-haul,
ultra-long haul, metro, however, we do not differentiate
between the classes in this document. Most OLSs being deployed
today use wave division multiplexing (WDM), or dense division
multiplexing (DWDM) techniques to multiplex many channels over
a single pair of fibers. Therefore, the OLS is also commonly
referred to as a DWDM transmission system. An OLS typically
contains multiple types of nodes including DWDM and Optical
Amplifier (OA) nodes. Although an OLS contains multiple nodes,
they work as a single system, and for the purposes of this
document, we treat the OLS as a single system. Note that an
OLS may be either opaque or transparent, however, in this
document we only address opaque OLSs.
. OLS Client:
Any device that attaches to an OLS for the purpose of using its
data transmission services. An OLS client may be either opaque
or transparent. In Figure 1, the OXC is shown as an OLS client
with the service delivery platforms connected to the OXC;
however, the service delivery platforms may also be direct OLS
clients. Whenever the material in this document applies to any
OLS client, we use this most general term.
. Link:
The term link refers to a circuit or logical connection between
two peer OLS clients. The OLS transmits the data on a link
between the two peer OLS clients. A link may be uni-
directional or bi-directional.
. Port:
Place where an OLS client attaches to an OLS. A link requires
that both OLS clients are attached to corresponding ports on
the OLS.
This work is motivated by two main issues. The first is the need to
enhance the fault detection and recovery support for PXCs, and the
second is to enhance the discovery of link characteristics for
optical networks in general. These issues are discussed separately
below. We then provide more specific requirements for an interface
between the OLS and OLS client proposed to solve these issues called
the Optical Link Interface (OLI).
[Page 4]
Internet Draft draft-ietf-ccamp-oli-reqts-00.txt February 2002
DISCLAIMER: The name ôOLIö, introduced in [OIF2000.254], has been
chosen due to the lack of a better name at this time. Not all of
the co-authors agree on the name OLI.
2. Fault Detection and Notification for PXCs
Standard SONET/SDH equipment provides extensive fault detection,
reporting and handling capabilities. These SONET/SDH standards can
be employed by opaque devices using SONET/SDH overhead messaging;
however, as networks transition to the use of more transparent
optical networking devices, such as PXCs, access to the SONET/SDH
overhead may not exist in every node. Once a connection is
established, PXCs have only limited visibility into the health of
the connection. Even though the PXC is all-optical, an opaque OLS
terminates channels electrically and regenerate them optically,
which presents an opportunity to monitor the health of a channel
between PXCs. The elements of an OLS also typically communicate
over an internal control channel. This can provide a system wide
view of OLS client-to-client link health. In a sense, the OLI
allows the OLSs to become the ôeyes and the earsö of the PXC.
The typical OLS located between a pair of PXCs monitors for
degradation and faults along the entire fiber path. Expensive
electronic circuitry monitors such degradations at the SONET/SDH and
wavelength level at various points along the fiber path. Repeaters
and Amplifiers detect fiber cuts and pass along the information to
other equipment along the path. SONET/SDH-level failures can be
detected as well. To use the SONET/SDH-level fault reporting
methods, all devices require the expensive electronic circuitry. A
PXC can avoid the use of SONET/SDH circuitry to provide a more cost
effective solution. In this perspective, an OLI between the OLS and
PXC can provide the same fault information to a non-SONET/SDH
client, while reducing the cost of that client, and, therefore
overall network cost.
3. Discovery of Link Properties
The establishment of connections in an optical network may be
accomplished either through a centralized management system or a
distributed control system, such as GMPLS.
A great deal of information about a link between two clients is
known by the OLS. Exposing this information to the control plane
can improve network usability by further reducing required manual
configuration and also greatly enhancing fault detection and
recovery.
[Page 5]
Internet Draft draft-ietf-ccamp-oli-reqts-00.txt February 2002
The configuration and management of todayÆs transport networks are
largely driven by significant human intervention, which increases
the time to turn up revenue generating services and is prone to
errors and inefficiencies. Even where management systems provide
automation for some provisioning and management tasks, the
management systems are still largely proprietary and cumbersome.
Furthermore, optical networks are more commonly being deployed with
equipment from multiple vendors which further burdens the user with
multiple management systems. A standard interface between the OLS
and its clients can simplify the users job by allowing some
provisioning functions to be accomplished by just the client
management application.
The Generalized Multi-protocol Label Switching (GMPLS) body of work
[GMPLS-ARCH] is being specified in the IETF to provide a standard
automated and distributed IP control plane for optical networks.
The use of GMPLS will enable the dynamic provisioning of resources
and provide network survivability using protection and restoration
techniques. The main intent of GMPLS is to make optical networks
more manageable, scalable and efficient, while maintaining or
improving on their current high availability characteristics. GMPLS
protocols define standard control interfaces between service
delivery platforms and OXCs to exchange routing [GMPLS-OSPF, GMPLS-
ISIS] and signaling [GMPLS-SIG, GMPLS-RSVP, GMPLS-LDP] information,
and perform link management functions [LMP]. An interface with the
OLS can allow GMPLS devices to automatically learn information about
the links, and therefore, will reduce required manual configuration.
4. Requirements for the Optical Link Interface
In this section we define more specific requirements for an Optical
Link Interface (OLI) between the OLS and its clients. As described
above, the OLI is required to provide fast failure detection and
notification for PXCs, as well as to provide much-needed information
for the operation of both centralized and GMPLS-controlled optical
networks.
4.1. OLI General Principles
. In optical networks there will be a management plane and a
control plane. The fundamental purpose of the control plane is
to accurately and rapidly create, maintain, and delete
connections within the optical network; while the purpose of
the management plane is to provide operators with capabilities
such as root cause analysis, service definition, and SLA
verification. The OLI is targeted at the information that is
required for the control plane to accomplish its task.
[Page 6]
Internet Draft draft-ietf-ccamp-oli-reqts-00.txt February 2002
. The OLI should be a simple protocol mechanism for reporting the
health and properties of OLSs based on a well-defined set of
parameters.
. The OLI-defined parameters should be accessible via query by
both the control and the management plane of the network
regardless of the architecture used (i.e., distributed or
centralized).
. The OLI should be extensible so that we can start with a set of
most-needed parameters initially, and be able to extend later
by adding new parameter types and new parameters within a type.
In particular, the initial focus is on opaque OLSs. However,
the OLS should be extensible for use with all optical networks
containing PXCs and transparent OLSs.
. The initial focus of the OLI is on SONET and SDH equipment.
However, the OLI must be extensible to support other types of
equipment such as Ethernet and G.709.
. All the intelligence such as data collection, analysis,
triggering, routing decisions, etc. should reside in the
network control and management plane functions. What and how
the OLI-parameters are used is totally up to the control and
management plane design. In effect, this will allow OLI to be
decoupled from any particular control plane protocol such as
GMPLS.
. In general, care must be taken to make the OLI implementable on
existing OLS hardware, while still being flexible enough to
allow enhanced operations with future generations of OLS
hardware. This desire may make it necessary to specify some
optional OLI features.
4.2. General OLI Characteristics
. The OLI must be reliable.
. The OLI must provide security measures.
. The OLI must not assume a one-to-one relationship between OLS
and client. I.e., an OLS client will most likely be attached
to multiple different OLSs, and a single OLS may have multiple
different clients at a single location.
4.3. OLI Functionality
4.3.1. Neighbor Discovery
[Page 7]
Internet Draft draft-ietf-ccamp-oli-reqts-00.txt February 2002
. It should be possible for adjacent nodes to use the OLI with as
little configuration as possible.
. The OLI should support discovery and negotiation of optional
features.
4.3.2. Control Channel Maintenance
. The OLI must support the use of out-of-band communications for
all messages (except for the specific in-band signals for
connectivity discovery described in Section 4.3.4).
. The OLI must provide a mechanism to maintain the OLI
session/control channel between neighboring nodes. For
example, a simple hello or keep-alive protocol could be used.
If a session fails it should be reestablished and the
information should be resynchronized as described in Section
4.3.3.
4.3.3. OLI Synchronization
. The OLI must specify a process for the OLS and OLS client to
resynchronize if the session is disrupted for any reason (such
as a reboot or temporary loss of control channel connectivity).
. The resynchronization process should be defined such that the
OLS does not need to remember the instructions issued by the
OLS client. The client should re-issue the
instructions/commands to OLS during the resynchronization.
4.3.4. Connectivity Discovery
. The OLI must provide a protocol including in-band signals for
auto discovery of optical connectivity.
. The OLI must support control over link transparency.
Link transparency control is used by OLS clients to control whether
the OLS terminates the in-band messages, or allows them to pass
through so that the OLS client can discover its peer at a higher
layer.
4.3.5. Fault Management
. Fault reporting must be both event-driven and available on
request (e.g., polling).
. The defect notification must be fast enough to support switch
times in the range of a few 10Æs of milliseconds.
[Page 8]
Internet Draft draft-ietf-ccamp-oli-reqts-00.txt February 2002
Note: The OLS does not participate in end-to-end fault isolation.
It is the role of the control plane to determine whether switching
is done on the section or path level and to make the protection
switching decisions.
. The OLI should support the aggregation of fault reporting. For
example, the failure of a single fiber could cause the failure
of 100Æs to 1000Æs of ports simultaneously. If possible, it
would be better to send a single message to report all
failures.
4.3.5.1. Fault Notification
At a minimum, the following fault granularity must be provided:
. Signal Okay (OK): Port is operational.
. Signal Fail (SF): A hard signal failure including (but not
limited to) loss of signal (LOS), loss of frame (LOF), Line
AIS, or a BER (BIP-8 measure through B1/B2) exceeding a
specified value.
. Signal Degrade (SD): A soft failure caused by a BER exceeding a
preselected threshold. The specific BER used to define the
threshold is may be configured, but is typically in the range
of 10-5 to 10-9.
. It should be possible to negotiate a line behavior for the
above failures. For example, it may be more advantageous to a
PXC for the OLS to turn off its laser than to insert AIS-L when
a failure is detected.
. It is expected that the thresholds necessary (e.g., BER) for
detecting the above failures are provisioned at the OLS. It
may also be useful to support the negotiation of some of these
thresholds.
4.3.5.2. Trace Monitoring
Trace monitoring is an important feature, especially for PXCs. The
trace monitoring features described in this section, allow the PXC
to do basic trace monitoring on circuits by using the capabilities
on the attached OLSs
. It must be possible for an OLS Client to request the OLS to
monitor a link for a specific pattern in the overhead. An
[Page 9]
Internet Draft draft-ietf-ccamp-oli-reqts-00.txt February 2002
example of this overhead is the SONET Section Trace message
transmitted in the J0 byte. If the actual trace message does
not match the expected trace message, the OLS must report the
mismatch condition.
. It must be possible for an OLS client to request the value of
the current trace message on a given port.
. It should be possible for an OLS client to request the OLS to
insert a trace message. It is optional for an OLS to provide
this service.
4.3.5.3. Alarm Suppression
. It must be possible to enable a port in an unequipped state on
an OLS, but suppress alarms. This allows the OXC to have a
port/wavelength ready, but not necessarily operational.
4.3.6. Link Property Information
The link property advertisement provides information known to
transport systems that would otherwise need to be configured at the
OLS client. Link properties, in general, constitute the information
needed by the control plane for constraint-based routing and
connection establishment. Additionally, the information advertised
in the Link Property advertisement is intended to be more-or-less
static, as opposed to the more dynamic information available in the
Performance Information Advertisement described in the next section.
The OLI should provide a mechanism for advertising the following
information:
. Link Descriptor
. Signal Type: The overhead termination type (e.g., STM-16 or
OC-48).
. Bandwidth Encoding: Bandwidth supported on the link.
. Shared Risk Link Group Identifier (SRLG): SRLGs to which the
link is a member. This information may be manually configured
on the OLS by the service providers. It may also be derived
based on information known to the OLS (e.g., all circuits
sharing a single fiber). The SRLG can be used for diverse path
computation. See [GMPLS-OSPF] or [GMPLS-ISIS] for more details
on SRLGs.
[Page 10]
Internet Draft draft-ietf-ccamp-oli-reqts-00.txt February 2002
. Span Length: Distance of fiber in the OLS. May be used as a
routing metric or to estimate delay. This value may either be
estimated by the OLS, or provisioned at the OLS.
. Administrative Group (Color).
[Page 11]
Internet Draft draft-ietf-ccamp-oli-reqts-00.txt February 2002
5. References
[GMPLS-ARCH] E. Mannie, Editor, ôGeneralized Multi-Protocol Label
Switching (GMPLS) Architectureö, Internet Draft,
draft-many-gmpls-architecture-00.txt, (work in
progress), February 2001.
[GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A., Drake, J.,
Bernstein, G., Fedyk, D., Mannie, E., Saha, D., and
Sharma, V., ôIS-IS Extensions in Support of
Generalized MPLSö, Internet Draft, draft-ietf-isis-
gmpls-extensions-02.txt, (work in progress), February
2001.
[GMPLS-LDP] Ashwood-Smith, P. et al, ôGeneralized MPLS Signaling -
CR-LDP Extensionsö, Internet Draft, draft-ietf-mpls-
generalized-cr-ldp-01.txt, (work in progress),
February 2001.
[GMPLS-OSPF] Kompella, K., et. al, ôOSPF Extensions in Support of
Generalized MPLSö, Internet Draft, draft-kompella-
ospf-gmpls-extensions-01.txt, (work in progress),
February 2001.
[GMPLS-SIG] 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.
[LMP] Lang, J., et. al, ôLink Management Protocol (LMP)ö,
Internet Draft, draft-ietf-mpls-lmp-02.txt, (work in
progress), March 2001.
[LMP-WDM] A. Fredette, et al., ôLink Management Protocol (LMP)
for WDM Transmission Systems,ö Internet Draft, draft-
fredette-lmp-wdm-01.txt, (work in progress), March
2001.
[NTIP] V. Sahay et al., ôNetwork Transport Interface Protocol
(NTIP) for Photonic Cross Connects (PXC),ö Internet
Draft, draft-sahay-ccamp-ntip-00.txt, (work in
progress), February 2001.
[OIF2000.254] 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.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3," BCP 9, RFC 2026, October 1996.
[Page 12]
Internet Draft draft-ietf-ccamp-oli-reqts-00.txt February 2002
6. Author Contact Information
Osama Aboul-Magd John Labourdette
Nortel Networks Tellium
osama@nortelnetworks.com jlabourdette@tellium.com
Curtis Brownmiller Jonathan Lang
WorldCom Calient Networks
Curtis.Brownmiller@wcom.com jplang@calient.net
Sudheer Dharanikota Eric Mannie
Nayna Networks Ebone (GTS)
sudheer@nayna.com Eric.Mannie@ebone.com
John Drake Babu Narayanan
Calient Networks Nortel Networks
jdrake@calient.net bon@nortelnetworks.com
Naganand Doraswamy Dimitri Papadimitriou
PhotonEx Corp. Alcatel IPO-NSG
naganand@photonex.com dimitri.papadimitriou@alcatel.be
Georgios Ellinas Bala Rajagopalan
Tellium Tellium
gellinas@tellium.com BRaja@tellium.com
Andre Fredette Rajiv Ramaswami
PhotonEx Corp. Nortel Networks
fredette@photonex.com rajiv@nortelnetworks.com
Rohit Goyal Vasant Sahay
Axiowave Networks Nortel Networks
rgoyal@axiowave.com vasants@nortelnetworks.com
Riad Hartani Ed Snyder
Caspian Networks PhotonEx Corp.
rhartani@caspiannetworks.com esnyder@photonex.com
Bilel Jamoussi Yong Xue
Nortel Networks UUNET/WorldCom
jamoussi@nortelnetworks.com yxue@UU.NET
[Page 13]
