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]