Network Working Group T. Nadeau
INTERNET-DRAFT BT
Intended Status: Informational T. Otani
Created: October 22, 2007 KDDI R&D Labs
Expires: April 22, 2008 D. Brungard
at&t
A. Farrel
Old Dog Consulting
OAM Requirements for Generalized Multi-Protocol Label Switching
(GMPLS) Networks
draft-ietf-ccamp-gmpls-oam-requirements-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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
This document describes requirements for operations and management
(OAM) for Generalized Multi-Protocol Label Switching (GMPLS)
networks, as well as for applications of GMPLS.
T. Nadeau, et al. [Page 1]

draft-ietf-ccamp-gmpls-oam-requirements October 20071. Introduction
This document describes requirements for control plane operations and
management (OAM) for Generalized Multi-Protocol Label Switching
(GMPLS) networks. It also describes OAM requirements associated with
the interaction between the GMPLS Control Plane and Data Plane OAM.
The OAM requirements specified in this document apply to GMPLS
networks as well as to applications of GMPLS functions such as
dynamic bandwidth broker applications.
[RFC3945] describes how GMPLS extends Multi-Protocol Label Switching
(MPLS) to support a variety of data plane technologies. The
requirements set out in this document apply to all forms of GMPLS
LSPs.
Note that the requirements for OAM for GMPLS networks are built on
the foundation requirements for OAM for MPLS networks [RFC4377], as
well as the existing OAM techniques available in non-packet networks
that may be controlled by GMPLS. These existing requirements are not
repeated in this document except to illustrate new requirements.
2. Terminology2.1 Conventions Used in this Document
Although this is not a protocol specification, 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 [RFC2119] for clarity of
presentation of requirements.
2.2 Key Terms
Definitions of key terms for MPLS OAM and GMPLS are found in
[RFC3945] and [RFC4377], and the reader is assumed to be familiar
with those definitions which are not repeated here.
The reader may also find it helpful to be familiar with at least the
terminology sections of the SONET/SDH and OTN architectures [G.709]
and [G.784].
T. Nadeau, et al. [Page 3]

draft-ietf-ccamp-gmpls-oam-requirements October 20072.3 Acronyms
GMPLS: Generalized Multi-Protocol Label Switching
CE: Customer Edge
DoS: Denial of Service
ECMP: Equal Cost Multipath
LDP: Label Distribution Protocol
LSP: Label Switched Path
LSR: Label Switching Router
OAM: Operations and Management
OA&M: Operations, Administration and Maintenance.
RSVP: Resource reSerVation Protocol
SP: Service Provider
TE: Traffic Engineering
SONET: Synchronous Optical Network
SDH: Synchronous Digital Hierarchy
TDM: Time Division Multiplexing
3. Motivations
OAM for MPLS networks has been established as a fundamental
requirement both through operational experience and through its
documentation in numerous Requests For Comment. Early MPLS OAM
documents developed specific solutions to individual issues or to
problems encountered in MPLS deployments. Coordination of the full
OAM requirements for MPLS was achieved in [RFC4377] and [RFC3609] in
recognition of the fact that the previous piecemeal approach could
lead to inconsistent and inefficient applicability of OAM techniques
across the MPLS architecture, and might require significant
modifications to operational procedures and systems in order to
provide consistent and useful OAM functionality.
Similarly, operational requirements for OAM have been established for
SONET/SDH/TDM networks. However, no requirements documents exist for
GMPLS networks which provide a comprehensive set of OAM requirements
which take into consideration both the GMPLS control plane protocols
and the underlying data planes. Since GMPLS networks pose some unique
configurations and problems for OAM not covered by existing
requirements or solutions documents, this document sets out the
requirements that need to be satisfied to fill this gap.
T. Nadeau, et al. [Page 4]

draft-ietf-ccamp-gmpls-oam-requirements October 20074. General Requirements
The general requirements described in this section are inspired by
those described for point-to-point MPLS in [RFC4377], and where the
GMPLS network is a packet network it is expected that the solutions
will be identical or very similar. The subsections below do not
repeat material from [RFC4377], but simply give references to that
document.
However, where the requirements for GMPLS OAM differ from or are more
extensive than those expressed in [RFC4377], additional text is
supplied.
Moreover, these requirements should be commonly applied to not only a
single domain network but also an inter-domain network [RFC4726].
4.1 GMPLS Control Plane and Communications Channel
The GMPLS control plane SHOULD provide a health check function
between GMPLS control entities.
The control plane MUST provide a health check on the connectivity of
the control channel, and this SHOULD be configurable for both on-
demand operation and continual monitoring. This requirement applies
both to in-band and out-of-band control channel support.
If multiple control channels exist between two LSRs, the health check
SHOULD be supported for each control channel.
These functions MUST be independent of the underlying technology of
the control plane or data plane.
4.2 Interaction Between the Management and Control Planes4.2.1 Signaling
It MUST be possible to monitor and manage the information about an
LSP (including session name, attributes, source/destination pair, and
route) created by the GMPLS control plane. Such management SHOULD be
provided through MIB modules.
It SHOULD be possible to monitor and distinguish the LSPs traversing
any TE link in the network. In the event of any data plane event that
affects any TE link, it MUST be possible for the management plane to
correlate the data plane faults to the individual control plane LSPs.
The control plane MUST allow the management plane administrative
privileges, e.g., changing the operational status of an LSP for pre-
planned maintenance and recovery-related operations. To support a
pre-planned maintenance activity or during a control plane failure,
it SHOULD be possible for selected LSPs to be manually switched from
T. Nadeau, et al. [Page 5]

draft-ietf-ccamp-gmpls-oam-requirements October 2007
their primary route to their secondary route though the management
plane.
The management plane SHOULD have the ability to change the recovery
type of active LSPs (for example, from unprotected to 1+1 protected,
or from full LSP rerouting to pre-planned LSP rerouting) without
disrupting traffic on the LSPs.
It SHOULD also be possible for the management plane to change other
properties of LSPs without impacting data plane operations. These
properties include, but are not limited to:
- LSP recovery type
- recovery priorities
- reversion support
- TBD List to be completed
The management plane SHOULD provide a mechanism to force the switch-
over to a different route or to a rcovery LSP.
4.2.2 Routing
It MUST be possible to manage and monitor the GMPLS routing
information exchanged in the control plane and to manage and monitor
the process by which the informaiton is exchanged. Such management
SHOULD be provided through MIB modules.
Management SHOULD have access to at least the following GMPLS
properties of TE links:
- bandwidth
- switching type
- source/destination address pair
Mechanisms SHOULD be provided in the management plane to verify the
consistency of the connectivity information distributed by routing
mechanisms in the control plane with the physical connectivity in the
data plane.
4.2.3 Link Management
The management plane MUST be able to monitor and manage the status
of TE links, and status changes of TE links MUST be notified to the
management plane. This SHOULD be provided through MIB modules.
Link verification mechanisms using the data plane and the control
plane should be supported interactively without configuring each
plane independently.
T. Nadeau, et al. [Page 6]

draft-ietf-ccamp-gmpls-oam-requirements October 20074.3 Interaction Between the GMPLS Control Plane and Data Plane
The GMPLS control plane supports operational separation from the data
plane. Various applications (e.g., ASON Call support [RFC4974], and
GMPLS recovery mechanisms [RFC4872], [RFC4873]) require the control
plane to be aware of the data plane operational status. The
operational state of the data plane SHOULD be automatically reported
to the control plane. On the other hand, the operational state of the
GMPLS control plane MUST NOT impact the operaitonal state of the data
plane.
4.4 Detection of Label Switch Path Defects
GMPLS decouples the data plane and the control plane. If the route of
an LSP is traced in the control plane, the route information SHOULD
include information about the data plane resources utilized by the
LSP so that an operator can check the validity of the data plane by
examining the data plane state directly. Mechanisms MAY be provided
to automate this correlation functionality.
4.5 Diagnosis of a Broken Label Switch Path
LMP [RFC4204] and LMP-WDM [RFC4209] are defined for use in GMPLS
networks manage TE links. The functions provided include fault
detection and fault isolation. The management plane SHOULD be able
to access this informaiton to make correlations between broken data
links and the implied status of both the TE links that the data links
support and the LSPs that traverse the data links.
Additionally, LSPs may be used as data links to support TE links
[RFC4206]. In this case, the management plane SHOULD be able to
access LSP status information to make correlations between failed
LSPs and the TE links that the LSPs support.
4.6 Path Characterization
Path characterization function is the ability to indicate the detail
of created LSPs.
The control plane MUST provide mechanisms to gather path
characterization information. The informaiton collected by the
control plane MUST be accessible to the management plane, and this
access SHOULD be through a MIB module.
T. Nadeau, et al. [Page 7]

draft-ietf-ccamp-gmpls-oam-requirements October 20074.7 Service Level Agreement Measurement
Existing data planes already provide various mechanisms to measure
the level of service being provided. These mechanisms are technology-
specific and include bit interleaved parity (BIP)-8 in SONET/SDH
overhead, and error counts in forward error correction (FEC) function
on OTN interfaces. These mechanisms operate distinct from the control
plane.
Mechanisms MUST be provided in the management to control the use of
these mechanisms and to gather the recorded information. It MUST be
possible to correlate the infromation gathered to the LSPs and the
services that the LSPs support.
Mechanisms MAY be provided thrugh the control plane to control the
use of these mechanisms and to distribute the information recorded.
4.8 Frequency of OAM Execution
This requirement is the same as for the MPLS OAM requirements. See
[RFC4377] section 4.5.
4.9 Alarm Suppression, Aggregation, and Layer Coordination
Alarm suppression function is required for in order to support link
maintenance. The GMPLS control plane MUST provide the ability to
control whether data plane components on the path of an LSP do or do
not generate alarms in the case of data plane faults.
To avoid a stream of alarms, alarm aggregation may be implemented by
LSRs and this may be achieved by determining the main cause and by
prioritizing the alarms. This function MAY be managed through the
control plane for data plane components on the path of an LSP.
Considering multi-layer GMPLS networks, such as a TDM switch capable
network over a lambda switch capable network, the generated alarms
MAY be correlated between layers by using the linkage information
between control planes of different layers.
4.10 Support for OAM Interworking for Fault Notification
MPLS OAM and GMPLS OAM SHOULD be interwork to support the operation
of an MPLS-TE network over a GMPLS network [MPLS/GMPLS].
The operator SHOULD be able to control OAM function separately in
each network, but SHOULD be able to coordinate the OAM funciton. For
example, in the case of a data link failure in the GMPLS network, the
it SHOULD be possible to configure the GMPLS OAM to apply priorities
to the following actions:
T. Nadeau, et al. [Page 8]

draft-ietf-ccamp-gmpls-oam-requirements October 2007
- report the data link failure to the management plane of the GMPLS
network
- report the data link failure to the management plane of the MPLS
network
- trigger recovery operations within the GMPLS network
- trigger recovery operations within the MPLS network
4.11 Error Detection and Recovery
Error detection and recovery SHOULD be applicable not only to a
single domain network, but also an inter-domain network. Those
operations SHOULD be automated through the control plane and the data
plane.
4.12 Standard Management Interfaces
Common interfaces for the control and the management of the GMPLS
network are desired to facilitate wide deployment GMPLS networks.
Some GMPLS MIB modules have been standardized in [RFC4631],
[RFC4802], and [RFC4803] building on [RFC3811], [RFC3812], and
[RFC3813]. [RFC4220] provides a MIB module for managing and
monitoring TE links.
Since only those MIB modules do not cover all the OAM requirements
set out in this document, additional MIB modules SHOULD be developed
such as [TED-MIB].
4.13 Detection of Denial of Service Attacks
This requirement is the same as for the MPLS OAM requirements. See
[RFC4377] section 4.10.
4.14 Per-LSP Accounting Requirements
A GMPLS LSP may support MPLS LSPs hierarchically. By pointing out the
GMPLS LSP, those MPLS LSPs over it SHOULD be managed and accounted.
5. Security Considerations
This document introduces no new security issues beyond those detailed
in the MPLS OAM requirements. See [RFC4377] section 5.
6. IANA Considerations
This informational document makes no requests for IANA action.
T. Nadeau, et al. [Page 9]

draft-ietf-ccamp-gmpls-oam-requirements October 20079. Author's Address
Tomohiro Otani
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino
Saitama, 356-8502. Japan
Phone: +81-49-278-7357
Email: otani@kddilabs.jp
Thomas D. Nadeau
British Telecom
BT Centre
81 Newgate Street
EC1A 7AJ
London
Email: tom.nadeau@bt.com
Deborah Brungard (AT&T)
Rm. D1-3C22-200 S. Laurel Ave.
Middletown, NJ 07748, USA
Email: dbrungard@att.com
Adrian Farrel
Old Dog Consulting
Email: adrian@olddog.co.uk
10. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
T. Nadeau, et al. [Page 12]

draft-ietf-ccamp-gmpls-oam-requirements October 200711. Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
T. Nadeau, et al. [Page 13]