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

Versions: 00 01 02

Internet Engineering Task Force                            R. Martinotti
Internet-Draft                                               D. Caviglia
Intended status: Informational                                  Ericsson
Expires: December 9, 2011                                    N. Sprecher
                                                  Nokia Siemens Networks
                                                         A. D'Alessandro
                                                              A. Capello
                                                          Telecom Italia
                                                              Y. Suemura
                                              NEC Corporation of America
                                                            June 7, 2011


                Interworking between MPLS-TP and IP/MPLS
                draft-martinotti-mpls-tp-interworking-02

Abstract

   Purpose of this ID is to illustrate interworking scenarios between
   network(s) supporting MPLS-TP and network(s) supporting IP/MPLS.
   Main interworking aspects, issues and open points are highlighted.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on December 9, 2011.

Copyright Notice

   Copyright (c) 2011 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



Martinotti, et al.      Expires December 9, 2011                [Page 1]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Scope of this document . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  3
   3.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   6.  Elements used in the figures . . . . . . . . . . . . . . . . .  5
   7.  Interconnectivity Options  . . . . . . . . . . . . . . . . . .  6
     7.1.  Network Layering model . . . . . . . . . . . . . . . . . .  8
       7.1.1.  OAM Implication of the Layering model  . . . . . . . .  8
       7.1.2.  Layering model control plane consideration . . . . . .  8
     7.2.  Network Layering scenarios . . . . . . . . . . . . . . . .  8
       7.2.1.  Port based transparent transport of IP/MPLS  . . . . .  8
       7.2.2.  VLAN based transparent transport of IP/MPLS  . . . . . 12
       7.2.3.  Port based transport of IP/MPLS with Link Layer
               removal  . . . . . . . . . . . . . . . . . . . . . . . 12
       7.2.4.  IP/MPLS / MPLS-TP hybrid edge node . . . . . . . . . . 15
       7.2.5.  MPLS-TP carried over IP/MPLS . . . . . . . . . . . . . 18
     7.3.  Network Partitioning Model . . . . . . . . . . . . . . . . 18
       7.3.1.  Connectivity constraints of the partitioning model . . 18
       7.3.2.  OAM Implications of the partitioning model . . . . . . 19
     7.4.  Network Partitioning scenarios . . . . . . . . . . . . . . 19
       7.4.1.  Border Node - Multisegment Pseudowire  . . . . . . . . 20
       7.4.2.  Border Node - LSP stitching  . . . . . . . . . . . . . 22
       7.4.3.  Border Link - Multisegment Pseudowire  . . . . . . . . 25
       7.4.4.  Border Link - LSP stitching  . . . . . . . . . . . . . 27
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
   10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 30
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 32
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     12.2. Informative References . . . . . . . . . . . . . . . . . . 32
   Appendix A.  Additional Stuff  . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33







Martinotti, et al.      Expires December 9, 2011                [Page 2]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


1.  Introduction

1.1.  Scope of this document

   This document illustrates the most likely interworking scenarios
   between MPLS-TP and IP/MPLS.  For each of the examined scenarios
   interworking aspects, limitations, issues and open points, with
   particular focus on OAM capabilities, are provided.

   The main architectural construct considered in this document foresees
   PWE3 Protocol Stack Reference Model and MPLS Protocol Stack Reference
   Model.  See [RFC 5921] for details.


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


3.  Acronyms

      AC Attachment circuit

      CE Customer Edge

      CLI Client

      CP Control Plane

      DP Data Plane

      ETH Ethernet MAC Layer

      ETY Ethernet Physical Layer

      IWF Interworking Function

      LER Label Edge Router

      LSP Label Switched Path

      LSR Label Switch Router







Martinotti, et al.      Expires December 9, 2011                [Page 3]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


      MAC Media Access Control

      MEP Maintenance Association End Point

      MIP Maintenance Association Intermediate Point

      MP Management Plane

      MS-PW Multi Segment PW

      NE Network Element

      OAM Operations, Administration and Maintenance

      PE Provider Edge

      PHY Physical Layer

      PSN Packet Switched Network

      PW Pseudowire

      SRV Server

      SS-PW Single Segment PW

      S-PE Switching Provider Edge

      T-PE Terminating Provider Edge


4.  Problem Statement

   This document addresses interworking issues between MPLS-TP network
   and IP/MPLS network.  The network decomposition can envisage network
   layering and/or network partitioning.

   The presented scenarios are not intended to be comprehensive, for
   instance more complex scenarios can be created composing those
   described in this document.


5.  Terminology

   As far as this document is concerned, the following terminology is
   used:





Martinotti, et al.      Expires December 9, 2011                [Page 4]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


   o  IP/MPLS NE: a NE that supports IP/MPLS functions

   o  IP/MPLS Network: a network in which IP/MPLS NEs are deployed

   o  MPLS-TP NE: a NE that supports MPLS-TP functions

   o  MPLS-TP Network: a network in which MPLS-TP NEs are deployed

   o  Node: either MPLS-TP NE, IP/MPLS NE or CE

   o  Ingress direction: from client to network

   o  Egress direction: from network to client

   For each of the scenarios described in this document, two paragraphs
   may appear, one related to possible issues already envisaged by the
   authors (Open Issues), the other related to aspects still left for
   further study and/or definition (Open Points).

   This Section provides some terminology about network layering and
   partitioning.  Primarily source of those definitions is [ITU-T
   G.805].  Readers already familiar with these concepts can skip this
   Section.


6.  Elements used in the figures

   A legenda of the symbols, which are most used in the following
   Sections, is provided, in order to facilitate comprehension of the
   scenarios.





















Martinotti, et al.      Expires December 9, 2011                [Page 5]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


                   Node:
                    -----  Direct connection
                    - - -  Virtual connection
                    .....  one or more direct connections

                   Layers:
                    |      Termination
                    +      Connection
                    <->    Stitching

                    OAM:
                    > or < MEP
                    O      MIP



                                 Figure 1


7.  Interconnectivity Options

   The MPLS-TP project adds dataplane OAM functionality to the MPLS tool
   set that permits executive action to be delegated to the dataplane.
   This provides the option of running MPLS without a control plane
   while still providing carrier grade resiliency options for connection
   oriented operation.  Connection oriented operation alone does not
   offer the scalability to offer contemporary multipoint service
   solutions, but the combination of MPLS-TP connection oriented
   backhaul and IP/MPLS service capabilities permits the deployment of
   networks that scale significantly beyond the boundaries of current
   control plane scaling.

   This section describes the methods in which IP/MPLS and MPLS-TP
   domains can interconnect.  The network decomposition can envisage
   network layering and/or network partitioning.  The presented
   scenarios are not intended to be comprehensive, for instance more
   complex scenarios can be created composing those described in this
   document.  The various elements introduced in this section will be
   referred to in later sections.

   The following figure illustrates the Network Layering concept, as it
   is described in Section 7.1:









Martinotti, et al.      Expires December 9, 2011                [Page 6]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


        ____     ___                                    ___     __
      _/    \___/   \                                 _/   \___/  \_
     /               \__                             /              \__
    /===================\===+                  +====/==================\
   |                    |___O------------------O___|                   |
    \                   /\__/_ _ _ _ _ _ _ _ _ _\__/\                 /
     \   ___      __   /  \/                     \/  \   ___     _   /
      \_/   \____/  \_/   |                       |   \_/   \___/ \_/
         Layer n          |                       |      Layer n
                          |       __    __        |
                          |     _/  \__/  \       |
                          |    /           \__    |
                          |   /               \   |
      ____                +-0|                 |0-+
      \__/ Adaptation         \               /
                               \   __   _    /
       __                       \_/  \_/ \__/
       \/  Termination            Layer n-1


                             Network Layering

                                 Figure 2

   Layer n is carried over Layer n-1, via adaptation and termination
   functions.  Some readers will also call this concept "Overlay model".

   The following figure illustrates the Network Partitioning concept, as
   it is described in Section 7.3:


     ___     ___       ____                ____     ___       ___
   _/   \___/   \    _/    \__           _/    \___/   \    _/   \__
  /              \__/         \         /               \__/        \_
 /                              \  |   /                              \
|     Sub-Network Domain 1      |+++++|    Sub-Network Domain 2        |
 \                              /  |   \                              /
  \   __      ___     __      _/        \   ___      ___     __     _/
   \_/  \____/   \___/  \____/           \_/   \____/   \___/  \___/



                           Network Partitioning

                                 Figure 3

   The boundary between the two subnetworks can be a link (as defined by
   [ITU-T G.805]), but also a Node, which in this case SHALL be able to



Martinotti, et al.      Expires December 9, 2011                [Page 7]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


   handle the technologies of both subnetworks.

   The two subnetworks are at the same level.  Some readers will also
   call this concept "Peer model".

7.1.  Network Layering model

   Two relationship are considered: the IP/MPLS network is carried over
   the MPLS-TP one, the MPLS-TP network is carried over the IP/MPLS one.
   This version of the draft focuses on the former relationship.  In the
   MPLS-TP architecture, the pseudo wire is the primary unit of carriage
   of non-MPLS-TP payloads.  This provides a clean demarcation between
   MPLS-TP operations and transported payloads.

7.1.1.  OAM Implication of the Layering model

   The overlay model has the virtue of uniform deployment of OAM
   capabilities and encapsulations at all MIPs and MEPs at a given layer
   in the label stack.  The IP/MPLS architecture does include OAM
   transactions originated by MIPs so the layer interworking function
   for MPLS-TP servers is simplified.

7.1.2.  Layering model control plane consideration

   The interworking between an IP/MPLS domain and an MPLS-TP domain
   highly depends on the implemented model (i.e. layering or
   partitioning) and different scenarios can be implemented depending on
   a number of different aspects.

   In the case of layering model, the first aspect consists on the
   provisioning of the LSP at the N-1 layer (MPLS-TP layer).  Two
   possible scenarios are foreseen: pre-configuration of the MPLS-TP LSP
   or induced provisioning.  The pre-configuration of the MPLS-TP LSP
   can be performed either manually via NMS or via the MPLS-TP control
   plane signaling and the MPLS-TP LSP can be exported to the IP/MPLS
   domain as a forwarding adjacency.  On the other side the signaling
   messages at the IP/MPLS layer, upon reaching the border of the
   MPLS-TP domain, can induce the signaling of the MPLS-TP LSP via
   RSVP-TE.  Other use cases depend on how the IP/MPLS is carried over
   the MPLS-TP domain and are analyzed scenario by scenario in the
   following sections.

7.2.  Network Layering scenarios

7.2.1.  Port based transparent transport of IP/MPLS

   This scenario foresees an IP/MPLS network carried over an MPLS-TP
   network.  The selection of the route over the MPLS-TP network is done



Martinotti, et al.      Expires December 9, 2011                [Page 8]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


   on a per port basis.  The interworking is done via Link Layer (e.g.
   Ethernet) encapsulation in PW over MPLS-TP (as per PWE3 Protocol
   Stack Reference Model).  MPLS-TP LSPs are pre-configured with respect
   to IP/MPLS LSPs and IP/MPLS LSRs may be seen one hop away.

   The following figure illustrates the functional interworking among
   the networks:


    Networks:
                              Customer Network
        +---+ - - - - - - - - - - - - - - - - - - - - - - - - - +---+
            | _________________________________________________ |
            |/                 IP/MPLS Network                 \|
            +---------------+ - - - - - - - - - +---------------+
             \______________|___________________|______________/
                            | _________________ |
                            |/ MPLS-TP Network \|
                            +-------------------+
                           ^ \_________________/
                    PW emulation (VPWS)

    Nodes:
     +++++                                                         +++++
     + 1 +----+ - - - - - - - - - - - - - - - - - - - - - - - +----+ 9 +
     +++++    |                                               |    +++++
      CE    +++++   +++++                           +++++   +++++    CE
            + 2 +...+ 3 +-----+- - - - - - - -+-----+ 7 +...+ 8 +
            +++++   +++++     |               |     +++++   +++++
             LER     LSR    +++++   +++++   +++++    LSR     LER
             PE       CE    + 4 +...+ 5 +...+ 6 +             PE
                            +++++   +++++   +++++
                             LER     LSR     LER
                             PE               PE


             Port based transparent transport - Networks view

                                 Figure 4

   The LSR 3 and 7 are one hop away from the IP/MPLS layer point of
   view, CP/MP of IP/MPLS is transparently transported by MPLS-TP
   network.

   In case the Link Layer is Ethernet, the service provided by the
   MPLS-TP network could be an E-Line service realized via VPWS.  The
   LER4 and 6 do not need to know that above the Ethernet layer there is
   an MPLS LSP.



Martinotti, et al.      Expires December 9, 2011                [Page 9]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


7.2.1.1.  OAM Considerations

   The following figure illustrates the stacking relationship among the
   technology layers and OAM relationship among the networks:


   Layers:
    |--------+----------------------CLI----------------------+--------|
    |--SRV--| |--------------------(PW)---------------------| |--SRV--|
              |------+--------------LSP--------------+------|
              |-SRV-| |------+------SRV------+------| |-SRV-|
                      |-PHY-| |------PW-----| |-PHY-|
                              |--LSP-+------|
                              |-SRV-| |-SRV-|

   OAM:
   (5)         >------O-----------------------------O------<         LSP
   (4)                 >---------------------------<             SECTION
   (3)                         >-----------<                          PW
   (2)                         >-----O-----<                         LSP
   (1)  >--<   >...<   >---<   >...<   >...<   >---<   >...<   >--<  PHY

   Nodes:
    +++++  +++++   +++++   +++++   +++++   +++++   +++++   +++++  +++++
    + 1 +--+ 2 +...+ 3 +---+ 4 +...+ 5 +...+ 6 +---+ 7 +...+ 8 +--+ 9 +
    +++++  +++++   +++++   +++++   +++++   +++++   +++++   +++++  +++++
     CE     LER     LSR     LER     LSR     LER     LSR     LER     CE


          Port based transparent transport - Layers and OAM view

                                 Figure 5

   Several levels of OAM are shown in the previous figure, these are not
   comprehensive and any subset of them MAY be configured in a network.
   A brief description of the different levels is provided:

      (5) Edge-to-Edge MPLS OAM on IP/MPLS network (at LSP level)

      (4) Section OAM on IP/MPLS network

      (3) Edge-to-Edge MPLS-TP OAM on MPLS-TP network (at PW level)

      (2) Edge-to-Edge MPLS-TP OAM on MPLS-TP network (at LSP level)







Martinotti, et al.      Expires December 9, 2011               [Page 10]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


      (1) Physical level OAM (MAY be of several kinds)

   In case of fault detected at the MPLS-TP LSP (2) level, the
   corresponding server MEP asserts a signal fail condition and notifies
   that to the co-located MPLS-TP client/server adaptation function
   which then generates OAM packets with AIS information in the
   downstream direction to allow the suppression of secondary alarms at
   the MPLS-TP MEP in the client (sub-) layer, which in this example
   correspond to PW layer (3).

   Note that the OAM layers not directly related to MPLS-TP network have
   been reported just for completeness of the scenario; however their
   behavior and interworking are out of scope of this document.  For
   MPLS-TP Alarm reporting detailed description, please refer to
   [draft-ietf-mpls-tp-oam-framework].

7.2.1.2.  Control Plane considerations

   In this case the interconnection between the IP/MPLS domain and the
   MPLS-TP domain consists of a link.  This does not allow a transparent
   transport of the IP control messages (e.g.  LDP) over the MPLS-TP
   LSPs due to the fact that the egress node of the MPLS-TP domain is
   not able to route IP packets on its interfaces.  The IP control
   messages need to be carried over an Ethernet frame over a PWE3 before
   being injected into the MPLS-TP LSP.  In other words they are
   forwarded with two labels, the PWE3 one (S=0) and the LSP one (S=1).
   The IP control message, upon reaching the egress LER of the MPLS-TP
   domain, can be correctly forwarded to the ingress node of the IP/MPLS
   domain.

7.2.1.3.  Services view

   There are two service models supported by the overlay model when
   combined with Ethernet PWs.  The first is simple p2p encapsulation
   and transport of all traffic presented to the MPLS-TP on a given
   interface.  This is of limited utility due to the number of ports
   required to achieve the desired level of network interconnect across
   the MPLS-TP core.

   The second is that the MPLS-TP LER maps VLANs to distinct PWs such
   that multiple IP/MPLS adjacencies can be supported over each
   interface between the IP/MPLS LSR and the MPLS-TP LER.  This
   potentially can require a large number of IP/MPLS adjacencies
   overlaying the core.

   In both cases the service can be unprotected or protected.





Martinotti, et al.      Expires December 9, 2011               [Page 11]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


7.2.1.4.  Resiliency considerations

   In the scenario where the service is unprotected, resiliency is fully
   delegated to the IP/MPLS network, which will depend on a combination
   of routing convergence and/or FRR to maintain service.  This will be
   at the expense of routing stability.

   A protected service can offer significant improvements in routing
   stability with the exception that the link between the IP/MPLS LSRs
   and the MPLS-TP LERs and the MPLS-TP LERs themselves are single
   points of failure.  There is an advantage in that the single points
   of failures are adjacent to the MPLS LSRs such that there is a high
   probability of such failures manifesting themselves immediately in
   the form of a physical layer loss-of-signal failure and thus
   accelerating recovery.  Multiple failure scenarios may also result in
   the IP/MPLS overlay having to take action to recover connectivity but
   this would be gated by whatever OAM detection mechanisms were
   employed by the IP/MPLS layer as there is no equivalent of MPLS-TP
   LDI across the interconnect interface.

7.2.2.  VLAN based transparent transport of IP/MPLS

   This scenario is analogous to the previous one.  The interconnection
   between the IP/MPLS LSRs and the MPLS-TP PEs is done via .1Q Tagged
   Ethernet, and VLANs are used to select the routes over the p2p
   Ethernet connectivity services over MPLS-TP (VPWS).  The interworking
   is done via Ethernet encapsulation in PW over MPLS-TP (as per PWE3
   Protocol Stack Reference Model).  This VLAN based interconnection may
   be used in order to reduce the number of physical interfaces between
   the two networks.  The same considerations of previous scenarios
   apply.

7.2.3.  Port based transport of IP/MPLS with Link Layer removal

   This scenario foresees an IP/MPLS network carried over an MPLS-TP
   network.  The selection of the route over the MPLS-TP network is done
   on a per port basis.  The physical interface between the IP/MPLS and
   the MPLS-TP network may be of different kind (e.g.  Ethernet, POS);
   the interworking is done via Link Layer removal and client packet
   (MPLS and IP) encapsulation in PW over MPLS-TP (as per PWE3 Protocol
   Stack Reference Model).  MPLS-TP LSPs are pre-configured with respect
   to IP/MPLS LSPs and are seen as routing adjacencies by the IP/MPLS
   network.

   The following figure illustrates the functional interworking among
   the networks:





Martinotti, et al.      Expires December 9, 2011               [Page 12]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


    Networks:
                               Customer Network
        +---+ - - - - - - - - - - - - - - - - - - - - - - - - - +---+
            | _________________________________________________ |
            |/                 IP/MPLS Network                 \|
            +---------------+ - - - - - - - - - +---------------+
             \______________|___________________|______________/
                            | _________________ |
                            |/ MPLS-TP Network \|
                            +-------------------+
                           ^ \_________________/
                      PW emulation

    Nodes:
     +++++                                                         +++++
     + 1 +----+ - - - - - - - - - - - - - - - - - - - - - - - +----+ 9 +
     +++++    |                                               |    +++++
      CE    +++++   +++++                           +++++   +++++    CE
            + 2 +...+ 3 +-----+- - - - - - - -+-----+ 7 +...+ 8 +
            +++++   +++++     |               |     +++++   +++++
             LER     LSR    +++++   +++++   +++++    LSR     LER
             PE       CE    + 4 +...+ 5 +...+ 6 +             PE
                            +++++   +++++   +++++
                             LER     LSR     LER
                             PE               PE


       Port based transport with Link Layer removal - Networks view

                                 Figure 6

   The LSR 3 and 7 are one hop away from the IP/MPLS layer point of
   view.

   The service provided by the MPLS-TP network is p2p; client traffic is
   separated on a per port basis, so that (for example) all traffic
   coming from LSR 3 on the interface to LER 4 is transparently
   transported via LER 6 to LSR 7 and viceversa.  The client traffic to
   be encapsulated is both MPLS packets (DP) and IP packets (DP, CP and
   MP).  The encapsulation may be performed via PWs, that is, one PW is
   needed for MPLS and one for IP between any given port pair or
   directly using the LSP label stacking.  The encapsulation via PW is
   is required such that the IP/MPLS section preserves PHY like
   properties and to operationally isolate TP and IP/MPLS operation
   (e.g. reserved label handling link GAL and Router Alert).






Martinotti, et al.      Expires December 9, 2011               [Page 13]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


7.2.3.1.  OAM considerations

   The following figure illustrates the stacking relationship among the
   technology layers and OAM relationship among the networks:


   Layers:
    |--------+----------------------CLI----------------------+--------|
    |--SRV--| |--------------------(PW)---------------------| |--SRV--|
              |------+--------------LSP--------------+------|
              |-SRV-| |-SRV-| |---PW--------| |-SRV-| |-SRV-|
                              |--LSP-+------|
                              |-SRV-| |-SRV-|

   OAM:
   (5)         >------O-----------------------------O------<         LSP
   (4)                 >---------------------------<             SECTION
   (3)                         >-----------<                          PW
   (2)                         >-----O-----<                         LSP
   (1)  >---<   >---<  >---<   >...<   >...<   >---<   >---<   >---< PHY

   Nodes:
    +++++  +++++   +++++   +++++   +++++   +++++   +++++   +++++  +++++
    + 1 +--+ 2 +...+ 3 +---+ 4 +...+ 5 +...+ 6 +---+ 7 +...+ 8 +--+ 9 +
    +++++  +++++   +++++   +++++   +++++   +++++   +++++   +++++  +++++
     CE     LER     LSR     LER     LSR     LER     LSR     LER     CE


    Port based transport with Link Layer removal - Layers and OAM view

                                 Figure 7

   Several levels of OAM are possible, a subset of them is shown in the
   previous figure, however these are not comprehensive, any subset of
   them MAY be configured in a network.  A brief description of the
   levels is provided:

      (5) Edge-to-Edge MPLS OAM on IP/MPLS network (at LSP level)

      (4) Section MPLS OAM

      (3) Edge-to-Edge MPLS-TP OAM on MPLS-TP network (at PW level)

      (2) Edge-to-Edge MPLS-TP OAM on MPLS-TP network (at LSP level)







Martinotti, et al.      Expires December 9, 2011               [Page 14]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


      (1) Physical level OAM (MAY be of several kinds)

7.2.3.2.  Control Plane considerations

   In the case of transparent transport of the IP/MPLS over the MPLS-TP
   domain there are no differences, from a control plane point of view,
   with respect to the case of Ethernet encapsulation over MPLS-TP.
   Same considerations carried out in section 5.1.3.1.1.2 apply to this
   section.

7.2.3.3.  Services view

   The service model for the transparent transport mode is simple p2p
   encapsulation andtransport of all traffic presented to the MPLS-TP on
   a given interface.  This is of limited utility due tothe number of
   ports required to achieve the desired level of network interconnect
   across the MPLS-TP core.  It would potentially also requires a
   correspondingly high number of IP/MPLS adjacenciesto overlay the
   core.

   The service can be unprotected or protected.

7.2.3.4.  Resiliency considerations

   The resiliency considerations are the same as for the overlay model.

7.2.4.  IP/MPLS / MPLS-TP hybrid edge node

   In this scenario the physical interface between the IP/MPLS and the
   MPLS-TP network is generic and may be other than Ethernet (e.g.
   POS); the interworking is done via client LSP packet encapsulation as
   per MPLS labeled or IP traffic over MPLS-TP as per RFC 5921.  MPLS-TP
   LSPs are pre-configured with respect to IP/MPLS LSPs and are seen as
   routing adjacencies between the hybrid edge nodes by the IP/MPLS
   network.

   The service that is offered to the IP/MPLS network is that of a
   multi-point MPLS VPN.

   The following figure illustrates the functional interworking among
   the networks.










Martinotti, et al.      Expires December 9, 2011               [Page 15]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


    Networks:
                                                      Customer Network
        +---+ - - - - - - - - - - - - - - - - - - - - - - - - - +---+
            | _________________________________________________ |
            |/                 IP/MPLS Network                 \|
            +---------------+ - - - - - - - - - +---------------+
             \______________|___________________|______________/
                            | _________________ |
                            |/ MPLS-TP Network \|
                            +-------------------+
                             \_________________/

    Nodes:
     +++++                                                         +++++
     + 1 +----+ - - - - - - - - - - - - - - - - - - - - - - - +----+ 9 +
     +++++    |                                               |    +++++
      CE    +++++   +++++   +++++           +++++   +++++   +++++    CE
            + 2 +...+ 3 +---+   +- - - - - -+   +---+ 7 +...+ 8 +
            +++++   +++++   +   +           +   +   +++++   +++++
             LER     LSR    +LSR+   +++++   +LSR+    LSR     LER
             PE             + 4 +...+ 5 +...+ 6 +             PE
                            +++++   +++++   +++++
                             LER     LSR     LER


            IP/MPLS encapsulation over MPLS-TP - Networks view

                                 Figure 8

   The Node 4 and 6 in the above figure act as dual function:

   o  LSR of client IP/MPLS network

   o  LER of server MPLS-TP subnetwork

7.2.4.1.  OAM considerations

   The following figure illustrates the stacking relationship among the
   technology layers and OAM relationship among the networks:












Martinotti, et al.      Expires December 9, 2011               [Page 16]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


   Layers:
    |--------+----------------------CLI----------------------+--------|
    |--SRV--| |--------------------(PW)---------------------| |--SRV--|
              |------+-------+------LSP------+-------+------|
              |-SRV-| |-SRV-| |-LSP--+------| |-SRV-| |-SRV-|
                              |-SRV-| |-SRV-|
   OAM:
   (3)         >--------------O-------------O--------------<         LSP
   (2)                         >-----O-----<                         LSP
   (1)  >---<   >---<  >---<   >...<   >...<   >---<   >---<   >---< PHY

   Nodes:
    +++++  +++++   +++++   +++++   +++++   +++++   +++++   +++++  +++++
    + 1 +--+ 2 +...+ 3 +---+ 4 +...+ 5 +...+ 6 +---+ 7 +...+ 8 +--+ 9 +
    +++++  +++++   +++++   +++++   +++++   +++++   +++++   +++++  +++++
     CE     LER     LSR     LER     LSR     LER     LSR     LER     CE


         IP/MPLS encapsulation over MPLS-TP - Layers and OAM view

                                 Figure 9

   Several levels of OAM are possible, a subset of them is shown in the
   previous figure, however these are not comprehensive, any subset of
   them MAY be configured in a network.  A brief description of the
   levels is provided:

      (3) Edge-to-Edge MPLS OAM on IP/MPLS network (at LSP level)

      (2) Edge-to-Edge MPLS-TP OAM on MPLS-TP network (at LSP level)

      (1) Physical level OAM (MAY be of several kinds)

7.2.4.2.  Control Plane considerations

   This case is different from the previous two because the
   interconnection between the IP/MPLS domain and the MPLS-TP domain
   consists of a node.  This lead to the fact that IP control messages
   do not need to be carried over a PWE3 along the MPLS-TP domain but
   can be directly carried over an LSP.  In other words they are
   forwarded with a single LSP label (S=1) and , upon reaching the
   hybrid node between the MPLS-TP domain and the next IP/MPLS domain ,
   the signaling can be carried on.

7.2.4.3.  Services view

   The service model for the hybrid edge node model is that the MPLS-TP
   network appears to the IP/MPLS network as a complete IP/MPLS



Martinotti, et al.      Expires December 9, 2011               [Page 17]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


   subnetwork.  This has the virtue of collapsing the number of IP/MPLS
   adjacencies required to overlay the core.

   The service can be unprotected or protected.  And the protection can
   be a combination of MPLS-TP resiliency and IP/MPLS recovery actions.

7.2.4.4.  Resiliency considerations

   The resiliency considerations are similar to that of the overlay
   model.  However the extension of the control plane to the hybrid node
   means the lack of a dataplane LDI equivalent is mitigated, the IP/
   MPLS domain having been extended to reach the MPLS-TP OAM domain such
   that LDI indications from core failures can interwork directly the
   the control plane and accelerate recovery actions.

7.2.5.  MPLS-TP carried over IP/MPLS

   TODO

7.3.  Network Partitioning Model

   In the rest of this Section the following assumptions apply:

   o  Customer network is carried partly over IP/MPLS subnetwork (e.g.
      via PW encapsulation) and partly over MPLS-TP subnetwork.

   o  An example of server layer of MPLS is Ethernet.

   For the purposes of this Section, MPLS-TP subnetwork is deployed
   between a CE and an IP/MPLS subnetwork.  Other kinds of deployment
   are possible (not shown in this document), for instance:

   o  More than two subnetworks are deployed between the CEs

   o  MPLS-TP can be deployed between two subnetworks

7.3.1.  Connectivity constraints of the partitioning model

   The partitioning model is constrained to interconnecting LSPs or PWs
   with common behavioral characteristics.  As MPLS-TP is constrained to
   connection oriented behavior the portion of the LSP that transits an
   IP/MPLS subnetwork will need to be effectively constrained to the
   same profile, that is connection oriented, and no PHP or merging.  No
   ECMP or transit of LAG cannot be guaranteed which means OAM fate
   sharing may not exist in IP/MPLS subnetworks and the end-to-end OAM
   may only serve to coordinate dataplane resiliency actions between
   MEPs with respect to faults in the MPLS-TP subnetworks.




Martinotti, et al.      Expires December 9, 2011               [Page 18]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


7.3.2.  OAM Implications of the partitioning model

   The partitioning model requires the concatenations of path segments
   that do not necessarily have common OAM components and have a number
   of possible implementations.  At the simplest level configuration of
   common OAM capabilities and encapsulation between the MEPs in the MEG
   is required.  The set that is common to the MEPs in the MEG may not
   necessarily be supported by the MIPs, and knowldege of MIP capability
   will not figure into MEP neogitation, so the MEPs may select a common
   mode that is not common with that supported by the MIPs.

   The primary consequence being that MPLS-TP MIP originated
   transactions, or messages targeted to MIPs using MPLS-TP
   encapsulations will not be guaranteed to provide a uniform quality of
   information as not all MIPs will support MPLS-TP OAM extensions, and
   as noted will not participate in MEP-MEP configuration or
   negotiation.

   This means that GAL encapsulated OAM may only serve to coordinate
   dataplane resiliency actions between MEPs with respect to faults in
   the MPLS-TP subnetworks and faults in the IP/MPLS subnetwork are
   recovered by IP/MPLS mechanisms (e.g.  FRR).  Edge to edge monitoring
   of MPLS/MPLS-TP networks may be implemented using an edge to edge LSP
   OAM/PW OAM, in order not to need a gateway/translation function on
   the border node between the two domains.

7.4.  Network Partitioning scenarios

   The main features to be taken into account in deploying a partitioned
   network are the following:

   o  Border Node or Border Link

   o  MultiSegment Pseudowire or LSP Stitching

   o  Network Interworking

   o  End-to-End OAM support

   o  Interaction between DP of IP/MPLS and DP of MPLS-TP

   o  Interaction between CP of IP/MPLS and MP of MPLS-TP

   o  Interaction between CP of IP/MPLS and CP of MPLS-TP

   o  Interaction between MP of IP/MPLS and MP of MPLS-TP





Martinotti, et al.      Expires December 9, 2011               [Page 19]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


7.4.1.  Border Node - Multisegment Pseudowire

   The following figure illustrates the functional interworking among
   the networks:


            Networks:
                              Customer Network
                +---+ - - - - - - - - - - - - - - - - - +---+
                    | _______________   _______________ |
                    |/  IP/MPLS Net. \ /  MPLS-TP Net. \|
                    +-----------------+-----------------+
                   ^ \_______________/ \_______________/
              PW emulation

            PWs:
                      |-------------MS-PW-------------|
                      |---------------|---------------|
                                ^         ^
                                PW segments

            Nodes:
             +++++                                         +++++
             + 1 +----+- - - - - - - - - - - - - - - -+----+ 7 +
             +++++    |                               |    +++++
              CE    +++++   +++++   +++++   +++++   +++++    CE
                    + 2 +...+ 3 +---+ 4 +...+ 5 +...+ 6 +
                    +++++   +++++   +++++   +++++   +++++
                     LER     LSR     LER     LSR     LER
                     T-PE            S-PE           T-PE


       Border Node - Multisegment Pseudowire - Networks and PWs view

                                 Figure 10

7.4.1.1.  OAM considerations

   The following figure illustrates the stacking relationship among the
   technology layers and OAM relationship among the networks:











Martinotti, et al.      Expires December 9, 2011               [Page 20]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


           Layers:
            |--------+--------------CLI--------------+--------|
            |--SRV--| |---------PW---+--------------| |--SRV--|
                      |-LSP--+------| |--LSP-+------|
                      |-SRV-| |-SRV-| |-SRV-| |-SRV-|

           OAM:
           (3)         >-------------O-------------<       MS-PW
           (2)         >-----O-----<   >-----O-----<         LSP
           (1)  >--<   >...<   >---<   >...<   >...<   >--<  PHY

           Nodes:
            +++++  +++++   +++++   +++++   +++++   +++++  +++++
            + 1 +--+ 2 +...+ 3 +---+ 4 +...+ 5 +...+ 6 +--+ 7 +
            +++++  +++++   +++++   +++++   +++++   +++++  +++++
             CE     LER     LSR     LER     LSR     LER     CE


        Border Node - Multisegment Pseudowire - Layers and OAM view

                                 Figure 11

   Several levels of OAM are possible, a subset of them is shown in the
   previous figure, however these arenot comprehensive, any subset of
   them MAY be configured in a network.  A brief description of the
   different levels is provided:

      (3) Edge-to-Edge MPLS/MPLS-TP OAM on whole network (at PW level)

      (2) Edge-to-Edge MPLS OAM and Edge-toEdge MPLS-TP OAM on each
      network partition respectively (at LSPlevel)

      (1) Physical level OAM (MAY be of several kind)

   Open Points:

   o  Interworking between LSP OAM (2) and MS-PW OAM (3) is still to be
      cleared/defined

   o  Edge-to-Edge MS-PW OAM (3) must be configured on different
      subnetworks

7.4.1.2.  Control Plane considerations

   TODO






Martinotti, et al.      Expires December 9, 2011               [Page 21]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


7.4.1.3.  Services view

   The generalized service model for all partitioning models is a p2p
   connection for the PW client.

7.4.1.4.  Resiliency considerations

   The PW can be configured to be protected or unprotected at the PW
   layer.  If it is unprotected it is dependent on the underlying
   domains (MPLS-TP or IP/MPLS) resiliency mechanisms to offer
   subnetwork protection, but the S-PE is a single point of failure.  A
   protected PW can be set up such that the working and protection PWs
   traverse physically diverse S-PEs.

   Implementing E2E protection at the PW layer requires CC flows on the
   PW which for large numbersof PWs may have scaling implications.

   When the PW is protected, the border node as an MS-PW stitching point
   permits the interworking of MPLS-TP fault indications with the PW
   signaling in the IP/MPLS domain such that fast E2E protection
   switching can be coordinated without requiring fast CC/CV OAM flows
   in the PW layer.

7.4.2.  Border Node - LSP stitching

   The following figure illustrates the functional interworking among
   the networks:
























Martinotti, et al.      Expires December 9, 2011               [Page 22]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


            Networks:
                              Customer Network
                +---+ - - - - - - - - - - - - - - - - - +---+
                    | _______________   _______________ |
                    |/  IP/MPLS Net. \ /  MPLS-TP Net. \|
                    +-----------------+-----------------+
                   ^ \_______________/ \_______________/
              PW emulation

            PWs:
                      |-------------SS-PW-------------|

            Nodes:
             +++++                                         +++++
             + 1 +----+- - - - - - - - - - - - - - - -+----+ 9 +
             +++++    |                               |    +++++
              CE    +++++   +++++   +++++   +++++   +++++    CE
                    + 2 +...+ 3 +---+ 4 +...+ 5 +...+ 6 +
                    +++++   +++++   +++++   +++++   +++++
                     LER     LSR     LER     LSR     LER
                     PE                               PE


            Border Node - LSP stitching - Networks and PWs view

                                 Figure 12

   The following figure illustrates the stacking relationship among the
   technology layers and OAM relationship among the networks:






















Martinotti, et al.      Expires December 9, 2011               [Page 23]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


           Layers:
            |--------+--------------CLI--------------+--------|
            |--SRV--| |--------------PW-------------| |--SRV--|
                      |------+-S-LSP<->S-LSP-+------|
                      |-SRV-| |-SRV-| |-SRV-| |-SRV-|

           OAM:
           (4)         >---------------------------<          PW
           (3)         >-------------O-------------<         LSP
           (2)         >-----O-----<   >-----O-----<         TCM
           (1)  >--<   >...<   >---<   >...<   >...<   >--<  PHY

           Nodes:
            +++++  +++++   +++++   +++++   +++++   +++++  +++++
            + 1 +--+ 2 +...+ 3 +---+ 4 +...+ 5 +...+ 6 +--+ 7 +
            +++++  +++++   +++++   +++++   +++++   +++++  +++++
             CE     LER     LSR     LER     LSR     LER     CE


             Border Node - LSP stitching - Layers and OAM view

                                 Figure 13

   Note: in this case a SS-PW extends over the subnetworks as the
   stitched LSP does.  TCM can be used to monitor the LSP segments.

   Several levels of OAM are possible, a subset of them is shown in the
   previous figure, however these are not comprehensive, any subset of
   them MAY be configured in a network.  A brief description of the
   different levels is provided:

      (4) Edge-to-Edge MPLS/MPLS-TP OAM on whole network (at PW level)

      (3) Edge-to-Edge MPLS/MPLS-TP OAM on whole network (at LSP level)

      (2) Edge-to-Edge MPLS OAM and Edge-toEdge MPLS-TP OAM on each
      network partition respectively (at TCM level)

      (1) Physical level OAM (MAY be of several kind)

   Open Points:

   o  Edge-to-Edge LSP OAM (3) must be configured on different
      subnetworks

   o  Edge-to-Edge PW OAM (4) must be configured on different
      subnetworks




Martinotti, et al.      Expires December 9, 2011               [Page 24]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


   o  Interworking between TCM OAM (2) and LSP OAM (3) is still to be
      cleared/defined

7.4.3.  Border Link - Multisegment Pseudowire

   The following figure illustrates the functional interworking among
   the networks:


            Networks:
                              Customer Network
                +---+ - - - - - - - - - - - - - - - - - -+---+
                    | ___________         ______________ |
                    |/IP/MPLS N. \       /  MPLS-TP N.  \|
                    +-------------+-----+----------------+
                   ^ \___________/       \______________/
              PW emulation

            PWs:
                      |------------MS-PW--------------|
                      |-----------|-----|-------------|
                                ^    ^     ^
                                PW segments

            Nodes:
             +++++                                         +++++
             + 1 +----+- - - - - - - - - - - - - - - -+----+ 6 +
             +++++    |                               |    +++++
              CE    +++++     +++++     +++++       +++++    CE
                    + 2 +.....+ 3 +-----+ 4 +.......+ 5 +
                    +++++     +++++     +++++       +++++
                     LER       LER       LER         LER
                     T-PE      S-PE      S-PE       T-PE


           Border Link - Multisegment Pseudowire - Networks view

                                 Figure 14

7.4.3.1.  OAM considerations

   The following figure illustrates the stacking relationship among the
   technology layers and OAM relationship among the networks:








Martinotti, et al.      Expires December 9, 2011               [Page 25]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


           Layers:
            |--------+-------------CLI---------------+--------|
            |--SRV--| |--------+----PW---+----------| |--SRV--|
                      |--LSP--| |--LSP--| |---LSP---|
                      |- SRV -| |--SRV--| |- -SRV- -|

           OAM:
           (3)         >-------O---------O---------<       MS-PW
           (2)         >-----<   >-----<   >-------<         LSP
           (1)  >--<   >.....<   >-----<   >.......<   >--<  PHY

           Nodes:
            +++++  +++++     +++++     +++++       +++++  +++++
            + 1 +--+ 2 +.....+ 3 +-----+ 4 +.......+ 5 +--+ 6 +
            +++++  +++++     +++++     +++++       +++++  +++++
             CE     LER       LER       LER         LER     CE


        Border Link - Multisegment Pseudowire - Layers and OAM view

                                 Figure 15

   Several levels of OAM are possible, a subset of them is shown in the
   previous figure, however these are not comprehensive, any subset of
   them MAY be configured in a network.  A brief description of the
   different levels is provided:

      (3) Edge-to-Edge MPLS/MPLS-TP OAM on whole network (at PW level)

      (2) Edge-to-Edge MPLS OAM, Border MPLS OAM and Edge-toEdge MPLS-TP
      OAM on each network partition respectively (at LSP level)

      (1) Physical level OAM (MAY be of several kinds)

   Open Points:

   o  Interworking between LSP OAM (2) and MS-PW OAM (3) is still to be
      cleared/defined

   o  LSP between Node 3 and 4 could be avoided, however in this case PW
      over Ethernet should be specified.

   o  Edge-to-Edge MS-PW OAM (3) must be configured on different
      subnetworks







Martinotti, et al.      Expires December 9, 2011               [Page 26]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


7.4.3.2.  Control Plane considerations

   TODO

7.4.3.3.  Services view

   The generalized service model for all partitioning models is a p2p
   connection for the PW client.

7.4.3.4.  Resiliency considerations

   The PW can be configured to be protected or unprotected at the PW
   layer.  If it is unprotected it is dependent on the underlying
   domains (MPLS-TP or IP/MPLS) resiliency mechanisms to offer
   subnetwork protection, but the border S-PEs and border link are all
   single points of failure.  A protected PW can be set up such that the
   working and protection PWs traverse physically diverse border links.

   Implementing E2E protection at the PW layer requires CC flows on the
   PW which for largenumbers of PWs may have scaling implications.

7.4.4.  Border Link - LSP stitching

   The following figure illustrates the functional interworking among
   the networks:


























Martinotti, et al.      Expires December 9, 2011               [Page 27]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


            Networks:
                              Customer Network
                +---+ - - - - - - - - - - - - - - - - - -+---+
                    | ___________         ______________ |
                    |/IP/MPLS N. \       /  MPLS-TP N.  \|
                    +-------------+-----+----------------+
                   ^ \___________/       \______________/
              PW emulation

            PWs:
                      |------------SS-PW--------------|

            Nodes:
             +++++                                         +++++
             + 1 +----+- - - - - - - - - - - - - - - -+----+ 6 +
             +++++    |                               |    +++++
              CE    +++++     +++++     +++++       +++++    CE
                    + 2 +.....+ 3 +-----+ 4 +.......+ 5 +
                    +++++     +++++     +++++       +++++
                     LER       LER       LER         LER
                     PE                               PE


                Border Link - LSP stitching - Networks view

                                 Figure 16

7.4.4.1.  OAM considerations

   The following figure illustrates the stacking relationship among the
   technology layers and OAM relationship among the networks:




















Martinotti, et al.      Expires December 9, 2011               [Page 28]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


           Layers:
            |--------+-------------CLI---------------+--------|
            |--SRV--| |-------------PW--------------| |--SRV--|
                      |-S-LSP-<->-S-LSP-<->-S-LSP---|
                      |- SRV -| |--SRV--| |- -SRV- -|
           OAM:
           (4)         >---------------------------<       SS-PW
           (3)         >-------O---------O---------<         LSP
           (2)         >-----<   >-----<   >-------<         TCM
           (1)  >--<   >.....<   >-----<   >.......<   >--<  PHY
           Nodes:
            +++++  +++++     +++++     +++++       +++++  +++++
            + 1 +--+ 2 +.....+ 3 +-----+ 4 +.......+ 5 +--+ 6 +
            +++++  +++++     +++++     +++++       +++++  +++++
             CE     LER       LER       LER         LER     CE


             Border Link - LSP stitching - Layers and OAM view

                                 Figure 17

   Note: in this case a SS-PW extends over the subnetworks as the
   stitched LSP does.  TCM can be used to monitor the LSP segments.

   Several levels of OAM are possible, a subset of them is shown in the
   previous figure, however these arenot comprehensive, any subset of
   them MAY be configured in a network.  A brief description of the
   different levels is provided:

      (4) Edge-to-Edge MPLS/MPLS-TP OAM on whole network (at PW level)

      (3) Edge-to-Edge MPLS/MPLS-TP OAM on whole network (at LSP level)

      (2) Edge-to-Edge MPLS OAM, Border MPLS OAM and Edge-toEdge MPLS-TP
      OAM on each network partition respectively (at TCM level)

      (1) Physical level OAM (MAY be of several kinds)

7.4.4.2.  Control Plane considerations

   TODO

7.4.4.3.  Services view

   The generalized service model for all partitioning models is a p2p
   connection for the PW client.





Martinotti, et al.      Expires December 9, 2011               [Page 29]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


7.4.4.4.  Resiliency considerations

   The LSP can be configured to be protected end to end, have subnetwork
   protection or be unprotected at the LSP layer.  In the subnetwork
   protection scenario the border S-PEs and the borderlink are all
   single points of failure.

   When GAL/GACh encapsulated OAM is deployed at (a minimum) of the LSP
   MEPs, it is possible to envision interworking of the MPLS-TP LSP and
   LSPs in the IP/MPLS domain set up with RSVP-TE and/or with LDP.  In
   the latter case the MPLS-TP LSP maps to a FEC rather than a specific
   LSP but the MPLS_TP LSP would need to appear as a FEC in LDP with
   associated scaling impacts.

   Open Points:

   o  Edge-to-Edge LSP OAM (3) must be configured on different
      subnetworks

   o  Edge-to-Edge PW OAM (4) must be configured on different
      subnetworks

   o  Interworking between TCM OAM (2) and LSP OAM (3) is still to be
      cleared/defined

   o  Interaction between IP/MPLS and MPLS-TP CPs is still to be
      cleared/defined


8.  Acknowledgements

   The authors gratefully acknowledge the input of Attila Takacs.


9.  IANA Considerations

   This memo includes no request to IANA.


10.  Contributing Authors


      David Allan
      Ericsson
      Holger Way
      San Jose
      U.S.




Martinotti, et al.      Expires December 9, 2011               [Page 30]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


      Email: david.i.allan@ericsson.com




      Elisa Bellagamba
      Ericsson
      Torshamnsgatan 48
      Stockholm  164 80
      Sweden

      Email: elisa.bellagamba@ericsson.com




      Daniele Ceccarelli
      Ericsson
      Via A. Negrone 1/A
      Genova - Sestri Ponente  16153
      Italy

      Email: daniele.ceccarelli@ericsson.com




      David Saccon
      Ericsson
      Holger Way
      San Jose
      U.S.

      Email: david.saccon@ericsson.com




      John Volkering
      Ericsson

      Email: john.volkering@ericsson.com









Martinotti, et al.      Expires December 9, 2011               [Page 31]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


11.  Security Considerations

   This document does not introduce any additional security aspects
   beyond those applicable to PWE3 and MPLS.


12.  References

12.1.  Normative References

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

12.2.  Informative References

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

   [RFC5654]  Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
              and S. Ueno, "Requirements of an MPLS Transport Profile",
              RFC 5654, September 2009.

   [RFC5921]  Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
              Berger, "A Framework for MPLS in Transport Networks",
              RFC 5921, July 2010.

   [RFC5860]  Vigoureux, M., Ward, D., and M. Betts, "Requirements for
              Operations, Administration, and Maintenance (OAM) in MPLS
              Transport Networks", RFC 5860, May 2010.

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

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

   [ITU-T G.805]
              "Generic functional architecture of transport networks",
              ID ITU-T G.805, March 2000.


Appendix A.  Additional Stuff

   This becomes an Appendix.





Martinotti, et al.      Expires December 9, 2011               [Page 32]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


Authors' Addresses

   Riccardo Martinotti
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente  16153
   Italy

   Email: riccardo.martinotti@ericsson.com


   Diego Caviglia
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente  16153
   Italy

   Email: diego.caviglia@ericsson.com


   Nurit Sprecher
   Nokia Siemens Networks
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon  45241
   Israel

   Email: nurit.sprecher@nsn.com


   Alessandro D'Alessandro
   Telecom Italia
   Via Reiss Romoli, 274
   Torino  10148
   Italy

   Email: alessandro.dalessandro@telecomitalia.it


   Alessandro Capello
   Telecom Italia
   Via Reiss Romoli, 274
   Torino  10148
   Italy

   Email: alessandro.capello@telecomitalia.it






Martinotti, et al.      Expires December 9, 2011               [Page 33]


Internet-Draft  draft-martinotti-mpls-tp-interworking-02       June 2011


   Yoshihiko Suemura
   NEC Corporation of America
   14040 Park Center Road
   Herndon, VA  20171
   USA

   Email: Yoshihiko.Suemura@necam.com












































Martinotti, et al.      Expires December 9, 2011               [Page 34]


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