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 2007
Table of Contents
1. Introduction .................................................. 3
2. Terminology ................................................... 3
2.1 Conventions Used in this Document ............................ 3
2.2 Key Terms .................................................... 3
2.3 Acronyms ..................................................... 3
3. Motivations ................................................... 4
4. General Requirements .......................................... 4
4.1 GMPLS Control Plane and Communications Channel ............... 7
4.2 Interaction Between the Management and Control Planes ........ 7
4.2.1 Signaling .................................................. 7
4.2.2 Routing .................................................... 7
4.2.3 Link Management ............................................ 9
4.3 Interaction Between the GMPLS Control Plane and Data Plane ... 9
4.4 Detection of Label Switch Path Defects ....................... 9
4.5 Diagnosis of a Broken Label Switch Path ..................... 10
4.6 Path Characterization .......................................
4.7 Service Level Agreement Measurement .........................
4.8 Frequency of OAM Execution ..................................
4.9 Alarm Suppression, Aggregation, and Layer Coordination ......
4.10 Support for OAM Interworking for Fault Notification ........
4.11 Error Detection and Recovery ...............................
4.12 Standard Management Interfaces .............................
4.13 Detection of Denial of Service Attacks ....................
4.14 Per-LSP Accounting Requirements ............................
5. Security Consideration .......................................
6. IANA Considerations ..........................................
7. References ...................................................
7.1 Normative References ........................................
7.2 Informative References ......................................
8. Acknowledgments ..............................................
9. Author's Address .............................................
10. Intellectual Property Statement .............................
11. Copyright Statement .........................................
T. Nadeau, et al. [Page 2]
draft-ietf-ccamp-gmpls-oam-requirements October 2007
1. 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. Terminology
2.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 2007
2.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 2007
4. 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 Planes
4.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 2007
4.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 2007
4.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 2007
7. References
7.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3945] E. Mannie, "Generalized Multi-Protocol Label
Switching Architecture", RFC 3945, October, 2004.
[RFC4377] T. Nadeau, et al., "OAM Requirements for MPLS
Network" RFC 4377, February 2006.
7.2 Informative References
[RFC3609] Bonica, R., Kompella, K., and Meyer, D., "Tracing
Requirements for Generic Tunnels", RFC 3609, September
2003.
[RFC3811] Nadeau, T., and Cucchiara, J., "Definitions of Textual
Conventions (TCs) for Multiprotocol Label Switching
(MPLS) Management", RFC 3811, June 2004.
[RFC3812] Srinivasan, C., Viswanathan, A., and Nadeau, T.,
"Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) Management Information Base (MIB)",
RFC 3812, June 2004.
[RFC3813] Srinivasan, C., Viswanathan, A., and Nadeau, T.,
"Multiprotocol Label Switching (MPLS) Label Switching
Router (LSR) Management Information Base (MIB)",
RFC 3813, June 2004.
[RFC4204] J. P. Lang, "Link Management Protocol(LMP)", RFC4204,
October 2005.
[RFC4206] Kompella, K. and Rekhter, Y., "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
October 2005.
[RFC4209] A. Fredette, "Link Management Protocol (LMP) for
Dense Wavelength Division Multiplexing (DWDM) Optical
Line Systems", RFC4209, October 2005.
[RFC4220] Dubuc, M., Nadeau, T., and Lang, J., "Traffic
Engineering Link Management Information Base",
RFC 4220, November 2005.
T. Nadeau, et al. [Page 10]
draft-ietf-ccamp-gmpls-oam-requirements October 2007
[RFC4631] M. Dubuc, et al, "Link Management Protocol (LMP)
Management Information Base (MIB)", RFC4631, September
2006.
[RFC4726] A. Farrel, et al, "A Framework for Inter-Domain MPLS
Traffic Engineering", RFC4726, November 2006.
[RFC4802] T. Nadeau, et al, "Generalized Multiprotocol Label
Switching (GMPLS) Traffic Engineering Management
Information Base", RFC4802, February 2007.
[RFC4803] T. Nadeau, et al, "Generalized Multiprotocol Label
Switching (GMPLS) Label Switching Router (LSR)
Management Information Base", RFC4803, Feb., 2007.
[RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872,
May 2007.
[RFC4873] L. Berger, "GMPLS Based Segment Recovery", RFC 4873,
May 2007.
[RFC4974] Papadimitriou, D. and Farrel, A., "Generalized MPLS
(GMPLS) RSVP-TE Signaling Extensions in Support of
Calls", RFC 4974, August 2007.
[G.709] "Interfaces for the optical transport network (OTN)",
ITU-T G.709, February 2001.
[G.784] "Synchronous Digital Hierarchy (SDH) management",
ITU-T G.784, June 1999.
[MPLS/GMPLS] K. Kumaki, "Interworking Requirements to Support
operation of MPLS-TE over GMPLS networks", draft-ietf-
ccamp-mpls-gmpls-interwork-reqts, work in progress.
[TED-MIB] Miyazawa, M., Otani, T., Nadeaud, T., and Kumaki, K.,
"Traffic Engineering Database Management Information
Base in support of GMPLS", draft-ietf-ccamp-gmpls-ted-
mib, work in progress.
8. Acknowledgments
The authors wish to acknowledge and thank Masanori Miyazawa, Don
O'Connor, and Tom Petch for their valuable comments on this document.
T. Nadeau, et al. [Page 11]
draft-ietf-ccamp-gmpls-oam-requirements October 2007
9. 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 2007
11. 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]