Internet Engineering Task Force R. Martinotti, Ed. Internet-Draft D. Caviglia Intended status: Informational Ericsson Expires: May 13, 2010 Y. Suemura NEC Corporation of America N. Sprecher Nokia Siemens Networks A. D'Alessandro Telecom Italia November 9, 2009 Network Layering deployment scenario between MPLS-TP and IP/MPLS draft-martinotti-mpls-tp-iw-layering-00 Abstract Purpose of this ID is to illustrate deployment scenarios between network supporting MPLS-TP and network supporting IP/MPLS, where there is a network layering relationship between them. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the Martinotti, et al. Expires May 13, 2010 [Page 1] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Network Layering . . . . . . . . . . . . . . . . . . . . . 5 6. Elements used in the figures . . . . . . . . . . . . . . . . . 6 7. Network Layering . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Ethernet encapsulation over MPLS-TP . . . . . . . . . . . 7 7.2. Transparent transport of IP/MPLS . . . . . . . . . . . . . 10 7.3. IP/MPLS / MPLS-TP hybrid edge node . . . . . . . . . . . . 14 7.3.1. IP/MPLS does not require PHP from MPLS-TP . . . . . . 14 7.3.2. IP/MPLS requires PHP from MPLS-TP . . . . . . . . . . 17 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 13.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Martinotti, et al. Expires May 13, 2010 [Page 2] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 1. Introduction 1.1. Background MPLS-TP is a joint ITU-IETF effort to include the MPLS Transport Profile within the IETF MPLS architecture to support the capabilities and functionalities of a packet transport network as defined by ITU-T. In the MPLS-TP requirements [RFC 5654] it is highlighted that an MPLS-TP architecture must allow interworking with new and already deployed IP/MPLS networks. 1.2. Scope of this document This document illustrates the most likely deployment scenarios between MPLS-TP and IP/MPLS, in case of network layering relationship between them. For each of the examined scenarios interworking aspects, limitations, issues and open points, with particular focus on OAM capabilities and control plane, are provided. The main architectural construct considered in this document foresees PWE3 Protocol Stack Reference Model, however also MPLS Protocol Stack Reference Model is used. See [draft mpls-tp framework] for details. Note: due to the early level of definition of CP of MPLS-TP, any possible interaction between CP of IP/MPLS and CP of MPLS-TP is left for further study. 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 Martinotti, et al. Expires May 13, 2010 [Page 3] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 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 MAC Media Access Control MEP Maintenance Association End Point MIP Maintenance Association Intermediate Point MP Management Plane NE Network Element OAM Operations, Administration and Maintenance PE Provider Edge PHY Physical Layer PSN Packet Switched Network PW Pseudowire SRV Server 4. Problem Statement This document addresses the case of network decomposition related to layering relationship. The scenarios illustrated foresee MPLS-TP network as a server network, IP/MPLS as a client network. Interworking aspects, limitations, issues and open points are described. Note: the presented scenarios are not intended to be comprehensive. Martinotti, et al. Expires May 13, 2010 [Page 4] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 5. Terminology As far as this document is concerned, the following terminology is used: 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. 5.1. Network Layering The following figure illustrates the Network Layering concept: Martinotti, et al. Expires May 13, 2010 [Page 5] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 ____ ___ ___ __ _/ \___/ \ _/ \___/ \___ / \__ / \ /===================\===+ +====/==================\ | |___O------------------O___| | \ ____ /\__/_ _ _ _ _ _ _ _ _ _\__/\ _________/ \______/ \_____/ \/ \/ \______/ Layer n | ___________ | Layer n | / \__ | | / \ | ____ +-0| |0-+ \__/ Adaptation \ __ / __ \_/ \______/ \/ Termination Layer n-1 Network Layering Figure 1 Layer n is carried over Layer n-1, via adaptation and termination functions. Some readers will also call this concept "Overlay model". 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. Connection: ----- Direct connection - - - Virtual connection ..... one or more direct connections Layers: | Termination + Connection OAM: > or < MEP O MIP Figure 2 Martinotti, et al. Expires May 13, 2010 [Page 6] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 7. Network Layering This Section provides some deployment scenarios, using the layering concept described in Section 5. In the rest of this Section the following assumptions apply: o Customer network is carried over IP/MPLS (e.g. via PW encapsulation) o IP/MPLS network is client of MPLS-TP subnetwork 7.1. Ethernet encapsulation over MPLS-TP IP/MPLS network is deployed over Ethernet (at least on interfaces interconnecting to the MPLS-TP subnetwork). The interworking is done via Ethernet frame 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 may be seen as forwarding adjacencies by IGP instance of IP/MPLS networks. The following figure illustrates the functional interworking among the networks: Martinotti, et al. Expires May 13, 2010 [Page 7] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 Networks: Customer Network +---+ - - - - - - - - - - - - - - - - - - - - - - - - - +---+ | _________________________________________________ | |/ IP/MPLS Network \| +---------------+ - - - - - - - - - +---------------+ ^ \______________|___________________|______________/ PW emulation | _________________ | |/ 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 Ethernet encapsulation - Networks view Figure 3 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. The service provided by the MPLS-TP network could be an E-Line service realized via VPWS in case of port based service interface and p2p connectivity between LSR 3 and LSR 7 or multiple E-Line services in case of VLAN based service interface (e.g. LSR3 could be connected to more that one LSRs through the MPLS-TP network). In both of the above cases the LER4 and 6 do not need to know that above the Ethernet layer there is an MPLS LSP. The following figure illustrates the stacking relationship among the technology layers and OAM relationship among the networks: Martinotti, et al. Expires May 13, 2010 [Page 8] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 Layers: |--------+----------------------CLI----------------------+--------| |--SRV--| |---------------------PW----------------------| |--SRV--| |------+--------------LSP--------------+------| |-ETH-| |------+----ETH--------+------| |-ETH-| |-ETY-| |-ETY-| |------PW-----| |-ETY-| |-ETY-| |--LSP-+------| |-ETH-| |-ETH-| |-ETY-| |-ETY-| OAM: (6) >-------------------------------------------< PW (5) >------O-----------------------------O------< LSP (4) >----O-----------------O----< ETH (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 Ethernet encapsulation - Layers and OAM view Figure 4 Several levels of OAM are shown in the previous figure, these are not comprehensive (e.g. Ethernet OAM defines several levels for each layer) and any subset of them MAY be configured in a network. A brief description of the different levels is provided: (6) Edge-to-Edge MPLS OAM on IP/MPLS network (at PW level) (5) Edge-to-Edge MPLS OAM on IP/MPLS network (at LSP level) (4) Router-to-Router Eth 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 May 13, 2010 [Page 9] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 (1) Physical level OAM (MAY be of several kinds) Note that the OAM layers not directly related to MPLS-TP network have been reported just for completeness of the scenario, however their behaviour and interworking are out of scope of this document. Control Plane aspects: In this scenario, IP/MPLS packets are carried over Attachment Circuits (ACs), each of which connects MPLS-TP CE (Node 3 and 7 in Figure 4) and PE (Node 4 and 6), and an Ethernet PW between the PEs. The Ethernet PW is setup over one or more MPLS-TP LSPs. The MPLS-TP network may have its own IGP independent from the IP/MPLS IGP. The Ethernet PW may be advertised by the IP/MPLS IGP as a forwarding adjacency so that it can be used for IP/MPLS path computation. if the MPLS-TP network has a C-plane, it can interwork with the IP/MPLS C-plane via UNI signaling, such as OIF UNI 2.0 [OIF UNI 2.0]. In Figure 4, Node 3 and Node 7 work as UNI-C devices, while Node 4 and Node 6 work as UNI-N devices. It is also possible to implement UNI-C and/or UNI-N function in centralized entities called "UNI Proxies" [OIF UNI 2.0]. The Ethernet PW over MPLS-TP is dynamically setup/ modified/released, typically using PW signaling, in response to the UNI signaling. The MPLS-TP LSP may be statically configured or dynamically setup/modified/released , typically using MPLS-TP signaling, based on its own policy in accordance with the PW status. Open Points: o Interworking between LSP OAM (2), PW OAM (3) and ETH OAM (4) is still to be cleared/defined; it could imply fault indication, alarm suppression, etc. 7.2. Transparent transport of IP/MPLS In this scenario the physical interface between the IP/MPLS and the MPLS-TP network is generic and may be other that Ethernet (e.g. POS); the interworking is done via client LSP packet 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 may be seen as forwarding adjacencies by IGP instance of IP/MPLS networks. The following figure illustrates the functional interworking among the networks: Martinotti, et al. Expires May 13, 2010 [Page 10] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 Networks: Customer Network +---+ - - - - - - - - - - - - - - - - - - - - - - - - - +---+ | _________________________________________________ | |/ IP/MPLS Network \| +---------------+ - - - - - - - - - +---------------+ ^ \______________|___________________|______________/ PW emulation | _________________ | |/ 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 Transparent transport of IP/MPLS - Networks view Figure 5 The LSR 3 and 7 are one hop away from the IP/MPLS layer point of view. This scenario includes at least two cases for data plane implementation. In the first case, IP/MPLS packets are carried over Attachment Circuits (ACs), each of which connects MPLS-TP CE (Node 3 and 7 in Figure 6) and PE (Node 4 and 6), and an IP/MPLS PW between the PEs. The IP/MPLS PW is setup over one or more MPLS-TP LSPs. In the second case, IP/MPLS packets are carried over Attachment Circuits (ACs), each of which connects MPLS-TP CE and PE, and an MPLS-TP LSP which provides the Network Layer Transport Service [draft mpls-tp framework] between the PEs. The first case is described in the following. The service provided by the MPLS-TP network is p2p; client traffic is separated on a per port basis, so that all traffic coming from interface toward LSR 3 is transparently transported to LSR 7 and Martinotti, et al. Expires May 13, 2010 [Page 11] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 viceversa. The client traffic to be encapsulated is both client MPLS packet (client DP) and IP packet (client CP and MP), encapsulation is performed via PWs, that is, one PW is needed for the DP (LSP) and one for the CP/MP (IP). An LSP for IP packets devoted for CP must be pre-configured in order to enable the interworking scenario. If CP interaction between IP/ MPLS and MPLS-TP is not enabled then the LSP for carrying out MPLS packets (client DP) must be pre-configured. 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-+------| |-ETH-| |-ETH-| |-ETY-| |-ETY-| OAM: (5) >-------------------------------------------< PW (4) >------O-----------------------------O------< LSP (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 Transparent transport of IP/MPLS - Layers and OAM view Figure 6 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: Martinotti, et al. Expires May 13, 2010 [Page 12] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 (5) Edge-to-Edge MPLS OAM on IP/MPLS network (at PW level) (4) Edge-to-Edge MPLS OAM on IP/MPLS network (at LSP level) (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) (1) Physical level OAM (MAY be of several kinds) Control Plane aspects: MPLS-TP network may have its own IGP independent from the IP/MPLS IGP. The IP/MPLS PW or the MPLS-TP LSP may be advertised by the IP/ MPLS IGP as a forwarding adjacency so that it can be used for IP/MPLS path computation. If the MPLS-TP network has a C-plane, it can interwork with the IP/MPLS C-plane via UNI signaling, such as OIF UNI 2.0 [OIF UNI 2.0]. In Figure 6, Node 3 and Node 7 work as UNI-C devices, while Node 4 and Node 6 work as UNI-N devices. It is also possible to implement UNI-C and/or UNI-N function in centralized entities called "UNI Proxies" [OIF UNI 2.0]. In the first case mentioned above, the IP/MPLS PW over MPLS-TP is dynamically setup/ modified/released, typically using PW signaling, in response to the UNI signaling. The MPLS-TP LSP may be statically configured or dynamically setup/modified/released, typically using MPLS-TP signaling, based on its own policy in accordance with the PW status. In the second case, the MPLS-TP LSP is dynamically setup/modified/ released, typically using MPLS-TP signaling, in response to the UNI signaling. Open Points: o This scenario needs the definition of MPLS packets and IP packets encapsulation in PW. o This scenario needs extension of the OIF UNI 2.0 to support IP/ MPLS services. o Interworking between MPLS-TP network OAM ((2), (3)) and IP/MPLS network OAM ((4), (5)) is still to be cleared/defined; it could imply fault indication, alarm suppression, etc. o Interaction between IP/MPLS and MPLS-TP CPs is still to be cleared/defined Martinotti, et al. Expires May 13, 2010 [Page 13] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 7.3. IP/MPLS / MPLS-TP hybrid edge node The following main features SHOULD be taken into account: o Two or more client interfaces MAY be involved in the service o Peering of client DP (label swapping of client MPLS packets) o Possible tunneling of MP of client MPLS Layer o Possible peering/tunneling CP of client MPLS Layer o Possible handling of PHP of client MPLS Layer 7.3.1. IP/MPLS does not require PHP from MPLS-TP In this scenario the edge nodes of the MPLS-TP subnetwork are one hop away from the client node of the IP/MPLS network. The following figure illustrates the functional interworking among the networks. Martinotti, et al. Expires May 13, 2010 [Page 14] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 IP/MPLS network does not require PHP from MPLS-TP Networks: Customer Network +---+ - - - - - - - - - - - - - - - - - - - - - - - - - +---+ | _________________________________________________ | |/ IP/MPLS Network \| +---------------+ - - - - - - - - - +---------------+ ^ \______________|___________________|______________/ PW emulation | _________________ | |/ MPLS-TP Network \| +-------------------+ ^ \_________________/ PW emulation 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 7 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 In this scenario, PE nodes of the MPLS-TP network (Node 4 and Node 6 in Figure 8) are hybrid of IP/MPLS LSR and MPLS-TE LER functions. There are at least two cases for data plane implementation between the IP/MPLS LSR function in Node 4 and the one in Node 6. The first case is to use an IP/MPLS PW which is setup over one or more MPLS-TP LSPs. The second case is to use an MPLS-TP LSP which provides the Network Layer Transport Service [draft mpls-tp framework]. The first case is described in the following. Note that this scenario needs the definition of MPLS packets and IP Martinotti, et al. Expires May 13, 2010 [Page 15] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 packets encapsulation in PW (to be discussed, see Open Points). The following figure illustrates the stacking relationship among the technology layers and OAM relationship among the networks: IP/MPLS network does not require PHP from MPLS-TP Layers: |--------+----------------------CLI----------------------+--------| |--SRV--| |---------------------PW----------------------| |--SRV--| |------+-------+------LSP------+-------+------| |-SRV-| |-SRV-| |------PW-----| |-SRV-| |-SRV-| |-LSP--+------| |-ETH-| |-ETH-| |-ETY-| |-ETY-| OAM: (5) >-------------------------------------------< PW (4) >--------------O-------------O--------------< LSP (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 IP/MPLS encapsulation over MPLS-TP - Layers and OAM view Figure 8 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 PW level) (4) Edge-to-Edge MPLS OAM on IP/MPLS network (at LSP level) (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) (1) Physical level OAM (MAY be of several kinds) Control Plane aspects: Martinotti, et al. Expires May 13, 2010 [Page 16] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 The MPLS-TP network may have its own IGP independent from the IP/MPLS IGP. Node 4 and Node 6 may be involved in both the IP/MPLS and MPLS-TP IGPs. The IP/MPLS PW or the MPLS-TP LSP may be advertised by the IP/MPLS IGP as a forwarding adjacency so that it can be used for IP/MPLS path computation. Node 4 and Node 6 may also be involved in the IP/MPLS signaling. An IP/MPLS LSP can be setup by signaling along the route Node 3 - Node 4 - Node 6 - Node 7, and vice versa. The signaling messages may be carried over the IP/MPLS PW or the MPLS-TP LSP. In the first case mentioned above, the IP/MPLS PW and the MPLS-TP LSP may be statically configured or dynamically setup/ modified/released based on their own policies in accordance with the IP/MPLS LSP status. In the second case, the MPLS-TP LSP may be statically configured or dynamically setup/modified/released based on its own policy in accordance with the IP/MPLS LSP status. Open Points: o Interworking between MPLS-TP network OAM ((2), (3)) and IP/MPLS network OAM ((4), (5)) is still to be cleared/defined; it could imply fault indication, alarm suppression, etc. o Interaction between IP/MPLS and MPLS-TP CPs is still to be cleared/defined o MPLS-TP edge nodes provides Forwarding Adjacency to the IP/MPLS network; this handling is left for further study. 7.3.2. IP/MPLS requires PHP from MPLS-TP Note: the following scenario is NOT recommended. In this scenario the edge nodes of the MPLS-TP subnetwork are one hop away from at least one client node (of the IP/MPLS network) requiring PHP. The following figure illustrates the functional interworking among the networks: Martinotti, et al. Expires May 13, 2010 [Page 17] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 IP/MPLS requires PHP from MPLS-TP Networks: Customer Network +---+ - - - - - - - - - - - - - - - - - - - - - - +---+ | ___________________________________________ | |/ IP/MPLS Network (PHP)-> \| +---------------+ - - - - - - - - - +---------+ ^ \______________|___________________|________/ PW emulation | _________________ | |/ MPLS-TP Network \| +-------------------+ ^ \_________________/ PW emulation Nodes: +++++ +++++ + 1 +----+ - - - - - - - - - - - - - - - - - - - - +----+ 8 + +++++ | (PHP)-> | +++++ CE +++++ +++++ +++++ +++++ +++++ CE + 2 +...+ 3 +---+ +- - - - - -+ +-----+ 7 + +++++ +++++ + + + + +++++ LER LSR +LSR+ +++++ +LSR+ LER PE + 4 +...+ 5 +...+ 6 + PE +++++ +++++ +++++ LER LSR LER IP/MPLS encapsulation over MPLS-TP - Network view Figure 9 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 As Node 8 of client IP/MPLS network requires PHP, Node 6 which act as penultimate hop is required to drop LSP label of client IP/MPLS tunnel (indicated in direction from center to right on Node 6). The following figure illustrates the stacking relationship among the technology layers and OAM relationship among the networks: Martinotti, et al. Expires May 13, 2010 [Page 18] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 IP/MPLS requires PHP from MPLS-TP Layers (direction from 1 to 8 shown): |--------+----------------------CLI----------------+--------| |--SRV--| |---------------------PW------(PHP)->---| |--SRV--| |------+-------+------LSP-----| |--SRV--| |-SRV-| |-SRV-| |--PW---------| |-LSP--+------| |-ETH-| |-ETH-| |-ETY-| |-ETY-| OAM: (4) >-------------?---------------?-------< PW (3) >-----------< PW (2) >-----------< LSP (1) >---< >...< >...< >-----< PHY Nodes: +++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++ + 1 +--+ 2 +...+ 3 +---+ 4 +...+ 5 +...+ 6 +-----+ 7 +--+ 8 + +++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++ CE LER LSR LER LSR LER LER CE IP/MPLS encapsulation over MPLS-TP - Layers and OAM view Figure 10 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 OAM on IP/MPLS network (at PW level) (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) (1) Physical level OAM (MAY be of several kinds) Open Issues: o As in the IP/MPLS network the LSP, which is tunneled over MPLS-TP network, is terminated on a Node requiring PHP (Node 8), IP/MPLS OAM cannot be used at LSP level, so monitoring can be performed at PW level. Martinotti, et al. Expires May 13, 2010 [Page 19] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 o Interworking on Node 6 between MPLS-TP OAM and IP/MPLS OAM (at PW level) MAY be performed in egress direction, but its details are out of scope of this document. o Interworking between MPLS-TP OAM and IP/MPLS OAM (at PW level) SHOULD NOT be performed in ingress direction, due to independence of layers. Open Points: o Interworking between MPLS-TP network OAM ((2), (3)) and IP/MPLS network OAM (4) is still to be cleared/defined o Interaction between IP/MPLS and MPLS-TP CPs is still to be cleared/defined o MPLS-TP edge nodes provides Forwarding Adjacency to the IP/MPLS network; this handling is left for further study. 8. Conclusions This document has illustrated some deployment scenarios where a layering raltionship is in place between MPLS-TP (server layer) and IP/MPLS (client layer). Where open points and open issues still appear, the reader is invited to contribute to their resolution. The following scenarios are recommended: Network Layering Ethernet encapsulation over MPLS-TP Transparent transport of IP/MPLS 9. Contributors Alessandro Capello (Telecom Italia). 10. Acknowledgements The authors gratefully acknowledge the input of Attila Takacs (Ericsson). Martinotti, et al. Expires May 13, 2010 [Page 20] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 11. IANA Considerations This memo includes no request to IANA. 12. Security Considerations This document does not introduce any additional security aspects beyond those applicable to PWE3 and MPLS. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 13.2. Informative References [RFC 3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC 5654] Niven-Jenkins, B., Brungard, D., and M. Betts, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. [draft mpls-tp framework] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in Transport Networks", ID draft-ietf-mpls-tp-framework-06, October 2009. [draft mpls-tp oam requirements] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in MPLS Transport Networks", ID draft-ietf-mpls-tp-oam-requirements-03, August 2009. [ITU-T G.805] "Generic functional architecture of transport networks", ID ITU-T G.805, March 2000. [OIF UNI 2.0] Optical Internetworking Forum Implementation Agreement OIF-UNI-02.0-Common, "User Network Interface (UNI) 2.0 Signaling Specification: Common Part", ID OIF UNI 2.0, February 2008. Martinotti, et al. Expires May 13, 2010 [Page 21] Internet-Draft draft-martinotti-mpls-tp-iw-layering-00 November 2009 Authors' Addresses Riccardo Martinotti (editor) 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 Yoshihiko Suemura NEC Corporation of America 14040 Park Center Road Herndon, VA 20171 USA Email: Yoshihiko.Suemura@necam.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 Martinotti, et al. Expires May 13, 2010 [Page 22]