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

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

     Network Working Group                            Loa Andersson, Ed.
     Internet Draft                                             Acreo AB
     Intended status: Informational                      Lou Berger, Ed.
     Expires: August 22, 2008                                       LabN
                                                        Luyuan Fang, Ed.
                                                                   Cisco
                                                        Nabil Bitar, Ed.
                                                                 Verizon

                                                       February 22, 2009


                          MPLS-TP Control Plane Framework
                 draft-abfb-mpls-tp-control-plane-framework-00.txt


     Status of this Memo

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

        This memo provides information for the Internet community.  It
        does not specify an Internet standard of any kind.  Distribution
        of this memo is unlimited.

        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/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 August 22, 2009.





     Andersson, et al.      Expires August 22, 2009             [Page 1]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


        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
        (http://trustee.ietf.org/license-info) in effect on the date of
        publication of this document. Please review these documents
        carefully, as they describe your rights and restrictions with
        respect to this document.

     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,
          manual configuration, the triggering of LSP setup, label
          allocation schemes, and hybrid services are out of scope of
          this document.


     Table of Contents

        1. Introduction...............................................3
           1.1. Scope.................................................3
           1.2. Basic Approach........................................4
           1.3. Reference Model.......................................5
        2. Control plane requirements.................................7
           2.1. Primary Requirements..................................8
           2.2. MPLS-TP Framework Derived Requirements...............12
           2.3. OAM Framework Derived Requirements...................13
           2.4. Security Requirements................................13
        3. TE LSPs...................................................14
           3.1. General reuse of existing GMPLS control plane
           mechanisms................................................14
              3.1.1. "In-band" and "out of band".....................14
              3.1.2. Addressing......................................15
           3.2. Signaling............................................16


     Andersson, et al.     Expires August 22, 2009             [Page 2]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


           3.3. Routing..............................................17
              3.3.1. ISIS-TE/OSPF-TE routing in support of MPLS-TP...17
                 3.3.1.1. ISIS-TE/OSPF-TE routing for MPLS-TP........18
                 3.3.1.2. Multiple Switching Capabilities............18
                 3.3.1.3. Hierarchy..................................18
              3.3.2. TE link bundling................................19
           3.4. OAM, MEP (hierarchy) configuration & control.........19
           3.5. Traffic engineering and constraint-based path
           computation...............................................20
              3.5.1. Relation to PCE.................................20
           3.6. Applicability........................................21
           3.7. Recovery.............................................21
              3.7.1. E2E, segment....................................21
              3.7.2. P2P, P2MP.......................................21
           3.8. Diffserv object usage in GMPLS (E-LSPs, L-LSPs)......21
           3.9. Management plane support.............................21
           3.10. CP reference points (E-NNI, I-NNI, UNI).............21
           3.11. MPLS to MPLS-TP interworking........................21
        4. Pseudo Wires..............................................21
           4.1. General reuse of existing PW control plane mechanisms24
           4.2. Signaling............................................24
           4.3. Recovery (Redundancy)................................24
        5. Security Considerations...................................24
        6. IANA Considerations.......................................25
        7. Acknowledgments...........................................25
        8. References................................................25
            Normative References.....................................25
           8.1.......................................................25
           8.2. Informative References...............................27
        9. Authors' Addresses........................................28

     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. 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.



     Andersson, et al.     Expires August 22, 2009             [Page 3]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


        In particular, Sections 2.4 and 2.8 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 MPLS-TP LSPs. The PWs are used to
        carry client signal other than IP and MPLS. The relationship
        between pseudo wires carried 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 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 scopes 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 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.2. 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.
        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.



     Andersson, et al.     Expires August 22, 2009             [Page 4]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


        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 (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 present 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].
        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].
        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.

     1.3. 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 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




     Andersson, et al.     Expires August 22, 2009             [Page 5]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


        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.

           |< ---- 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

        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.     Expires August 22, 2009             [Page 6]


     Internet-Draft    MPLS-TP Control Plane Framework    February 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.

     2. Control plane requirements

        The requirements for the MPLS-TP control plane are derived from
        the MPLS-TP requirements and framework documents, specifically


     Andersson, et al.     Expires August 22, 2009             [Page 7]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


        [TP-REQ], [TP-FWK], [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 [TP-REQ]:

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

         2.  The MPLS-TP control plane must support a connection-
             oriented packet switching model with traffic engineering
             capabilities.

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

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

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

         6.  A control plane must be defined for MPLS-TP, but its use
             is a network operator's choice.

         7.  A failure of the control plane must not interfere with the
             deliver of service or recovery of established transport
             paths.

         8.  The MPLS-TP control plane must work across domains.

         9.  The MPLS-TP control plane must not dictate any particular
             physical or logical topology, and must include support
             ring topologies.

         10. The MPLS-TP control plane must not provision transport
             paths which contain forwarding loops.

         11. The MPLS-TP control plane must support multiple client
             layers.




     Andersson, et al.     Expires August 22, 2009             [Page 8]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


         12. The MPLS-TP control plane must be able to operate
             independently over server layer networks.

         13. The MPLS-TP control plane must allow a server layer to
             hide addressing and topology information form a client
             layer.

         14. The MPLS-TP control plane must allow for the
             identification of a transport path on each link and at the
             destination.

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

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

         17. Intermediate nodes must be aware about the pairing
             relationship of the forward and the backward directions
             belonging to the same bidirectional transport path.

         18. The MPLS-TP control plane may support transport paths with
             asymmetric bandwidth requirements.

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

         20. The MPLS-TP control plane should support bandwidth
             modification.

         21. The MPLS-TP control plane must support scale gracefully to
             support a large number of transport paths, nodes and
             links.

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

         23. 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.

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





     Andersson, et al.     Expires August 22, 2009             [Page 9]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


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

         25. The MPLS-TP control plane mechanisms used for P2P and P2MP
             recovery should identical.

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

         27. 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 100% of the traffic on the protected
                  path.

               c. Objectives SHOULD be configurable per transport path,
                  and SHOULD include bandwidth and QoS.

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

         29. The MPLS-TP control plane must operate in synergy with
             (including coordination of timing) the recovery mechanisms
             present in any underlying server transport network (for
             example, Ethernet, SDH, OTN, WDM) to avoid race conditions
             between the layers.

         30. 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).

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

         32. The MPLS-TP control plane must support 1+1 protection for
             P2P LSPs.




     Andersson, et al.     Expires August 22, 2009             [Page 10]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


         33. The MPLS-TP control plane must support 1+1 unidirectional
             protection for P2MP LSPs.

         34. The MPLS-TP control plane must support 1:n protection for
             P2P LSPs.

         35. The MPLS-TP control plane must support 1:n unidirectional
             protection for P2MP LSPs.

         36. The MPLS-TP control plane must support the sharing of
             resources between a restoration LSP and the LSP being
             replaced.

         37. The MPLS-TP control plane must support restoration
             priority.

         38. The MPLS-TP control plane must support preemption
             priority.

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

         40. The MPLS-TP control plane must support the definition of
             shared protection groups.

         41. The MPLS-TP control plane must support sharing of
             protection resources.

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

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

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

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

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

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

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



     Andersson, et al.     Expires August 22, 2009             [Page 11]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


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

         50. The MPLS-TP control plane must support protection state
             coordination (PSC).

         51. The MPLS-TP control plane must support transport services
             that provide differentiated services and different traffic
             types with traffic class separation associated with
             different traffic.

         52. 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 guaranteed.

         53. 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]:

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

         55. 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.

         56. The MPLS-TP control plane must support both E-LSP and L-
             LSP.

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

         58. 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.

         59. The MPLS-TP control plane is based on the GMPLS control
             plane for MPLS-TP LSPs. More specifically, GMPLS RSVP-TE
             is used for LSP signaling, and GMPLS OSPF-TE and ISIS-TE
             are used for routing.




     Andersson, et al.     Expires August 22, 2009             [Page 12]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


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

         61. The MPLS-TP control plane must be capable of performing
             fast restoration in the event of network failures.

         62. 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.

         63. 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]:

         64. The MPLS-TP control plane must allow for the use of OAM
             proactive Continuity Check (CC) and Connectivity
             Verification (CV) function.

               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.

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

         66. 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.



     Andersson, et al.     Expires August 22, 2009             [Page 13]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


     3. TE LSPs

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

     3.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 both
        multi-switching environments 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 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
        Packet technologies. In particular, it will present how to
        signal packet- LSPs and how the four PSC-i regions could be
        used.

     3.1.1.  "In-band" and "out of band"

        For an MPLS-TP network, "in-band" is defined such that the
        control plane runs over a network set up by that same control
        plane.

        For an MPLS-TP network, "out of band" is defined such that the
        control plane runs over a network that has been established by
        other means than the control plane itself.

        The term out-of-band is typically refers to the relationship of
        the management and control planes relative to the data plane.
        It 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 term out-of-band, and it 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


     Andersson, et al.     Expires August 22, 2009             [Page 14]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


          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.


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

     3.1.2. Addressing

        MPLS-TP uses the IPv4 and IPv6 address families to identify
        MPLS-TP nodes by default for network management and signaling
        purpose. 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,


     Andersson, et al.     Expires August 22, 2009             [Page 15]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


        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.

     3.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). ATM labels are
        encoded with the VPI right justified in bits 0-15 and the VCI
        right justified in bits 16-31". 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 neighbour (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
        (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


     Andersson, et al.     Expires August 22, 2009             [Page 16]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


        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.

     3.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.

     3.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.


     Andersson, et al.     Expires August 22, 2009             [Page 17]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


     3.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)

     3.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 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.

     3.3.1.3. Hierarchy

        [RFC4206] defines network regions based on switching
        capabilities. The hierarchy of regions is novel in GMPLS and



     Andersson, et al.     Expires August 22, 2009             [Page 18]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


        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.

     3.3.2. TE link bundling

     3.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


     Andersson, et al.     Expires August 22, 2009             [Page 19]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


        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.

     3.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.

     3.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.


     Andersson, et al.     Expires August 22, 2009             [Page 20]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009



     3.6. Applicability

     3.7. Recovery

     3.7.1. E2E, segment

     3.7.2. P2P, P2MP

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

     3.9. Management plane support

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

     3.11. MPLS to MPLS-TP interworking

        - Leverage current MPLS and GMPLS development

        - Backward compatibility


     4. Pseudo Wires

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

        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 HDLCP/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



     Andersson, et al.     Expires August 22, 2009             [Page 21]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


        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-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



     Andersson, et al.     Expires August 22, 2009             [Page 22]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


        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 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


     Andersson, et al.     Expires August 22, 2009             [Page 23]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


        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.

          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

     4.1. General reuse of existing PW control plane mechanisms

     4.2. Signaling

     4.3. Recovery (Redundancy)

     5. 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.

        It is also understood that that 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.




     Andersson, et al.     Expires August 22, 2009             [Page 24]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


     6. IANA Considerations

     7. Acknowledgments

        Funding for the RFC Editor function is provided by the IETF
        Administrative Support Activity (IASA).

        The authors would like to acknowledge the contributions of
        Yannick Brehon to this work.

     8. References

     8.1. Normative References

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

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






     Andersson, et al.     Expires August 22, 2009             [Page 25]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


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

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

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

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


     Andersson, et al.     Expires August 22, 2009             [Page 26]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009


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



     8.2. Informative References

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

        [Segmented-PW] Martini, L., Nadeau, T., and Duckett M., "
                  Segmented Pseaudowire", work in Progress, draft-ietf-
                  pwe3-segmented-pw-11.txt, February 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-05.txt,
                  September 2008.

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

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

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

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





     Andersson, et al.     Expires August 22, 2009             [Page 27]


     Internet-Draft    MPLS-TP Control Plane Framework    February 2009



     9. 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.     Expires August 22, 2009             [Page 28]


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