Internet DRAFT - draft-medved-pwe3-of-config
draft-medved-pwe3-of-config
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.
<Payload> \
<Payload-SA> - PW payload
<Payload-DA> /
Next, the iPProc adds the Transport header.
<Payload> \
<Payload-SA> - PW payload
<Payload-DA /
<T-SA, T-DA> - Transport header
The Virtual OF switch then pushes on PW label with S=1.
<Payload> \
<Payload-SA> - PW payload
<Payload-DA> /
<PW Label, S=1> - PW label
<T-SA, T-DA> - Transport header
Finally, the oPProc pushes the Transport label and switches the
packet onto the Transport LSP.
<Payload> \
<Payload-SA> - PW payload
<Payload-DA> /
<PW Label, S=1> - PW label
<T Label, S=0> - Transport label
<T-SA, T-DA> - 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:
<ofp-flow-mod> ::= <ofp-header>
<COOKIE>
<COOKIE_MASK>
<TABLE_ID>
<COMMAND>
<IDLE_TIMEOUT>
<HARD_TIMEOUT>
<PRIORITY>
<BUFFER_ID>
<OUT_PORT>
<OUT_GROUP>
<FLAGS>
<ofp-match>
<instructions>
<ofp-header> ::= <VERSION>
<OFP_MSG_TYPE>
<LENGTH>
<XID>
Medved, et al. Expires January 11, 2013 [Page 11]
Internet-Draft PW Configuration using OpenFlow July 2012
<ofp-match> ::= <MATCH_TYPE>
<MATCH_LENGTH>
<oxm_fields>
<oxm-fields> ::= <oxm-tlv> [<oxm-fields>]
<oxm-tlv> ::= <OXM_CLASS>
<OXM_FIELD>
<OXM_HASHMASK>
<OXM_LENGTH>
<PAYLOAD>
<instructions> ::= <instruction> [<instructions>]
<instruction> ::= ( <ofp-instruction-actions> |
<ofp-instruction-write-metadata> |
<ofp-instruction-goto-table> |
<ofp-instruction-meter> )
<ofp-instruction-actions> ::= <TYPE>
<LEN>
<PAD>
<actions>
<actions> ::= <ofp-action> [<actions>]
<ofp-action> ::= (<ofp-action-output> |
<ofp-action-group> |
<ofp-action-push-mpls> |
<ofp-action-pop-mpls> | ...)
<ofp-action-group> ::= <TYPE>
<LEN>
<GROUP_ID>
<ofp-action-output> ::= <TYPE>
<LEN>
<PORT>
<MAX_LEN>
<ofp-action-push-mpls> ::= <TYPE>
<LEN>
<ETHERTYPE>
<MPLS_HEADER>
<ofp-action-pop-mpls> ::= <TYPE>
<LEN>
Medved, et al. Expires January 11, 2013 [Page 12]
Internet-Draft PW Configuration using OpenFlow July 2012
<ETHERTYPE>
Figure 6: The 'Modify Flow Entry' message
Note that not all action types defined in [OF-1.3.0] for <ofp-action>
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:
<ofp-group-mod> ::= <ofp-header>
<COMMAND>
<GROUP_MSG_TYPE>
<GROUP_ID>
<buckets>
<ofp-header> ::= <VERSION>
<OFP_MSG_TYPE>
<LENGTH>
<XID>
<buckets> ::= <ofp-bucket> [<buckets>]
<ofp-bucket> ::= <LEN>
<WEIGHT>
<WATCH_PORT>
<WATCH_GROUP>
<actions>
<actions> ::= <ofp-action> [<actions>]
<ofp-action> ::= (<ofp-action-output> | <ofp-action-group> | ...)
<ofp-action-output> ::= <TYPE>
<LEN>
<PORT>
<MAX_LEN>
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: <COMMAND> is set to 'OFPGC_ADD' or
'OFPGC_MODIFY', <GROUP_MSG_TYPE> is set to 'OFPGT_FF'(fast
failover group) and <GROUP_ID> 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): <VERSION> is set to 4, <OFP_MSG_TYPE>
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.
<WEIGHT> is set to 1, <WATCH_PORT> is set to [VP1],
<WATCH_GROUP> is set to 'OFPG_ANY'. <action-list> contains a
single item - an <ofp-action-output> 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.
<WEIGHT> is set to 10, <WATCH_PORT> is set to [VP2],
<WATCH_GROUP> is set to 'OFPG_ANY'. <action-list> contains a
single item - an <ofp-action-output> 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
<TABLE_ID> to '1', the value of <COMMAND> 'OFPFC_MODIFY_STRICT',
the value of <BUFFER_ID> to 'OFP_NO_BUFFER', the value of
<OUT_PORT> to 'OFPP_ANY', and the value of <OUT_GROUP> 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): <VERSION> is set to 4, <OFP_MSG_TYPE>
is set to 'OFPT_GROUP_MOD'.
Ofp-Match: The Controller MUST set the <MATCH_TYPE> field to
'OFPMT_OXM' and include a single <oxm-tlv> with the <OXM_CLASS>
field set to 'OFPXMC_OPENFLOW_BASIC', the <OXM_FIELD> field set to
'OFPXMT_OFB_IN_PORT', the <OXM_HASHMASK> field set to '0', and the
<PAYLOAD> field set to [AC1].
Instructions: The Controller MUST set the type field <TYPE> to
'OFPIT_APPLY_ACTIONS' and include the following action list:
Push MPLS Header: the value of <TYPE> set to 'OFPAT_PUSH_LABEL';
the value of <ETHERTYPE> set to MPLS Unicast; the value of
<MPLS_HEADER> set as follows: Label=[PWL1], TTL=1, TC=???, S=1.
Group: the value of <TYPE> set to 'OFPAT_GROUP' and the value of
<GROUP_ID> 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
<TABLE_ID> to '1', the value of <COMMAND> 'OFPFC_MODIFY_STRICT',
the value of <BUFFER_ID> to 'OFP_NO_BUFFER', the value of
<OUT_PORT> to 'OFPP_ANY', and the value of <OUT_GROUP> 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): <VERSION> is set to 4, <OFP_MSG_TYPE>
is set to 'OFPT_GROUP_MOD'.
Ofp-Match: The Controller MUST set the <MATCH_TYPE> field to
'OFPMT_OXM' and include the following <oxm-tlv> match list:
Match Input Port: the value of the <OXM_CLASS> field set to
'OFPXMC_OPENFLOW_BASIC'; the value of the <OXM_FIELD> field set
to 'OFPXMT_OFB_IN_PORT'; the value of the <OXM_HASHMASK> field
set to '0' and the value <PAYLOAD> field set to [VP3] (for the
primary Transport LSP) or [VP4] (for the backup Transport LSP).
Match MPLS Label: the value of the <OXM_CLASS> field set to
'OFPXMC_OPENFLOW_BASIC'; the value of the <OXM_FIELD> field set
to 'OFPXMT_OFB_MPLS_LABEL'; the value of the <OXM_HASHMASK>
field set to '0' and the value <PAYLOAD> 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 <OXM_CLASS> field set to
'OFPXMC_OPENFLOW_BASIC'; the value of the <OXM_FIELD> field set
to 'OFPXMT_OFP_MPLS_BOS'; the value of the <OXM_HASHMASK> field
set to '0' and the value <PAYLOAD> field set to 1.
Instructions: The Controller MUST set the type field <TYPE> to
'OFPIT_APPLY_ACTIONS' and include the following action list:
Pop MPLS Header: the value of <TYPE> set to 'OFPAT_POP_MPLS' and
the value of <ETHERTYPE> set to MPLS Unicast.
Output: the value of <TYPE> set to 'OFPAT_OUTPUT' and the value
of <PORT> 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]
