Network Working Group J. Medved Internet-Draft A. McLachlan Intended status: Informational D. Meyer Expires: January 11, 2013 Cisco Systems July 10, 2012 MPLS-TP Pseudowire Configuration using OpenFlow 1.3 draft-medved-pwe3-of-config-01 Abstract This document describes a method by which MPLS-TP Pseudowires (PW) can be configured in an LER using OpenFlow 1.3. In addition to the configuration of PWs this document also specifies how to enact OAM for these PWs using standard IETF conventions defined by the GAL label method. The primary goal of this document is to provide a simple and yet flexible method for configuring PWs using standardized tools from the emerging SDN toolkit. Status of this Memo This Internet-Draft is submitted 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 January 11, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Medved, et al. Expires January 11, 2013 [Page 1] Internet-Draft PW Configuration using OpenFlow July 2012 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. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Reference Topology . . . . . . . . . . . . . . . . . . . . 5 2.1. The MPLS-TP Node . . . . . . . . . . . . . . . . . . . . . 7 2.1.1. The Virtual OF Switch . . . . . . . . . . . . . . . . 9 2.1.2. The OAM Engine . . . . . . . . . . . . . . . . . . . . 10 3. PW Configuration . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Configuration Messages . . . . . . . . . . . . . . . . . . 11 3.1.1. The Flow Modification Message . . . . . . . . . . . . 11 3.1.2. The Group Modification Message . . . . . . . . . . . . 13 3.2. PW Head-End Node Configuration . . . . . . . . . . . . . . 13 3.2.1. 'Modify Group Entry' Message Details . . . . . . . . . 14 3.2.2. 'Modify Flow Entry' Message Details . . . . . . . . . 15 3.3. PW Tail-End Node Configuration . . . . . . . . . . . . . . 15 3.3.1. 'Modify Flow Entry' Message Details . . . . . . . . . 16 4. PW OAM Considerations . . . . . . . . . . . . . . . . . . . . 17 4.1. OAM Overview . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. PW OAM Engine Configuration . . . . . . . . . . . . . . . 17 4.3. OAM and S-Bit considerations . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. Normative References . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Medved, et al. Expires January 11, 2013 [Page 2] Internet-Draft PW Configuration using OpenFlow July 2012 1. Introduction 1.1. Requirements Language 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 RFC 2119 [RFC2119]. 1.2. Terminology This document uses the following terminology: Term Definition ----------- ---------------------------------------------------- AC: Attachment Circuit ACH: Associated Channel Header BFD: Bidirectional Forwarding Detection CE: Customer Edge G-ACh: Generic Associated Channel GAL: G-ACh Label iPPRoc: input Packet Processing function LER: Label Edge Router LSP: Label Switch Path LSR: Label Switch Router MPLS: Multiprotocol Label Switching MPLS-TP: MPLS Transport Profile MPLS-TP P: MPLS-TP Provider LSR MPLS-TP PE: MPLS-TP Provider Edge LSR PDU: Protocol Data Unit PG: Port Group PSN: Packet Switching Network PW: Pseudowire OAM: Operations, Administration, and Maintenance OAM Engine: Operations, Administration, and Maintenance Engine OF: OpenFlow oPPRoc: output Packet Processing function SDN: Software Defined Networks VP: Virtual Port 1.3. Overview MPLS-TP provides a relatively light weight layer 2 transport technology by leveraging elements of existing transport platforms and a subset of the more recent MPLS protocol standards. PWs are configured as bi-directional paths over the MPLS-TP network, usually by an external management platform. At present no open standards Medved, et al. Expires January 11, 2013 [Page 3] Internet-Draft PW Configuration using OpenFlow July 2012 exist to provision these PWs, and therefore there is a reliance on vendor specific provisioning platforms. It should be noted that there exists alternative methods for the static provisioning of PWs, including via SNMP ([RFC5601]). This document describes a mechanism that uses the emerging OpenFlow standard ([OF-1.3.0]) to provision PWs and PW OAM at a Label Edge Router (LER) in a MPLS-TP environment. The method described here uses standard MPLS-TP control planes. In particular, this document does not specify new control planes for either MPLS-TP or for PW setup (e.g., T-LDP as specified in [RFC6373]). Naturally the implementation of OpenFlow will be required on the TP switch, as would an OAM Engine, the functions of which are described in this document. In addition, an OpenFlow Controller will be required for the provisioning functions. Because OpenFlow is an open standard, it enables Service Providers to adopt a more consolidated approach to provisioning. An OpenFlow Controller can be common to a number of different elements in the network, as being driven by current industry Software Defined Networks (SDN) developments. This document uses the reference MPLS-TP architecture defined in [RFC5921], which is shown in the following figure: Medved, et al. Expires January 11, 2013 [Page 4] Internet-Draft PW Configuration using OpenFlow July 2012 |<----------------- Client Layer ------------------->| | | | |<-------- Pseudowire -------->| | | | encapsulated, packet | | | | transport service | | | | | | | | Transport | | | | |<------ LSP ------->| | | | V V V V | V ^ +----+ +-----+ +----+ ^ V +-----+ | | PE1|=======\ /========| PE2| | +-----+ | | |.......PW1.| \ / |............| | | | | CE1 |----------| | | X | | |----------| CE2 | | | | |.......PW2.| / \ |............| | | | +-----+ | | |=======/ \========| | | +-----+ ^ | +----+ ^ +-----+ +----+ | ^ | | Provider | ^ Provider | | | | Edge 1 | | Edge 2 | | Customer | | P Router | Customer Edge 1 | TE LSP | Edge 2 | | | | AC AC Figure 1: MPLS-TP Architecture (Single Segment PW) from RFC5921 A Pseudowire (PW) is configured between an ingress attachment circuit on a head-end switch (Provider Edge 1, PE1) and an egress attachment circuit on a tail-end node (Provider Edge 2, PE2). For a complete service, a PW must be configured in each direction. 2. The Reference Topology Relevant components from the above architecture diagram for LERs are shown in the reference topology in Figure 2. For clarity, only one of the two PWs that constitute a complete service is shown in the reference topology and discussed in subsequent sections: the PW from Provider Edge 1 (Head-End Node) to Provider Edge 2 (Tail-End Node). A PW in the opposite direction (from PE2 to PE1) would be configured similarly. Medved, et al. Expires January 11, 2013 [Page 5] Internet-Draft PW Configuration using OpenFlow July 2012 PW PW End Service End Service <------------------------- Pseudowire ------------------------> | | | +------------------------+ | | | Management Application | | | +------------A-----------+ | | | | | +-------V-------+ | | +----------->| OF Controller |<-----------+ | | | +---------------+ | | V | | V +---------V---------+ +---------V---------+ | | Primary T-LSP | | | [VP1]*********************[VP3] | -->[AC1] | Backup T-LSP | [AC2]--> | [VP2]*********************[VP4] | | Head-End Node | | Tail-End Node | | (PE1) | | (PE2) | +-------------------+ +-------------------+ Figure 2: Reference topology Pseudowires are configured from a network / provisioning Management Application which communicates with MPLS-TP nodes through an OpenFlow Controller (OF Controller). The Management Application configures an end-to-end Pseudowire ([PW1]) between Attachment Circuit [AC1] on the headend node and Attachment Circuit [AC2] on the tail-end node. At the head-end, all traffic coming from an input port (Attachment Circuit [AC1]) is switched onto the PW, and at the tail-end all traffic coming from the Pseudowire is switched to an output port (Attachment Circuit [AC2]). The Pseudowire is assigned a PW Label [PWL1]. The Management Application configures both packet forwarding and OAM function related to Pseudowires. In the reference topology, the head-end and tail-end nodes are connected via a pair of transport LSPs - a primary Transport LSP (T-LSP) and a backup Transport LSP. Configuration and setup of transport the LSPs is outside the scope of this document. Tunnels are represented as Virtual Ports; in OpenFlow parlance, a function that performs functionality outside the OpenFlow specification is called a "virtual port" (see Section B.9.4 of [OF-1.3.0]). Here [VP1] and [VP2] are virtual ports on the head-end node, and [VP3] and [VP4] are virtual ports on the tail-end node. Medved, et al. Expires January 11, 2013 [Page 6] Internet-Draft PW Configuration using OpenFlow July 2012 2.1. The MPLS-TP Node A reference MPLS-TP Node has three major programmable components: a Virtual OF Switch, an OAM Engine, and Packet Processing functions attached to input and output ports of the Virtual OF Switch. The MPLS-TP node shown in the following figure. +------------+ | Controller | +------------+ | V +----------------------------------------------------------+ | +-------------------+ | --+->[iPProc]->[In]->| |->[Out]--[oPProc]-+-> | | | | --+->[iPProc]->[In]->| Virtual OF Switch |->[Out]->[oPProc]-+-> | | | | | +--->[In]->| |->[Out]--+ | | | +-------------------+ | | | | +---------------+ | | | +-----------| OAM Engine |<-----------+ | | +---------------+ | | MPLS-TP Node | +----------------------------------------------------------+ Figure 3: MPLS-TP Node Components The Virtual OF Switch performs packet switching. It is controlled by an external controller, which in turn is driven by an MPLS-TP Management Application. Packets arrive at the Virtual OF Switch through a virtual port consisting of an Attachment Circuits followed by an input Packet Processing function (iPProc). The the iPProc encapsulates arriving packets on the Attachment Circuit in the outer transport (Ethernet) header. This is required because OpenFlow can only push MPLS labels onto the top of a label stack encapsulated in an existing Ethernet header. Furthermore, since OpenFlow cannot push an Ethernet header (see Section 5.12 of [OF-1.3.0]), the encapsulation must be done in a virtual port in order to construct a valid packet. Note also that while pushing and popping MPLS labels is optional functionality in the OpenFlow specification, it is required to support the functionality described in this document. When a packet arrives on an Attachment Circuit, say [AC1], the iPProc function receives the packet and encapsulates it in what will become the outer transport header. The packet is then handed to the Virtual Medved, et al. Expires January 11, 2013 [Page 7] Internet-Draft PW Configuration using OpenFlow July 2012 OF Switch which can now push the PW label onto the packet. Note that for purposes of this revision of this document it is assumed that the controller (and hence the Virtual OF Switch) receives PW label out- of-band. The packet is then output to a virtual port in which the oPProc pushes the appropriate Transport label and switches the packet onto the Transport LSP. This sequence is depicted in Figure 4. Finally, while it is in principle possible for the OF Switch to also push the Transport label, the design decision taken here is push the Transport label in a virtual port in order to keep the OF Switch as simple as possible; in this case by limiting it to one table. A packet initially arrives at the AC with the following headers and payload. This packet becomes the PW payload. \ - PW payload / Next, the iPProc adds the Transport header. \ - PW payload - Transport header The Virtual OF switch then pushes on PW label with S=1. \ - PW payload / - PW label - Transport header Finally, the oPProc pushes the Transport label and switches the packet onto the Transport LSP. \ - PW payload / - PW label - Transport label - Transport header Figure 4: Input Encapsulation Sequence When receiving a packet on a Transport LSP, the iPProc pops the Medved, et al. Expires January 11, 2013 [Page 8] Internet-Draft PW Configuration using OpenFlow July 2012 Transport label from packets exiting the Transport LSP (again, the choice to pop the Transport label in the iPProc is to limit the OF switch one table). The PW Label is subsequently popped by the Virtual OF switch. Finally, the oPProc receives the packet sent to the virtual port, strips the transport header from the outgoing packet and delivers it to the Attachment Circuit. The OAM Engine generates and receives&processes OAM packets. It can perform OAM functions for both Pseudowires and Transport LSPs. At the head-end node, the OAM Engine is connected to a Virtual OF Switch input port. OAM packets are switched through the Virtual OF Switch either onto either Pseudowires or onto the transport LSPs. At the tail-end node, the OAM Engine is connected to a Virtual OF Switch output port. OAM packets are switched either from transport LSPs or Pseudowires to the OAM Engine. The tail-end node OAM Engine detects failure conditions. The head-end OAM Engine performs corrective actions. 2.1.1. The Virtual OF Switch The Virtual OF switch is comprised of a single flow table (Flow Table 1) and a single group table. The Virtual OF Switch is shown in the following figure. +------------+ | Controller | +------------+ | V +-----------------------------------------+ | +-------+ +-------+ | --+--->[In]->| | | |->[Out]---+-- | | Flow | | Group | | --+--->[In]->| Table |-->| Table |->[Out]---+-- | | 1 | | | | --+--->[In]->| | | |->[Out]---+-- | +-------+ +-------+ | | Virtual OF Switch | +-----------------------------------------+ Figure 5: The Virtual OF Switch Although the Virtual OF switch is the same at both the head-end and tail-end nodes, the group table is only used at the head-end node, where a Fast Failover group is set up for each pair of ports that correspond to the primary-backup Transport LSP pair. At the tail-end node, only flows are set up. Medved, et al. Expires January 11, 2013 [Page 9] Internet-Draft PW Configuration using OpenFlow July 2012 Transport LSPs are identified as virtual ports to the OF controller. For the Reference Topology in Figure 2, the primary transport LSP is identified to OpenFlow as Virtual Port [VP1] and the backup transport LSP is identified as Virtual Port [VP2]. At the head-end switch in the Reference Topology a Fast Failover group [PG1] is set up for ports [VP1] and [VP2]. The Virtual OF Switch MUST support the following OFPXMC_OPENFLOW_BASIC match fields ([OF-1.3.0], Section A.2.3.7): o Match on Switch Input Port (OFPXMT_OFB_IN_PORT) o Match on MPLS Label (OFPXMT_OFB_MPLS_LABEL) o Match on MPLS BoS bit (OFPXMT_OFP_MPLS_BOS) o Match on Ethertype (OXM_OF_ETH_TYPE) The Virtual OF Switch must support the following OF actions ([OF-1.3.0], Section A.2.5): o Output to switch port (OFPAT_OUTPUT) o Push a new MPLS tag (OFPAT_PUSH_MPLS) o Pop the outer MPLS tag (OFPAT_POP_MPLS) o Apply group (OFPAT_GROUP) 2.1.2. The OAM Engine The liveness of Transport LSPs and PWs are monitored by OAM. The desired model is to have an OAM engine residing locally on the switch. At the ingress to a PW the OAM Engine will inject OAM packets into the PW data path. At the egress of a PW the switch will detect OAM packets (performing a flow-match operation) and punt OAM packets to the OAM Engine, which will evaluate them, and if need be perform corrective action and/or produce notifications. The OAM function for Transport LSPs is out of scope for this revision of this document. However, PW-OAM mechanisms described in this document could also applicable to Transport LSP-OAM. In addition to generating and processing OAM packets, the OAM Engine participates in the liveness monitoring function (see Section 6.6 of [OF-1.3.0]) for virtual port Fast Failover groups at the head-end switch. When the OAM Engine detects a PW failure, it triggers the Virtual OF Switch to move traffic from the primary transport LSP's Medved, et al. Expires January 11, 2013 [Page 10] Internet-Draft PW Configuration using OpenFlow July 2012 virtual port [VP1] to the backup transport LSP's virtual port [VP2]. The OAM Engine's liveness monitoring function is described in more detail in [OF-1.3.0]. Note that in addition to the OAM Engine, the Virtual OF Switch MAY use other liveness monitoring mechanisms for the virtual port Fast Failover groups, which are out of scope of this document. 3. PW Configuration 3.1. Configuration Messages The Controller uses OpenFlow protocol messages defined in [OF-1.3.0] to configure transport pseudo-wires. The Flow Modification message and the Group Modification message types are used. To configure a PW at the head-end node, the Controller uses a sequence of a Group Modification message followed by a Flow Modification message. At the tail-end node, the Controller uses Flow Modification messages only. The message formats in this document are specified using Routing Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 3.1.1. The Flow Modification Message The Flow Modification message - 'Modify Flow Entry' - is defined in [OF-1.3.0], Section A.3.4.1 as follows: ::= ::= Medved, et al. Expires January 11, 2013 [Page 11] Internet-Draft PW Configuration using OpenFlow July 2012 ::= ::= [] ::= ::= [] ::= ( | | | ) ::= ::= [] ::= ( | | | | ...) ::= ::= ::= ::= Medved, et al. Expires January 11, 2013 [Page 12] Internet-Draft PW Configuration using OpenFlow July 2012 Figure 6: The 'Modify Flow Entry' message Note that not all action types defined in [OF-1.3.0] for are listed in Figure 6. 3.1.2. The Group Modification Message The Group Modification message - 'Modify Group Entry' - is defined in [OF-1.3.0], Section A.3.4.2 as follows: ::= ::= ::= [] ::= ::= [] ::= ( | | ...) ::= Figure 7: The 'Modify Group Entry' message 3.2. PW Head-End Node Configuration Consider the reference topology in Figure 2. The Management Application will configure a cross-connect between the Attachment Circuit [AC1] and the virtual port pair {[VP1], [VP2]} joined in the Fast Failover group [PG1]. The cross-connect determines that traffic Medved, et al. Expires January 11, 2013 [Page 13] Internet-Draft PW Configuration using OpenFlow July 2012 from Port AC will be switched to Group PG1. The internal mechanism in Group PG1 (outside the scope of this document) will determine whether traffic will go out on Port [VP1] (the primary transport LSP) or on Port [VP2] (the backup transport LSP). The Management Application uses the following message sequence to create the cross-connect: 1. The 'Modify Group Entry' message, defined in Figure 7 creates or modifies an entry in the Group Table. Each entry in the Group Table corresponds to a pair of virtual ports that correspond to a pair of primary / backup transport LSPs. This entry states that as long as Port [VP1] is alive, traffic coming to group [PG1] will go out on [VP1]. If Port [VP1] is not alive AND Port [VP2] is alive, then traffic coming to group [PG1] will go out on Port [VP2]. If neither of the ports are alive, traffic will be dropped. Note that it's up to the switch to determine that a given port is alive - and it can use any mechanism that it wants to do that. 2. The 'Modify Flow Entry' message, defined in Figure 6, adds an entry to Flow Table 1 for a flow that matches traffic from Input Port [AC1]. The actions for the flow are 1.) Push the PW MPLS header on the packet, and 2.) Forward the packet to Group [PG1], which was setup in Step 1). The following sections describe in details each message. 3.2.1. 'Modify Group Entry' Message Details The fields in the 'Modify Group Entry' message are set as follows:> 'Modify Group Entry' message: is set to 'OFPGC_ADD' or 'OFPGC_MODIFY', is set to 'OFPGT_FF'(fast failover group) and is set to the identifier of the Fast Failover group that was setup for the primary and secondary transport LSPs - [PG1]. OpenFlow Header (ofp-header): is set to 4, is set to 'OFPT_GROUP_MOD'. Buckets: there are two action buckets - Bucket1 and Bucket2: Bucket1 is associated with the virtual port corresponding to the primary transport LSP, and its fields are set as follows. is set to 1, is set to [VP1], is set to 'OFPG_ANY'. contains a single item - an to Virtual Port [VP1]. Medved, et al. Expires January 11, 2013 [Page 14] Internet-Draft PW Configuration using OpenFlow July 2012 Bucket2 is associated with the virtual port corresponding to the backup transport LSP, and its fields are set as follows. is set to 10, is set to [VP2], is set to 'OFPG_ANY'. contains a single item - an to Virtual Port [VP2]. 3.2.2. 'Modify Flow Entry' Message Details The fields in the Modify Flow Entry' message are set as follows: 'Modify Flow Entry' message: The controller MUST set the value of to '1', the value of 'OFPFC_MODIFY_STRICT', the value of to 'OFP_NO_BUFFER', the value of to 'OFPP_ANY', and the value of to 'OFPG_ANY'. The Controller SHOULD set the values of all other atomic fields to appropriate values as required by the operation of the configuration protocol. It is recommended that the 'IDLE_TIMEOUT' and 'HARD_TIMEOUT' fields are set to 0 for persistant PW configurations OpenFlow Header (ofp-header): is set to 4, is set to 'OFPT_GROUP_MOD'. Ofp-Match: The Controller MUST set the field to 'OFPMT_OXM' and include a single with the field set to 'OFPXMC_OPENFLOW_BASIC', the field set to 'OFPXMT_OFB_IN_PORT', the field set to '0', and the field set to [AC1]. Instructions: The Controller MUST set the type field to 'OFPIT_APPLY_ACTIONS' and include the following action list: Push MPLS Header: the value of set to 'OFPAT_PUSH_LABEL'; the value of set to MPLS Unicast; the value of set as follows: Label=[PWL1], TTL=1, TC=???, S=1. Group: the value of set to 'OFPAT_GROUP' and the value of set to [PG1]. 3.3. PW Tail-End Node Configuration Consider the reference topology in Figure 2. The Management Application will configure two cross-connects: one cross-connect between the primary Transport LSP's virtual port ([VP3]) and the Attachment Circuit [AC2], and one between the primary transport LSP's virtual port ([VP3]) and the Attachment Circuit [AC2]. Under normal circumstances, traffic will arrive at the primary Transport LSP's Virtual Port [VP3]. When the primary Transport LSP is not available Medved, et al. Expires January 11, 2013 [Page 15] Internet-Draft PW Configuration using OpenFlow July 2012 and the backup Transport LSP is ok, traffic will arrive at the backup Transport LSP's Virtual Port [VP4]. Note that the cross-connect between the backup Transport LSP's Virtual Port [VP4] and the Attachment Circuit [AC2] can be programmed along with the cross-connect between the primary Transport LSP's Virtual Port [VP3] and the Attachment Circuit [AC2], or at the time when the primary Transport LSP's Virtual Port [VP3] goes down. The cross-connects between the primary Transport LSP's Virtual Port [VP3] and the Attachment Circuit [AC2], and between the backup transport LSP's Virtual Port [VP4] and the Attachment Circuit [AC2] are programmed by sending 'Modify Flow Entry' messages to the switch. Programming details are described in the following section. 3.3.1. 'Modify Flow Entry' Message Details The fields in the Modify Flow Entry' messages are set as follows: 'Modify Flow Entry' message: The controller MUST set the value of to '1', the value of 'OFPFC_MODIFY_STRICT', the value of to 'OFP_NO_BUFFER', the value of to 'OFPP_ANY', and the value of to 'OFPG_ANY'. The Controller SHOULD set the values of all other atomic fields to appropriate values as required by the operation of the configuration protocol. It is recommended that the 'IDLE_TIMEOUT' and 'HARD_TIMEOUT' fields are set to 0 for persistant PW configurations OpenFlow Header (ofp-header): is set to 4, is set to 'OFPT_GROUP_MOD'. Ofp-Match: The Controller MUST set the field to 'OFPMT_OXM' and include the following match list: Match Input Port: the value of the field set to 'OFPXMC_OPENFLOW_BASIC'; the value of the field set to 'OFPXMT_OFB_IN_PORT'; the value of the field set to '0' and the value field set to [VP3] (for the primary Transport LSP) or [VP4] (for the backup Transport LSP). Match MPLS Label: the value of the field set to 'OFPXMC_OPENFLOW_BASIC'; the value of the field set to 'OFPXMT_OFB_MPLS_LABEL'; the value of the field set to '0' and the value field set to [PWL1]. Medved, et al. Expires January 11, 2013 [Page 16] Internet-Draft PW Configuration using OpenFlow July 2012 Match BoS bit: the value of the field set to 'OFPXMC_OPENFLOW_BASIC'; the value of the field set to 'OFPXMT_OFP_MPLS_BOS'; the value of the field set to '0' and the value field set to 1. Instructions: The Controller MUST set the type field to 'OFPIT_APPLY_ACTIONS' and include the following action list: Pop MPLS Header: the value of set to 'OFPAT_POP_MPLS' and the value of set to MPLS Unicast. Output: the value of set to 'OFPAT_OUTPUT' and the value of set to [AC2]. 4. PW OAM Considerations 4.1. OAM Overview OAM for MPLS-TP is an important consideration and needs to be addressed in a scalable manner and needs to function with the same performance available today. Centralization of control or digestion of OAM messages, where they are redirected back to a central controller will introduce delay. Therefore the goal is to drive OAM setup for PWs using messages from the Controller to the Switch. The functions of the OAM, for example OAM packet generation, error detection, action/notification will therefore still reside locally on the switch. [RFC6423] is used as a reference for unified OAM for MPLS-TP, in particular Section 3, which includes provision for GAL with PW in MPLS-TP. [RFC5860] lists OAM requirements for MPLS Transport networks. 4.2. PW OAM Engine Configuration If OAM is required on a particular PW it requires only a small number of configuration actions on the OAM Engine and on the Virtual OF Switch. o The head-end OAM Engine is programmed to generate OAM packets for the PW. The header for these packets will composed of at least 2 labels, the first being the PW label for which the OAM is being generated, and the following label being the GAL label (13). The contents of the GACH packet are out of scope for this draft and will be down to the individual OAM implementation. Medved, et al. Expires January 11, 2013 [Page 17] Internet-Draft PW Configuration using OpenFlow July 2012 o At the head-end Virtual OF switch, a flow is programmed for each Pseudowire to switch the OAM packets generated by the OAM Engine to their respective destination PW. As the PW label is being placed on the OAM packet, we can easily match on this and forward the OAM packet down the correct PW to ensure it follows the same data path. o At the tail-end Virtual OF switch, a single flow is programmed to switch all received OAM packets to the OAM Engine. The match criteria on the flow is the MPLS BoS bit set to 0, which means that a GAL label is present on the packet. This flow MUST have higher priority than any flow matching on a PW label. o The tail-end OAM Engine is programmed to receive OAM packets, check that a valid PW label is present on the packet and to detect failures. OAM mechanisms that can be implemented by the OAM Engine are out of scope for this revision of the document. For example, the OAM Engine can also implement BFD (Echo) Mode [RFC5880] where echo packets are returned via the remote forwarding plane, which can be done using an OF match rule. 4.3. OAM and S-Bit considerations In order to ensure that the switch can identify the last label in the stack the S bit needs to be set on the label which will be at the bottom of the stack. The OAM Engine will be required to set the S bit on the GAL label (13) to ensure that the subsequent G-ACh packet is treated correctly. By using OF actions to move all OAM Engine packets into the PW we ensure that not only all types of OAM are supported transparently, but also that the S bit is correctly set. 5. IANA Considerations This document does not introduce any IANA requirements. 6. Security Considerations Procedures described in this document do not change the OpenFlow protocol security model described in [OF-1.3.0], Section 6.3. A secure communications channel SHOULD be set up between the controller and the MPLS-TP node. Medved, et al. Expires January 11, 2013 [Page 18] Internet-Draft PW Configuration using OpenFlow July 2012 7. Acknowledgements The authors would like to thank Frank Brockners, Dan Frost, Giles Heron, Zoltan Lajos Kis, Andy Malis, Yakov Stein, Joe Tardo, Sasha Vainshtein and Dave Ward for their review and insightful comments. 8. Normative References [OF-1.3.0] Open Networking Foundation, "OpenFlow Switch Specification, Version 1.3.0 (Wire Protocol 0x04)", April 16, 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009. [RFC5601] Nadeau, T. and D. Zelig, "Pseudowire (PW) Management Information Base (MIB)", RFC 5601, July 2009. [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010. [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. Gray, "MPLS Transport Profile (MPLS-TP) Control Plane Framework", RFC 6373, September 2011. [RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)", RFC 6423, November 2011. Medved, et al. Expires January 11, 2013 [Page 19] Internet-Draft PW Configuration using OpenFlow July 2012 Authors' Addresses Jan Medved Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: jmedved@cisco.com Andrew McLachlan Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: amclachl@cisco.com David Meyer Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: dmm@cisco.com Medved, et al. Expires January 11, 2013 [Page 20]