anchor.diff:  
   ## <a id='architecture'></a>Architecture ##
   
  -Cloud Foundry supports three models for Route Services: static, brokered services; fully-brokered services; and user-provided services. In each case, you configure a route service to run either inside or outside of Cloud Foundry, in order to process traffic addressed to an app.
  +Cloud Foundry supports three models for Route Services: fully-brokered services; static, brokered services; and user-provided services. In each case, you configure a route service to process traffic addressed to an app.
   
  -### <a id="static-brokered"></a>Static, Brokered Service ###
  +### <a id="fully-brokered"></a>Fully-Brokered Service ###
   
  -In this model, an operator installs a static routing service, which might be a piece of hardware, in front of the Load Balancer. This routing service receives traffic to all apps running in the Cloud Foundry deployment. The service provider creates a service broker to publish the service to the CF marketplace. Developers can then create an instance of the service and bind it to their apps with the following commands:
  +In this model, the CF router receives all traffic to apps in the deployment before any processing by the route service. Developers can bind a route service to any app, and if an app is bound to a route service, the CF router sends its traffic to the service. After the route service processes requests, it sends them back to the load balancer in front of the CF router. The second time through, the CF router recognizes that the route service has already handled them, and forwards them directly to app instances.
  +
  +![Fully brokered](images/route-services-fully-brokered.png)
  +
  +The route service can run inside or outside of CF, so long as it fulfills the [Service Instance Responsibilities](#service-instance-responsibilities) to integrate it with the CF router. A service broker publishes the route service to the CF marketplace, making it available to developers. Developers can then create an instance of the service and bind it to their apps with the following commands:
   
   `cf create-service BROKER_SERVICE_PLAN SERVICE_INSTANCE`
   `cf bind-route-service YOUR_APP_DOMAIN SERVICE_INSTANCE [--hostname HOSTNAME]`
   
  -In this model, you configure route services on an app-by-app basis. When you bind a service to an app, the service broker tells the routing service to process that app's traffic rather than pass the requests through unchanged.
  +Developers configure the service either through the service provider's web interface or by passing [arbitrary parameters](../devguide/services/managing-services.html#arbitrary-params-create) to their `cf create-service` call, through the `-c` flag.
  +
  +**Advantages:**
  +
  +- Developers can use a Service Broker to dynamically configure how the route service processes traffic to specific applications.
  +- Adding route services requires no manual infrastructure configuration.
  +- Traffic to apps that do not use the service makes fewer network hops; requests for those apps do not pass through the route service.
  +
  +**Disadvantages:**:
  +
  +- Traffic to apps that use the route service makes additional network hops, as compared to the static model.
  +
  +### <a id="static-brokered"></a>Static, Brokered Service ###
  +
  +In this model, an operator installs a static routing service, which might be a piece of hardware, in front of the Load Balancer. The routing service runs outside of Cloud Foundry and receives traffic to all apps running in the CF deployment. The service provider creates a service broker to publish the service to the CF marketplace. As with a [fully-brokered service](#fully-brokered), a developer can use the service by instantiating it with `cf create-service` and binding it to an app with `cf bind-route-service`. 
   
   ![Static, brokered](images/route-services-static-brokered.png)
  +
  +In this model, you configure route services on an app-by-app basis. When you bind a service to an app, the service broker directs the routing service to process that app's traffic rather than pass the requests through unchanged.
   
   **Advantages:**
   
  
positive.code: - Developers must manually provision/configure route services out of the context of Cloud Foundry; no service broker automates these operations.
  - Traffic to apps that use the route service makes additional network hops, as compared to the static model.
  
  ### <a id="route-architecture-summary"></a>Route Architecture Summary ###
  
  The models above require the [broker](#broker-responsibilities) and [service instance](#service-instance-responsibilities) responsibilities below, as summarized in the following table:
  
  <table id='route-architecture-summary' border="1" class="nice" >
    <tr>
      <th>Route Services Architecture</th>
      <th>Fulfills CF <a href="#service-instance-responsibilities">Service Instance Responsibilities</a></th>
      <th>Fulfills CF <a href="#broker-responsibilities">Broker Responsibilities</a></th>
    </tr><tr>
      <td>Static Brokered</td>
      <td>No</td>
      <td>Yes</td>
    </tr><tr>
      <td>Fully-Brokered</td>
      <td>Yes</td>
      <td>Yes</td>
    </tr><tr>
      <td>User-Provided</td>
  
negative.code: - Adding route services requires manual infrastructure configuration.
  - Unnecessary network hops for traffic to apps that do not use the route service; requests for all apps hosted by the the deployment pass through the route service component.
  
  ### <a id="user-provided"></a>User-Provided Service ###
  
  If a route service is not listed in the CF marketplace by a broker, a developer can still bind it to their app as a User-Provided service. The service can run anywhere, either inside or outside of CF, but it must fulfill the integration requirements described in [Service Instance Responsibilities](#service-instance-responsibilities). The service also needs to be reachable by an outbound connection from the CF Router.
  
  ![User-provided](images/route-services-user-provided.png)
  
  This model is identical to the [fully-brokered service](#fully-brokered) model, except without the broker. Developers configure the service manually, outside of Cloud Foundry. They can then create a user-provided service instance and bind it to their application with the following commands, supplying the URL of their route service:
  
  `cf create-user-provided-service SERVICE_INSTANCE -r ROUTE_SERVICE_URL`
  `cf bind-route-service DOMAIN SERVICE_INSTANCE [--hostname HOSTNAME]`
  
  **Advantages:**
  
  