[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 draft-ietf-mpls-tp-framework

Network Working Group                                     Matthew Bocci
Internet Draft                                            Marc Lasserre
Intended status: Informational                           Alcatel-Lucent
Expires: January 2009
                                                         Stewart Bryant
                                                    Cisco Systems, Inc.

                                                           July 7, 2008



                A Framework for MPLS in Transport Networks
                      draft-blb-mpls-tp-framework-00


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

   This Internet-Draft will expire on January 7, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).









<Lastname>             Expires January 7, 2009                 [Page 1]


Internet-Draft            MPLS TP Framework                   July 2008


Abstract

   There is a requirement to use MPLS to provide a network layer to
   support packet transport services. It is desirable that the operation
   and maintenance of such an MPLS based packet transport network follow
   operational models typical in optical transport networks, while
   providing additional OAM, survivability and other maintenance
   functions not currently supported by MPLS. This draft presents a
   framework for an architectural and functional profile of MPLS in
   order to support packet transport services.

Conventions used in this document

   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 [1].

Table of Contents

   1. Introduction...................................................3
      1.1. Motivation................................................3
      1.2. Scope.....................................................3
      1.3. Terminology...............................................3
   2. Summary of Requirements........................................3
   3. Transport Profile Overview.....................................4
      3.1. Architecture..............................................4
      3.2. Generic-ACH Label (GAL)...................................4
      3.3. Generic Associated Channel Header(GE-ACH).................5
      3.4. Forwarding................................................7
      3.5. Operations and Management (OAM)...........................8
      3.6. Control Plane.............................................9
         3.6.1. PW Control Plane....................................10
         3.6.2. LSP Control Plane...................................10
      3.7. Survivability............................................11
      3.8. Network Management.......................................12
   4. Security Considerations.......................................13
   5. IANA Considerations...........................................13
   6. Acknowledgments...............................................13
   7. References....................................................14
      7.1. Normative References.....................................14
      7.2. Informative References...................................15
   Authors' Addresses...............................................16
   Contributing Authors' Addresses..................................16
   Intellectual Property Statement..................................17
   Disclaimer of Validity...........................................17




<Lastname>             Expires January 7, 2009                 [Page 2]


Internet-Draft            MPLS TP Framework                   July 2008


1. Introduction

1.1. Motivation

   Transport technologies (e.g. SDH, ATM, OTN) have been designed with
   specific characteristics:

   o  Strictly connection oriented

      Long-lived connections

      Manually provisioned connections

   o  High level of protection and availability

   o  Quality of service

   o  Extended OAM capabilities

   The development of MPLS-TP has been driven by carriers needing to
   evolve SONET/SDH networks to support packet based services and
   networks.

   MPLS-TP defines a profile of MPLS targeted at transport applications.
   This profile specifies the specific MPLS characteristics and
   extensions required to meet transport requirements.

1.2. Scope

   This document specifies the high-level functionality of MPLS-TP
   required for adding transport-oriented capabilities to MPLS.

1.3. Terminology

2. Summary of Requirements

   This section summarizes the requirements for the MPLS transport
   profile. Such requirements are specified in more detail in [21], .
   [22] and [23].

   Solutions MUST NOT modify the MPLS forwarding architecture, and MUST
   be based on existing pseudowire and LSP constructs. Point to point
   LSPs MAY be unidirectional or bi-directional. Bi-directional LSPs
   MUST be congruent. Point to multipoint LSPs MUST be unidirectional.

   There MUST NOT be any LSP merging.



<Lastname>             Expires January 7, 2009                 [Page 3]


Internet-Draft            MPLS TP Framework                   July 2008


   OAM, protection and forwarding of data packets MUST be able to
   operate without IP forwarding support i.e. it MUST be possible to
   forward packets solely based on switching the MPLS or PW label. It
   must also be possible to establish and maintain LSPs and pseudowires
   both in the absence or presence of a dynamic control plane. When
   static provisioning is used, there MUST be no dependency on dynamic
   routing or signaling.

   LSP and pseudowire monitoring is only achieved through the use of OAM
   and MUST NOT rely on control plane or routing functions to determine
   the health of a path. Information from OAM functions is solely
   responsible for initiating path recovery actions.

   Mechanisms and capabilities must be able to interoperate with
   existing MPLS and pseudowire control and forwarding planes.

3. Transport Profile Overview

3.1. Architecture

   The architecture for a transport profile of MPLS (MPLS-TP) is based
   on the MPLS-TE and (MS-)PW architectures defined in RFC 3031 [2],
   RFC 3985 [5]  and [16].

   The MPLS-TP forwarding plane is a profile of the MPLS LSP and (MS-)PW
   forwarding paradigm as detailed in section .3.4.

   MPLS-TP supports a comprehensive set of OAM and protection-switching
   capabilities for packet transport applications, similar to existing
   SONET/SDH OAM and protection, as described in sections .3.5. and .
   3.7.
   MPLS-TP is operated with centralized Network Management Systems with
   or without the support of a distributed control plane as described in
   sections .3.6. and .3.8.

   MPLS-TP defines mechanisms to differentiate specific packets (e.g.
   OAM, APS, MCC or SCC) from those carrying user data packets. These
   mechanisms are described in sections .3.2. and .3.3.

3.2. Generic-ACH Label (GAL)

   MPLS-TP requires a mechanism to differentiate specific packets (e.g.
   OAM) from others, such as normal user-plane ones. This special label
   is referred to as the 'Generic-ACH Label (GAL)', as defined in [17].

   The 'Generic-ACH Label (GAL)' is a generic exception mechanism used
   firstly to differentiate specific packets (e.g. OAM) from others,


<Lastname>             Expires January 7, 2009                 [Page 4]


Internet-Draft            MPLS TP Framework                   July 2008


   such as normal user-plane ones, and secondly, to indicate that the
   Generic Associated Channel Header (GE-ACH) appears immediately after
   the bottom of the label stack.

   Note that MPLS-TP OAM packets will not reside immediately after the
   'Generic-ACH Label (GAL)' but behind the Generic Associated Channel
   Header (GE-ACH).

   In MPLS-TP, the 'Generic-ACH Label (GAL)' always appears at the
   bottom of the label stack (i.e. S bit set to 1).

3.3. Generic Associated Channel Header(GE-ACH)

   The MPLS transport profile makes use of a generic associated channel
   (GE-ACH) to support Fault, Configuration, Accounting, Performance and
   Security (FCAPS) functions by carrying packets related to OAM, APS,
   SCC and MCC, over LSPs or PWs, carried in band. The GE-ACH is defined
   in [18] and it is similar to the PWE3 Associated Channel, which is
   used to carry OAM packets across pseudowires. The GE-ACH is indicated
   by a generic associated channel header, similar to the PWE3 VCCV
   control word, and this is present for all LSPs and PWs making use of
   FCAPS functions supported by the GE-ACH.

   The GE-ACH functionality for LSPs SHOULD be limited to only OAM, APS,
   MCC and SCC channel data.

   Figure 1 shows the reference model depicting how the control channel
   is associated with the pseudowire protocol stack, as per RFC 5085 .
   [15].




















<Lastname>             Expires January 7, 2009                 [Page 5]


Internet-Draft            MPLS TP Framework                   July 2008


       +-------------+                                +-------------+
       |  Layer2     |                                |  Layer2     |
       |  Emulated   |       < Emulated Service >     |  Emulated   |
       |  Services   |                                |  Services   |
       +-------------+                                +-------------+
       |             |            VCCV/PW             |             |
       |Demultiplexer|    < Associated Channel >      |Demultiplexer|
       +-------------+                                +-------------+
       |    PSN      |          < PSN Tunnel >        |    PSN      |
       +-------------+                                +-------------+
       |  Physical   |                                |  Physical   |
       +-----+-------+                                +-----+-------+
             |                                              |
             |             ____     ___       ____          |
             |           _/    \___/   \    _/    \__       |
             |          /               \__/         \_     |
             |         /                               \    |
             +--------|      MPLS/MPLS-TP Network       |---+
                       \                               /
                        \   ___      ___     __      _/
                         \_/   \____/   \___/  \____/

      Figure 1 : PWE3 Protocol Stack Reference Model including the PW
                        Associated Control Channel

   PW associated channel messages are encapsulated using the PWE3
   encapsulation, so that they are handled and processed in the same
   manner (or in some cases, an analogous manner) as the PW PDUs for
   which they provide a control channel.

   Figure 2 shows the reference model depicting how the control channel
   is associated with the LSP protocol stack.

















<Lastname>             Expires January 7, 2009                 [Page 6]


Internet-Draft            MPLS TP Framework                   July 2008


       +-------------+                                +-------------+
       |             |                                |             |
       |  Payload    |          < Service >           |   Payload   |
       |  Services   |                                |             |
       +-------------+                                +-------------+
       |             |            LSP                 |             |
       |Demultiplexer|     < Associated Channel >     |Demultiplexer|
       +-------------+                                +-------------+
       |    PSN      |            < LSP >             |    PSN      |
       +-------------+                                +-------------+
       |  Physical   |                                |  Physical   |
       +-----+-------+                                +-----+-------+
             |                                              |
             |             ____     ___       ____          |
             |           _/    \___/   \    _/    \__       |
             |          /               \__/         \_     |
             |         /                               \    |
             +--------|      MPLS/MPLS-TP Network       |---+
                       \                               /
                        \   ___      ___     __      _/
                         \_/   \____/   \___/  \____/

           Figure 2 : MPLS Protocol Stack Reference Model including the
                          LSP Associated Control Channel

   LSP associated channel messages are encapsulated using a generic
   associated control channel header (GE-ACH). The presence of the GE-
   ACH is indicated by the inclusion of an additional 'Generic-ACH Label
   (GAL)'. This arrangement means that both normal data packets and
   packets carrying an ACH are carried over LSPs in a similar manner.
   Note that where a traffic engineered LSP is used the paths will be
   identical.

3.4. Forwarding

   MPLS-TP LSPs use the MPLS label switching operations defined in RFC
   3031 [2]. The MPLS encapsulation format is as defined in RFC 3032 .
   [3]. Per-platform or the per-interface label space can be selected.

   MPLS-TP (MS-)PWs support the PW forwarding operations defined in .
   [5]. Standard PW encapsulation mechanisms are applicable for
   different client layers as defined by the IETF PWE3 WG.

   MPLS-TP LSPs can be unidirectional or bidirectional point-to-point.
   As for MPLS, point-to-multipoint MPLS-TP LSPs are unidirectional.




<Lastname>             Expires January 7, 2009                 [Page 7]


Internet-Draft            MPLS TP Framework                   July 2008


   The forward and backward directions of bidirectional MPLS-TP LSPs are
   congruent: they follow the same path and the pairing relationship
   between the forward and the backward directions is known in each node
   traversed by bidirectional LSPs.

   Equal cost multi-path (ECMP) load balancing is not applicable to
   MPLS-TP LSPs. MPLS-TP LSP merging is prohibited.

   Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default.

   Both E-LSP and L-LSP are supported in MPLS-TP, as defined in RFC 3270
   [4].

   The Class of Service (CoS) field (former MPLS EXP field) follows the
   definition and processing rules of [19] and RFC 3270 [4], only the
   pipe and short-pipe models are supported in MPLS-TP.

3.5. Operations and Management (OAM)

   MPLS-TP requires that a set of OAM capabilities is available to
   perform fault management (e.g. fault detection and localization) and
   performance monitoring (e.g. signal quality measurement) of the MPLS-
   TP network and the services.

   The following OAM functions are intended to be supported by MPLS-TP
   and are intended to be applicable to any layer defined within MPLS-
   TP, i.e. MPLS Section, LSP and PW:

   o  Continuity Check

   o  Connectivity verification

   o  Performance monitoring

   o  Alarm suppression

   o  Remote Integrity

   For all of the above listed functions, (except alarm suppression)
   both "continuous" and "on-demand" operations are envisaged.

   Performance monitoring includes means for both "packet loss
   measurement" and "delay measurement".

   A requirement has been expressed for MPLS-TP OAM packets share the
   same fate as of data packets and that a means exists to identify OAM
   packets. The documents [17] and [18] propose specific mechanisms


<Lastname>             Expires January 7, 2009                 [Page 8]


Internet-Draft            MPLS TP Framework                   July 2008


   relying on the combination of the 'Generic-ACH Label (GAL)' and
   Generic Associated Channel Header for MPLS Sections and LSPs and
   using the Generic Associated Channel Header only for MPLS PWs.

   MPLS-TP OAM toolset is able to operate without IP functionality and
   without relying on control and/or management planes. In the case of
   MPLS-TP deployment with IP functionality, all existing IP-MPLS OAM
   functions, e.g. LSP-Ping, BFD and VCCV, can be used.

   OAM mechanisms are able to detect link and node failures and
   performance degradations and trigger recovery actions, according to
   the requirements of the service.

3.6. Control Plane

   The MPLS Transport Profile utilizes a distributed control plane to
   enable fast, dynamic and reliable service provisioning in multi-
   vendor and multi-domain environments using standardized protocols
   that guarantee interoperability. The MPLS-TP control plane is based
   on the MPLS control plane for pseudowires and the GMPLS control plane
   for MPLS-TP LSPs, respectively. More specifically, LDP is used for PW
   signaling and RSVP-TE for LSP signaling. The distributed MPLS-TP
   control plane provides the following basic functions:

   o  Signaling

   o  Routing

   o  Traffic engineering and constraint-based path computation

   In a multi-domain environment, the MPLS-TP control plane provides
   different types of interfaces at domain boundaries or within the
   domains such as UNI, I-NNI, and E-NNI where different policies are in
   place that control what kind of information is exchanged across these
   different types of interfaces.

   The MPLS-TP control plane is capable to activate MPLS-TP OAM
   functions as described in the OAM section of this document (.3.5. )
   e.g. for fault detection and localization in the event of a failure
   in order to efficiently restore failed transport paths.

   The MPLS-TP control plane supports all MPLS-TP data plane
   connectivity patterns that are needed for establishing multiple types
   of transport paths including protected paths as described in the
   survivability section (.3.7. ) of this document. Examples of the
   MPLS-TP data plane connectivity patterns are LSPs utilizing the fast



<Lastname>             Expires January 7, 2009                 [Page 9]


Internet-Draft            MPLS TP Framework                   July 2008


   reroute backup methods as defined in [6] and ingress-to-egress 1+1
   or 1:1 protected LSPs.

   Moreover, the MPLS-TP control plane is capable of performing fast
   restoration in the event of network failures.

   The MPLS-TP control plane provides its own survivability features and
   recovers from control plane failures and degradations using graceful
   operations. The MPLS-TP control plane is largely decoupled from the
   MPLS-TP data plane such that failures in the control plane do not
   impact the control plane and vice versa.

3.6.1. PW Control Plane

   An MPLS-TP packet transport network provides many of its transport
   services in the form of single-segment or multi-segment pseudowires
   following the PWE3 architecture as defined in [5] and [16] . In
   this context, the setup and maintenance of single-segment or multi-
   segment pseudowires is based on the Label Distribution Protocol (LDP)
   as per [9].

   It shall be noted that multi-segment pseudowire signaling is still
   work in progress. The control plane supporting multi-segment
   pseudowires is based on [13].

3.6.2. LSP Control Plane

   MPLS-TP provider edge nodes aggregate multiple pseudowires and carry
   them across the MPLS-TP network through MPLS-TP tunnels (MPLS-TP
   LSPs). The generalized MPLS (GMPLS) protocol suite already supports
   packet-switched capable (PSC) technologies and is therefore used as
   control plane for MPLS-TP transport paths (LSPs). The LSP control
   plane includes:

   o  RSVP-TE for signalling

   o  OSPF-TE for routing

   RSVP-TE signaling in support of GMPLS as defined in [11] is used for
   the setup, modification, and release of MPLS-TP transport paths and
   protection paths. It supports unidirectional, bi-directional and
   multicast types of LSPs. The route of a transport path is typically
   calculated in the ingress node of a domain and the RSVP explicit
   route object (ERO) is utilized for the setup of the transport path
   exactly following the given route.




<Lastname>             Expires January 7, 2009                [Page 10]


Internet-Draft            MPLS TP Framework                   July 2008


   OSPF-TE routing in support of GMPLS as defined in [8] is used for
   carrying link state information in a MPLS-TP network.

   For routing scalability reasons, parallel physical links in an MPLS-
   TP network are typically bundled into TE-links as defined in [7] and
   the OSPF-TE routing protocol disseminates link state information on a
   TE-link basis.

3.7. Survivability

   A wide variety of resiliency schemes have been developed to meet the
   various network and service survivability objectives. As part of the
   MPLS/PW paradigms, MPLS FRR [6] provides two methods for local
   repair using back-up LSP tunnels, while PWE redundancy [14] supports
   scenarios where the protection for the PW can not be fully provided
   by the PSN layer (i.e. where the backup PW terminates on a different
   target PE node than the working PW). Additionally, GMPLS provides a
   set of control plane driven well known protection and restoration
   mechanisms [11]. Finally, as part of the transport networks and
   applications paradigms, APS-based linear and ring protection
   mechanisms are defined in [10] and [24].

   These schemes have different scopes. They are protecting against link
   and/or node failures and can be applied end-to-end or on a segment of
   the considered connection.

   These protection schemes propose different levels of resiliency (e.g.
   1+1, 1:1, shared).

   The applicability of any given scheme to meet specific requirements
   is outside the current scope of this document.

   MPLS-TP resiliency mechanisms characteristics are listed below

   o  Linear, ring and meshed protection schemes are supported.

   o  MPLS-TP recovery mechanisms (protection and restoration), rely on
      OAM mechanisms to detect and localize network faults or service
      degenerations.

   o  APS-based protection mechanisms (linear and ring) rely on MPLS-TP
      APS mechanisms to coordinate and trigger protection switching
      actions.

   o  MPLS-TP recovery schemes are designed to be applicable at various
      levels (MPLS section, LSP and PW), providing segment and end-to-
      end recovery.


<Lastname>             Expires January 7, 2009                [Page 11]


Internet-Draft            MPLS TP Framework                   July 2008


   o  MPLS-TP recovery mechanisms support means for avoiding race
      conditions in switching activity triggered by a fault condition
      detected both at server layer and at MPLS-TP layer.

   o  MPLS-TP recovery mechanisms can be data plane, control plane or
      management plane based.

   o  MPLS-TP allows for revertive and non-revertive behavior

   o  Multiple resiliency mechanisms can be applied to any connection.

3.8. Network Management

   The network management architecture and requirements for MPLS-TP are
   specified in [23]. It derives from the generic specifications
   described in ITU-T G.7710/Y.1701 [12] for transport technologies. It
   also leverages on the OAM requirements for MPLS Networks [20] and
   MPLS-TP Networks [22] and expands on the requirements to cover the
   modifications necessary for fault, configuration, performance, and
   security.

   The Equipment Management Function (EMF) of a MPLS-TP NE provides the
   means through which a management system manages the NE. The
   Management Communication Channel (MCC), realized by the GE-ACH,
   provides a logical operations channel between NEs for transferring
   Management information. For the management interface from a
   management system to a MPLS-TP NE, there is no restriction on which
   management protocol should be used. It is allowed to provision and
   manage an end-to-end connection across a network where some segments
   are create/managed, for examples by Netconf or SNMP and other
   segments by XML or CORBA interfaces. It is allowed to run maintenance
   operations on a connection which is independent of the provisioning
   mechanism. An MPLS-TP NE is not required to offer more than one
   standard management interface.

   The Fault Management (FM) functions within the EMF of an MPLS-TP NE
   enable the supervision, detection, validation, isolation, correction,
   and alarm handling of abnormal operation of the MPLS-TP network and
   its environment. Supervision for transmission (such as continuity,
   connectivity, etc.), software processing, hardware, and environment
   are essential for FM. Alarm handling includes alarm severity
   assignment, alarm suppression/aggregation/correlation, alarm
   reporting control, and alarm reporting.

   Configuration Management (CM) provides functions to exercise control
   over, identify, collect data from, and provide data to MPLS-TP NEs.
   In addition to general configuration for hardware, software,


<Lastname>             Expires January 7, 2009                [Page 12]


Internet-Draft            MPLS TP Framework                   July 2008


   protection switching, alarm reporting control, and date/time setting,
   the EMF of the MPLS-TP NE also supports the configuration of
   maintenance entity identifiers (such as MEP ID and MIP ID). The EMF
   also supports configuration of the OAM parameters as part of
   connectivity management to meet specific operational requirements,
   such as whether one-time on-demand or periodically based on a
   specified frequency.

   The Performance Management (PM) functions within the EMF of an MPLS-
   TP NE supports the evaluation and reporting upon the behaviour of the
   equipment, NE, and network with the objective of providing coherent
   and consistent interpretation of the network behaviour, in particular
   for hybrid network which consists of multiple transport technologies.
   Packet loss measurement and delay measurement are collected so that
   they can be used to detect performance degradation. Performance
   degradation is reported via fault management for corrective actions
   (e.g. protection switch) and via performance monitoring for Service
   Level Agreement (SLA) verification and billing. The performance data
   collection mechanisms should be flexible to be configured to operate
   on-demand or proactively.

4. Security Considerations

   To be covered in a future revision of this document.

5. IANA Considerations

   To be covered in a future revision of this document.

6. Acknowledgments

   To be covered in a future revision of this document.

















<Lastname>             Expires January 7, 2009                [Page 13]


Internet-Draft            MPLS TP Framework                   July 2008


7. References

7.1. Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label
         Switching Architecture", RFC 3031, January 2001

   [3]   Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032,
         January 2001

   [4]   Le Faucheur, F., et al., "Multi-Protocol Label Switching (MPLS)
         Support of Differentiated Services", RFC 3270 May 2002

   [5]   Bryant, S., Pate, P. "Pseudo Wire Emulation Edge-to-Edge (PWE3)
         Architecture", RFC 3985, March 2005

   [6]   Pan, P., Swallow, G., Atlas, A., "Fast Reroute Extensions to
         RSVP-TE for LSP Tunnels", RFC 4090, May 2005

   [7]   Kompella, K. Rekhter, Y., Berger, L., " Link Bundling in MPLS
         Traffic Engineering (TE)", RFC 4201 October, 2005

   [8]   Kompella, K. Rekhter, Y., "OSPF Extensions in Support of
         Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203
         October 2005

   [9]   Martini, L. et al., "Pseudowire Setup and Maintenance Using the
         Label Distribution Protocol (LDP)", RFC 4447, April 2006

   [10]  ITU-T Recommendation G.8131/Y.1382 (02/07) " Linear protection
         switching for Transport MPLS (T-MPLS) networks"

   [11]  Lang, J.P., Rekhter, Y., Papadimitriou, D. (Editors), "RSVP-TE
         Extensions in Support of End-to-End Generalized Multi-Protocol
         Label Switching (GMPLS) Recovery", RFC 4872, May 2007

   [12]  ITU-T Recommendation G.7710/Y.1701 (07/07), "Common equipment
         management function requirements"

   [13]  Martini, L., Bocci, M., Balus, F., "Dynamic Placement of Multi
         Segment Pseudo Wires", draft-ietf-pwe3-dynamic-ms-pw-06,
         November 2007




<Lastname>             Expires January 7, 2009                [Page 14]


Internet-Draft            MPLS TP Framework                   July 2008


   [14]  Muley, P., et al., "Pseudowire (PW) Redundancy", draft-muley-
         pwe3-redundancy-02, November 2007

   [15]  Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit
         Connectivity Verification (VCCV): A Control Channel for
         Pseudowires", RFC 5085, December 2007

   [16]  Bocci, M., Bryant, S., "An Architecture for Multi-Segment
         Pseudowire Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw-arch-
         04, June 2008

   [17]  Vigoureux, M., Swallow, G., Aggarwal, R., "Assignment of the
         Generic Associated Channel Header Label (GAL)", draft-
         vigoureux-mpls-tp-gal-00, June 2008

   [18]  Bocci, M., Ward, D., "MPLS Generic Associated Channel", draft-
         bocci-pwe3-mpls-tp-ge-ach-00, June 2008

   [19]  Andersson, L., ""EXP field" renamed to "CoS Field"", draft-
         ietf-mpls-cosfield-def-03, July 2008

7.2. Informative References

   [20]  Nadeau, T., et al., "Operations and Management (OAM)
         Requirements for Multi-Protocol Label Switched (MPLS)
         Networks", RFC 4377, February 2006

   [21]  Niven-Jenkins, B., Brungard, D., Betts, M., "MPLS-TP
         Requirements", draft-jenkins-mpls-mpls-tp-requirements-00, July
         2008

   [22]  Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
         MPLS Transport Networks", draft-vigoureux-mpls-tp-oam-
         requirements-00, July 2008

   [23]  Lam, H.-K., Mansfield, S., Gray, E., "MPLS TP Network
         Management Requirements", draft-gray-mpls-tp-nm-req-00, July
         2008

   [24]  Draft ITU-T Recommendation G.8132/Y.1382, "T-MPLS shared
         protection ring", http://www.itu.int/md/T05-SG15-080211-TD-
         PLEN-0501/en







<Lastname>             Expires January 7, 2009                [Page 15]


Internet-Draft            MPLS TP Framework                   July 2008


Authors' Addresses

   Matthew Bocci
   Alcatel-Lucent

   Email: matthew.bocci@alcatel-lucent.co.uk


   Marc Lasserre
   Alcatel-Lucent

   Email:  mlasserre@alcatel-lucent.com


   Stewart Bryant
   Cisco Systems, Inc.

   Email :stbryant@cisco.com


Contributing Authors' Addresses

   Dieter Beller
   Alcatel-Lucent

   Email: d.beller@alcatel-lucent.de


   Italo Busi
   Alcatel-Lucent

   Email: italo.busi@alcatel-lucent.it


   Hing-Kam Lam
   Alcatel-Lucent

   Email: hklam@alcatel-lucent.com


   Lieven Levrau
   Alcatel-Lucent

   Email: llevrau@alcatel-lucent.com





<Lastname>             Expires January 7, 2009                [Page 16]


Internet-Draft            MPLS TP Framework                   July 2008


   Vincenzo Sestito
   Alcatel-Lucent

   Email: vincenzo.sestito@alcatel-lucent.it


   Martin Vigoureux
   Alcatel-Lucent

   Email: martin.vigoureux@alcatel-lucent.com


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.

Disclaimer of Validity

   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.




<Lastname>             Expires January 7, 2009                [Page 17]


Internet-Draft            MPLS TP Framework                   July 2008


Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.





































<Lastname>             Expires January 7, 2009                [Page 18]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/