Internet DRAFT - draft-pillay-esnault-ospf-service-distribution

draft-pillay-esnault-ospf-service-distribution







Network Working Group                                  P. Pillay-Esnault
Internet-Draft                                              B. Pithawala
Intended status: Standards Track                                D. Yeung
Expires: January 16, 2014                                  Cisco Systems
                                                           July 15, 2013


                    Service Distribution using OSPF
           draft-pillay-esnault-ospf-service-distribution-02

Abstract

   The Open Shortest Path First (OSPF) protocol is used to carry data on
   behalf of other services using the Opaque Link State Advertisements.
   The protocol's flooding mechanism is well suited to cover the data
   propagation requirements of services such as Traffic Engineering.
   The current mechanism cannot scale for a large number of services nor
   satisfy some of their new set of requirements.  This document
   describes a new mechanism in OSPF to support service and data
   distribution for a large number of services, computation of preferred
   service access points and a controlled service data exchange.

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 16, 2014.

Copyright Notice

   Copyright (c) 2013 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



Pillay-Esnault, et al.  Expires January 16, 2014                [Page 1]

Internet-Draft       Service Distribution using OSPF           July 2013


   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
   2.  Specification of Requirements . . . . . . . . . . . . . . . .   3
   3.  Requirements for service data propagation . . . . . . . . . .   3
   4.  Typical Scenario for Services Distribution Router . . . . . .   4
   5.  OSPF Service Distribution Router  . . . . . . . . . . . . . .   4
   6.  Storage Of Service Data . . . . . . . . . . . . . . . . . . .   5
   7.  Mechanics of the OSPF Service Information Distribution
       Implementation  . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Advertising and Signaling of SDR Capability . . . . . . .   6
     7.2.  Advertising the Service Distribution Router and its
           address mapping . . . . . . . . . . . . . . . . . . . . .   7
     7.3.  Advertising the Directory of Producers and Consumers  . .   8
     7.4.  Service Routing Capable Router Operations . . . . . . . .  11
       7.4.1.  Operation due to Producer changes . . . . . . . . . .  11
       7.4.2.  Operation due to Consumer changes . . . . . . . . . .  12
   8.  Calculation of Optimal Producer . . . . . . . . . . . . . . .  12
   9.  Service Router Data Operations  . . . . . . . . . . . . . . .  12
     9.1.  Implementation of SDDA  . . . . . . . . . . . . . . . . .  13
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  13
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   12. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  14
   13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14
   14. Normative References  . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Originally, routing protocols were designed to propagate routing
   related information only.  With the advent of Traffic Engineering,
   the IGPs started to be used as a transport mechanism.  Most of the
   applications using IGPs as transport are still very much limited and
   confined to routing applications with similar requirements.

   Today, OSPF can carry data for applications using Opaque LSAs.  These
   Opaque LSAs are an integral part of the OSPF database and will be
   flooded, synchronized and updated just as any other LSA.  However,
   they do not contribute directly to any routes or trigger an SPF.

   Opaque LSAs will need to be flooded across all the OSPF area or
   domain and neighbor adjacencies to FULL state will depend on
   successful exchange of these LSAs.



Pillay-Esnault, et al.  Expires January 16, 2014                [Page 2]

Internet-Draft       Service Distribution using OSPF           July 2013


   The Link State IGPs are limited on the size of payload information
   they can carry as it will be flooded and stored in every single
   router all across their areas or domain regardless whether it is of
   interest or not.

   This document describes a new mechanism in OSPF to support service
   and data distribution for a large number of services, computation of
   preferred service access points and controlled distribution of
   service data.

   We presuppose familiarity with the contents of [RFC4970], [RFC5250],
   [RFC2328] and [RFC5340] .

2.  Specification of Requirements

   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].

3.  Requirements for service data propagation

   Services requirements differ from the traditional routing information
   dissemination model.  The service data may be unrelated to routing or
   be of interest only to some routers.  The new set of requirements for
   using OSPF as Service Distribution Router (SDR) is as follows

      Scale to a large number of services

      No assumption regarding size, format or nature of the data

      No assumption regarding topology

      Routing and service data separated and independent

      Must support cases where minimal number of routers only may be
      upgraded

      Must support dynamic events

      Routers only store and process data of interest

      Ability to compute the shortest path to a producer or consumer of
      a service per IGP metrics or service metrics.

      There is no assumptions regarding producers and consumers of
      services, their location or uniqueness.

      Secured data may reside only on some routers.



Pillay-Esnault, et al.  Expires January 16, 2014                [Page 3]

Internet-Draft       Service Distribution using OSPF           July 2013


   In addition the routing requirements for OSPF as Service data
   distribution are

      Backward compatible with Open Standard OSPF

      Minimal/No impact on routing convergence and performance

4.  Typical Scenario for Services Distribution Router

   A SDR is typically reachable by multiple consumers or producers of
   data.  The router itself may not be connected directly to any other
   router with Service Distribution Capability.  The intermediate
   routers may have limited storage capability or cannot store the data
   for security reasons.

   The SDR is aware of the topological information of the other service
   routers and can compute paths to the preferred Producer SDR (PSDR) or
   the Consumers SDR (CSDR) of a service.The SDR will implement tables
   of producers and consumers for services.

   The SDR ensures that interested subscribers to a service are notified
   with the latest updates.

   Producers or consumers can join or leave a service at any time using
   APIs.  The SDR receiving the notification of "registration" or "de-
   registration" flood the change of state to all the known SDRs in its
   topology.  Therefore, all SDR have the same view of the producers/
   consumers topology.

5.  OSPF Service Distribution Router

   A SDR leverages OSPF's capability to store and flood the topology and
   other attributes of SDR capable routers.  SDRs form an overlay and do
   not require to be directly connected to each other.  SDRs do not need
   to maintain adjacency between them other than the normal OSPF
   adjacency for routing purposes.  The SDRs rely on the OSPF underlying
   network for reachability to other SDR routers.

   SDRs advertise a directory of producers and consumers of services and
   are capable to compute preferred producers.  The SDRs delegate data
   exchange processing to remote SDRs to an external agent.  This agent
   is described in detail in section 9 of this document.

   The OSPF Opaque LSAs is used to carry relevant and interesting
   information for reachability and nature of SDR capable routers.

   In order to limit the service data dissemination costs (storage,
   bandwidth, security, ..), SDRs may store only data of interest.



Pillay-Esnault, et al.  Expires January 16, 2014                [Page 4]

Internet-Draft       Service Distribution using OSPF           July 2013


       Access other           Distribute data to
       OSPF Routers           other Data Exchange Agent
             ^                          ^
             |                          |
             |                          |
       +----------------------------------------+
       |     |                          |       |
       |     |                          |       |
       |    +-------------+       +----------+  |
       |    |   OSPF      |       | Data     |  |
       |    |             |<-->   | Exchange |  |
       | +->|             |       | Agent    |  |
       | |  +-------------+       +----------+  |
       | |  | OSPF Area DB|         |           |
       | |  |             |         |           |
       | |  |             |         |           |   +------------+
       | |  |             |         |           |   |            |
       | |  +-------------+         |APIs       |   | Producer   |
       | |  | OSPF Opaque |         |(Access)   |   |  Apps.     |
       | |  |    LSAs     |         |           |   +------------+
       | |  |             |         |           |           |
       | |  |             |         |           |           |
       | |  +-------------+         |           |           |
       | |                          |           |           |
       | |    +---------------------v------+    |API(Update)|
       | +->  |    Service Data Database   |<---------------+
       |APIs  |     May be unrelated to    |    |(secured access)
       |      |         routing            |    |
       |      |                            | API|   +------------+
       |      |                           |<------->|            |
       |      +----------------------------+    |   | Consumer   |
       |                                        |   |  Apps      |
       |                                        |   +------------+
       +----------------------------------------+
              Service Distribution Router


                   The OSPF Service Distribution Router

   The following sections describe the extensions in OSPF protocol to
   support this capability.

6.  Storage Of Service Data

   The service data can be stored in an independent Service Data
   Database(SDD).  There is no assumption made here on the size, format
   or nature of data.  The data can even be stored on the disk of the
   router and accessible by APIs to OSPF and other applications for



Pillay-Esnault, et al.  Expires January 16, 2014                [Page 5]

Internet-Draft       Service Distribution using OSPF           July 2013


   query and update.  A SDD is not part of OSPF and does not participate
   in the bringing up of adjacencies.

   It is desirable that the service data database have a very flexible
   format to cater for a broad range of applications.  A possible
   solution is that the database records be defined as container objects
   which themselves contain service metadata.

7.  Mechanics of the OSPF Service Information Distribution
    Implementation

7.1.  Advertising and Signaling of SDR Capability

   The OSPF SDR router will identify itself to the rest of the domain by
   advertising its capability and a routable ip address.  For example,
   this address MAY be a loopback interface configured to uniquely
   identify an OSPF SDR router.  A new bit for SDR capability is
   reserved in the Router Information Capabilities TLV of the Router
   Information LSA, as defined in section 2.1 of [RFC4970].

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |     Options   |  11           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       4       |                    0                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                            TLVs                             -+
   |                             ...                               |


                      The OSPF Router Information LSA

      Flooding scope for AS 11

   The format of the Router Informational Capabilities TLV is defined in
   2.3 and 2.4 of [RFC4970]







Pillay-Esnault, et al.  Expires January 16, 2014                [Page 6]

Internet-Draft       Service Distribution using OSPF           July 2013


   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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Informational Capabilities                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 The Router Informational Capabilities TLV

   A new informational capability bit is defined for Service
   Distribution Routers

      Bit Capabilities

      6 Service Distribution Router Capability

7.2.  Advertising the Service Distribution Router and its address
      mapping

   A new TLV is defined in the Router Information LSA is used to
   advertise a routable address to reach the router.

   TLV
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            2                  |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Address Format            |         Address length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Reachable IPv4/IPv6 address mapping to SDR                |
   :                                                               :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        SDR Metric             |        Type of metric         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Service router TLV and address Mapping

      Type: A 16-bit field set to 2 representing the Service
      Distribution Router Address Mapping This TLV is applicable both to
      OSPFv2 and OSPFv3.

      Length: A 16-bit field that indicates the length of the value
      portion in octets.



Pillay-Esnault, et al.  Expires January 16, 2014                [Page 7]

Internet-Draft       Service Distribution using OSPF           July 2013


      Address Format: A 16-bit field that indicates the length of the
      value portion in octets.

      Possible values



         1 : IPv4 Address

         2 : IPv6 Address

      Address Length: A 16-bit field that indicates the length of the
      value portion in octets.

      Address : Routable IPv4/IPv6 address mapped to SDR

      SDR metric: A 16-bit field that indicates SDR metric greater than
      0.

      Type of metric:



         0 : None defined - Ignore SDR Metric

         1 : SDR metric overrides the IGP metric

         2 : Computed metric is composite of IGP metric + SDR metric

7.3.  Advertising the Directory of Producers and Consumers

   Opaque LSAs with autonomous system flooding scope as described in
   [RFC5250], are used to describe the services reachable through this
   router using TLVs.

   Definition of TLV

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           3                   |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Producer      |     Number of services(subTLVs)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Sub TLV Description Serv n                       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
   :                               .                               :
   ~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~



Pillay-Esnault, et al.  Expires January 16, 2014                [Page 8]

Internet-Draft       Service Distribution using OSPF           July 2013


   |              Sub TLV Description Serv m                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Subscriber    |    Number of services of interest (SubTLVs)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Sub TLV Subscribe Serv x                         :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
   :                               .                               :
   ~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~
   |              Sub TLV Subscribe Serv y                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                               .                               :


         Example of TLV for Directory of Producers and Subscribers

   Type: A 16-bit field set to 3 representing the Directory of the
   Service Distribution Router.  This TLV is applicable both to OSPFv2
   and OSPFv3.

   Length: A 16-bit field that indicates the length of the value portion
   in octets.

   Services are described in a unique sub-TLV.  The sub-TLV should
   contain a Service Identifier which uniquely identifies the service
   with network wide significance.  The sub-TLV format should be
   flexible and it MAY be used to advertise a preference metric for the
   service.

   TLV
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            1                  |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Service ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Service metric                 |        Type of metric         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                        Service Description Sub-TLV

   Type: A 16-bit field set to 1 representing the Service Description
   Sub-TLV This TLV is applicable both to OSPFv2 and OSPFv3.

   Length: A 16-bit field that indicates the length of the value portion
   in octets.




Pillay-Esnault, et al.  Expires January 16, 2014                [Page 9]

Internet-Draft       Service Distribution using OSPF           July 2013


   Service ID: A 32-bit field representing the Service Identifier.  This
   TLV is applicable both to OSPFv2 and OSPFv3.

   Service Metric: A 16-bit field that indicates the metric associated
   with the service.  A metric of 0 would represent undefined.  An
   unreachable or oversubscribed service has a metric of 0xFFFFFFFF.

   Type of metric:

      0 : None defined - Ignore Service Metric

      1 : Service metric overrides the IGP/SDR metric

      2 : Computed metric is composite of IGP metric + SDR metric +
      Service metric

   The Services of interest (Consumers exist) are described in a unique
   sub-TLV.  The sub-TLV should contain a Service Identifier which
   uniquely identifies the service with network wide significance.  The
   sub-TLV format should be flexible and MUST contained the preferred
   SDR ID.  If no producer exists yet for the service then the Preferred
   SDR ID should be set to 0.

   TLV
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            2                  |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Service ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             PSDR ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Service Subscription Sub-TLV

   Type: A 16-bit field set to 2 representing the Service Subscription
   Sub-TLV This TLV is applicable both to OSPFv2 and OSPFv3.

   Length: A 16-bit field that indicates the length of the value portion
   in octets.

   Service ID: A 32-bit field representing the Service Identifier.  A
   Service Identifier may only be defined in a unique sub-tlv.  This TLV
   is applicable both to OSPFv2 and OSPFv3.





Pillay-Esnault, et al.  Expires January 16, 2014               [Page 10]

Internet-Draft       Service Distribution using OSPF           July 2013


   PSDR ID: A 32-bit field that indicates the PSDR for data exchange.
   Set to 0 if there is no producer for the service.

   The topological view and characteristics of the OSPF Overlay Service
   Distribution Routers can be used to compute preferred producer
   independent of IGP metrics.  It is possible to have multiple LSAs for
   large directories however a service must be described in a unique
   sub-tlv for the SDR.

7.4.  Service Routing Capable Router Operations

   The additional requirements are

      No assumption on topology

      Multiple producers may exists

      Multiple consumers can all have different service interest

      Producers/Consumers may join and leave at anytime

      Consumers and Producers have access to the Service Data database

   The SDR capable routers advertise the consumers who subscribe to a
   service.  The producers may connect to the SDR router to update the
   services/data in the Service Data database.  The SDR router then
   builds the Opaque LSA describing the producer services which are
   reachable through it as well as the services its consumers are
   interested in.

   When the router has a full neighbor relationship, it now has the
   topological view of all SDR capable routers in the domain as well as
   the services they offer and are interested in.

   Leveraging the fact that the OSPF has already run its SPF, the
   reachability of overlay SDR capable routers and services offered.  It
   is possible to calculate the preferred Producer SDR for a service by
   using a composite of the IGP metric, the SDR metric and the service
   metric.  The list of preferred producers for a service can then be
   evaluated at each SDR.

   The list of Consumer SDRs interested in service can also easily be
   computed from the directory of consumers.

7.4.1.  Operation due to Producer changes

   The producer service operations are




Pillay-Esnault, et al.  Expires January 16, 2014               [Page 11]

Internet-Draft       Service Distribution using OSPF           July 2013


      New producer advertises a service

      Existing Producer start advertising a new service

      Existing Producer stops advertising a service.

   The router will be notified by the application regarding the new
   producer and the services offered.  The router will then either
   update or create an Opaque LSA to advertise this new information and
   flood it to all SR routers.

   Upon receiving this information, remote SDR routers can recalculate
   the preferred PSDR.  It may also need to perform some operations if
   it have consumers for this new service.

7.4.2.  Operation due to Consumer changes

   The consumer service operations are

      A new consumer join and add subscription

      An existing consumer stops subscriptions

      An existing consumer adds subscriptions

   The router will be notified by the application regarding the new
   consumer and the services it is interested in.  The router will then
   either update or create an Opaque LSA to advertise this new
   information and flood it to all SDR routers.

   Upon receipt of the new Opaque LSA the remote SDR routers can then
   update the list of CSDRs interested in their services per latest
   information.

8.  Calculation of Optimal Producer

   Leveraging OSPF capability to store and compute paths on a topology,
   the same mechanisms can be used to compute the Optimal PSDRs using
   the SPF for SDR reachable address using IGP metrics, SDR metric and
   the service metric.  The Optimal PSDR is used in the consumer subtlv.

9.  Service Router Data Operations

   OSPF SDR delegates the task of SDD distribution to the Data Exchange
   Agent.  This text defines an implementation of such an agent and
   named it the Service Data Distribution Agent (SDDA).  OSPF SDR
   provides SDDA information about which Consumer SDR is interested
   which service provided by this OSPF (Producer) SDR.  The SDDA makes



Pillay-Esnault, et al.  Expires January 16, 2014               [Page 12]

Internet-Draft       Service Distribution using OSPF           July 2013


   use of such information to setup distribution channel for SDD
   distribution from this OSPF Producer SDR to other OSPF Consumer SDRs.

   For each OSPF Consumer SDR which subscribes to at least one service
   provided by this OSPF Producer SDR, there will be a different
   distribution channel created.

   The distribution channel is setup when the OSPF Consumer SDR has
   subscribed to its first service provided by this OSPF Producer SDR.
   When the OSPF Consumer SDR subscribes to additional service provided
   by this OSPF Producer SDR, service data for the new service will be
   carried over the existing distribution channel.  In order words, the
   same distribution channel can carry service data for different
   services.  The services carried are said to be bound to the
   distribution channel.

   When a distribution channel is first setup for a service or a new
   service is bound to the channel, the SDDA will notify the SDD.  In
   turn, the SDD will send the latest data for that service to the SDDA
   for distribution over that channel.

   On the other hand, whenever the SDD has new version of data for a
   service, the SDD will send those data to the SDDA, which will
   distribute the new data to all the distribution channels which carry
   the service.

9.1.  Implementation of SDDA

   The SDDA can be implemented in many ways and beyond the scope of this
   document.  For example, the SDDA can use BGP capability to transport
   service data as described in [BGPSERV] as its transport protocol for
   service data distribution.

10.  Security Considerations

   The new extensions defined in this document do not introduce any new
   security concerns other than those already defined in Section 6 of
   [RFC2328] and [RFC5340].

11.  IANA Considerations

   This document has no actions for IANA.









Pillay-Esnault, et al.  Expires January 16, 2014               [Page 13]

Internet-Draft       Service Distribution using OSPF           July 2013


12.  Contributors

   The authors would like to acknowledge the contributions of

      Mike Dubroskiy

      Rashmi Shrivastava

      Jean-Michel Esnault

13.  Acknowledgments

   The authors would like to thank Les Ginsberg, Keyur Patel and many
   others who participated in numerous discussions.

   This document was produced using Marshall Rose's xml2rfc tool.

14.  Normative References

   [BGPSERV]  Patel, K., Medved, J., Fernando, R., and B. Pithawala,
              "Service Advertisement using BGP", April 2013, <http://
              www.ietf.org/internet-drafts/draft-keyupate-bgp-
              services-02>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2328]  Moy, J., "OSPF Version 2", RFC 2328, April 1998.

   [RFC4970]  Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
              Shaffer, "Extensions to OSPF for Advertising Optional
              Router Capabilities", RFC 4970, July 2007.

   [RFC5250]  Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
              OSPF Opaque LSA Option", RFC 5250, July 2008.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, July 2008.

Authors' Addresses

   Padma Pillay-Esnault
   Cisco Systems
   510 McCarty Blvd
   Milpitas, CA  95035
   USA

   EMail: ppe@cisco.com



Pillay-Esnault, et al.  Expires January 16, 2014               [Page 14]

Internet-Draft       Service Distribution using OSPF           July 2013


   Burjiz Pithawala
   Cisco Systems
   510 McCarty Blvd
   Milpitas, CA  95035
   USA

   EMail: bpithaw@cisco.com


   Derek Yeung
   Cisco Systems
   510 McCarty Blvd
   Milpitas, CA  95035
   USA

   EMail: myeung@cisco.com



































Pillay-Esnault, et al.  Expires January 16, 2014               [Page 15]