[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-ccamp-mpls-tp-cp-framework

Internet Draft                             Loa Andersson, Ed. (Acreo AB)
Category: Informational                           Lou Berger, Ed. (LabN)
Expiration Date: January 13, 2010               Luyuan Fang, Ed. (Cisco)
                                              Nabil Bitar, Ed. (Verizon)

                                                           July 13, 2009

                    MPLS-TP Control Plane Framework

           draft-abfb-mpls-tp-control-plane-framework-01.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 BCP 78 and 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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on January 13, 2010.

Copyright and License Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


Andersson, et al              Informational                     [Page 1]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


Abstract

   The MPLS Transport Profile (MPLS-TP) supports both static
   provisioning of transport paths via an NMS/OSS, and dynamic
   provisioning of transport paths via a control plane. This document
   provides the framework for MPLS-TP dynamic provisioning, and covers
   control plane signaling, routing, addressing, traffic engineering,
   path computation, and recovery in the event of network failures. The
   document focuses on the control of Label Switched Paths (LSPs) as the
   Pseudowire (PW) control plane is not modified by MPLS-TP.  MPLS-TP
   uses GMPLS as the control plane for MPLS-TP LSPs.  Backwards
   compatibility to MPLS is required. Management plane functions such as
   manual configuration, the initiation of LSP setup are out of scope of
   this document.

Table of Contents

    1      Introduction  ...........................................   3
    1.1    Conventions Used In This Document  ......................   3
    1.2    Scope  ..................................................   3
    1.3    Basic Approach  .........................................   4
    1.4    Reference Model  ........................................   5
    2      Control plane requirements  .............................   8
    2.1    Primary Requirements  ...................................   8
    2.2    MPLS-TP Framework Derived Requirements  .................  16
    2.3    OAM Framework Derived Requirements  .....................  17
    2.4    Security Requirements  ..................................  19
    3      Relationship of PWs and TE LSPs  ........................  19
    4      TE LSPs  ................................................  19
    4.1    General reuse of existing GMPLS control plane mechanisms  ...19
    4.1.1  In-Band and Out-Of-Band  ................................  20
    4.1.2  Addressing  .............................................  21
    4.2    Signaling  ..............................................  21
    4.3    Routing  ................................................  22
    4.3.1  ISIS-TE/OSPF-TE routing in support of MPLS-TP  ..........  23
    4.3.2  TE link bundling  .......................................  25
    4.4    OAM, MEP (hierarchy) configuration & control  ...........  25
    4.5    Traffic engineering and constraint-based path computation  ..25
    4.5.1  Relation to PCE  ........................................  26
    4.6    Applicability  ..........................................  26
    4.7    Recovery  ...............................................  26
    4.7.1  E2E, segment  ...........................................  26
    4.7.2  P2P, P2MP  ..............................................  27
    4.7.3  Recovery Triggers  ......................................  27
    4.8    Diffserv object usage in GMPLS (E-LSPs, L-LSPs)  ........  27
    4.9    Management plane support  ...............................  27
    4.9.1  Management Plane / Control Plane Ownership Transfer  ....  27
    4.10   CP reference points (E-NNI, I-NNI, UNI)  ................  28
    4.11   MPLS to MPLS-TP interworking  ...........................  28
    5      Pseudo Wires  ...........................................  28
    5.1    General reuse of existing PW control plane mechanisms  ..  31



Andersson, et al              Informational                     [Page 2]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


    5.2    Signaling  ..............................................  31
    5.3    Recovery (Redundancy)  ..................................  31
    6      Security Considerations  ................................  31
    7      IANA Considerations  ....................................  31
    8      Acknowledgments  ........................................  31
    9      References  .............................................  32
    9.1    Normative References  ...................................  32
    9.2    Informative References  .................................  34
   10      Authors' Addresses  .....................................  36



1. Introduction

   The MPLS Transport Profile (MPLS-TP) is being defined in a joint
   effort between the International Telecommunications Union (ITU) and
   the IETF.  The requirements for MPLS-TP are defined in the
   requirements document, see [TP-REQ].  These requirements state that
   "A solution MUST be provided to support dynamic provisioning of MPLS-
   TP transport paths via a control plane."  This document provides the
   framework for such dynamic provisioning.



1.1. 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 [RFC2119].



1.2. Scope

   This document covers control plane related topics for MPLS-TP Label
   Switched Paths (LSPs) and Pseudowire (PW).  The control plane
   requirements for MPLS-TP are defined in [TP-REQ]. These requirements
   defined the role of the control plane in MPLS-TP.  In particular,
   Sections 2.4 and portions of the remainder of Section 2 of [TP-REQ]
   provide specific control plane requirements.

   The LSPs provided by MPLS-TP are used as a server layer for IP, MPLS
   and PWs, as well as other tunneled MPLS-TP LSPs. The PWs are used to
   carry client signal other than IP and MPLS. The relationship between
   pseudo wires and MPLS-TP LSPs is exactly the same as between pseudo
   wires and MPLS LSPs in a Packet switched network (PSN). The PW
   encapsulation over MPLS-TP LSPs used in MPLS-TP networks is the same



Andersson, et al              Informational                     [Page 3]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


   as for PWs over MPLS in an MPLS network. MPLS-TP also defines
   protection and restoration (or, collectively, recovery) functions.
   The MPLS-TP control plane provides methods to establish, remove and
   control MPLS-TP LSP and PW functions.  This includes control of data
   plane, OAM and recovery functions.

   A general framework for MPLS-TP has been defined in [TP-FWK], and a
   survivability framework for MPLS-TP has been defined in [TP-SURVIVE].
   These document scope the approaches and protocols that will be used
   as the foundation for MPLS-TP.  Notably, Section 3.5 of [TP-FWK]
   scopes the IETF protocols that serve as the foundation of the MPLS-TP
   control plane.  The PW control plane is based on the existing PW
   control plane, see [RFC4447], and the PW end-to-end (PWE3)
   architecture, see [RFC3985].  The LSP control plane is based on
   Generalized MPLS (GMPLS), see [RFC3945], which is built on MPLS-TE
   and its numerous extensions. [TP-SURVIVE] focuses on LSPs, and the
   protection functions that must be supported within MPLS-TP. It does
   not specify which control plane mechanisms are to be used.

   This document discusses the impact of MPLS-TP requirements on the
   signaling that is used to provision pseudo wires as specified in
   RFC4447. This document also discusses the impact of the MPLS-TP
   requirements on the GMPLS signaling and routing protocols that is
   used to provision MPLS-TP LSPs.


1.3. Basic Approach

   The basic approach taken in defining the MPLS-TP Control Plane
   framework is:

      1) MPLS technology as defined by the IETF is the foundation for
         the MPLS Transport Profile. [Editor's note: should also be in
         primary TP documents.]
      2) The data plane for MPLS and MPLS-TP is identical, i.e. any
         extensions defined for MPLS-TP is also applicable to MPLS.  And
         the same encapsulation used for MPLS over any layer 2 network
         is also used for MPLS-TP.  [Editor's note: should also be in
         primary TP documents.]
      3) MPLS PWs are used as-is by MPLS-TP including the use of
         targeted-LDP for PW signaling [RFC4447], OSPF-TE, ISIS-TE or
         MP-BGP as they apply for Multi-Segment(MS)-PW routing. However,
         the PW can be encapsulated over an MPLS-TP LSP in (established
         using methods and procedures for MPLS-TP LSP establishment) in
         addition to the presently defined methods of carrying PWs over
         packet switched networks (PSNs). That is, the MPLS-TP domain is
         a packet switched network from PWE3 architecture aspect
         [RFC3985].






Andersson, et al              Informational                     [Page 4]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


      4) The MPLS-TP LSP control plane builds on the GMPLS control plane
         as defined by the IETF for transport LSPs, the protocols within
         scope are RSVP-TE [RFC3473], OSPF-TE [RFC4203][RFC5392], and
         ISIS-TE [RFC5307][RFC5316].  ASON/ASTN signaling and routing
         requirements in the context of GMPLS can be found in [RFC4139]
         and [RFC4258].
      5) Existing IETF MPLS and GMPLS RFCs and evolving Working Group
         Internet-Drafts should be reused wherever possible.
      6) If needed, extensions for the MPLS-TP control plane should
         first based on the existing and evolving IETF work, secondly
         based on work by other Standard bodies only when IETF decides
         that the work is out of IETF scope. New extensions may be
         defined otherwise.
      7) Extensions to the GMPLS control plane may be required in order
         to fully automate MPLS-TP functions.
      8) Control-plane software upgrades to existing equipment running
         MPLS is acceptable and expected.
      9) It is permissible for functions present in the GMPLS control
         plane not to be used in MPLS-TP networks, e.g. the possibility
         to merge LSPs.
     10) One possible use of the control plane is to configure, enable
         and empower OAM functionality; this will require extensions to
         existing control plane specifications.
     11) MPLS-TP requirements are primarily defined in Section 2.4 and
         relevant portions of the remainder Section 2 of [TP-REQ].


1.4. Reference Model

   The control plane reference model is based on the general MPLS-TP
   reference model as defined in MPLS-TP framework [TP-FWK]. Per MPLS-TP
   framework [TP-FWK], MPLS-TP control plane is based on GMPLS with
   RSVP-TE for LSP signaling and LDP for PW signaling.  In both cases,
   OSPF-TE or ISIS-TE with GMPLS extensions is used for dynamic routing.

   From a service perspective, client interfaces are provided for both
   the PWs and LSPs.  PW client interfaces are defined on an interface
   technology basis, e.g., Ethernet over PW [RFC4448]. In the context of
   MPLS-TP LSP, the client interface is expected to be provided via a
   UNI, [RFC4208].  As discussed in [TP-FWK], MPLS-TP also presumes an
   LSP NNI reference point.

   The MPLS-TP end-to-end control plane reference model is shown in
   Figure 1.  It shows the control plane protocols used by MPLS-TP, as
   well as the UNI and NNI reference points.  [Editor's note: need to
   add more explanatory text.]








Andersson, et al              Informational                     [Page 5]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


      |< ---- client signal (IP / MPLS / L2 / PW) ------------ >|
        |< --------- SP1 ----------- >|< ------- SP2 ------- >|
          |< ---------- MPLS-TP End to End PW ------------ >|
            |< -------- MPLS-TP End to End LSP --------- >|

   +---+   +---+  +---+  +---+  +---+   +---+  +---+  +---+   +---+
   |CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2|
   +---+   +---+  +---+  +---+  +---+   +---+  +---+  +---+   +---+
        UNI                          NNI                   UNI

   TE-RTG    |< ---------------- >|< --- >|< ---------- >|
   RSVP-TE

      LDP    |< --------------------------------------- >|

    Figure 1. End-to-End MPLS-TP Control Plane Reference Model

     Legend:
          CE:            Customer Edge
          Client signal: defined in MPLS-TP Requirements
          L2:            Any layer 2 signal that may be carried
                         over a PW, e.g. Ethernet.
          NNI:           Network to Network Interface
          PE:            Provider Edge
          SP:            Service Provider
          TE-RTG:        OSPF-TE or ISIS-TE
          UNI:           User to Network Interface

   Figure 2 adds three hierarchical LSP segments, labeled as "H- LSPs".
   These segments are present to support OAM and MEPs within each
   provider and across the inter-provider NNI.  The MEPs are used to
   collect performance information and support OAM triggered
   survivability schemes as discussed in [TP-SURVIVE], and each H-LSP
   may be protected using any of the schemes discussed in [TP-SURVIVE].




















Andersson, et al              Informational                     [Page 6]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


       |< ------- client signal (IP / MPLS / L2 / PW) ------ >|
         |< -------- SP1 ----------- >|< ------- SP2 ----- >|
           |< ----------- MPLS-TP End to End PW -------- >|
             |< ------- MPLS-TP End to End LSP ------- >|
             |< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->|

   +---+   +---+  +---+  +---+  +---+   +---+  +---+  +---+   +---+
   |CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2|
   +---+   +---+  +---+  +---+  +---+   +---+  +---+  +---+   +---+
        UNI                          NNI                   UNI

           ..... ..... ..... ......... ......... ..... .....
           |MEP|-|MIP|-|MIP|-|MEP|MEP|-|MEP|MEP|-|MIP|-|MEP|
           ''''' ''''' ''''' ''''''''' ''''''''' ''''' '''''


   TE-RTG    |< -- >|< -- >|< -- >||< -- >||< -- >|< -- >|
   RSVP-TE   (within the MPLS-TP domain)

   TE-RTG    |< ---------------- >|< ---- >|< --------- >|
   RSVP-TE

      LDP    |< --------------------------------------- >|

     Figure 2. MPLS-TP Control Plane Reference Model with OAM

     Legend:
          CE:            Customer Edge
          Client signal: defined in MPLS-TP Requirements
          L2:            Any layer 2 signal that may be carried
                         over a PW, e.g. Ethernet.
          H-LSP:         Hierarchical LSP
          MEP:           Maintenance end points
          MIP:           Maintenance intermediate points
          NNI:           Network to Network Interface
          PE:            Provider Edge
          SP:            Service Provider
          TE-RTG:        OSPF-TE or ISIS-TE

   While not shown in the Figures above, it is worth noting that the
   MPLS-TP control plane must support the addressing separation and
   independence between the data, control and management planes as shown
   in Figure 3 of [TP-FWK].  Address separation between the planes is
   already included in GMPLS.










Andersson, et al              Informational                     [Page 7]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


2. Control plane requirements

   The requirements for the MPLS-TP control plane are derived from the
   MPLS-TP requirements and framework documents, specifically [TP-REQ],
   [TP-FWK], [TP-OAM-REQ], [TP-OAM], and [TP-SURVIVE].  The requirements
   are summarized in this section, but do not replace those documents.
   If there are differences between this section and those documents,
   those documents shall be considered authoritative.


2.1. Primary Requirements

   These requirements are based on Section 2 [TP-REQ]:
      1. Any new functionality that is defined to fulfill the
         requirements for MPLS-TP must be agreed within the IETF through
         the IETF consensus process as per [RFC4929].

      2. The MPLS-TP control plane design should as far as reasonably
         possible re-use existing MPLS standards.

      3. The MPLS-TP control plane must be able to interoperate with
         existing IETF MPLS and PWE3 control planes where appropriate.

      4. The MPLS-TP control plane must be sufficiently well-defined
         that interworking equipment supplied by multiple vendors will
         be possible both within a single domain, and between domains.

      5. The MPLS-TP control plane must support a connection- oriented
         packet switching model with traffic engineering capabilities
         that allow deterministic control of the use of network
         resources.

      6. The MPLS-TP control plane must support traffic engineered
         point-to-point (P2P) and point-to-multipoint (P2MP) transport
         paths.

      7. The MPLS-TP control plane must support unidirectional,
         associated bidirectional and co-routed bidirectional point-to-
         point transport paths.

      8. The MPLS-TP control plane must support unidirectional point-to-
         multipoint transport paths.

      9. All nodes (i.e., ingress, egress and intermediate) must be
         aware about the pairing relationship of the forward and the
         backward directions belonging to the same co-routed
         bidirectional transport path.







Andersson, et al              Informational                     [Page 8]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


     10. Edge nodes (i.e., ingress and egress) must be aware about the
         pairing relationship of the forward and the backward directions
         belonging to the same associated bidirectional transport path.

     11. Transit nodes should be aware about the pairing relationship of
         the forward and the backward directions belonging to the same
         associated bidirectional transport path.

     12. The MPLS-TP control plane must support bidirectional transport
         paths with symmetric bandwidth requirements, i.e. the amount of
         reserved bandwidth is the same in the forward and backward
         directions.

     13. The MPLS-TP control plane must support bidirectional transport
         paths with asymmetric bandwidth requirements, i.e. the amount
         of reserved bandwidth differs in the forward and backward
         directions.

     14. The MPLS-TP control plane must support the logical separation
         of the control and management planes from the data plane.

     15. The MPLS-TP control plane must support the physical separation
         of the control and management planes from the data plane.

     16. A control plane must be defined to support dynamic provisioning
         and restoration of MPLS-TP transport paths, but its use is a
         network operator's choice.

     17. A control plane must not be required to support the static
         provisioning of MPLS-TP transport paths.

     18. The MPLS-TP control plane must permit the co-existence of
         statically and dynamically provisioned/managed MPLS-TP
         transport paths within the same layer network or domain.

     19. The MPLS-TP control plane should be operable in a way that is
         similar to the way the control plane operates in other
         transport layer technologies.

     20. The MPLS-TP control plane must avoid or minimize traffic impact
         (e.g. packet delay, reordering and loss) during network
         reconfiguration.

     21. The MPLS-TP control plane must work across multiple homogeneous
         domains.

     22. The MPLS-TP control plane should work across multiple non-
         homogeneous domains.






Andersson, et al              Informational                     [Page 9]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


     23. The MPLS-TP control plane must not dictate any particular
         physical or logical topology.

     24. The MPLS-TP control plane must include support of ring
         topologies which may be deployed with arbitrarily
         interconnection, support rings of at least 16 nodes.

     25. The MPLS-TP control plane must support scale gracefully to
         support a large number of transport paths, nodes and links.
         That is it must be able to scale at least as well as control
         planes in existing transport technologies with growing and
         increasingly complex network topologies as well as with
         increasing bandwidth demands, number of customers, and number
         of services.

     26. The MPLS-TP control plane should not provision transport paths
         which contain forwarding loops.

     27. The MPLS-TP control plane must support multiple client layers.
         (e.g.  MPLS-TP, IP, MPLS, Ethernet, ATM, FR, etc.)

     28. The MPLS-TP control plane must provide a generic and extensible
         solution to support the transport of MPLS-TP transport paths
         over one or more server layer networks (such as MPLS-TP,
         Ethernet, SONET/SDH, OTN, etc.).  Requirements for bandwidth
         management within a server layer network are outside the scope
         of this document.

     29. In an environment where an MPLS-TP layer network is supporting
         a client layer network, and the MPLS-TP layer network is
         supported by a server layer network then the control plane
         operation of the MPLS-TP layer network must be possible without
         any dependencies on the server or client layer network.

     30. The MPLS-TP control plane must allow for the transport of a
         client MPLS or MPLS-TP layer network over a server MPLS or
         MPLS-TP layer network.

     31. The MPLS-TP control plane must allow the operation the layers
         of a multi-layer network that includes an MPLS-TP layer
         autonomously.

     32. The MPLS-TP control plane must allow the hiding of MPLS-TP
         layer network addressing and other information (e.g. topology)
         from client layer networks.  However, it should be possible, at
         the option of the operator, to leak a limited amount of
         summarized information (such as SRLGs or reachability) between
         layers.






Andersson, et al              Informational                    [Page 10]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


     33. The MPLS-TP control plane must allow for the identification of
         a transport path on each link within and at the destination
         (egress) of the transport network.

     34. The MPLS-TP control plane must allow for P2MP capable server
         (sub-)layers.

     35. The MPLS-TP control plane must be extensible in order to
         accommodate new types of client layer networks and services.

     36. The MPLS-TP control plane should support the reserved bandwidth
         associated with a transport path to be increased without
         impacting the existing traffic on that transport path provided
         enough resources are available.

     37. The MPLS-TP control plane should support the reserved bandwidth
         of a transport path to be decreased without impacting the
         existing traffic on that transport path, provided that the
         level of existing traffic is smaller than the reserved
         bandwidth following the decrease.

     38. The MPLS-TP control plane must support an unambiguous and
         reliable means of distinguishing users' (client) packets from
         MPLS-TP control packets (e.g. control plane, management plane,
         OAM and protection switching packets).

     39. The control plane for MPLS-TP must fit within the ASON
         architecture.  The ITU-T has defined an architecture for
         Automatically Switched Optical Networks (ASON) in G.8080
         [ITU.G8080.2006] and G.8080 Amendment 1 [ITU.G8080.2008]. An
         interpretation of the ASON signaling and routing requirements
         in the context of GMPLS can be found in [RFC4139] and
         [RFC4258].

     40. The MPLS-TP control plane must support control plane topology
         and data plane topology independence.

     41. A failure of the MPLS-TP control plane must not interfere with
         the deliver of service or recovery of established transport
         paths.

     42. The MPLS-TP control plane must be able to operate independent
         of any particular client or server layer control plane.

     43. The MPLS-TP control plane should support, but not require, an
         integrated control plane encompassing MPLS-TP together with its
         server and client layer networks when these layer networks
         belong to the same administrative domain.






Andersson, et al              Informational                    [Page 11]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


     44. The MPLS-TP control plane must support configuration of
         protection functions and any associated maintenance (OAM)
         functions.

     45. The MPLS-TP control plane must support the configuration and
         modification of OAM maintenance points as well as the
         activation/deactivation of OAM when the transport path or
         transport service is established or modified.

     46. The MPLS-TP control plane must capable of restarting and
         relearning its previous state without impacting forwarding.

     47. The MPLS-TP control plane must provide a mechanism for dynamic
         ownership transfer of the control of MPLS-TP transport paths
         from the management plane to the control plane and vice versa.
         The number of reconfigurations required in the data plane must
         be minimized (preferably no data plane reconfiguration will be
         required).

     48. The MPLS-TP control plane must support protection and
         restoration mechanisms, i.e., recovery.

         Note that the MPLS-TP Survivability Framework document, [TP-
         SURVIVE], provides additional useful information related to
         recovery.

     49. The MPLS-TP control plane mechanisms should be identical (or as
         similar as possible) to those already used in existing
         transport networks to simplify implementation and operations.
         However, this must not override any other requirement.

     50. The MPLS-TP control plane mechanisms used for P2P and P2MP
         recovery should be identical to simplify implementation and
         operation.  However, this must not override any other
         requirement.

     51. The MPLS-TP control plane must support recovery mechanisms that
         are applicable at various levels throughout the network
         including support for link, transport path, segment,
         concatenated segment and end to end recovery.

     52. The MPLS-TP control plane must support recovery paths that meet
         the SLA protection objectives of the service.  Including:

            a. Guarantee 50ms recovery times from the moment of fault
               detection in networks with spans less than 1200 km.

            b. Protection of up to 100% of the traffic on the protected
               path.





Andersson, et al              Informational                    [Page 12]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


            c. Recovery must meet SLA requirements over multiple
               domains.

     53. The MPLS-TP control plane should support per transport path
         Recovery objective.

     54. The MPLS-TP control plane must support recovery mechanisms that
         are applicable to any topology.

     55. The MPLS-TP control plane must operate in synergy with
         (including coordination of timing/timer settings) the recovery
         mechanisms present in any client or server transport networks
         (for example, Ethernet, SDH, OTN, WDM) to avoid race conditions
         between the layers.

     56. The MPLS-TP control plane must support recovery and reversion
         mechanisms that prevent frequent operation of recovery in the
         event of an intermittent defect.

     57. The MPLS-TP control plane must support revertive and non-
         revertive protection behavior.

     58. The MPLS-TP control plane must support 1+1 bidirectional
         protection for P2P transport paths.

     59. The MPLS-TP control plane must support 1+1 unidirectional
         protection for P2P transport paths.

     60. The MPLS-TP control plane must support 1+1 unidirectional
         protection for P2MP transport paths.

     61. The MPLS-TP control plane must support the ability to share
         protection resources amongst a number of transport paths.

     62. The MPLS-TP control plane must support 1:n bidirectional
         protection for P2P transport paths, and this should be the
         default for 1:n protection.

     63. The MPLS-TP control plane must support 1:n unidirectional
         protection for P2MP transport paths.

     64. The MPLS-TP control plane may support 1:n unidirectional
         protection for P2P transport paths.

     65. The MPLS-TP control plane may support extra-traffic.

     66. The MPLS-TP control plane should support 1:n (including 1:1)
         shared mesh recovery.






Andersson, et al              Informational                    [Page 13]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


     67. The MPLS-TP control plane must support sharing of protection
         resources such that protection paths that are known not to be
         required concurrently can share the same resources.

     68. The MPLS-TP control plane must support the sharing of resources
         between a restoration transport path and the transport path
         being replaced.

     69. The MPLS-TP control plane must support restoration priority so
         that an implementation can determine the order in which
         transport paths should be restored.

     70. The MPLS-TP control plane must support preemption priority in
         order to allow restoration to displace other transport paths in
         the event of resource constraints.

     71. The MPLS-TP control plane may support revertive and non-
         revertive restoration behavior.

     72. The MPLS-TP control plane must support recovery being triggered
         by physical (lower) layer fault indications.

     73. The MPLS-TP control plane must support recovery being triggered
         by OAM.

     74. The MPLS-TP control plane must support management plane
         recovery triggers (e.g., forced switch, etc.).

     75. The MPLS-TP control plane must support the differentiation of
         administrative recovery actions from recovery actions initiated
         by other triggers.

     76. The MPLS-TP control plane should support control plane
         restoration triggers (e.g., forced switch, etc.).

     77. The MPLS-TP control plane must support priority logic to
         negotiate and accommodate coexisting requests (i.e., multiple
         requests) for protection switching (e.g., administrative
         requests and requests due to link/node failures).

     78. The MPLS-TP control plane must support the relationships of
         protection paths and protection-to-working paths (sometimes
         known as protection groups).

     79. The MPLS-TP control plane must support pre-calculation of
         recovery paths.

     80. The MPLS-TP control plane must support pre-provisioning of
         recovery paths.





Andersson, et al              Informational                    [Page 14]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


     81. The MPLS-TP control plane must support the external commands
         defined in [RFC4427]. External controls overruled by higher
         priority requests (e.g., administrative requests and requests
         due to link/node failures) or unable to be signaled to the
         remote end (e.g.  because of a protection state coordination
         fail) must be dropped.

     82. The MPLS-TP control plane must permit the testing and
         validation of the integrity of the protection/recovery
         transport path.

     83. The MPLS-TP control plane must permit the testing and
         validation of protection/ restoration mechanisms without
         triggering the actual protection/restoration.

     84. The MPLS-TP control plane must permit the testing and
         validation of protection/ restoration mechanisms while the
         working path is in service.

     85. The MPLS-TP control plane must permit the testing and
         validation of protection/ restoration mechanisms while the
         working path is out of service.

     86. The MPLS-TP control plane must support the establishment and
         maintenance of all recovery entities and functions.

     87. The MPLS-TP control plane must support signaling of recovery
         administrative control.

     88. The MPLS-TP control plane must support protection state
         coordination (PSC). Since control plane network topology is
         independent from the data plane network topology, the PSC
         supported by the MPLS-TP control plane may run on resources
         different than the data plane resources handled within the
         recovery mechanism (e.g. backup).

     89. The MPLS-TP control plane may support recovery mechanisms that
         are optimized for specific network topologies.  These
         mechanisms must be interoperable with the mechanisms defined
         for arbitrary topology (mesh) networks to enable protection of
         end-to-end transport paths.

     90. (Editor's note: inclusion of ring specific control plane
         requirements are TBD, See Section 2.8.6.1. of [TP-REQ])

     91. The MPLS-TP control plane must include support for
         differentiated services and different traffic types with
         traffic class separation associated with different traffic.






Andersson, et al              Informational                    [Page 15]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


     92. The MPLS-TP control plane must support the provisioning of
         services that provide a guaranteed of Service Level
         Specifications (SLS), with support for hard and relative end-
         to-end bandwidth guarantees.  [Editor's note: add reference to
         definition of hard and relative guarantees]

     93. The MPLS-TP control plane must support the provisioning of
         services which are sensitive to jitter and delay.


2.2. MPLS-TP Framework Derived Requirements

   The following additional requirements are based on [TP-FWK]:

     94. Per-packet equal cost multi-path (ECMP) load balancing is not
         applicable to MPLS-TP.

     95. Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by
         default. The applicability of PHP to both MPLS-TP LSPs and MPLS
         networks general providing packet transport services will be
         clarified in a future version.

     96. The MPLS-TP control plane must support both E-LSP and L- LSP as
         specified in [RFC3270].

     97. The address spaces used in the management, control and data
         planes are independent.

     98. The MPLS-TP control plane is based on the MPLS control plane
         for pseudowires, and more specifically, LDP is used for PW
         signaling.

     99. Both single-segment and multi-segment PWs shall be supported by
         the MPLS-TP control plane.  MPLS-TP shall use the definition of
         multi-segment PWs that is under development in the IETF
         independent from MPLS-TP.

    100. The MPLS-TP control plane is based on the GMPLS control plane
         for MPLS-TP LSPs. More specifically, GMPLS RSVP-TE [RFC3473]
         and related extensions are used for LSP signaling, and GMPLS
         OSPF-TE [RFC5392] and ISIS-TE [RFC5316] are used for routing.

    101. The MPLS-TP LSP control plane must allow for interoperation
         with the MPLS-TE LSP control plane.

    102. The MPLS-TP control plane must ensure its own survivability and
         to enable it to recover gracefully from failures and
         degradations.  These include graceful restart and hot redundant
         configurations.





Andersson, et al              Informational                    [Page 16]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


    103. The MPLS-TP control plane must support linear, ring and meshed
         protection schemes.


2.3. OAM Framework Derived Requirements

   The following additional requirements are based on [TP-OAM-REQ] and
   [TP-OAM]:

    104. The MPLS-TP control plane must support the capability to
         enable/disable OAM functions as part of service establishment.

    105. The MPLS-TP control plane must support the capability to
         enable/disable OAM functions after service establishment.  In
         such cases, the customer must not perceive service degradation
         as a result of OAM enabling/disabling.

    106. The MPLS-TP control plane must allow for the IP/MPLS and PW OAM
         protocols (e.g., LSP-Ping [RFC4379], MPLS-BFD [BFD-MPLS], VCCV
         [RFC5085] and VCCV-BFD [VCCV-BFD]).

    107. The MPLS-TP control plane must allow for the ability to support
         experimental OAM functions.  These functions must be disabled
         by default.

    108. The MPLS-TP control plane must support the choice of which (if
         any) OAM function(s) to use and on which PW, LSP or Section to
         apply it(them) to.

    109. The MPLS-TP control plane must provide a mechanism to support
         the localization of faults and the notification of appropriate
         nodes.  Such notification should trigger corrective (recovery)
         actions.

    110. The MPLS-TP control plane must allow service provider to be
         informed of a fault or defect affecting the service(s) it
         provides, even if the fault or defect is located outside of his
         domain.

    111. Information exchange between various nodes involved in the
         MPLS-TP control plane should be reliable such that, for
         example, defects or faults are properly detected or that state
         changes are effectively known by the appropriate nodes.

    112. The MPLS-TP control plane must provide functionality to control
         the verification of the continuity (checks) (CC) of a PW, LSP
         or Section.







Andersson, et al              Informational                    [Page 17]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


    113. The MPLS-TP control plane must provide functionality to control
         the verification of the connectivity (CV) of a PW, LSP or
         Section.

    114. The MPLS-TP control plane may provide functionality to control
         the conduction of diagnostic tests on a PW, LSP or Section.

    115. The MPLS-TP control plane must provide functionality to enable
         an End Point to discover the Intermediate (if any) and End
         Point(s) along a PW, LSP or Section, and more generally to
         trace (record) the route of a PW, LSP or Section.

    116. The MPLS-TP control plane must provide functionality to enable
         an End Point of a PW, LSP or Section to instruct its associated
         End Point(s) to lock the PW, LSP or Section.  Note that lock
         corresponds to an administrative status in which forwarding
         traffic on and from the PW, LSP or Section is disabled.  (This
         requirement duplicates a requirement stated above but is listed
         again to maintain alignment with [TP-OAM].)

    117. The MPLS-TP control plane must provide functionality to enable
         an Intermediate Point of a PW or LSP to report, to an End Point
         of that same PW or LSP, an external lock condition affecting
         that PW or LSP.

    118. The MPLS-TP control plane must provide functionality to enable
         an Intermediate Point of a PW or LSP to report, to an End Point
         of that same PW or LSP, a fault or defect condition affecting
         that PW or LSP.

    119. The MPLS-TP control plane must provide functionality to enable
         an End Point to report, to its associated End Point, a fault or
         defect condition that it detects on a PW, LSP or Section for
         which they are the End Points.

    120. The MPLS-TP control plane must provide functionality to enable
         the propagation, across an MPLS-TP network, of information
         pertaining to a client defect of fault condition detected at an
         End Point of a PW or LSP, if the client layer mechanisms do not
         provide an alarm notification/propagation mechanism.

    121. The MPLS-TP control plane must provide functionality to enable
         the control of quantification of packet loss ratio over a PW,
         LSP or Section.

    122. The MPLS-TP control plane must provide functionality to report
         an expected one-way, and if appropriate, the two-way, delay of
         a PW, LSP or Section.






Andersson, et al              Informational                    [Page 18]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


    123. The MPLS-TP control plane must support the configuration of
         MEPs.

            a. The CC and CV functions operate between MEPs.

            b. All OAM packets coming to a MEP source are tunneled via
               label stacking, and therefore a MEP may only be present
               at an LSP's ingress and egress nodes (and never at an
               LSP's transit node).

            c. The CC and CV functions may serve as a trigger for
               protection switching, see requirement 45 above.

            d. This implies that LSP hierarchy must be used in cases
               where OAM is used to trigger recovery.

    124. The MPLS-TP control plane must support the signaling of the
         transmission period and the ME identifier used in CC and CV.


2.4. Security Requirements

   There are no specific MPLS-TP control plane security requirements.
   The existing framework for MPLS and GMPLS security is documented on
   [MPLS-SEC] and that document applies equally to MPLS-TP.


3. Relationship of PWs and TE LSPs

   [Editor's note:  This section (and the remainder of this document) is
   preliminary and will be edited/replaced in future versions.]

   TBD


4. TE LSPs

   [Editor's note:  This section (and the remainder of this document) is
   preliminary and will be edited/replaced in future versions.]


4.1. General reuse of existing GMPLS control plane mechanisms

   As described in [RFC3945], Generalized MPLS (GMPLS) extends MPLS to
   support additional switching technologies. GMPLS is thus capable of
   controlling packet technologies. Most of the initial efforts on
   Generalized MPLS (GMPLS) have been related to delivering circuit
   connectivity. With the emergence of devices capable of multiple
   switching capabilities and the integrated control paradigm, there is
   a need to clarify the applicability of GMPLS to packet switching
   technologies. In particular, the formal definition of FAs and



Andersson, et al              Informational                    [Page 19]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


   hierarchy in [RFC4206] led to the definition of four regions for PSC
   (Packet Switching Capable) interfaces: PSC-1, PSC-2, PSC-3, and
   PSC-4.  This document describes the GMPLS topics specifically related
   to MPLS-TP.


4.1.1. In-Band and Out-Of-Band

   The terms in-band and out-of-band typically refer to the relationship
   of the management and control planes relative to the data plane.  The
   terms may be used to refer to the management plane independent of the
   control plane, or to both of them in concert.  There are multiple
   uses of the terms in-band and out-of-band, and they may relate to a
   channel, a path or a network.  Each of these can be used
   independently or in combination.  Briefly, the terms are typically
   used as follows:

     o In-band
       This term is used to refer to cases where management and/or
       control plane traffic is sent using or embedded in the same
       communication channel used to transport the associated data.  IP
       forwarded, MPLS packet, and Ethernet networks are all examples
       where control traffic is typically sent in-band with the data
       traffic.

     o Out-of-band, in-fiber
       This term is used to refer to cases where management and/or
       control plane traffic is sent using a different communication
       channel from the associated data traffic, and the
       control/management communication channel resides in the same
       fiber as the data traffic. Optical transport networks typically
       operate in an out-of-band in-fiber configuration.

     o Out-of-band, aligned topology
       This term is used to refer to the cases where management and/or
       control plane traffic is sent using a different communication
       channel from the associated data traffic, and the
       control/management communication must follow the same node-to-
       node path as the data traffic.  Such topologies are usually
       supported using a parallel fiber or other configuration where
       multiple data channels are available and one is (dynamically)
       selected as the control channel.

     o Out-of-band, independent topology
       This term is used to refer to the cases where management and/or
       control plane traffic is sent using a different communication
       channel from the associated data traffic, and the
       control/management communication may follow a path that is
       completely independent of the data traffic.  Such configurations
       don't preclude the use of in-fiber or aligned topology links, but
       alignment is not required.



Andersson, et al              Informational                    [Page 20]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


   In the context of MPLS-TP, requirement 4 can be met using out-of-band
   in-fiber or aligned topology types of control.  Requirement 5 can
   only be met by using Out-of-band, independent topology.  GMPLS
   routing and signaling can be used to support in-band and all of the
   out-of-band forms of control, see [RFC3945].


4.1.2. Addressing

   MPLS-TP uses the IPv4 and IPv6 address families to identify MPLS-TP
   nodes by default for network management and signaling purposes. The
   separation of the control and management planes from the data plane
   allows each plane to be independently addressable.  Each plane may
   use addresses that are not mutually reachable, e.g., it is likely
   that the data plane will not be able to reach an address from the
   management or control planes and vice versa.  Each plane may also use
   a different address family.  It is even possible to reuse addresses
   in each plane, but this is not recommended as it is likely lead to
   operational confusion.

   Unnumbered interfaces and links are also permitted and usage is at
   the discretion of the network operator.


4.2. Signaling

   In this section, we reference the existing MPLS and GMPLS signaling
   and routing mechanisms which can be used to support MPLS-TP LSPs.
   When controlling a packet-switched data-plane with GMPLS, the packets
   have an MPLS (see [RFC3032]) format, with the so-called "shim header"
   including a 20-bit label. Unlike MPLS, GMPLS uses the Generalized
   Label Object defined in [RFC3471] to signal such labels.

   In the current RSVP-TE signaling protocol, many objects make use of
   the Generalized Label.

   According to [RFC3471], a Generalized Label has the following format:
   "Generic MPLS labels and Frame Relay labels are encoded right
   justified aligned in 32 bits (4 octets)". This is primarily used in
   RESV messages to encode the downstream assigned label which shall be
   used on a link or FA of an LSP, using the LABEL object (class = 16).
   When the C-Type is set to 2, this LABEL object is carrying a
   Generalized Label encoded as defined in [RFC3471].

   When a node wishes to restrict the set of labels possibly assigned by
   its downstream neighbor (for the LSP), it can use the LABEL_SET
   object in PATH messages: the Label Type must be set to "Generalized
   Label" (value=2) and the Sub-Channels must be such Generalized
   Labels.

   The SUGGESTED_LABEL, RECOVERY_LABEL and UPSTREAM_LABEL objects



Andersson, et al              Informational                    [Page 21]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


   (respectively, class = 129, 34, 35; C-Type = 2) of the PATH messages
   have an identical format to that of the Generalized Label Object.

   Similarly, the RECORD_ROUTE object of the PATH message can record the
   labels which are used along the LSP, using the label subobject TLV
   (type = 3). In this subobject, the C-type of the recorded label is
   copied (value is therefore 2 in the packet case), and the Label
   Object is copied into the appropriate field.

   The Generalized Label Request Object must be used in PATH messages
   (C-Type = 4) instead of the simple Label Request without range such
   as defined in [RFC3209] (C-Type = 1). In this object the Switching
   Type is then set to PSC-1, PSC-2, PSC-3 or PSC-4 (respectively values
   1 to 4) according to the type of LSP being opened (see Section 3).

   The ACCEPTABLE_LABEL_SET object (Class= 130, C-Type = 1) of the
   PathErr message has an identical format to that of the LABEL_SET
   object of PATH messages.

   An MPLS-TP domain may be a switching point for an LSP that extends
   between client network islands. In this case, the MPLS- TP domain
   edge that connects to the respective client domain may have a static
   switching in the data plane done on the interface connecting to the
   respective client node. Alternatively, the LSP may be signaled
   between the client network and the MPLS-TP domain. There are two
   cases: (1) the client network connects via a GMPLS UNI to the MPLS-TP
   domain with knowledge of the remote MPLS-TP edge node and link that
   connects to the remote client node or there is some reachability
   information exchanged between the MPLS-TP domain and the client
   network via dynamic protocol, or (2) integrated model whereby the
   client network is an integrated part of the MPLS-TP domain, less
   likely option in some of the operation environments.


4.3. Routing

   The major extension in the context of routing PSC-LSPs within the
   GMPLS framework is the use of the various PSC-regions introduced by
   [RFC3945]. With the introduction of the hierarchy, formally specified
   in [RFC4206], it is necessary to use PSC-x as Switching Capability
   (SC) and therefore, the nesting process is modified with regards to
   the MPLS procedures. In particular, the policy chosen for announcing
   the SC associated with a Forwarding Adjacency has a significant
   impact. That is an MPLS-TP announced as an FA in a client network in
   an integrated model to support hierarchical MPLS-TP in MPLS-TP
   domain.








Andersson, et al              Informational                    [Page 22]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


4.3.1. ISIS-TE/OSPF-TE routing in support of MPLS-TP

   The major extension in the context of routing PSC-LSPs within the
   GMPLS framework is the use of the various PSC-regions introduced by
   [RFC3945]. In MPLS, no hierarchy being formally defined, no
   limitations were applied on nesting packet LSPs within other packet
   LSPs. With the introduction of the hierarchy, formally specified in
   [RFC4206], it is necessary to use PSC-x as Switching Capability (SC)
   and therefore, the nesting process is modified with regards to the
   MPLS procedures.  In particular, the policy chosen for announcing the
   SC associated with a Forwarding Adjacency has a significant impact.


4.3.1.1. ISIS-TE/OSPF-TE routing for MPLS-TP

   Per [RFC4203] for OSPF and [RFC5307] for IS-IS, the Interface
   Switching Capability Descriptor (ISCD) is a sub-TLV (of type 15) of
   the Link TLV, which is used to indicate the Switching Capability (or
   Capabilities) of an interface. Per [RFC4203], this TLV indicates
   encoding, MTU and bandwidth available at each priority level. The TLV
   also carries a Switching Capability field which indicates the
   switching hierarchy level:

       1: Packet-Switch Capable-1 (PSC-1)

       2: Packet-Switch Capable-2 (PSC-2)

       3: Packet-Switch Capable-3 (PSC-3)

       4: Packet-Switch Capable-4 (PSC-4)


4.3.1.2. Multiple Switching Capabilities

   To support interfaces that have more than one ISCD (see Section
   "Interface Switching Capability Descriptor" of [RFC4202]), the ISCD
   may occur more than once within a single routing protocol link
   description message. This allows a single packet TE-link or FA to be
   announced in multiple PSC regions, both as a PSC-1 and PSC-2 for
   instance.

   The "regular" packet TE-links (non-FAs) can also be configured to be
   used by one or several of the regions. A TE-link set to a single PSC-
   x region will be reserved for establishing PSC-x LSPs, whereas one
   set to multiple PSC-x, PSC-y and PSC-z regions will be shared by PSC
   LSPs of these switching types.

   When a TE-link or an FA is shared among regions, it is important for
   the nodes receiving traffic over this link/FA to have a single label-
   space shared across the regions. This is critical for the node to
   guarantee it will receive packets with different labels in different



Andersson, et al              Informational                    [Page 23]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


   packet regions, even when they arrive on the same interface.

   The fact that the label-space must be cross-region is independent
   from the fact that label-spaces may be per- interface, per-tunnel,
   per-upstream neighbor or per-platform.


4.3.1.3. Hierarchy

   [RFC4206] defines network regions based on switching capabilities.
   The hierarchy of regions is novel in GMPLS and this section intends
   to clarify the hierarchy for PSC nodes, and the use of the various
   PSC-regions.

   According to [RFC4206], there are four PSC regions which are
   hierarchically ordered in the following way: PSC-1 < PSC-2 < PSC-3 <
   PSC-4, that is PSC-1 is the smallest SC and PSC-4 is the largest SC.
   Let us consider two consecutive nodes of an LSP, such that the first
   node's SC is PSC-x and the second node's is PSC-y. The first node is
   said to be at the border of two packet regions, with regard to that
   LSP, if PSC-y is larger than PSC-x (i.e.: x < y ). Similarly, the
   second node is said to be at the border of two packet regions, with
   regard to that LSP, if x > y.

   According to [RFC4202], "a unidirectional LSP must have the same sets
   of SCs at both ends". Additionally, such an LSP will only be routed
   over TE-links and/or FAs which have (at least) that SC (since
   otherwise, the region crossing would trigger the setup of an FA-LSP,
   as described in [RFC4206]). This imposes that a PSC-x LSP be setup
   using only TE-links and/or FAs which include at least PSC-x. In the
   packet-switching context, this means that a PSC-x cannot directly use
   links/FAs which do not have a PSC-x set in their ISCD's Switching
   Capability Field. Therefore, if one wants to establish a PSC-x LSP
   across a PSC-y region, an FA- LSP must either be available or set-up.
   It may be announced in the PSC-x region routing instance (which may
   be the same as the PSC-y region routing instance) as a PSC-x TE-link.
   The SC associated with an FA is announced using the routing
   protocol's Interface Switching Capability Descriptor (ISCD) (see
   Section 3.1). For instance, if a PSC-1 LSP has to be setup across a
   PSC- 3 region, the region border node will first have to establish a
   PSC-3 LSP in which the PSC-1 LSP will be nested. The PSC-3 LSP may
   then be used to announce an FA in the PSC-1 routing protocol.

   In the four packet regions, the switching principles are the same,
   which means that a PSC node is most likely to have in fact all four
   PSC-1, PSC-2, PSC-3 and PSC-4 switching types. When using a packet
   LSP to nest other LSPs, the policy for deciding which PSCs to
   announce for the packet FAs and TE-links, and the policy for cross-
   region LSP triggering determine the type of interactions between the
   PSC-regions. This means there are in fact multiple ways of using the
   PSC regions.



Andersson, et al              Informational                    [Page 24]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


4.3.2. TE link bundling

4.4. OAM, MEP (hierarchy) configuration & control

   Current MPLS LSP and PW OAM capabilities are not suitable for
   transport applications. Hence IETF has started work to define a

   comprehensive set of MPLS-TP OAM functions. Specific OAM requirements
   for MPLS-TP are documented in [draft-ietf-mpls-tp- oam-requirements].
   In addition to the actual OAM requirements, it is also required that
   the control plane is able to configure and control OAM entities. This
   requirement is not yet addressed by the foreseen MPLS-TP control
   protocols (i.e, GMPLS for LSPs and T-LDP for PWs).

   To emphasize the importance of OAM establishment via the control
   plane it must be noted that for proper OAM; OAM messages and the
   actual normal traffic must be congruent: taking the same path and
   relying on the same forwarding decisions at intermediate nodes.
   Hence, it is desirable that OAM is setup together with the
   establishment of the data path (i.e., with the same signaling). This
   way OAM setup is bound to connection establishment signaling,
   avoiding two separate management/configuration steps (connection
   setup followed by OAM configuration) which would increases delay,
   processing and more importantly may be prune to misconfiguration
   errors.

   It must be noted that although the control plane is used to establish
   OAM entities, subsequently OAM is executed independently from the
   control plane. That is, OAM mechanisms are responsible for monitoring
   and initiating recovery actions (driving switches between primary and
   backup paths).

   GMPLS RSVP-TE based OAM configuration and control should be general
   to be applicable to a wide range of data plane technologies and OAM
   solution and not be limited to the MPLS technology and MPLS-TP OAM.
   On the other hand, GMPLS based OAM configuration must satisfy all
   MPLS-TP requirements.

   PW OAM establishment is FFS.


4.5. Traffic engineering and constraint-based path computation

   Same approach as MPLS.  Specific algorithms out of scope.  Similar to
   MPLS, but adds bidirectional and recovery path computation.









Andersson, et al              Informational                    [Page 25]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


4.5.1. Relation to PCE

   Path Computation Element (PCE) may be used for path computation of a
   GMPLS LSP across domains and in a single domain. A Network Management
   System (NMS) may be used to trigger path computation for a GMPLS LSP
   and configure the cross-connects along the computed path.
   Alternatively, the path computation may be triggered by a network
   node via PCE Communication Protocol (PCECP) and the LSP signaled
   using GMPLS.


4.6. Applicability

4.7. Recovery

4.7.1. E2E, segment

   GMPLS defines recovery signaling for P2P LSPs in [RFC4872], RSVP-TE
   extensions in support for end-to-end GMPLS recovery, and [RFC4873],
   GMPLS segment recovery.  GMPLS segment recovery provides a superset
   of the function in end-to-end recovery.  The former can be viewed as
   a special case of segment recovery where there is a single recovery
   domain whose borders coincide with the ingress and egress of the LSP.

   All five of the protection types defined for recovery are supported
   in MPLS-TP.
     - 1+1 bidirectional protection for P2P LSPs
     - 1+1 unidirectional protection for P2MP LSPs
     - 1:n (including 1:1) protection with or without extra traffic
     - Rerouting without extra traffic (sometimes known as soft
       rerouting), including shared mesh restoration
     -  Full LSP rerouting

   Recovery MUST be signaled using the mechanism defined in [RFC4872]
   and [RFC4873].  The use of Notify messages to trigger protection
   switching and recovery is not required in MPLS-TP as this function is
   expected to be supported via OAM.  However, it's use is not
   precluded.

   The restoration priority for an MPLS-TP LSP is taken from the setup
   priority field in the SESSION_ATTRIBUTE object.

   The preemption priority for an MPLS-TP LSP is taken from the holding
   priority field in the SESSION_ATTRIBUTE object.










Andersson, et al              Informational                    [Page 26]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


4.7.2. P2P, P2MP

4.7.3. Recovery Triggers

   The GMPLS control plane allows for management plane recovery triggers
   and directly supports control plane recovery triggers.  Support for
   control plane recovery triggers is defined in [RFC4872] which refers
   to the triggers as "Recovery Commands".  These commands can be used
   with both end-to-end and segment recovery, but are always controlled
   on an end-to-end basis.  The recovery triggers/commands defined in
   [RFC4872] are:
      a. Lockout of recovery LSP
      b. Lockout of normal traffic
      c. Forced switch for normal traffic
      d. Requested switch for normal traffic
      e. Requested switch for recovery LSP

   Note that control plane triggers are typically invoked in response to
   a management plane request at the ingress.


4.8. Diffserv object usage in GMPLS (E-LSPs, L-LSPs)

4.9. Management plane support

   In MPLS-TP networks, like in any other technology, a control plane
   can be used to speed up and simplify provisioning and recovery
   actions in case of failures.  The control plane needs, as does the
   data plane, to interact with the management plane in order to set-
   up/delete/modify LSPs and it also needs to be managed as any other
   network components by the Management Plane.

   [Editor's note: need to describe how the last sentence is supported
   via standard MIBs.]


4.9.1. Management Plane / Control Plane Ownership Transfer

   In networks where both control plane and management plane are
   provided, LSP provisioning can be bone either by control plane or
   management plane.  As mentioned in the requirements section above, it
   must be possible to transfer, or handover, management plane created
   circuit under the control plane domain and vice-versa. [RFC5493]
   defines the specific requirements for an LSP ownership handover
   procedure. It must be possible for the control plane to notify, in
   reliable manner, the management plane about the status/result of
   either synchronous or asynchronous, with respect to the management
   plane, operation performed.  Moreover it must be possible to monitor,
   via query or spontaneous notify, the status of the control plane
   object such as example the TE Link status, the available resources,
   etc. A mechanism must be made available by the control plane to the



Andersson, et al              Informational                    [Page 27]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


   management plane to log control plane LSP related operation, that is,
   it must be possible from the NMS to have a clear view of the life,
   (traffic hit, action performed, signaling etc.) of a given LSP. The
   LSP handover procedure for MPLS-TP LSPs is supported via [PC-SCP].


4.10. CP reference points (E-NNI, I-NNI, UNI)

4.11. MPLS to MPLS-TP interworking

   - Leverage current MPLS and GMPLS development

   - Backward compatibility


5. Pseudo Wires

   [Editor's note: This section is preliminary and will be
   edited/replaced in future versions.  There could be some differences
   (e.g., OAM interaction), and this section will focus on those
   differences.]

   MPLS Pseudo Wires, as defined in [RFC3985], provide for emulated
   services over an MPLS Packet Switched Network (PSN). There are
   several types of pseudowires: (1) Ethernet PWs providing for Ethernet
   port or Ethernet VLAN over MPLS [RFC4448], (2) HDLC/PPP Pseudowire
   providing for HDLC/PPP leased line transport of MPLS[RFC4618], (3)
   ATM PWs [RFC4816], (4) Frame Relay PWs [RFC4619], and (5) circulation
   Emulation PWs [RFC4553].

   Today's transport networks based on PDH, WDM, or SONET/SDH provide
   transport for PDH or SONET (e.g., ATM over SONET or Packet PPP over
   SONET) client signals with no payload awareness.  Implementing PW
   capability allows the use of an existing technology to substitute the
   TDM transport with Packet-aware transport, using well-defined
   pseudowire encapsulation methods for carrying various packet services
   over MPLS, and providing for potentially better bandwidth
   utilization.

   There are two types of pseudowires: (1) Single-Segment pseudowires
   (SS-PW), and (2) Multi-segment pseudowires (MS-PW).  An MPLS-TP
   domain may transport a PW with endpoints within a client network
   transparently. Alternatively, an MPLS-TP edge node may be the
   Terminating PE (T-PE) for a PW, performing adaptation from the native
   attachment circuit technology (e.g.  Ethernet 802.1q) to an MPLS PW
   for transport over an MPLS-TP domain, with a GMPLS LSP or a hierarchy
   of LSPs transporting the PW between the T-PEs. In this way, the PW is
   analogous to a transport channel in a TDM network and the LSP is
   equivalent to a container of multiple non-concatenated channels,
   albeit they are packet containers. The MPLS-TP domain may also
   contain Switching PEs (S-PEs) for a multi-segment PW whereby the T-



Andersson, et al              Informational                    [Page 28]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


   PEs may be at the edge of the MPLS-TP domain or in a client network.
   In this latter case, a T-PE in a client network is a T-PE performing
   the adaptation of the native service to MPLS and the MPLS-TP domain
   performs Pseudo-wire switching.

   SS-PW signaling control plane is based on LDP with specific
   procedures defined in [RFC4447]. [Segmented-PW] and [MS-PW] allow for
   static switching of multi-segment pseudowires in data and control
   plane and for dynamic routing and placement of an MS-PW whereby
   signaling is still based on Targeted LDP (T-LDP).  The MPLS-TP domain
   shall use the same PW signaling protocols and procedures for placing
   SS-PWs and MS-PWs. This will leverage existing technology as well as
   facilitate interoperability with client networks with native
   attachment circuits or PW segment that is switched across the MPLS-TP
   domain.

   The same control protocol and procedures are reused as much as
   possible. However, when using PWs in MPLS-TP, a set of new
   requirements are defined which may require extensions of the existing
   control mechanisms. This section identifies areas where extensions
   are needed based on the PW Control Plane related requirements
   documented in [draft-ietf-mpls-tp-requirements].

   The baseline requirement for extensions to support transport
   applications is that any new mechanisms and capabilities must be able
   to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3
   [RFC3985] control and data planes where appropriate. Hence,
   extensions of the PW Control Plane must be in-line with the
   procedures defined in [RFC4447].

   For MPLS-TP, it is required that the data and control planes are both
   logically and physically separated. That is, the PW Control Plane
   must be able to operate out-of-band (OOB). This ensures that in the
   case of control plane failures the data plane is not affected and can
   continue to operate normally. This was not a design requirement for
   the current PW Control Plane. However, due to the PW concept, i.e.,
   PWs are connecting logical entities ('forwarders'), and the operation
   of the PW control protocol, i.e., only edge PE nodes (T-PE, S-PE)
   take part in the signaling exchanges: moving T-LDP out-of-band seems
   to be, theoretically, a straightforward exercise.

   More precisely, if IP addressing is used in the MPLS-TP control plane
   then T-LDP addressing can be maintained, although all addresses will
   refer to control plane entities. Both, the PWid FEC and Generalized
   PWid FEC Elements can possibly be used in an OOB case as well
   (Detailed evaluation is FFS). The PW Label allocation and exchange
   mechanisms can be possibly reused unchanged (Detailed evaluation is
   FFS). Binding a PW to an LSP, or PW segments to LSPs can be left to
   networks elements acting as T-PEs and S-PEs or a control plane entity
   that may be the same one signaling the PW. If the control plane is
   physically separated from the forwarder, the control plane must be



Andersson, et al              Informational                    [Page 29]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


   able to program the forwarders with necessary information.

   For transport applications, it is mandatory that bidirectional
   traffic is following congruent paths. Today, each direction of a PW
   or a PW segment is bound to a unidirectional LSP that extends between
   two T-PEs, S-PEs, or a T-PE and an S-PE. The unidirectional LSPs in
   both directions are not required to following congruent paths, and
   therefore both directions of a PW may not follow congruent paths. The
   only requirement today is that a PW or a PW segment shares the same
   T-PEs in both directions, and same S-PEs in both directions. This
   poses a new requirement on the PW Control Plane, namely to ensure
   that both ends map the PW to the same transport path. When a
   bidirectional LSP is selected on one end to transport the PW, a
   mechanism is needed that signals to the remote end which LSP has been
   selected locally to transport the PW. This likely can be accomplished
   by adding a new TLV to PW signaling. This coincides with the gap
   identified for OOB support: a new mechanism may be needed to
   explicitly bind PWs to the supporting transport LSP.

   Alternatively, two unidirectional LSPs may be used to support the PW.
   However, to meet the congruency requirement, the LSPs must be placed
   so that they are forced to follow the same path (switches and links).
   This maybe accomplished by placing one unidirectional TE-LSP in one
   direction at one endpoint, and forcing the other endpoint to setup a
   TE-LSP with an ERO that has the nodes/links in the reverse order from
   the RRO seen in the path message of the LSP in the reverse direction.
   In this case, when one endpoint selects an LSP to bind the PW to, it
   must identify to the remote end which LSP to bind the other direction
   of the PW to.

   Transport applications require resource guarantees. In the case of
   transport LSPs, resource reservation mechanisms are provided via
   RSVP-TE and the use of DiffServ. If multiple PWs are

   multiplexed into the same transport LSP resources, contention may
   occur. However, local policy at PEs may ensure proper resource
   sharing among PWs mapped into a resource guaranteed LSP. On the other
   hand, it is limited if any guarantees can be provided to PWs if the
   LSPs used to support MPLS-TP PWs do not support resource guarantees.

   The PW control plane must be able to establish and configure all of
   the available features manageable for the PW, including protection
   and OAM entities and mechanisms. There is ongoing work on PW
   protection and MPLS-TP OAM.

   To summarize, the main areas identified for potential PW Control
   Plane extensions to support MPLS-TP are the following.







Andersson, et al              Informational                    [Page 30]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


     o Move PW Control Plane out-of-band

     o Explicit control of PW to LSP binding

     o PW QoS and congestion control

     o PW protection

     o PW OAM configuration and control


5.1. General reuse of existing PW control plane mechanisms

5.2. Signaling

5.3. Recovery (Redundancy)

6. Security Considerations

   [Editor's note:  This section is preliminary and will be
   edited/replaced in future versions.]

   This document is a framework document and does not describe bits on
   the wire and have a very small impact on MPLS/GMPLS security issues.
   However it gives guidelines for future extension to existing MPLS and
   GMPLS protocols, it is understood that the documents that specify
   these extensions will address the security issues that relates to the
   extensions.

   The MPLS/GMPLS security framework [MPLS-SEC] is applicable to both
   this document and the documents that will be written as a result of
   the output of this document.


7. IANA Considerations

   There are no new IANA considerations introduced by this document.


8. Acknowledgments

   The authors would like to acknowledge the contributions of Yannick
   Brehon, Diego Caviglia, Nic Neate, and Dave Mcdysan to this work.











Andersson, et al              Informational                    [Page 31]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


9. References

9.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels," RFC 2119.

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

   [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
             Farinacci, D., Li, T., and Conta, A. "MPLS Label
             Stack Encoding", RFC 3032, January 2001.

   [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
             V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
             LSP Tunnels", RFC 3209, December 2001.

   [RFC3471] Berger, L., "Generalized Multi-Protocol Label
             Switching (GMPLS) Signaling Functional Description",
             RFC 3471, January 2003.

   [RFC3473] Berger, L. Ed., "Generalized Multi-Protocol Label
             Switching (GMPLS) Signaling Resource ReserVation
             Protocol-Traffic Engineering (RSVP-TE) Extensions",
             January 2003.

   [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
             Support of Generalized Multi-Protocol Label
             Switching(GMPLS)", RFC 4202, October 2005.

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

   [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
             (LSP) Hierarchy with Generalized Multi-Protocol Label
             Switching (GMPLS) Traffic Engineering (TE)", RFC
             4206, October 2005.

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

   [RFC4448] Martini, L., Ed., "Encapsulation Methods for
             Transport Ethernet over MPLS Network", RFC 4448,
             April 2006.






Andersson, et al              Informational                    [Page 32]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


   [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] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A.,
             "GMPLS Segment Recovery", RFC 4873, May 2007.

   [RFC4929] Andersson, L. and A. Farrel, "Change Process for
             Multiprotocol Label Switching (MPLS) and Generalized
             MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC
             4929, June 2007.

   [RFC5307] Kompella, K. and Rekhter, Y., "IS-IS Extensions in
             Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 5307, October 2008.

   [RFC5316] Chen, M., Zhang, R., and Duan, X., "ISIS Extensions
             in Support of Inter-Autonomous System (AS) MPLS and
             GMPLS Traffic Engineering", RFC 5392, December 2008.

   [RFC5392] Chen, M., Zhang, R., and Duan, X., "OSPF Extensions
             in Support of Inter-Autonomous System (AS) MPLS and
             GMPLS Traffic Engineering", RFC 5392, January 2009.

   [TP-FWK] Bocci, M., Ed., Et al, "A Framework for MPLS in
            Transport Networks", work in Progress,
            draft-ietf-mpls-tp-framework-02, July 2009.

   [TP-OAM] Busi, I., Ed., Niven-Jenkins, B., Ed., "MPLS-TP OAM
            Framework and Overview", work in Progress,
            draft-busi-mpls-tp-oam-framework-02, March 2009.

   [TP-OAM-REQ] Vigoureux, M., Ward, D, and Betts, M.,
                "Requirements for OAM in MPLS Transport
                Networks",
                draft-ietf-mpls-tp-oam-requirements-02, June
                2009.

   [TP-SURVIVE] Sprecher, N., et al., "Multiprotocol Label
                Switching Transport Profile Survivability
                Framework", work in Progress,
                draft-sprecher-mpls-tp-survive-fwk-01.txt,
                February 2009.

   [TP-REQ] Niven-Jenkins, B., Et al, "MPLS-TP Requirements",
            work in Progress, draft-ietf-mpls-tp-requirements-09,
            June 2009.






Andersson, et al              Informational                    [Page 33]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


9.2. Informative References

   [BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and
              G. Swallow, "BFD For MPLS LSPs",
              draft-ietf-bfd-mpls-07 (work in progress), June
              2008.

   [ITU.G8080.2006] International Telecommunications Union,
                    "Architecture for the automatically switched
                    optical network (ASON)", ITU- T Recommendation
                    G.8080, June 2006.

   [ITU.G8080.2008] International Telecommunications Union,
                    "Architecture for the automatically switched
                    optical network (ASON) Amendment 1", ITU-T
                    Recommendation G.8080 Amendment 1, March 2008.

   [MPLS-SEC] Fang, L., et al, "Security Framework for MPLS and
              GMPLS Networks", work in Progress,
              draft-ietf-mpls-mpls-and-gmpls-security-framework-05.txt,
              March 2009.

   [PC-SCP] Caviglia, D, et al, "RSVP-TE Signaling Extension For
            The Conversion Between Permanent Connections And Soft
            Permanent Connections In A GMPLS Enabled Transport
            Network.", draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt,
            work in progress, October 2008.


   [Segmented-PW] Martini, L., Nadeau, T., and Duckett M., "
                  Segmented Pseaudowire", work in Progress,
                  draft-ietf-pwe3-segmented-pw-12.txt, June 2009.

   [RFC3945] Mannie, E., "Generalized Multi-Protocol Label
             Switching (GMPLS) Architecture", RFC 3945, October
             2004.

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

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

   [RFC4139] Papadimitriou, D., et al, "Requirements for
             Generalized MPLS (GMPLS) Signaling Usage and
             Extensions for Automatically Switched Optical
             Network (ASON)", RFC4139, July 2005.






Andersson, et al              Informational                    [Page 34]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


   [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter,
             Y., "Generalized Multi-Protocol Label Switching
             (GMPLS) User-Network Interface (UNI): Resource
             ReserVation Protocol-Traffic Engineering (RSVP-TE)
             Support for the Overlay Model", RFC 4206, October
             2005.

   [RFC4258] Brungard, D., et al, "Requirements for Generalized
             Multi-Protocol Label Switching (GMPLS) Routing for
             the Automatically Switched Optical Network (ASON)",
             RFC4258, November 2005.

   [RFC4379] Kompella, K. and G. Swallow, "Detecting
             Multi-Protocol Label Switched (MPLS) Data Plane
             Failures", RFC 4379, February 2006.

   [RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection
             and Restoration) Terminology for Generalized
             Multi-Protocol Label Switching (GMPLS)", RFC4427,
             March 2006.

   [RFC4553] Vainshtein, A., Ed., and Stein, YJ., Ed.,"Structure-
             Agnostic Time Division Multiplexing (TDM) over Packet
             (SAToP)", RFC 4553, June 2006.

   [RFC4618] Martini, L., Rosen, E., Heron, G., and Malis, A.,
             "Encapsulation Methods for Transport of PPP/High-
             Level Data Link Control (HDLC) over MPLS Networks",
             RFC 4618, September 2006.

   [RFC4619] Martini, L., Ed., Kawa, C., Ed., and Malis, A., Ed.,
             "Encapsulation Methods for Transport of Frame Relay
             over Multiprotocol Label Switching (MPLS) Networks",
             September 2006.

   [RFC4816] Malis, A., Martini, L., Brayley, J., and Walsh, T.,
             "Pseudowire Emulation Edge-to-Edge (PWE3)
             Asynchronous Transfer Mode (ATM) Transparent Cell
             Transport Service", RFC 4816, February 2007.

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

   [RFC5493] Caviglia, D., et al, "Requirements for the
             Conversion between Permanent Connections and
             Switched Connections in a Generalized Multiprotocol
             Label Switching (GMPLS) Network", RFC 5493, April
             2009.





Andersson, et al              Informational                    [Page 35]


Internet-Draft draft-abfb-mpls-tp-control-plane-framework-01.txt  July 13, 2009


   [MS-PW]   Bocci, M., and Bryant, B., "An Architecture for
             Multi-Segment Pseudowire Emulation Edge-to-Edge",
             work in Progress, draft-ietf-pwe3-ms-pw-arch-06.txt,
             February 2009.

   [VCCV-BFD] Nadeau, T. and C. Pignataro, "Bidirectional
              Forwarding Detection (BFD) for the Pseudowire
              Virtual Circuit Connectivity Verification (VCCV)",
              draft-ietf-pwe3-vccv-bfd-06 (work in progress),
              July 2009.


10. Authors' Addresses

   Loa Andersson (editor)
   Redback Networks
   Phone: +46 8 632 77 14
   Email: loa@pi.nu

   Lou Berger (editor)
   LabN Consulting, L.L.C.
   Phone: +1-301-468-9228
   Email: lberger@labn.net

   Luyuan Fang (editor)
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough, MA 01719
   USA
   Email: lufang@cisco.com

   Nabil Bitar (editor)
   Verizon,
   40 Sylvan Rd.,
   Waltham, MA 02451
   Email:   nabil.n.bitar@verizon.com

   Attila Takacs
   Ericsson
   1. Laborc u.
   Budapest, HUNGARY 1037
   Email:   attila.takacs@ericsson.com

   Martin Vigoureux
   Alcatel-Lucent
   Email:   martin.vigoureux@alcatel-lucent.fr








Andersson, et al              Informational                    [Page 36]

Generated on: Mon Jul 13 13:10:02 EDT 2009


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