idnits 2.17.1 draft-medved-pwe3-of-config-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 10, 2012) is 4300 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PW1' is mentioned on line 221, but not defined == Missing Reference: 'AC1' is mentioned on line 648, but not defined == Missing Reference: 'AC2' is mentioned on line 727, but not defined == Missing Reference: 'PWL1' is mentioned on line 713, but not defined == Missing Reference: 'VP1' is mentioned on line 619, but not defined == Missing Reference: 'VP2' is mentioned on line 625, but not defined == Missing Reference: 'VP3' is mentioned on line 707, but not defined == Missing Reference: 'VP4' is mentioned on line 708, but not defined == Missing Reference: 'PG1' is mentioned on line 658, but not defined Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Medved 3 Internet-Draft A. McLachlan 4 Intended status: Informational D. Meyer 5 Expires: January 11, 2013 Cisco Systems 6 July 10, 2012 8 MPLS-TP Pseudowire Configuration using OpenFlow 1.3 9 draft-medved-pwe3-of-config-01 11 Abstract 13 This document describes a method by which MPLS-TP Pseudowires (PW) 14 can be configured in an LER using OpenFlow 1.3. In addition to the 15 configuration of PWs this document also specifies how to enact OAM 16 for these PWs using standard IETF conventions defined by the GAL 17 label method. The primary goal of this document is to provide a 18 simple and yet flexible method for configuring PWs using standardized 19 tools from the emerging SDN toolkit. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 11, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. The Reference Topology . . . . . . . . . . . . . . . . . . . . 5 60 2.1. The MPLS-TP Node . . . . . . . . . . . . . . . . . . . . . 7 61 2.1.1. The Virtual OF Switch . . . . . . . . . . . . . . . . 9 62 2.1.2. The OAM Engine . . . . . . . . . . . . . . . . . . . . 10 63 3. PW Configuration . . . . . . . . . . . . . . . . . . . . . . . 11 64 3.1. Configuration Messages . . . . . . . . . . . . . . . . . . 11 65 3.1.1. The Flow Modification Message . . . . . . . . . . . . 11 66 3.1.2. The Group Modification Message . . . . . . . . . . . . 13 67 3.2. PW Head-End Node Configuration . . . . . . . . . . . . . . 13 68 3.2.1. 'Modify Group Entry' Message Details . . . . . . . . . 14 69 3.2.2. 'Modify Flow Entry' Message Details . . . . . . . . . 15 70 3.3. PW Tail-End Node Configuration . . . . . . . . . . . . . . 15 71 3.3.1. 'Modify Flow Entry' Message Details . . . . . . . . . 16 72 4. PW OAM Considerations . . . . . . . . . . . . . . . . . . . . 17 73 4.1. OAM Overview . . . . . . . . . . . . . . . . . . . . . . . 17 74 4.2. PW OAM Engine Configuration . . . . . . . . . . . . . . . 17 75 4.3. OAM and S-Bit considerations . . . . . . . . . . . . . . . 18 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 79 8. Normative References . . . . . . . . . . . . . . . . . . . . . 19 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 82 1. Introduction 84 1.1. Requirements Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 1.2. Terminology 92 This document uses the following terminology: 94 Term Definition 95 ----------- ---------------------------------------------------- 97 AC: Attachment Circuit 98 ACH: Associated Channel Header 99 BFD: Bidirectional Forwarding Detection 100 CE: Customer Edge 101 G-ACh: Generic Associated Channel 102 GAL: G-ACh Label 103 iPPRoc: input Packet Processing function 104 LER: Label Edge Router 105 LSP: Label Switch Path 106 LSR: Label Switch Router 107 MPLS: Multiprotocol Label Switching 108 MPLS-TP: MPLS Transport Profile 109 MPLS-TP P: MPLS-TP Provider LSR 110 MPLS-TP PE: MPLS-TP Provider Edge LSR 111 PDU: Protocol Data Unit 112 PG: Port Group 113 PSN: Packet Switching Network 114 PW: Pseudowire 115 OAM: Operations, Administration, and Maintenance 116 OAM Engine: Operations, Administration, and Maintenance Engine 117 OF: OpenFlow 118 oPPRoc: output Packet Processing function 119 SDN: Software Defined Networks 120 VP: Virtual Port 122 1.3. Overview 124 MPLS-TP provides a relatively light weight layer 2 transport 125 technology by leveraging elements of existing transport platforms and 126 a subset of the more recent MPLS protocol standards. PWs are 127 configured as bi-directional paths over the MPLS-TP network, usually 128 by an external management platform. At present no open standards 129 exist to provision these PWs, and therefore there is a reliance on 130 vendor specific provisioning platforms. It should be noted that 131 there exists alternative methods for the static provisioning of PWs, 132 including via SNMP ([RFC5601]). 134 This document describes a mechanism that uses the emerging OpenFlow 135 standard ([OF-1.3.0]) to provision PWs and PW OAM at a Label Edge 136 Router (LER) in a MPLS-TP environment. The method described here 137 uses standard MPLS-TP control planes. In particular, this document 138 does not specify new control planes for either MPLS-TP or for PW 139 setup (e.g., T-LDP as specified in [RFC6373]). Naturally the 140 implementation of OpenFlow will be required on the TP switch, as 141 would an OAM Engine, the functions of which are described in this 142 document. In addition, an OpenFlow Controller will be required for 143 the provisioning functions. 145 Because OpenFlow is an open standard, it enables Service Providers to 146 adopt a more consolidated approach to provisioning. An OpenFlow 147 Controller can be common to a number of different elements in the 148 network, as being driven by current industry Software Defined 149 Networks (SDN) developments. 151 This document uses the reference MPLS-TP architecture defined in 152 [RFC5921], which is shown in the following figure: 154 |<----------------- Client Layer ------------------->| 155 | | 156 | |<-------- Pseudowire -------->| | 157 | | encapsulated, packet | | 158 | | transport service | | 159 | | | | 160 | | Transport | | 161 | | |<------ LSP ------->| | | 162 | V V V V | 163 V ^ +----+ +-----+ +----+ ^ V 164 +-----+ | | PE1|=======\ /========| PE2| | +-----+ 165 | | |.......PW1.| \ / |............| | | | 166 | CE1 |----------| | | X | | |----------| CE2 | 167 | | | |.......PW2.| / \ |............| | | | 168 +-----+ | | |=======/ \========| | | +-----+ 169 ^ | +----+ ^ +-----+ +----+ | ^ 170 | | Provider | ^ Provider | | 171 | | Edge 1 | | Edge 2 | | 172 Customer | | P Router | Customer 173 Edge 1 | TE LSP | Edge 2 174 | | 175 | | 176 AC AC 178 Figure 1: MPLS-TP Architecture (Single Segment PW) from RFC5921 180 A Pseudowire (PW) is configured between an ingress attachment circuit 181 on a head-end switch (Provider Edge 1, PE1) and an egress attachment 182 circuit on a tail-end node (Provider Edge 2, PE2). For a complete 183 service, a PW must be configured in each direction. 185 2. The Reference Topology 187 Relevant components from the above architecture diagram for LERs are 188 shown in the reference topology in Figure 2. For clarity, only one 189 of the two PWs that constitute a complete service is shown in the 190 reference topology and discussed in subsequent sections: the PW from 191 Provider Edge 1 (Head-End Node) to Provider Edge 2 (Tail-End Node). 192 A PW in the opposite direction (from PE2 to PE1) would be configured 193 similarly. 195 PW PW 196 End Service End Service 197 <------------------------- Pseudowire ------------------------> 198 | | 199 | +------------------------+ | 200 | | Management Application | | 201 | +------------A-----------+ | 202 | | | 203 | +-------V-------+ | 204 | +----------->| OF Controller |<-----------+ | 205 | | +---------------+ | | 206 V | | V 207 +---------V---------+ +---------V---------+ 208 | | Primary T-LSP | | 209 | [VP1]*********************[VP3] | 210 -->[AC1] | Backup T-LSP | [AC2]--> 211 | [VP2]*********************[VP4] | 212 | Head-End Node | | Tail-End Node | 213 | (PE1) | | (PE2) | 214 +-------------------+ +-------------------+ 216 Figure 2: Reference topology 218 Pseudowires are configured from a network / provisioning Management 219 Application which communicates with MPLS-TP nodes through an OpenFlow 220 Controller (OF Controller). The Management Application configures an 221 end-to-end Pseudowire ([PW1]) between Attachment Circuit [AC1] on the 222 headend node and Attachment Circuit [AC2] on the tail-end node. At 223 the head-end, all traffic coming from an input port (Attachment 224 Circuit [AC1]) is switched onto the PW, and at the tail-end all 225 traffic coming from the Pseudowire is switched to an output port 226 (Attachment Circuit [AC2]). The Pseudowire is assigned a PW Label 227 [PWL1]. The Management Application configures both packet forwarding 228 and OAM function related to Pseudowires. 230 In the reference topology, the head-end and tail-end nodes are 231 connected via a pair of transport LSPs - a primary Transport LSP 232 (T-LSP) and a backup Transport LSP. Configuration and setup of 233 transport the LSPs is outside the scope of this document. Tunnels 234 are represented as Virtual Ports; in OpenFlow parlance, a function 235 that performs functionality outside the OpenFlow specification is 236 called a "virtual port" (see Section B.9.4 of [OF-1.3.0]). Here 237 [VP1] and [VP2] are virtual ports on the head-end node, and [VP3] and 238 [VP4] are virtual ports on the tail-end node. 240 2.1. The MPLS-TP Node 242 A reference MPLS-TP Node has three major programmable components: a 243 Virtual OF Switch, an OAM Engine, and Packet Processing functions 244 attached to input and output ports of the Virtual OF Switch. The 245 MPLS-TP node shown in the following figure. 247 +------------+ 248 | Controller | 249 +------------+ 250 | 251 V 252 +----------------------------------------------------------+ 253 | +-------------------+ | 254 --+->[iPProc]->[In]->| |->[Out]--[oPProc]-+-> 255 | | | | 256 --+->[iPProc]->[In]->| Virtual OF Switch |->[Out]->[oPProc]-+-> 257 | | | | 258 | +--->[In]->| |->[Out]--+ | 259 | | +-------------------+ | | 260 | | +---------------+ | | 261 | +-----------| OAM Engine |<-----------+ | 262 | +---------------+ | 263 | MPLS-TP Node | 264 +----------------------------------------------------------+ 266 Figure 3: MPLS-TP Node Components 268 The Virtual OF Switch performs packet switching. It is controlled by 269 an external controller, which in turn is driven by an MPLS-TP 270 Management Application. 272 Packets arrive at the Virtual OF Switch through a virtual port 273 consisting of an Attachment Circuits followed by an input Packet 274 Processing function (iPProc). The the iPProc encapsulates arriving 275 packets on the Attachment Circuit in the outer transport (Ethernet) 276 header. This is required because OpenFlow can only push MPLS labels 277 onto the top of a label stack encapsulated in an existing Ethernet 278 header. Furthermore, since OpenFlow cannot push an Ethernet header 279 (see Section 5.12 of [OF-1.3.0]), the encapsulation must be done in a 280 virtual port in order to construct a valid packet. Note also that 281 while pushing and popping MPLS labels is optional functionality in 282 the OpenFlow specification, it is required to support the 283 functionality described in this document. 285 When a packet arrives on an Attachment Circuit, say [AC1], the iPProc 286 function receives the packet and encapsulates it in what will become 287 the outer transport header. The packet is then handed to the Virtual 288 OF Switch which can now push the PW label onto the packet. Note that 289 for purposes of this revision of this document it is assumed that the 290 controller (and hence the Virtual OF Switch) receives PW label out- 291 of-band. The packet is then output to a virtual port in which the 292 oPProc pushes the appropriate Transport label and switches the packet 293 onto the Transport LSP. This sequence is depicted in Figure 4. 294 Finally, while it is in principle possible for the OF Switch to also 295 push the Transport label, the design decision taken here is push the 296 Transport label in a virtual port in order to keep the OF Switch as 297 simple as possible; in this case by limiting it to one table. 299 A packet initially arrives at the AC with the following headers 300 and payload. This packet becomes the PW payload. 302 \ 303 - PW payload 304 / 306 Next, the iPProc adds the Transport header. 308 \ 309 - PW payload 310 - Transport header 313 The Virtual OF switch then pushes on PW label with S=1. 315 \ 316 - PW payload 317 / 318 - PW label 319 - Transport header 321 Finally, the oPProc pushes the Transport label and switches the 322 packet onto the Transport LSP. 324 \ 325 - PW payload 326 / 327 - PW label 328 - Transport label 329 - Transport header 331 Figure 4: Input Encapsulation Sequence 333 When receiving a packet on a Transport LSP, the iPProc pops the 334 Transport label from packets exiting the Transport LSP (again, the 335 choice to pop the Transport label in the iPProc is to limit the OF 336 switch one table). The PW Label is subsequently popped by the 337 Virtual OF switch. Finally, the oPProc receives the packet sent to 338 the virtual port, strips the transport header from the outgoing 339 packet and delivers it to the Attachment Circuit. 341 The OAM Engine generates and receives&processes OAM packets. It can 342 perform OAM functions for both Pseudowires and Transport LSPs. At 343 the head-end node, the OAM Engine is connected to a Virtual OF Switch 344 input port. OAM packets are switched through the Virtual OF Switch 345 either onto either Pseudowires or onto the transport LSPs. At the 346 tail-end node, the OAM Engine is connected to a Virtual OF Switch 347 output port. OAM packets are switched either from transport LSPs or 348 Pseudowires to the OAM Engine. The tail-end node OAM Engine detects 349 failure conditions. The head-end OAM Engine performs corrective 350 actions. 352 2.1.1. The Virtual OF Switch 354 The Virtual OF switch is comprised of a single flow table (Flow Table 355 1) and a single group table. The Virtual OF Switch is shown in the 356 following figure. 358 +------------+ 359 | Controller | 360 +------------+ 361 | 362 V 363 +-----------------------------------------+ 364 | +-------+ +-------+ | 365 --+--->[In]->| | | |->[Out]---+-- 366 | | Flow | | Group | | 367 --+--->[In]->| Table |-->| Table |->[Out]---+-- 368 | | 1 | | | | 369 --+--->[In]->| | | |->[Out]---+-- 370 | +-------+ +-------+ | 371 | Virtual OF Switch | 372 +-----------------------------------------+ 374 Figure 5: The Virtual OF Switch 376 Although the Virtual OF switch is the same at both the head-end and 377 tail-end nodes, the group table is only used at the head-end node, 378 where a Fast Failover group is set up for each pair of ports that 379 correspond to the primary-backup Transport LSP pair. At the tail-end 380 node, only flows are set up. 382 Transport LSPs are identified as virtual ports to the OF controller. 383 For the Reference Topology in Figure 2, the primary transport LSP is 384 identified to OpenFlow as Virtual Port [VP1] and the backup transport 385 LSP is identified as Virtual Port [VP2]. At the head-end switch in 386 the Reference Topology a Fast Failover group [PG1] is set up for 387 ports [VP1] and [VP2]. 389 The Virtual OF Switch MUST support the following 390 OFPXMC_OPENFLOW_BASIC match fields ([OF-1.3.0], Section A.2.3.7): 392 o Match on Switch Input Port (OFPXMT_OFB_IN_PORT) 394 o Match on MPLS Label (OFPXMT_OFB_MPLS_LABEL) 396 o Match on MPLS BoS bit (OFPXMT_OFP_MPLS_BOS) 398 o Match on Ethertype (OXM_OF_ETH_TYPE) 400 The Virtual OF Switch must support the following OF actions 401 ([OF-1.3.0], Section A.2.5): 403 o Output to switch port (OFPAT_OUTPUT) 405 o Push a new MPLS tag (OFPAT_PUSH_MPLS) 407 o Pop the outer MPLS tag (OFPAT_POP_MPLS) 409 o Apply group (OFPAT_GROUP) 411 2.1.2. The OAM Engine 413 The liveness of Transport LSPs and PWs are monitored by OAM. The 414 desired model is to have an OAM engine residing locally on the 415 switch. At the ingress to a PW the OAM Engine will inject OAM 416 packets into the PW data path. At the egress of a PW the switch will 417 detect OAM packets (performing a flow-match operation) and punt OAM 418 packets to the OAM Engine, which will evaluate them, and if need be 419 perform corrective action and/or produce notifications. 421 The OAM function for Transport LSPs is out of scope for this revision 422 of this document. However, PW-OAM mechanisms described in this 423 document could also applicable to Transport LSP-OAM. 425 In addition to generating and processing OAM packets, the OAM Engine 426 participates in the liveness monitoring function (see Section 6.6 of 427 [OF-1.3.0]) for virtual port Fast Failover groups at the head-end 428 switch. When the OAM Engine detects a PW failure, it triggers the 429 Virtual OF Switch to move traffic from the primary transport LSP's 430 virtual port [VP1] to the backup transport LSP's virtual port [VP2]. 431 The OAM Engine's liveness monitoring function is described in more 432 detail in [OF-1.3.0]. 434 Note that in addition to the OAM Engine, the Virtual OF Switch MAY 435 use other liveness monitoring mechanisms for the virtual port Fast 436 Failover groups, which are out of scope of this document. 438 3. PW Configuration 440 3.1. Configuration Messages 442 The Controller uses OpenFlow protocol messages defined in [OF-1.3.0] 443 to configure transport pseudo-wires. The Flow Modification message 444 and the Group Modification message types are used. To configure a PW 445 at the head-end node, the Controller uses a sequence of a Group 446 Modification message followed by a Flow Modification message. At the 447 tail-end node, the Controller uses Flow Modification messages only. 449 The message formats in this document are specified using Routing 450 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 452 3.1.1. The Flow Modification Message 454 The Flow Modification message - 'Modify Flow Entry' - is defined in 455 [OF-1.3.0], Section A.3.4.1 as follows: 457 ::= 458 459 460 461 462 463 464 465 466 467 468 469 470 472 ::= 473 474 475 477 ::= 478 479 481 ::= [] 483 ::= 484 485 486 487 489 ::= [] 491 ::= ( | 492 | 493 | 494 ) 496 ::= 497 498 499 501 ::= [] 503 ::= ( | 504 | 505 | 506 | ...) 508 ::= 509 510 512 ::= 513 514 515 517 ::= 518 519 520 522 ::= 523 524 526 Figure 6: The 'Modify Flow Entry' message 528 Note that not all action types defined in [OF-1.3.0] for 529 are listed in Figure 6. 531 3.1.2. The Group Modification Message 533 The Group Modification message - 'Modify Group Entry' - is defined in 534 [OF-1.3.0], Section A.3.4.2 as follows: 536 ::= 537 538 539 540 542 ::= 543 544 545 547 ::= [] 549 ::= 550 551 552 553 555 ::= [] 557 ::= ( | | ...) 559 ::= 560 561 562 564 Figure 7: The 'Modify Group Entry' message 566 3.2. PW Head-End Node Configuration 568 Consider the reference topology in Figure 2. The Management 569 Application will configure a cross-connect between the Attachment 570 Circuit [AC1] and the virtual port pair {[VP1], [VP2]} joined in the 571 Fast Failover group [PG1]. The cross-connect determines that traffic 572 from Port AC will be switched to Group PG1. The internal mechanism 573 in Group PG1 (outside the scope of this document) will determine 574 whether traffic will go out on Port [VP1] (the primary transport LSP) 575 or on Port [VP2] (the backup transport LSP). 577 The Management Application uses the following message sequence to 578 create the cross-connect: 580 1. The 'Modify Group Entry' message, defined in Figure 7 creates or 581 modifies an entry in the Group Table. Each entry in the Group 582 Table corresponds to a pair of virtual ports that correspond to a 583 pair of primary / backup transport LSPs. This entry states that 584 as long as Port [VP1] is alive, traffic coming to group [PG1] 585 will go out on [VP1]. If Port [VP1] is not alive AND Port [VP2] 586 is alive, then traffic coming to group [PG1] will go out on Port 587 [VP2]. If neither of the ports are alive, traffic will be 588 dropped. Note that it's up to the switch to determine that a 589 given port is alive - and it can use any mechanism that it wants 590 to do that. 592 2. The 'Modify Flow Entry' message, defined in Figure 6, adds an 593 entry to Flow Table 1 for a flow that matches traffic from Input 594 Port [AC1]. The actions for the flow are 1.) Push the PW MPLS 595 header on the packet, and 2.) Forward the packet to Group [PG1], 596 which was setup in Step 1). 598 The following sections describe in details each message. 600 3.2.1. 'Modify Group Entry' Message Details 602 The fields in the 'Modify Group Entry' message are set as follows:> 604 'Modify Group Entry' message: is set to 'OFPGC_ADD' or 605 'OFPGC_MODIFY', is set to 'OFPGT_FF'(fast 606 failover group) and is set to the identifier of the 607 Fast Failover group that was setup for the primary and secondary 608 transport LSPs - [PG1]. 610 OpenFlow Header (ofp-header): is set to 4, 611 is set to 'OFPT_GROUP_MOD'. 613 Buckets: there are two action buckets - Bucket1 and Bucket2: 615 Bucket1 is associated with the virtual port corresponding to the 616 primary transport LSP, and its fields are set as follows. 617 is set to 1, is set to [VP1], 618 is set to 'OFPG_ANY'. contains a 619 single item - an to Virtual Port [VP1]. 621 Bucket2 is associated with the virtual port corresponding to the 622 backup transport LSP, and its fields are set as follows. 623 is set to 10, is set to [VP2], 624 is set to 'OFPG_ANY'. contains a 625 single item - an to Virtual Port [VP2]. 627 3.2.2. 'Modify Flow Entry' Message Details 629 The fields in the Modify Flow Entry' message are set as follows: 631 'Modify Flow Entry' message: The controller MUST set the value of 632 to '1', the value of 'OFPFC_MODIFY_STRICT', 633 the value of to 'OFP_NO_BUFFER', the value of 634 to 'OFPP_ANY', and the value of to 635 'OFPG_ANY'. The Controller SHOULD set the values of all other 636 atomic fields to appropriate values as required by the operation 637 of the configuration protocol. It is recommended that the 638 'IDLE_TIMEOUT' and 'HARD_TIMEOUT' fields are set to 0 for 639 persistant PW configurations 641 OpenFlow Header (ofp-header): is set to 4, 642 is set to 'OFPT_GROUP_MOD'. 644 Ofp-Match: The Controller MUST set the field to 645 'OFPMT_OXM' and include a single with the 646 field set to 'OFPXMC_OPENFLOW_BASIC', the field set to 647 'OFPXMT_OFB_IN_PORT', the field set to '0', and the 648 field set to [AC1]. 650 Instructions: The Controller MUST set the type field to 651 'OFPIT_APPLY_ACTIONS' and include the following action list: 653 Push MPLS Header: the value of set to 'OFPAT_PUSH_LABEL'; 654 the value of set to MPLS Unicast; the value of 655 set as follows: Label=[PWL1], TTL=1, TC=???, S=1. 657 Group: the value of set to 'OFPAT_GROUP' and the value of 658 set to [PG1]. 660 3.3. PW Tail-End Node Configuration 662 Consider the reference topology in Figure 2. The Management 663 Application will configure two cross-connects: one cross-connect 664 between the primary Transport LSP's virtual port ([VP3]) and the 665 Attachment Circuit [AC2], and one between the primary transport LSP's 666 virtual port ([VP3]) and the Attachment Circuit [AC2]. Under normal 667 circumstances, traffic will arrive at the primary Transport LSP's 668 Virtual Port [VP3]. When the primary Transport LSP is not available 669 and the backup Transport LSP is ok, traffic will arrive at the backup 670 Transport LSP's Virtual Port [VP4]. 672 Note that the cross-connect between the backup Transport LSP's 673 Virtual Port [VP4] and the Attachment Circuit [AC2] can be programmed 674 along with the cross-connect between the primary Transport LSP's 675 Virtual Port [VP3] and the Attachment Circuit [AC2], or at the time 676 when the primary Transport LSP's Virtual Port [VP3] goes down. 678 The cross-connects between the primary Transport LSP's Virtual Port 679 [VP3] and the Attachment Circuit [AC2], and between the backup 680 transport LSP's Virtual Port [VP4] and the Attachment Circuit [AC2] 681 are programmed by sending 'Modify Flow Entry' messages to the switch. 682 Programming details are described in the following section. 684 3.3.1. 'Modify Flow Entry' Message Details 686 The fields in the Modify Flow Entry' messages are set as follows: 688 'Modify Flow Entry' message: The controller MUST set the value of 689 to '1', the value of 'OFPFC_MODIFY_STRICT', 690 the value of to 'OFP_NO_BUFFER', the value of 691 to 'OFPP_ANY', and the value of to 692 'OFPG_ANY'. The Controller SHOULD set the values of all other 693 atomic fields to appropriate values as required by the operation 694 of the configuration protocol. It is recommended that the 695 'IDLE_TIMEOUT' and 'HARD_TIMEOUT' fields are set to 0 for 696 persistant PW configurations 698 OpenFlow Header (ofp-header): is set to 4, 699 is set to 'OFPT_GROUP_MOD'. 701 Ofp-Match: The Controller MUST set the field to 702 'OFPMT_OXM' and include the following match list: 704 Match Input Port: the value of the field set to 705 'OFPXMC_OPENFLOW_BASIC'; the value of the field set 706 to 'OFPXMT_OFB_IN_PORT'; the value of the field 707 set to '0' and the value field set to [VP3] (for the 708 primary Transport LSP) or [VP4] (for the backup Transport LSP). 710 Match MPLS Label: the value of the field set to 711 'OFPXMC_OPENFLOW_BASIC'; the value of the field set 712 to 'OFPXMT_OFB_MPLS_LABEL'; the value of the 713 field set to '0' and the value field set to [PWL1]. 715 Match BoS bit: the value of the field set to 716 'OFPXMC_OPENFLOW_BASIC'; the value of the field set 717 to 'OFPXMT_OFP_MPLS_BOS'; the value of the field 718 set to '0' and the value field set to 1. 720 Instructions: The Controller MUST set the type field to 721 'OFPIT_APPLY_ACTIONS' and include the following action list: 723 Pop MPLS Header: the value of set to 'OFPAT_POP_MPLS' and 724 the value of set to MPLS Unicast. 726 Output: the value of set to 'OFPAT_OUTPUT' and the value 727 of set to [AC2]. 729 4. PW OAM Considerations 731 4.1. OAM Overview 733 OAM for MPLS-TP is an important consideration and needs to be 734 addressed in a scalable manner and needs to function with the same 735 performance available today. Centralization of control or digestion 736 of OAM messages, where they are redirected back to a central 737 controller will introduce delay. Therefore the goal is to drive OAM 738 setup for PWs using messages from the Controller to the Switch. The 739 functions of the OAM, for example OAM packet generation, error 740 detection, action/notification will therefore still reside locally on 741 the switch. 743 [RFC6423] is used as a reference for unified OAM for MPLS-TP, in 744 particular Section 3, which includes provision for GAL with PW in 745 MPLS-TP. [RFC5860] lists OAM requirements for MPLS Transport 746 networks. 748 4.2. PW OAM Engine Configuration 750 If OAM is required on a particular PW it requires only a small number 751 of configuration actions on the OAM Engine and on the Virtual OF 752 Switch. 754 o The head-end OAM Engine is programmed to generate OAM packets for 755 the PW. The header for these packets will composed of at least 2 756 labels, the first being the PW label for which the OAM is being 757 generated, and the following label being the GAL label (13). The 758 contents of the GACH packet are out of scope for this draft and 759 will be down to the individual OAM implementation. 761 o At the head-end Virtual OF switch, a flow is programmed for each 762 Pseudowire to switch the OAM packets generated by the OAM Engine 763 to their respective destination PW. As the PW label is being 764 placed on the OAM packet, we can easily match on this and forward 765 the OAM packet down the correct PW to ensure it follows the same 766 data path. 768 o At the tail-end Virtual OF switch, a single flow is programmed to 769 switch all received OAM packets to the OAM Engine. The match 770 criteria on the flow is the MPLS BoS bit set to 0, which means 771 that a GAL label is present on the packet. This flow MUST have 772 higher priority than any flow matching on a PW label. 774 o The tail-end OAM Engine is programmed to receive OAM packets, 775 check that a valid PW label is present on the packet and to detect 776 failures. 778 OAM mechanisms that can be implemented by the OAM Engine are out of 779 scope for this revision of the document. For example, the OAM Engine 780 can also implement BFD (Echo) Mode [RFC5880] where echo packets are 781 returned via the remote forwarding plane, which can be done using an 782 OF match rule. 784 4.3. OAM and S-Bit considerations 786 In order to ensure that the switch can identify the last label in the 787 stack the S bit needs to be set on the label which will be at the 788 bottom of the stack. The OAM Engine will be required to set the S 789 bit on the GAL label (13) to ensure that the subsequent G-ACh packet 790 is treated correctly. By using OF actions to move all OAM Engine 791 packets into the PW we ensure that not only all types of OAM are 792 supported transparently, but also that the S bit is correctly set. 794 5. IANA Considerations 796 This document does not introduce any IANA requirements. 798 6. Security Considerations 800 Procedures described in this document do not change the OpenFlow 801 protocol security model described in [OF-1.3.0], Section 6.3. 803 A secure communications channel SHOULD be set up between the 804 controller and the MPLS-TP node. 806 7. Acknowledgements 808 The authors would like to thank Frank Brockners, Dan Frost, Giles 809 Heron, Zoltan Lajos Kis, Andy Malis, Yakov Stein, Joe Tardo, Sasha 810 Vainshtein and Dave Ward for their review and insightful comments. 812 8. Normative References 814 [OF-1.3.0] 815 Open Networking Foundation, "OpenFlow Switch 816 Specification, Version 1.3.0 (Wire Protocol 0x04)", April 817 16, 2012. 819 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 820 Requirement Levels", BCP 14, RFC 2119, March 1997. 822 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 823 Used to Form Encoding Rules in Various Routing Protocol 824 Specifications", RFC 5511, April 2009. 826 [RFC5601] Nadeau, T. and D. Zelig, "Pseudowire (PW) Management 827 Information Base (MIB)", RFC 5601, July 2009. 829 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 830 Operations, Administration, and Maintenance (OAM) in MPLS 831 Transport Networks", RFC 5860, May 2010. 833 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 834 (BFD)", RFC 5880, June 2010. 836 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 837 Berger, "A Framework for MPLS in Transport Networks", 838 RFC 5921, July 2010. 840 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 841 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 842 Framework", RFC 6373, September 2011. 844 [RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the 845 Generic Associated Channel Label for Pseudowire in the 846 MPLS Transport Profile (MPLS-TP)", RFC 6423, 847 November 2011. 849 Authors' Addresses 851 Jan Medved 852 Cisco Systems 853 170 W. Tasman Drive 854 San Jose, CA 95134 855 USA 857 Email: jmedved@cisco.com 859 Andrew McLachlan 860 Cisco Systems 861 170 W. Tasman Drive 862 San Jose, CA 95134 863 USA 865 Email: amclachl@cisco.com 867 David Meyer 868 Cisco Systems 869 170 W. Tasman Drive 870 San Jose, CA 95134 871 USA 873 Email: dmm@cisco.com