MPLS Working Group T. Saad Internet-Draft G. Swallow Intended status: Standards Track Cisco Systems Inc Expires: April 18, 2016 October 16, 2015 Extensions to RSVP-TE for LSP Instant Install draft-saad-lsp-instant-install-rsvpte-00 Abstract When establishing new RSVP-TE LSPs, it is permissible that LSRs along the LSP path to forward the RSVP Resv message upstream before installing the forwarding state. In practise, this is done to parallelize the forwarding state installation. While the ingress can start to use the LSP as soon as the RSVP Resv message arrives, doing so may lead to traffic drops at intermediate LSRs that may not have completed the installation of forwarding state for the new LSP. This document describes procedures and provides extensions to RSVP-TE protocol to allow an ingress LSR to immediately install and forward traffic on a newly signalled LSP as soon as the RSVP reservation state is received. 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 April 18, 2016. Copyright Notice Copyright (c) 2015 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 Saad & Swallow Expires April 18, 2016 [Page 1] Internet-Draft RSVP-TE LSP Instant Install October 2015 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . 4 3.1. TE Data Link Label Collection Indication . . . . . . . . 4 3.2. TE Data Link Label Collection . . . . . . . . . . . . . . 4 3.3. TE Data Link Label Update . . . . . . . . . . . . . . . . 5 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. RRO TE Data Link Label Sub-object . . . . . . . . . . . . 5 5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . 7 5.1. TE Data Link Label Collection . . . . . . . . . . . . . . 7 5.2. TE Data Link Label Update . . . . . . . . . . . . . . . . 9 5.3. Compatibility . . . . . . . . . . . . . . . . . . . . . . 9 6. Behavior of LSRs for Instant LSP Installation . . . . . . . . 9 6.1. Behavior of Ingress LSR . . . . . . . . . . . . . . . . . 9 6.2. Behavior of All LSRs . . . . . . . . . . . . . . . . . . 10 7. Manageability Considerations . . . . . . . . . . . . . . . . 10 7.1. Policy Configuration . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 11 9.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 11 9.3. Policy Control Failure Error subcodes . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The RSVP-TE specification [RFC3209] describes a "make-before-break" mechanism to meet a traffic engineering requirement to reroute established TE tunnels without causing disruption to transported traffic or major impact to network operations. Such a mechanism necessitates the signaling and establishment of a new LSP tunnel and transferring traffic from the old LSP tunnel onto it before tearing down the old LSP tunnel. Using RSVP-TE, the new LSP is signaled in the network, resulting in reservations in the control plane and a new Saad & Swallow Expires April 18, 2016 [Page 2] Internet-Draft RSVP-TE LSP Instant Install October 2015 state in forwarding associated with the new LSP be created on each LSR hop of the LSP path. [RFC3209] states that an ingress can transition traffic on to the new LSP once it receives the RSVP Resv message for the new LSP, and proceed to tear down the old LSP. In practice, however, the RSVP Resv message for the new LSP can reach the ingress before one (or more) LSR(s) have completed programming their forwarding for the new LSP. In the meantime, if the ingress transitions traffic on to the new LSP, it will be impacted. To avoid prematurely transitioning traffic on to the newly instantiated LSP, it is common for the ingress LSR to delay the transition of traffic on to the new LSP - either by empirically determining a suitable wait time, or by continuously probing the newly created LSP data-path so it can be verified. Several mechanisms have been defined for the latter including, [RFC5884] and [I-D.ietf-mpls-self-ping]. Throughout this document we use the term installation-time to cover both the above waiting and probing. There are several cases where it is highly desirable that the ingress LSR installation-time be as minimal as possible. For example, if a partial failure of resource(s) (e.g. bundle link) along the LSP path occurs, the traffic that continues to be forwarded along the degraded resource(s) while ingress LSR undergoes "make-before-break" may experience congestion and drops. Another case may occur when a protected link or node fails and the protected traffic gets rerouted on to the backup path. In this case, while the ingress(es) initiate "make-before-break" to move traffic away from the backup path to newly computed path(s) post convergence, the protected rerouted traffic flowing on the backup path competes for resources with other protected traffic originally traversing the same path. This sometimes may lead to congestion drops as backup path becomes overloaded by with extra traffic traversing its link(s). Consequently, network operators usually desire to reduce the total time that the protected rerouted traffic remains on the backup path (aka. Total Time on Backup (TTOB)) while ingress(es) undergo "make- before-break" so to reduce the risk of congestion occurring. Other similar situation may also occur during RSVP-TE soft-preemption of LSP(s). This document defines procedures and extensions to RSVP protocol to allow the ingress to collect TE Data Link Label (DLL) information that. The ingress can use the collected DLLs to install and transition traffic on to a newly created LSP as soon as resource allocation on traversed link(s) is complete. Consequently, this eliminates the need for any wait time to program the new LSP state forwarding on traversed LSRs that is usually needed, and allows the Saad & Swallow Expires April 18, 2016 [Page 3] Internet-Draft RSVP-TE LSP Instant Install October 2015 "make-before-break" wait time to be reduced to the time to complete the resource allocation via RSVP on traversed link(s). 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 [RFC2119]. 2. Overview When establishing a new RSVP-TE LSP, the ingress computes a path and signals the LSP using RSVP-TE to allocate resources along the LSP path. The RSVP-TE extensions defined in this document allow the ingress to collect the Data Link Labels (DLLs) of TE link(s) traversed by the LSP. The DLL of a TE link is a label that is attached to a specific TE interface and that is programmed in forwarding such that an incoming packet with a top DLL label will be popped and packet forwarded over the associateed TE interface. Once available, the ingress can use the DLL(s) of traversed TE link(s) to compose a stack of MPLS labels that are prepended on to packets to be forwarded over the LSP; thereby, steering such packets over the same path where RSVP-TE resources have been allocated. 3. RSVP-TE Requirements The RSVP extensions defined in this document enable the ingress to retrieve information about DLLs of TE link(s) traversed by the LSP while signaling and installation of normal TE label(s) is under way. 3.1. TE Data Link Label Collection Indication The ingress node of the LSP SHOULD be capable of indicating whether the TE DLL information of traversed links are to be collected during the signaling procedure of setting up an LSP. 3.2. TE Data Link Label Collection If requested, the DLL information SHOULD be collected during the setup of an LSP. The LSP ingress can use the collected DLL(s) of traversed TE link(s) to install the newly created LSP and transition traffic on to it as soon as resource allocation is complete using RSVP. Saad & Swallow Expires April 18, 2016 [Page 4] Internet-Draft RSVP-TE LSP Instant Install October 2015 The DLL information SHOULD NOT be collected without an explicit request for it being made by the ingress node. 3.3. TE Data Link Label Update When the DLL information changes from information collected during signaling, the relevant nodes of the LSP SHOULD be capable of updating the DLL information of the LSP. This means that that the signaling procedure SHOULD be capable of updating the DLL information. Changes to TE data link information may indicate a change in the label value, or protection state associated with the label. 4. Encodings In order to indicate to nodes that the DLL collection is desired, this document defines a new flag in the Attribute Flags TLV (see [RFC5420]), which MAY be carried in an LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTES Object: o Bit Number (TBD-1): DLL Collection flag The DLL Collection flag is meaningful on a Path message. If the DLL Collection flag is set to 1, it means that the DLL information SHOULD be reported to the ingress and egress node along the setup of the LSP. The rules of the processing of the Attribute Flags TLV are not changed. 4.1. RRO TE Data Link Label Sub-object This document defines a new RRO sub-object (ROUTE_RECORD sub-object) to record the DLL(s) of traversed link(s) of the LSP. Its format is modeled on the RRO sub-objects defined in RFC 3209 [RFC3209]. The DLL RRO sub-object is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |U| Flags | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Saad & Swallow Expires April 18, 2016 [Page 5] Internet-Draft RSVP-TE LSP Instant Install October 2015 Type (TBD-2) TE Data Link Label type. Length The Length field contains the total length of the sub-object in bytes, including the Type and Length fields. The Length MUST be at least 4, and MUST be a multiple of 4, see [RFC3209]. U (1 bit) This bit indicates the direction of the label. It is 0 for the downstream label. It is set to 1 for the upstream label and is only used on bidirectional LSPs. Flags 0x01 Global label Indicates the label will be understood if received on any interface. 0x02 Local protection available Indicates that the outgoing link for this DLL is protected via a local repair mechanism. 0x04 Local protection in use Indicates that a local repair mechanism is in use to maintain traffic over this DLL (usually in the face of an outage of the link it was previously routed over). C-Type The C-Type of the included Label Object. Copied from the Label Object. Label This field identifies the label to be used. The format of this field is identical to the one used by the Label field in Generalized Label. The interpretation of this field depends on the type of the link over which the label is used, see [RFC3471]. As described in [RFC3209], the RECORD_ROUTE object is managed as a stack. The DLL sub-object SHOULD be pushed by the node before the Saad & Swallow Expires April 18, 2016 [Page 6] Internet-Draft RSVP-TE LSP Instant Install October 2015 link ipv4/ipv6 address. The DLL sub-object SHOULD be pushed after the Attribute sub-object, if present, and after the LABEL sub-object, if requested. A node MUST NOT push a TE DLL sub-object in the RECORD_ROUTE without also pushing either a IPv4 sub-object, a IPv6 sub-object, a Unnumbered Interface ID sub-object. A node can push multiple DLL sub-object(s) that pertain to the same link. For example, a policy may necessitate allocating multiple DLL(s) - e.g. a DLL with no protection, a DLL with NHOP protection, and another for NNHOP protection. In this case, all the DLL sub- object(s) pertaining to the link are pushed before pushing the link identifier. The rules of the processing of the LSP_REQUIRED_ATTRIBUTES, LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed. 5. Signaling Procedures 5.1. TE Data Link Label Collection Per [RFC3209], an ingress node initiates the recording of the route information of an LSP by adding a RRO to a Path message. If an ingress node also desires DLL recording, it MUST set the DLL Collection Flag in the Attribute Flags TLV which MAY be carried either in an LSP_REQUIRED_ATTRIBUTES Object when the collection is mandatory, or in an LSP_ATTRIBUTES Object when the collection is desired, but not mandatory. When a node receives a Path message which carries an LSP_REQUIRED_ATTRIBUTES Object and the DLL Collection Flag set, if local policy determines that the DLL information is not to be provided to the endpoints, it MUST return a PathErr message with: o Error Code 2 (policy) and o Error subcode "DLL Recording Rejected" (value TBD) to reject the Path message. When a node receives a Path message which carries an LSP_ATTRIBUTES Object and the DLL Collection Flag set, if local policy determines that the DLL information is not to be provided to the endpoints, the Path message SHOULD NOT be rejected due to DLL recording restriction and the Path message SHOULD be forwarded without any DLL sub- object(s) in the RRO of the corresponding outgoing Path message. If local policy permits the recording of the DLL information, the processing node SHOULD add local DLL information, as defined below, to the RRO of the corresponding outgoing Path message. The processing node MAY add multiple DLL sub-objects to the RRO if Saad & Swallow Expires April 18, 2016 [Page 7] Internet-Draft RSVP-TE LSP Instant Install October 2015 necessary. It then forwards the Path message to the next node in the downstream direction. If the addition of DLL information to the RRO would result in the RRO exceeding its maximum possible size or becoming too large for the Path message to contain it, the requested DLL MUST NOT be added. If the DLL collection request was contained in an LSP_REQUIRED_ATTRIBUTES Object, the processing node MUST behave as specified by [RFC3209] and drop the RRO from the Path message entirely. If the DLL collection request was contained in an LSP_ATTRIBUTES Object, the processing node MAY omit some or all of the requested DLL(s) from the RRO; otherwise, it MUST behave as specified by [RFC3209] and drop the RRO from the Path message entirely. Following the steps described above, the intermediate nodes of the LSP can collect the DLL information in the RRO during the processing of the Path message hop by hop. When the Path message arrives at the egress node, the egress node receives DLL information in the RRO. Per [RFC3209], when issuing a Resv message for a Path message which contains an RRO, an egress node initiates the RRO process by adding an RRO to the outgoing Resv message. The processing for RROs contained in Resv messages then mirrors that of the Path messages. When a node receives a Resv message for an LSP for which DLL Collection is specified, then if local policy allows recording DLL information, the node SHOULD add the DLL information to the RRO of the corresponding outgoing Resv message, as specified below. When the Resv message arrives at the ingress node, the ingress node can extract the DLL information from the RRO in the same way as the egress node. Note that the DLL information for the upstream direction cannot be assumed to be the same as that in the downstream. o For Path and Resv messages for a unidirectional LSP, a node SHOULD include the DLL sub-objects in the RRO for the downstream data link only. o For Path and Resv messages for a bidirectional LSP, a node SHOULD include DLL sub-objects in the RRO for both the upstream data link and the downstream data link from the local node. In this case, the node MUST include the information in the same order for both Path messages and Resv messages. That is, the DLL sub- object for the upstream link is added to the RRO before the DLL sub-object for the downstream link. Saad & Swallow Expires April 18, 2016 [Page 8] Internet-Draft RSVP-TE LSP Instant Install October 2015 Based on the above procedure, the endpoints can get the DLL information automatically. 5.2. TE Data Link Label Update When the DLL information of a data link is changed, the RSVP-TE LSPs traversing that link need to be made aware of the changes. The procedures defined in Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to refresh the DLL information if the change is to be communicated to other nodes according to the local node's policy. 5.3. Compatibility A node that does not recognize the TE DLL Collection Flag in the Attribute Flags TLV is expected to proceed as specified in RFC 5420 [RFC5420]. It is expected to pass the TLV on unaltered if it appears in a LSP_ATTRIBUTES object, or reject the Path message with the appropriate Error Code and Value if it appears in a LSP_REQUIRED_ATTRIBUTES object. A node that does not recognize the DLL RRO sub-object is expected to behave as specified in RFC 3209 [RFC3209] unrecognized subobjects are to be ignored and passed on unchanged. 6. Behavior of LSRs for Instant LSP Installation To use the instant LSP install procedures, the ingress and traversed LSR(s) will need to support the required RSVP-TE signaling extensions described earlier for requesting and recording DLL(s) of traversed link(s) of an LSP as well as to update their behavior as described below. 6.1. Behavior of Ingress LSR To be able to carry out instant LSP install procedures, the ingress of the LSP indicates to traversed nodes to record all DLL(s) of traversed link(s) of the LSP. This is achieved by the ingress setting the new flag in the Attribute Flags TLV as described in section Section 4. Upon receiving the RSVP Resv message of the newly signaled LSP, the resource allocation on traversed nodes is declared complete. The ingress LSR inspects the Resv message RRO contents for presence of the DLL information for all traversed TE link(s). The DLL(s) of all traversed link(s) MUST be present in the RRO to be able to proceed with instant LSP installation procedures. Saad & Swallow Expires April 18, 2016 [Page 9] Internet-Draft RSVP-TE LSP Instant Install October 2015 The ingress LSR programs its forwarding to impose the multiple outgoing label(s) corresponding to the collected DLL(s) in the Resv RRO - with top label of in the stack being the DLL of the first traversed TE link, and the bottom of the stack corresponding to the last TE link of the LSP. The ingress can directly transition traffic on to the DLL-LSP as soon as the forwarding state is programmed at the ingress. In addition to the instant LSP procedures, the ingress LSR invokes the "make-before-break" procedures to wait for new LSP forwarding state to be programmed on all LSR(s) before transitioning traffic from the DLL-LSP on to the new LSP. The ingress LSR transitions traffic on to the new LSP as soon as it is validated. Note in both cases, the traffic carried on the DLL-LSP and then on the new LSP flows along the same set of TE link(s), and the transition from the DLL-LSP to new LSP is expected to not cause any disruptions to transported traffic. 6.2. Behavior of All LSRs To support instant LSP procedures, all LSR(s) are expected to allocate a DLL label corresponding to each TE data link. An LSR can allocate multiple DLLs for the same TE link (for example, a DLL that has backup protection path, and another not). A packet arriving at an LSR whose top label matches a DLL will get it top label popped and packet forwarded downstream on the TE link associated with the DLL. Upon receiving an RSVP Path or Resv message and if the DLL Collection Flag set in the Attribute Flags TLV, the LSR(s) adds the DLL(s) sub- object corresponding to the RRO before forwarding the RSVP message. 7. Manageability Considerations 7.1. Policy Configuration In a border node of inter-domain or inter-layer network, the following TE DLL processing policy SHOULD be capable of being configured: o Whether the Data Link Label(s) of the domain or specific layer network can be exposed to the nodes outside the domain or layer network, or whether they SHOULD be summarized, mapped to values that are comprehensible to nodes outside the domain or layer network, or removed entirely. A node using RFC 5553 [RFC5553] and PKS MAY apply the same policy. Saad & Swallow Expires April 18, 2016 [Page 10] Internet-Draft RSVP-TE LSP Instant Install October 2015 8. Security Considerations This document builds on the mechanisms defined in [RFC3473], which also discusses related security measures. In addition, [RFC5920] provides an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane. The procedures defined in this document permit the transfer of the per link DLL data between domains during the signaling of LSPs, subject to policy at the domain boundary. It is recommended that domain boundary policies take the implications of releasing DLL information into consideration and behave accordingly during LSP signaling. 9. IANA Considerations 9.1. RSVP Attribute Bit Flags IANA has created a registry and manages the space of the Attribute bit flags of the Attribute Flags TLV, as described in section 11.3 of RFC 5420 [RFC5420], in the "Attribute Flags" section of the "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" registry located in http://www.iana.org/assignments/rsvp-te- parameters". IANA has made an early allocation in the "Attribute Flags" section of the mentioned registry that expires on 2015-09-11. This document introduces a new Attribute Bit Flag: Bit No Name Attribute Attribute RRO Reference Flags Path Flags Resv ----------- ---------- ---------- ----------- --- --------- TBD-1 TE DLL Yes Yes Yes This I-D collection flag 9.2. ROUTE_RECORD Object IANA manages the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters. IANA has made an early allocation in the Sub-object type 21 ROUTE_RECORD - Type 1 Route Record registry. The early allocation expires on 2015-09-11. This document introduces a new RRO sub-object: Value Description Reference --------------------- ------------------- --------- TBD-2 DLL sub-object This I-D Saad & Swallow Expires April 18, 2016 [Page 11] Internet-Draft RSVP-TE LSP Instant Install October 2015 9.3. Policy Control Failure Error subcodes IANA manages the assignments in the "Error Codes and Globally-Defined Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters. IANA has made an early allocation in the "Sub-Codes - 2 Policy Control Failure" subsection of the the "Error Codes and Globally-Defined Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry. The early allocation expires on 2015-09-11. This document introduces a new Policy Control Failure Error sub-code: Value Description Reference --------------------- ----------------------- --------- TBD-3 DLL Recording Rejected This I-D 10. References 10.1. Normative References [I-D.ietf-mpls-self-ping] Bonica, R., Minei, I., Conn, M., Pacella, D., and L. Tomotaki, "LSP Self-Ping", draft-ietf-mpls-self-ping-05 (work in progress), October 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, . [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, . Saad & Swallow Expires April 18, 2016 [Page 12] Internet-Draft RSVP-TE LSP Instant Install October 2015 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, February 2009, . [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource Reservation Protocol (RSVP) Extensions for Path Key Support", RFC 5553, DOI 10.17487/RFC5553, May 2009, . [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, June 2010, . 10.2. Informative References [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, . Authors' Addresses Tarek Saad Cisco Systems Inc Email: tsaad@cisco.com George Swallow Cisco Systems Inc Email: swallow@cisco.com Saad & Swallow Expires April 18, 2016 [Page 13]