<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-penno-pcp-asdn-00" ipr="trust200902">
  <front>
    <title abbrev="A-SDN">Application Enabled SDN (A-SDN)</title>

    <author fullname="Reinaldo Penno" initials="R." surname="Penno">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region></region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <phone></phone>

        <email>repenno@cisco.com</email>

        <uri></uri>
      </address>
    </author>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marathalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Dan Wing" initials="D." surname="Wing">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>California</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <email>dwing@cisco.com</email>
      </address>
    </author>

    <author fullname="Suresh Vinapamula" initials="S." surname="Vinapamula">
      <organization>Juniper Networks, Inc.</organization>

      <address>
        <postal>
          <street>1194 N Mathilda Ave</street>

          <city>Sunnyvale</city>

          <region>California</region>

          <code>94089</code>

          <country>USA</country>
        </postal>

        <phone></phone>

        <email>sureshk@juniper.net</email>

        <uri></uri>
      </address>
    </author>

    <date day="" month="" year="" />

    <abstract>
      <t>To allow traversal of firewalls or provide additional network
      services such as QoS or supplemental bandwidth, it is necessary to
      deploy application-aware network elements. Such network elements are
      costly to create, deploy, and are unable to adequately cope with changes
      to the application itself, stifling innovation.</t>

      <t>This document describes a different approach, where the application
      explicitly signals its needs to the network.</t>

      <!--
      <t>In the context of ongoing efforts to add more automation and promote
      means to dynamically interact with network resources (e.g., SDN-labeled
      efforts), various proposals are made to accommodate the needs of Network
      Providers to program the network with flow information and its
      associated metadata in order to apply policies such as traffic
      prioritization.</t>

      <t>Usually this programming is driven by a (centralized) controller that
      gather flow-related information and associated metadata through an army
      of probes, receiving a copy of the first packets of the flow, or even
      having to be on-path for the first few packets of the flow but not
      necessarily subsequent packets. But most of observed flows in current
      usages are dynamic, time-bound (short lived for some of them), possibly
      encrypted, peer-to-peer, possibly asymmetric, and might have different
      priorities depending on network conditions, direction, time of the day,
      and other factors. This means that hairpinning of packets through a
      controller, deep packet inspection, and other similar static methods
      such as portals cannot be employed successfully to glean flow and
      metadata information, and subsequently program the network.</t>

      <t>Unlike network-centric techniques, this document proposed an approach
      which involved hosts and applications.</t>
-->
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Problem Statement">
      <t>In the context of ongoing efforts to add more automation and promote
      means to dynamically interact with network resources (e.g., SDN-labeled
      efforts) <xref target="I-D.sin-sdnrg-sdn-approach"></xref>, various
      proposals are made to accommodate the needs of Network Providers to
      program the network with flow information and its associated metadata in
      order to apply policies such as traffic prioritization.</t>

      <t>Usually this programming is driven by a (centralized) controller that
      gather flow-related information and associated metadata through an army
      of probes, receiving a copy of the first packets of the flow, or even
      having to be on-path for the first few packets of the flow but not
      necessarily subsequent packets. But most of observed flows in current
      usages are dynamic, time-bound (short lived for some of them), possibly
      encrypted, peer-to-peer, possibly asymmetric, and might have different
      priorities depending on network conditions, direction, time of the day,
      and other factors.</t>

      <t>This means that hairpinning of packets through a controller, deep
      packet inspection, and other similar static methods such as portals
      cannot be employed successfully to glean flow and metadata information,
      and subsequently program the network. Therefore new methods must be
      devised.</t>

      <t>Unlike network-centric techniques, this document proposed an approach
      which involved hosts and applications.</t>
    </section>

    <section title="Scope">
      <t>Considerations related to dynamic network provisioning negotiation
      are out of scope. The reader can refer to <xref
      target="I-D.boucadair-connectivity-provisioning-protocol"></xref> for
      more details.</t>

      <t>The proposed architecture is not a replacement to existing legacy
      techniques. It is an enhancement to existing network infrastructure and
      service infrastructure than can be empowered by new features to better
      accommodate application-specific needs while network and services
      resources are also optimized and better partitioned.</t>

      <t>This document does not propose to update all existing/future
      applications to signal their network resources requirements; only a
      subset of applications having specific connectivity requirements and
      which require differentiated treatment at the network side are expected
      to be updated to support the framework defined in this document.</t>

      <t>This document does not require an end-to-end signalling before actual
      invocation of a service.</t>

      <t>This document does not make any assumption on how differentiated
      connectivity is delivered to end users. It is up to each administrative
      entity managing a network to enforce its own engineering policies,
      techniques and protocols. Note, differentiated connectivity services can
      be provided by one or a combination of several dimension (forwarding,
      routing, resources management). It is out of scope of this document to
      elaborate on such aspects.</t>
    </section>

    <section title="Proposed Approach">
      <t>In order to offer more automation and dynamicity in resource usage
      and invocation, this document proposes an architecture that is composed
      of three parts:</t>

      <t><list style="numbers">
          <t>Applications running on the end points (UEs, Server at a Data
          Centers, CPE routers) must communicate or install flow and
          associated metadata on network Elements. Means to discover such
          Network Elements may be supported.</t>

          <t>On the network side, a PDP (Policy Decision Point, <xref
          target="RFC2753"></xref>) is responsible for orchestrating
          resources, generating policies and trigger provisioning-related
          operations.</t>

          <t>The PDP configures the on-path devices to accommodate the
          signaled flow (e.g., open pinhole in the firewall, provide
          prioritized network services for the flow).</t>
        </list></t>

      <t>The diagram below depicts the general architecture and message flow
      for the Application-Enabled SDN (A-SDN).</t>

      <figure>
        <preamble></preamble>

        <artwork><![CDATA[
                                                     Controller

                                                  +---------------+
                                                  | PDP           |
                  . __ . __ . __ . __ . __ . __ . |               |
                  |                               |  ________     |
                  .                               | |REST    |    |
                  |                    +----------->|Server  |    |
                  .               Flow | 2        | '--------'    |
                  |            Install |          +-----.---------+
                  .                Req |                |
                 3|                    |              3 . Flow
                  .                    |                | Install
                  |       +------------|------+         .
                  .       |     Middlebox     |         |
  ________        |       | _________________ |     ____v____       _________
 |        |  ____v___     ||       |I|REST   ||    | Router  | ... | Router  |
 | Client |..|Switch |....|| Server|W|Client ||    | Switch  |     | Switch  |
 +--------+  |       |    ||       |F|       ||    '---------'     '---------'
    .        '-------'    |+-----------------+|
    .                     +-------------------+
    .                            ^
    .                            .
    .            1               .
    .. . . . . . . . . . . . . . .
           SDN signaling
           Request (Flow + Metadata)


 ....  e.g., PCP
 ----  e.g., REST
 -.-.  e.g., COPS-PR, Netconf, Openflow]]></artwork>

        <postamble>A middlebox could be a CPE router, edge router, switch,
        wireless access LAN controller, mobile gateway in 3GPP networks <xref
        target="RFC6459"></xref>, or any other flow-aware device.</postamble>
      </figure>

      <t></t>

      <t>This architecture provides several advantages such as:</t>

      <t><list style="symbols">
          <t>Host driven: The host (or application) is responsible for
          requesting proper flows and associated metadata based on each
          individual application needs. These needs may be time variant, and
          driven by processes only understood by the applications (or their
          users). The end host is the only entity in the system that has all
          of the information required to make the correct service request .
          This approach is compliant with requirements specific to encrypted
          and multi-party flows.</t>

          <t>Network Authorization: If network access control is required,
          then the host could also get authorization from the Application
          Server trusted by the network in order to install flows and
          associated actions (e.g., policies). The Application Server could be
          deployed in a third party network. This is important for networks
          which do not trust the host.</t>

          <t>Immediate incremental value for endpoints and applications: If,
          for example, a CPE router that supports this architecture is
          installed, applications could signal flow characteristics to the
          network on both directions, traffic prioritization, firewall
          pinholes and other services without changing the rest of the
          network. Meaning, although steps 2 and 3 of the picture above
          provide important end-to-end additional value they are not necessary
          for end-to-edge.</t>

          <t>Access agnostic: An application should not care if it is on an
          ADSL, Cable, Wi-Fi, 3G, Ethernet or other network type.</t>

          <t>Works across administrative domains: Home Network -&gt; ISP1.
          Home Network communicates with ISP1 using PCP.</t>

          <t>NAT and firewall aware: The flow information fed into the PDP
          will have pre and post NAT information, allowing provisioning using
          scoped IP addresses.</t>

          <t>Extensible: Client protocol can be extended to provide a wide
          range of flow associated metadata.</t>

          <t>Multi-interface support: Based on network conditions clients can
          switch from a Wi-Fi to a 3G interface, or install flows over certain
          paths</t>
        </list></t>
    </section>

    <section title="Protocols">
      <t>The first element of this architecture could be met by using the Port
      Control Protocol (PCP) <xref target="RFC6887"></xref>. Indeed, PCP Flow
      Extension <xref target="I-D.wing-pcp-flowdata"></xref> allows a PCP
      Client, usually a host, to signal flow characteristics to the network,
      and the network to signal its ability to accommodate that flow back to
      the host.</t>

      <t>For example, a video streaming client knowing the address of the
      remote server can request the required flow characteristics; for example
      N-Mbps of upstream bandwidth, M-Mbps of downstream bandwidth,
      low-latency, low-jitter etc. The network authorizes the request and
      signals back to the host that it can (fully or partially) accommodate
      the flow.</t>

      <t>The second element of this architecture requires a protocol that has
      built-in primitives for reliable near-real-time messages and, ideally,
      sharing of information about network availability between the network
      device and PDP. This element can be met by using REST, Extensible
      Messaging and Presence Protocol (XMPP) <xref target="RFC6120"></xref> or
      similar protocol.</t>

      <t>Finally, the PDP should be able to install flows in routers or
      switches and assign them a series of actions, modify flow actions,
      collect statistics, or (more importantly) extend the provisioning of
      these flows end-to-end. This third element of the architecture can be
      met by using any of several flow provisioning protocols as part of the
      PDP:</t>

      <t><list style="symbols">
          <t>PCP with the THIRD_PARTY option</t>

          <t>Netconf <xref target="RFC6241"></xref>, COPS-PR <xref
          target="RFC3084"></xref> , or any similar protocol. This document
          does not make any assumption on that interface.</t>
        </list></t>
    </section>

    <section title="A-SDN Flows">
      <t><figure>
          <artwork><![CDATA[                                                  +---------------+
                                                  | PDP           |
                  . __ . __ . __ . __ . __ . __ . |               |
                  |                               |  ________     |
                  .                               | |REST    |    |
                  |                    +----------->|Server  |    |
                  .               Flow | 2        | '--------'    |
                  |            Install |          +-----.---------+
                  .                Req |                |
                 3|                    |              3 . Flow
                  .                    |                | Install
                  |       +------------|------+         .
                  .       |     Middlebox     |         |
  ________        |       | _________________ |     ____v____       _________
 | PCP    |  ____v___     || PCP   |I|REST   ||    | Router  | ... | Router  |
 | Client |..|Switch |....|| Server|W|Client ||    | Switch  |     | Switch  |
 +--------+  |       |    ||       |F|       ||    '---------'     '---------'
    .        '-------'    |+-----------------+|
    .                     +-------------------+
    .                            ^
    .                            .
    .            1               .
    .. . . . . . . . . . . . . . .
           PCP PEER
             Req


 ....  PCP Message
 ----  REST Messages
 -.-.  Netconf, COPS, etc.]]></artwork>
        </figure></t>

      <section title="Signaling Prior to Flow Creation">
        <t>When an end host installs a flow in the middlebox through a PCP
        message a REST API call is made to the PDP. This message will carry
        the following information:</t>

        <t><list style="symbols">
            <t>Match condition: e.g., source/destination IP,
            source/destination port, L4 Protocol, Port, VLAN Id etc.</t>

            <t>Metadata: e.g., metadata conveyed in PCP FLOWDATA option.</t>

            <t>Lifetime: e.g., lifetime in PCP response will be mapped to
            idle_timeout and hard_timeout will be set to zero for the flow
            entry. (idle_timeout and hard_timeout are defined in OpenFlow
            switching protocol). This way PCP client is aware when the flow
            entry will be removed.</t>
          </list></t>

        <t>The PDP uses an appropriate protocol (e.g., netconf, COPS-PR,
        Openflow, etc.) to add/delete and modify flows and its metadata. For
        example Openflow controller using Openflow protocol version 1.3 <xref
        target="OpenFlow"></xref> would get the information of configured
        queues and associated property of each queue. The Openflow controller
        will either associate the flow with relevant queue or instruct the
        openflow-enabled network device to rewrite the DifServ CodePoint bits
        for the flow based on the metadata in REST message.</t>
      </section>

      <section title="Signaling After Flow Creation">
        <t>The application can create a implicit flow normally as with a TCP
        connection and later decide that it needs to modify it, for example,
        extending its lifetime or associating metadata such as bandwidth,
        delay, jitter, loss.</t>

        <t>The mechanism is very similar to flow creation but does not require
        a pre-signaling step.</t>
      </section>

      <section title="Flow Removal Event">
        <t>When a application-driven flow times out or is explicitly deleted,
        a REST API call is generated in the case the controller wants to be
        notified. This allows the PDP to delete the flow from other devices in
        the network.</t>

        <t>The PDP could also decide on its own to remove the installed flow.
        In this case a PCP unsolicited response will be sent to the PCP Client
        owner of such flow.</t>
      </section>

      <section title="Flow Modification">
        <t>After the PDP is notified of a flow creation, it can decide to
        modify its metadata. In order to do that the controller will send
        modify flow message through the appropriate protocol.</t>

        <t>If the PDP succeeds in modifying a flow, a PCP unsolicited response
        will be sent to the PCP Client owner of such flow.</t>
      </section>
    </section>

    <section title="Use Cases">
      <t>This section describes some use-cases in which A-SDNs can be
      beneficial.</t>

      <section title="Flow Prioritization">
        <t>A video streaming client that wants to have a low loss, medium
        delay service signals these flow characteristics in PCP FLOWDATA
        option. PCP server would convey this metadata to a PDP which would in
        turn add flow entry with inbound DSCP AF32 on SDN-enabled network
        devices.</t>

        <t>Packets matching this flow will be marked AF32 and internally put
        in an appropriate queue. More importantly, video packets should be
        marked as close as possible to the source.</t>
      </section>

      <section title="Flow High availability">
        <t>One of the ways for the PCP Server to determine that the flows are
        for business critical application is by using third party
        authorization. A PCP server for such flows will checkpoint all the
        state associated for such flows on the corresponding backup of active
        for high availability. At a high level, this authorization works by
        the PCP client first obtaining a cryptographic token from the
        authorizing network element (e.g., call controller) and includes that
        token in the PCP request. The PCP server in the network validates the
        token and grants access.</t>
      </section>

      <section title="On-demand Bandwidth">
        <t>In managed or unmanaged services deployments an enterprise many
        times needs more bandwidth for the entire link (all flows) or just
        some specific applications. Moreover, it does not need those
        permanently but just for a certain period of time. In this case the
        branch router can dynamically request this service from the network,
        streamlining service activation and modification.</t>
      </section>

      <section title="Analytics and Reporting">
        <t>Authorized applications within data centers and enterprises can
        attach metadata such as media-type, application-id and group to the
        flows which allows for ease and streamlined analytics and reporting
        without deep packet inspection.</t>
      </section>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>Security considerations in <xref target="RFC6887"></xref> and PCP
      Authentication <xref target="I-D.ietf-pcp-authentication"></xref> may
      need to be taken into account. For REST mutual authentication is
      required and TLS could be used for message integrity. Security-related
      consideration for the protocol enabled between the PDP and underlying
      nodes are discussed in <xref target="RFC6241"></xref> <xref
      target="RFC3084"></xref>.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document does not require any action from IANA.</t>
    </section>

    <section title="Acknowledgments">
      <t>TODO.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.6120"?>

      <?rfc include="reference.RFC.6887"?>

      <?rfc include='reference.I-D.wing-pcp-flowdata'?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.4594"?>

      <?rfc include='reference.RFC.2753'?>

      <?rfc include='reference.RFC.6459'?>

      <?rfc include='reference.I-D.sin-sdnrg-sdn-approach'?>

      <?rfc include='reference.I-D.boucadair-connectivity-provisioning-protocol'?>

      <?rfc include='reference.I-D.ietf-pcp-authentication'?>

      <?rfc include='reference.RFC.3084'?>

      <?rfc include='reference.RFC.6241'?>

      <reference anchor="OpenFlow"
                 target="http://www.openflow.org/documents/openflow-spec-v1.1.0.pdf">
        <front>
          <title>OpenFlow Switch Specification</title>

          <author fullname="OpenFlow" surname="OpenFlow">
            <organization>OpenFlow</organization>
          </author>

          <date month="February" year="2011" />
        </front>
      </reference>

      <!---->
    </references>
  </back>
</rfc>
