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]