< draft-pillay-esnault-ospf-service-distribution-02.txt   draft-pillay-esnault-ospf-service-distribution-03.txt >
Network Working Group P. Pillay-Esnault OSPF P. Pillay-Esnault
Internet-Draft B. Pithawala Internet-Draft Huawei Technologies
Intended status: Standards Track D. Yeung Intended status: Standards Track D. Yeung
Expires: January 16, 2014 Cisco Systems Expires: January 8, 2017 Cisco Systems
July 15, 2013 B. Pithawala
July 7, 2016
Service Distribution using OSPF Service Distribution using OSPF
draft-pillay-esnault-ospf-service-distribution-02 draft-pillay-esnault-ospf-service-distribution-03
Abstract Abstract
The Open Shortest Path First (OSPF) protocol is used to carry data on The Open Shortest Path First (OSPF) protocol is used to carry data on
behalf of other services using the Opaque Link State Advertisements. behalf of other services using the Opaque Link State Advertisements.
The protocol's flooding mechanism is well suited to cover the data The protocol's flooding mechanism is well suited to cover the data
propagation requirements of services such as Traffic Engineering. propagation requirements of services such as Traffic Engineering.
The current mechanism cannot scale for a large number of services nor However, the current mechanism cannot scale for a large number of
satisfy some of their new set of requirements. This document services nor satisfy some of their new set of requirements. This
describes a new mechanism in OSPF to support service and data document describes a new mechanism in OSPF to support service and
distribution for a large number of services, computation of preferred data distribution for a large number of services, computation of
service access points and a controlled service data exchange. preferred service access points and a controlled service data
exchange.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2014. This Internet-Draft will expire on January 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Requirements for service data propagation . . . . . . . . . . 3 3. Requirements for service data propagation . . . . . . . . . . 3
4. Typical Scenario for Services Distribution Router . . . . . . 4 4. Typical Scenario for Services Distribution Router . . . . . . 4
5. OSPF Service Distribution Router . . . . . . . . . . . . . . 4 5. OSPF Service Distribution Router . . . . . . . . . . . . . . 4
6. Storage Of Service Data . . . . . . . . . . . . . . . . . . . 5 6. Storage Of Service Data . . . . . . . . . . . . . . . . . . . 6
7. Mechanics of the OSPF Service Information Distribution 7. Mechanics of the OSPF Service Information Distribution
Implementation . . . . . . . . . . . . . . . . . . . . . . . 6 Implementation . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Advertising and Signaling of SDR Capability . . . . . . . 6 7.1. Advertising and Signaling of SDR Capability . . . . . . . 7
7.2. Advertising the Service Distribution Router and its 7.2. Advertising the Service Distribution Router and its
address mapping . . . . . . . . . . . . . . . . . . . . . 7 address mapping . . . . . . . . . . . . . . . . . . . . . 8
7.3. Advertising the Directory of Producers and Consumers . . 8 7.3. Advertising the Directory of Producers and Consumers . . 9
7.4. Service Routing Capable Router Operations . . . . . . . . 11 7.4. Service Routing Capable Router Operations . . . . . . . . 12
7.4.1. Operation due to Producer changes . . . . . . . . . . 11 7.4.1. Operation due to Producer changes . . . . . . . . . . 13
7.4.2. Operation due to Consumer changes . . . . . . . . . . 12 7.4.2. Operation due to Consumer changes . . . . . . . . . . 13
8. Calculation of Optimal Producer . . . . . . . . . . . . . . . 12 8. Calculation of Optimal Producer . . . . . . . . . . . . . . . 14
9. Service Router Data Operations . . . . . . . . . . . . . . . 12 9. Service Router Data Operations . . . . . . . . . . . . . . . 14
9.1. Implementation of SDDA . . . . . . . . . . . . . . . . . 13 9.1. Implementation of SDDA . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Service Distribution Router Capability bit . . . . . . . 15
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 11.2. Service ID Registry . . . . . . . . . . . . . . . . . . 15
14. Normative References . . . . . . . . . . . . . . . . . . . . 14 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
14. Normative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Originally, routing protocols were designed to propagate routing Originally, routing protocols were designed to propagate routing
related information only. With the advent of Traffic Engineering, related information only. With the advent of Traffic Engineering,
the IGPs started to be used as a transport mechanism. Most of the the IGPs started to be used as a transport mechanism. Most of the
applications using IGPs as transport are still very much limited and applications using IGPs as transport are still very much limited and
confined to routing applications with similar requirements. confined to routing applications with similar requirements.
Today, OSPF can carry data for applications using Opaque LSAs. These Today, OSPF can carry data for applications using Opaque LSAs. These
skipping to change at page 3, line 15 skipping to change at page 3, line 21
The Link State IGPs are limited on the size of payload information 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 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 router all across their areas or domain regardless whether it is of
interest or not. interest or not.
This document describes a new mechanism in OSPF to support service This document describes a new mechanism in OSPF to support service
and data distribution for a large number of services, computation of and data distribution for a large number of services, computation of
preferred service access points and controlled distribution of preferred service access points and controlled distribution of
service data. service data.
We presuppose familiarity with the contents of [RFC4970], [RFC5250], 2. Requirements Language
[RFC2328] and [RFC5340] .
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. 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 3. Requirements for service data propagation
Services requirements differ from the traditional routing information Services requirements differ from the traditional routing information
dissemination model. The service data may be unrelated to routing or dissemination model. The service data may be unrelated to routing or
be of interest only to some routers. The new set of requirements for be of interest only to some routers. The new set of requirements for
using OSPF as Service Distribution Router (SDR) is as follows using OSPF as Service Distribution Router (SDR) is as follows
Scale to a large number of services Scale to a large number of services
skipping to change at page 4, line 31 skipping to change at page 4, line 38
routers and can compute paths to the preferred Producer SDR (PSDR) or routers and can compute paths to the preferred Producer SDR (PSDR) or
the Consumers SDR (CSDR) of a service.The SDR will implement tables the Consumers SDR (CSDR) of a service.The SDR will implement tables
of producers and consumers for services. of producers and consumers for services.
The SDR ensures that interested subscribers to a service are notified The SDR ensures that interested subscribers to a service are notified
with the latest updates. with the latest updates.
Producers or consumers can join or leave a service at any time using Producers or consumers can join or leave a service at any time using
APIs. The SDR receiving the notification of "registration" or "de- APIs. The SDR receiving the notification of "registration" or "de-
registration" flood the change of state to all the known SDRs in its registration" flood the change of state to all the known SDRs in its
topology. Therefore, all SDR have the same view of the producers/ topology. Therefore, all SDR have the same view of the producers and
consumers topology. consumers in the topology.
5. OSPF Service Distribution Router 5. OSPF Service Distribution Router
A SDR leverages OSPF's capability to store and flood the topology and 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 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 not require to be directly connected to each other. SDRs do not need
to maintain adjacency between them other than the normal OSPF to maintain adjacency between them other than the normal OSPF
adjacency for routing purposes. The SDRs rely on the OSPF underlying adjacency for routing purposes. The SDRs rely on the OSPF underlying
network for reachability to other SDR routers. network for reachability to other SDR routers.
SDRs advertise a directory of producers and consumers of services and SDRs advertise a directory of producers and consumers of services and
are capable to compute preferred producers. The SDRs delegate data are capable to compute preferred producers. The SDRs delegate data
exchange processing to remote SDRs to an external agent. This agent exchange processing to remote SDRs to an external agent. The
is described in detail in section 9 of this document. implementation detail of the agent is outside the scope of this
document.
The OSPF Opaque LSAs is used to carry relevant and interesting The OSPF Opaque LSAs is used to carry relevant and interesting
information for reachability and nature of SDR capable routers. information for reachability and nature of SDR capable routers.
In order to limit the service data dissemination costs (storage, In order to limit the service data dissemination costs (storage,
bandwidth, security, ..), SDRs may store only data of interest. bandwidth, security, ..), SDRs may store only limited data of
interest.
Access other Distribute data to Access other Distribute data to
OSPF Routers other Data Exchange Agent OSPF Routers other Data Exchange Agent (controller)
^ ^ ^ ^
| | | |
| | | |
+----------------------------------------+ +----------------------------------------+
| | | | | | | |
| | | | | | | |
| +-------------+ +----------+ | | +-------------+ +----------+ |
| | OSPF | | Data | | | | OSPF | | Data | |
| | |<--> | Exchange | | | | |<--> | Exchange | |
| +->| | | Agent | | | +->| | | Agent | |
skipping to change at page 5, line 50 skipping to change at page 6, line 50
The OSPF Service Distribution Router The OSPF Service Distribution Router
The following sections describe the extensions in OSPF protocol to The following sections describe the extensions in OSPF protocol to
support this capability. support this capability.
6. Storage Of Service Data 6. Storage Of Service Data
The service data can be stored in an independent 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 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 or nature of data. The data can be stored on the disk of the router
router and accessible by APIs to OSPF and other applications for and accessible by APIs to OSPF and other applications for query and
query and update. A SDD is not part of OSPF and does not participate update or an external storage outside the router. A SDD is not part
in the bringing up of adjacencies. 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 database have a very flexible It is desirable that the service data databases have a very flexible
format to cater for a broad range of applications. A possible format to cater for a broad range of applications. The service data
solution is that the database records be defined as container objects may be secured and encrypted with authenticated access to outside
which themselves contain service metadata. 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 7. Mechanics of the OSPF Service Information Distribution
Implementation Implementation
7.1. Advertising and Signaling of SDR Capability 7.1. Advertising and Signaling of SDR Capability
The OSPF SDR router will identify itself to the rest of the domain by The OSPF SDR router will identify itself to the rest of the domain by
advertising its capability and a routable ip address. For example, advertising its capability and a routable ip address. For example,
this address MAY be a loopback interface configured to uniquely this address MAY be a loopback interface configured to uniquely
identify an OSPF SDR router. A new bit for SDR capability is identify an OSPF SDR router. A new bit for SDR capability is
reserved in the Router Information Capabilities TLV of the Router reserved in the Router Information Capabilities TLV of the Router
Information LSA, as defined in section 2.1 of [RFC4970]. Information LSA, as defined in section 2.1 of [RFC7770].
0 1 2 3 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 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 | | LS age | Options | 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 0 | | 4 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 46 skipping to change at page 7, line 49
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- TLVs -+ +- TLVs -+
| ... | | ... |
The OSPF Router Information LSA The OSPF Router Information LSA
Flooding scope for AS 11 Flooding scope for AS 11
The format of the Router Informational Capabilities TLV is defined in The format of the Router Informational Capabilities TLV is defined in
2.3 and 2.4 of [RFC4970] sections 2.3, 2.4 and 2.5 of [RFC7770]
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Informational Capabilities | | Informational Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Router Informational Capabilities TLV The Router Informational Capabilities TLV
skipping to change at page 7, line 25 skipping to change at page 8, line 25
Distribution Routers Distribution Routers
Bit Capabilities Bit Capabilities
6 Service Distribution Router Capability 6 Service Distribution Router Capability
7.2. Advertising the Service Distribution Router and its address 7.2. Advertising the Service Distribution Router and its address
mapping mapping
A new TLV is defined in the Router Information LSA is used to A new TLV is defined in the Router Information LSA is used to
advertise a routable address to reach the router. advertise a resolvable router ID or routable address to reach the
router.
TLV TLV
0 1 2 3 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 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 | | 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Format | Address length | | Address Format | Address length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable IPv4/IPv6 address mapping to SDR | | Reachable IPv4/IPv6 address mapping to SDR |
skipping to change at page 9, line 41 skipping to change at page 11, line 15
TLV TLV
0 1 2 3 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 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 | | 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service ID | | Service ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Service metric | Type of metric | |Service metric | Type of metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Tags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Description Sub-TLV Service Description Sub-TLV
Type: A 16-bit field set to 1 representing the Service Description Type: A 16-bit field set to 1 representing the Service Description
Sub-TLV This TLV is applicable both to OSPFv2 and OSPFv3. Sub-TLV This TLV is applicable both to OSPFv2 and OSPFv3.
Length: A 16-bit field that indicates the length of the value portion Length: A 16-bit field that indicates the length of the value portion
in octets. in octets.
Service ID: A 32-bit field representing the Service Identifier. This Service ID: A 32-bit field representing the Service Identifier. This
skipping to change at page 10, line 21 skipping to change at page 11, line 42
Type of metric: Type of metric:
0 : None defined - Ignore Service Metric 0 : None defined - Ignore Service Metric
1 : Service metric overrides the IGP/SDR metric 1 : Service metric overrides the IGP/SDR metric
2 : Computed metric is composite of IGP metric + SDR metric + 2 : Computed metric is composite of IGP metric + SDR metric +
Service 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 The Services of interest (Consumers exist) are described in a unique
sub-TLV. The sub-TLV should contain a Service Identifier which sub-TLV. The sub-TLV should contain a Service Identifier which
uniquely identifies the service with network wide significance. The uniquely identifies the service with network wide significance. The
sub-TLV format should be flexible and MUST contained the preferred 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. If no producer exists yet for the service then the Preferred
SDR ID should be set to 0. SDR ID should be set to 0.
TLV TLV
0 1 2 3 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 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
skipping to change at page 12, line 4 skipping to change at page 13, line 29
using a composite of the IGP metric, the SDR metric and the service 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 metric. The list of preferred producers for a service can then be
evaluated at each SDR. evaluated at each SDR.
The list of Consumer SDRs interested in service can also easily be The list of Consumer SDRs interested in service can also easily be
computed from the directory of consumers. computed from the directory of consumers.
7.4.1. Operation due to Producer changes 7.4.1. Operation due to Producer changes
The producer service operations are The producer service operations are
New producer advertises a service New producer advertises a service
Existing Producer start advertising a new service Existing Producer start advertising a new service
Existing Producer stops advertising a service. Existing Producer stops advertising a service.
The router will be notified by the application regarding the new The router will be notified by the application regarding the new
producer and the services offered. The router will then either producer and the services offered. The router will then either
update or create an Opaque LSA to advertise this new information and update or create an Opaque LSA to advertise this new information and
flood it to all SR routers. flood it to all SR routers.
Upon receiving this information, remote SDR routers can recalculate Upon receiving this information, remote SDR routers can recalculate
the preferred PSDR. It may also need to perform some operations if the preferred PSDR. It may also need to perform some operations if
it have consumers for this new service. it has consumers for this new service.
7.4.2. Operation due to Consumer changes 7.4.2. Operation due to Consumer changes
The consumer service operations are The consumer service operations are
A new consumer join and add subscription A new consumer join and add subscription
An existing consumer stops subscriptions An existing consumer stops subscriptions
An existing consumer adds subscriptions An existing consumer adds subscriptions
The router will be notified by the application regarding the new The router will be notified by the application regarding the new
consumer and the services it is interested in. The router will then consumer and the services it is interested in. The router will then
either update or create an Opaque LSA to advertise this new either update or create an Opaque LSA to advertise this new
information and flood it to all SDR routers. information and flood it to all SDR routers.
Upon receipt of the new Opaque LSA the remote SDR routers can then Upon receipt of the new Opaque LSA the remote SDR routers can then
update the list of CSDRs interested in their services per latest update the list of CSDRs interested in their services per latest
information. information.
skipping to change at page 13, line 32 skipping to change at page 15, line 9
turn, the SDD will send the latest data for that service to the SDDA turn, the SDD will send the latest data for that service to the SDDA
for distribution over that channel. for distribution over that channel.
On the other hand, whenever the SDD has new version of data for a 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 service, the SDD will send those data to the SDDA, which will
distribute the new data to all the distribution channels which carry distribute the new data to all the distribution channels which carry
the service. the service.
9.1. Implementation of SDDA 9.1. Implementation of SDDA
The SDDA can be implemented in many ways and beyond the scope of this The SDDA implentation is beyond the scope of this document.
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 10. Security Considerations
The new extensions defined in this document do not introduce any new The new extensions defined in this document do not introduce any new
security concerns other than those already defined in Section 6 of security concerns other than those already defined in Section 6 of
[RFC2328] and [RFC5340]. [RFC2328] and [RFC5340].
11. IANA Considerations 11. IANA Considerations
This document has no actions for IANA. 11.1. Service Distribution Router Capability bit
12. Contributors This draft requests IANA to assign the bit 6 for Service Distribution
Router Capability in the OSPF Router Informational Capabilities Bits.
The authors would like to acknowledge the contributions of 11.2. Service ID Registry
Mike Dubroskiy 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 |
+-------------+-----------------------------------+
Rashmi Shrivastava Service ID Assignments
Jean-Michel Esnault 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 13. Acknowledgments
The authors would like to thank Les Ginsberg, Keyur Patel and many The authors would like to thank Les Ginsberg, Keyur Patel and many
others who participated in numerous discussions. others who participated in numerous discussions.
This document was produced using Marshall Rose's xml2rfc tool. This document was produced using Marshall Rose's xml2rfc tool.
14. Normative References 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
[RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
Shaffer, "Extensions to OSPF for Advertising Optional DOI 10.17487/RFC2328, April 1998,
Router Capabilities", RFC 4970, July 2007. <http://www.rfc-editor.org/info/rfc2328>.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, July 2008. 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 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. 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 Authors' Addresses
Padma Pillay-Esnault Padma Pillay-Esnault
Cisco Systems Huawei Technologies
510 McCarty Blvd 2330 Central Expressway
Milpitas, CA 95035 Santa Clara CA 95050
USA
EMail: ppe@cisco.com
Burjiz Pithawala
Cisco Systems
510 McCarty Blvd
Milpitas, CA 95035
USA USA
EMail: bpithaw@cisco.com Email: padma@huawei.com
Derek Yeung Derek Yeung
Cisco Systems Cisco Systems
510 McCarty Blvd 510 McCarty Blvd
Milpitas, CA 95035 Milpitas, CA 95035
USA USA
EMail: myeung@cisco.com Email: myeung@cisco.com
Burjiz Pithawala
Email: burjizp@gmail.com
 End of changes. 41 change blocks. 
87 lines changed or deleted 111 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/