OSPF P. Pillay-Esnault
Internet-Draft Huawei Technologies
Intended status: Standards Track D. Yeung
Expires: January 8, 2017 Cisco Systems
B. Pithawala
July 7, 2016
Service Distribution using OSPF
draft-pillay-esnault-ospf-service-distribution-03
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.
However, 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 8, 2017.
Copyright Notice
Copyright (c) 2016 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
Pillay-Esnault, et al. Expires January 8, 2017 [Page 1]
Internet-Draft Service Distribution using OSPF July 2016
(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
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 6
7. Mechanics of the OSPF Service Information Distribution
Implementation . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Advertising and Signaling of SDR Capability . . . . . . . 7
7.2. Advertising the Service Distribution Router and its
address mapping . . . . . . . . . . . . . . . . . . . . . 8
7.3. Advertising the Directory of Producers and Consumers . . 9
7.4. Service Routing Capable Router Operations . . . . . . . . 12
7.4.1. Operation due to Producer changes . . . . . . . . . . 13
7.4.2. Operation due to Consumer changes . . . . . . . . . . 13
8. Calculation of Optimal Producer . . . . . . . . . . . . . . . 14
9. Service Router Data Operations . . . . . . . . . . . . . . . 14
9.1. Implementation of SDDA . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11.1. Service Distribution Router Capability bit . . . . . . . 15
11.2. Service ID Registry . . . . . . . . . . . . . . . . . . 15
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
14. Normative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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
Pillay-Esnault, et al. Expires January 8, 2017 [Page 2]
Internet-Draft Service Distribution using OSPF July 2016
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.
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.
2. 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] only when
they appear in all upper case. They may also appear in lower or
mixed case as English words, without any normative meaning.
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
Pillay-Esnault, et al. Expires January 8, 2017 [Page 3]
Internet-Draft Service Distribution using OSPF July 2016
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.
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 and
consumers in the 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
Pillay-Esnault, et al. Expires January 8, 2017 [Page 4]
Internet-Draft Service Distribution using OSPF July 2016
exchange processing to remote SDRs to an external agent. The
implementation detail of the agent is outside the scope 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 limited data of
interest.
Pillay-Esnault, et al. Expires January 8, 2017 [Page 5]
Internet-Draft Service Distribution using OSPF July 2016
Access other Distribute data to
OSPF Routers other Data Exchange Agent (controller)
^ ^
| |
| |
+----------------------------------------+
| | | |
| | | |
| +-------------+ +----------+ |
| | 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 be stored on the disk of the router
and accessible by APIs to OSPF and other applications for query and
Pillay-Esnault, et al. Expires January 8, 2017 [Page 6]
Internet-Draft Service Distribution using OSPF July 2016
update or an external storage outside the router. A SDD is not part
of OSPF and does not participate in the bringing up of adjacencies.
The SDD may be accessible through APIs to outside applications such
as an SDN controller.
It is desirable that the service data databases have a very flexible
format to cater for a broad range of applications. The service data
may be secured and encrypted with authenticated access to outside
applications as well. The scope of how to implement this database is
outside the scope of this document.
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 [RFC7770].
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
sections 2.3, 2.4 and 2.5 of [RFC7770]
Pillay-Esnault, et al. Expires January 8, 2017 [Page 7]
Internet-Draft Service Distribution using OSPF July 2016
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 resolvable router ID or 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.
Pillay-Esnault, et al. Expires January 8, 2017 [Page 8]
Internet-Draft Service Distribution using OSPF July 2016
Length: A 16-bit field that indicates the length of the value
portion in octets.
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
Pillay-Esnault, et al. Expires January 8, 2017 [Page 9]
Internet-Draft Service Distribution using OSPF July 2016
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
: . :
~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~
| 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.
Pillay-Esnault, et al. Expires January 8, 2017 [Page 10]
Internet-Draft Service Distribution using OSPF July 2016
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 Tags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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
Service Tags: A 32-bit field representing the Service Tags. Service
tags may be used for policy purposes. This TLV is applicable both to
OSPFv2 and OSPFv3.
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.
Pillay-Esnault, et al. Expires January 8, 2017 [Page 11]
Internet-Draft Service Distribution using OSPF July 2016
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.
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
Pillay-Esnault, et al. Expires January 8, 2017 [Page 12]
Internet-Draft Service Distribution using OSPF July 2016
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
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 has 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
Pillay-Esnault, et al. Expires January 8, 2017 [Page 13]
Internet-Draft Service Distribution using OSPF July 2016
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
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
Pillay-Esnault, et al. Expires January 8, 2017 [Page 14]
Internet-Draft Service Distribution using OSPF July 2016
distribute the new data to all the distribution channels which carry
the service.
9.1. Implementation of SDDA
The SDDA implentation is beyond the scope of this document.
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
11.1. Service Distribution Router Capability bit
This draft requests IANA to assign the bit 6 for Service Distribution
Router Capability in the OSPF Router Informational Capabilities Bits.
11.2. Service ID Registry
The Service ID registries has been defined
+-------------+-----------------------------------+
| Range | Assignment Policy |
+-------------+-----------------------------------+
| 0 | Reserved (not to be assigned) |
| | |
| 1-32767 | Unassigned (Standards Action) |
| | |
| 32768-65535 | Experimentation (No assignements) |
| | |
| 65536.. | Reserved |
+-------------+-----------------------------------+
Service ID Assignments
12. Contributors
The authors would like to acknowledge the contributions of Mike
Dubroskiy, Rashmi Shrivastava and Jean-Michel Esnault in the early
draft of this document.
13. Acknowledgments
The authors would like to thank Les Ginsberg, Keyur Patel and many
others who participated in numerous discussions.
Pillay-Esnault, et al. Expires January 8, 2017 [Page 15]
Internet-Draft Service Distribution using OSPF July 2016
This document was produced using Marshall Rose's xml2rfc tool.
14. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
July 2008, <http://www.rfc-editor.org/info/rfc5250>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <http://www.rfc-editor.org/info/rfc7770>.
Authors' Addresses
Padma Pillay-Esnault
Huawei Technologies
2330 Central Expressway
Santa Clara CA 95050
USA
Email: padma@huawei.com
Derek Yeung
Cisco Systems
510 McCarty Blvd
Milpitas, CA 95035
USA
Email: myeung@cisco.com
Pillay-Esnault, et al. Expires January 8, 2017 [Page 16]
Internet-Draft Service Distribution using OSPF July 2016
Burjiz Pithawala
Email: burjizp@gmail.com
Pillay-Esnault, et al. Expires January 8, 2017 [Page 17]