draft-ietf-opes-architecture-02.txt   draft-ietf-opes-architecture-03.txt 
Network Working Group Abbie. Barbir Network Working Group Abbie. Barbir
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: December 18, 2002 R. Chen Expires: January 31, 2003 R. Chen
AT&T Labs AT&T Labs
M. Hofmann M. Hofmann
Bell Labs/Lucent Technologies Bell Labs/Lucent Technologies
H. Orman H. Orman
Purple Streak Development Purple Streak Development
R. Penno R. Penno
Nortel Networks Nortel Networks
G. Tomlinson G. Tomlinson
The Tomlinson Group The Tomlinson Group
June 19, 2002 August 2, 2002
An Architecture for Open Pluggable Edge Services (OPES) An Architecture for Open Pluggable Edge Services (OPES)
draft-ietf-opes-architecture-02 draft-ietf-opes-architecture-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 18, 2002. This Internet-Draft will expire on January 31, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This memo defines an architecture for a cooperative application This memo defines an architecture for a cooperative application
service in which a data provider, a data consumer, and zero or more service in which a data provider, a data consumer, and zero or more
application entities cooperatively realize a data stream service. application entities cooperatively realize a data stream service.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Architecture . . . . . . . . . . . . . . . . . . . . . . 4 2. The Architecture . . . . . . . . . . . . . . . . . . . . . . 4
2.1 OPES Entities . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 OPES Entities . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Data Dispatcher . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1 Data Dispatcher . . . . . . . . . . . . . . . . . . . . . . 4
2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . 8 2.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . 10 2.5 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . 8
3. Security and Privacy Considerations . . . . . . . . . . . . 12 3. Security and Privacy Considerations . . . . . . . . . . . . 10
3.1 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . 12 3.1 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Callout protocol . . . . . . . . . . . . . . . . . . . . . . 13 3.2 Callout protocol . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Establishing trust . . . . . . . . . . . . . . . . . . . . . 13 3.4 Establishing trust . . . . . . . . . . . . . . . . . . . . . 11
3.5 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . 14 3.5 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . 12
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 13
References . . . . . . . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
When realizing a data stream service between a provider and a When supplying a data stream service between a provider and a
consumer, the need may arise to provision the use of other consumer, the need may arise to provision the use of other
application entities, in addition to the provider and consumer. For application entities, in addition to the provider and consumer. For
example, some party may wish to customize a data stream as a service example, some party may wish to customize a data stream as a service
to a consumer. The customization step might be based on the to a consumer. The customization step might be based on the
customer's geographical locality (e.g., language) or resource customer's resource availability (e.g., display capabilities).
availability (e.g., display capabilities).
In some cases in may be beneficial to provide a customization service In some cases in may be beneficial to provide a customization service
at network location instead of deploying it at either the provider or at a network location between the provider and consumer host rather
the consumer host. For certain services performed on end-user behalf than at one of these endpoints. For certain services performed on
this may be the only option of service deployment. In this case, one end-user behalf this may be the only option of service deployment.
or more additional application entities may participate in the data In this case, one or more additional application entities may
stream service. There are many possible provisioning scenarios which participate in the data stream service. There are many possible
make a data stream service attractive. In [1] a description of provisioning scenarios which make a data stream service attractive.
several scenarios is provided. In [1] a description of several scenarios is provided.
This document presents the architectural components of Open Pluggable This document presents the architectural components of Open Pluggable
Edge Services (OPES) that are needed in order to perform a data Edge Services (OPES) that are needed in order to perform a data
stream service. The architecture addresses the IAB considerations stream service. The architecture addresses the IAB considerations
described in [2]. These considerations are covered in the various described in [2]. These considerations are covered in the various
parts of the document, specifically with respect to tracing (Section parts of the document, specifically with respect to tracing (Section
2.5) and security considerations (Section 3). 2.5) and security considerations (Section 3).
The document is organized as follows: Section 2 introduces the OPES The document is organized as follows: Section 2 introduces the OPES
architecture. Section 3 discusses security considerations. Section architecture. Section 3 discusses security considerations. Section
skipping to change at page 4, line 22 skipping to change at page 4, line 22
o OPES flows: data flows that are cooperatively realized by the o OPES flows: data flows that are cooperatively realized by the
OPES entities; and, OPES entities; and,
o OPES rules: these specify when and how to execute OPES o OPES rules: these specify when and how to execute OPES
intermediary services. intermediary services.
2.1 OPES Entities 2.1 OPES Entities
An OPES entity is an application that operates on a data flow between An OPES entity is an application that operates on a data flow between
a data provider application and a data consumer application. OPES a data provider application and a data consumer application. OPES
entities can be one of the following: entities can be:
o an OPES service application, which analyzes and possibly o an OPES service application, which analyzes and possibly
transforms messages exchanged between the data provider transforms messages exchanged between the data provider
application and the data consumer application; or, application and the data consumer application;
o a data dispatcher, which invokes an OPES service application based o a data dispatcher, which invokes an OPES service application based
on OPES ruleset and application-specific knowledge. on OPES ruleset and application-specific knowledge.
In the network, OPES entities reside inside OPES processors. The In the network, OPES entities reside inside OPES processors. The
cooperative behavior of OPES entities introduces additional cooperative behavior of OPES entities introduces additional
functionality for each data flow provided that it matches the OPES functionality for each data flow provided that it matches the OPES
rules. rules.
In the current work, the data provider and data consumer applications In the current work, the data provider and data consumer applications
are not considered as OPES entities. The OPES architecture is are not considered as OPES entities. The OPES architecture is
largely independent of the protocol that is used by the OPES entities largely independent of the protocol that is used by the OPES entities
to exchange data. However, this document selects HTTP [4] as the to exchange data. However, this document selects HTTP [4] as the
example protocol to be used for realizing a data flow. In this example for the underlying protocol in OPES flows.
regard, the logical implementation stack of an OPES entity is
summarized in Figure 1.
---------------------------------------------------------------------
+-------------+
|OPES service |
| Application |
| |
+-------------+
| Data |
| Dispatcher |
| |
+-------------+
| |
| HTTP |
| |
+-------------+
| TCP/IP |
+-------------+
| ... |
+-------------+
Figure 1: OPES Logical Implementation
---------------------------------------------------------------------
Figure 1 depicts a "minimal" stack for OPES. However, other
protocols may be present, depending on the functions that are
performed by the application.
2.1.1 Data Dispatcher 2.1.1 Data Dispatcher
Data dispatchers include a ruleset that can be compiled from several Data dispatchers include a ruleset that can be compiled from several
sources and must resolve into an unambiguous result. The compiled sources and must resolve into an unambiguous result. The combined
ruleset enables an OPES processor to determine which service ruleset enables an OPES processor to determine which service
applications to invoke for which data flow. Accordingly, the data applications to invoke for which data flow. Accordingly, the data
dispatcher constitutes an enhanced policy enforcement point, where dispatcher constitutes an enhanced policy enforcement point, where
policy rules are evaluated, service-specific data handlers and state policy rules are evaluated, service-specific data handlers and state
information is maintained, as depicted in Figure 2. information is maintained, as depicted in Figure 1.
--------------------------------------------------------------------- ---------------------------------------------------------------------
+----------+ +----------+
| callout | | callout |
| server | | server |
+----------+ +----------+
|| ||
|| ||
|| ||
skipping to change at page 6, line 29 skipping to change at page 5, line 29
| | appl | || | | | appl | || |
| +----------+ || | | +----------+ || |
| +----------------------+ | | +----------------------+ |
OPES flow <---->| | data dispatcher and | |<----> OPES flow OPES flow <---->| | data dispatcher and | |<----> OPES flow
| | policy enforcement | | | | policy enforcement | |
| +----------------------+ | | +----------------------+ |
| OPES | | OPES |
| processor | | processor |
+--------------------------+ +--------------------------+
Figure 2: Data Dispatchers Figure 1: Data Dispatchers
--------------------------------------------------------------------- ---------------------------------------------------------------------
The architecture allows more than one policy enforcement point to be The architecture allows more than one policy enforcement point to be
present on an OPES flow. present on an OPES flow.
2.2 OPES Flows 2.2 OPES Flows
An OPES flow is a cooperative undertaking between a data provider An OPES flow is a cooperative undertaking between a data provider
application, a data consumer application, zero or more OPES service application, a data consumer application, zero or more OPES service
skipping to change at page 7, line 30 skipping to change at page 6, line 30
| | | | | | | | | | | | | | | | | | | | | | | |
| +----------+ +--------+ | | +--------+ +----------+ | | +----------+ +--------+ | | +--------+ +----------+ |
| | TCP/IP | | TCP/IP | | | | TCP/IP | | TCP/IP | | | | TCP/IP | | TCP/IP | | | | TCP/IP | | TCP/IP | |
| +----------+ +--------+ | | +--------+ +----------+ | | +----------+ +--------+ | | +--------+ +----------+ |
| || || || | | || || || | | || || || | | || || || |
| ============= ================= ============= | | ============= ================= ============= |
| | | | | | | |
+------------------------------+ +------------------------------+ +------------------------------+ +------------------------------+
| <----------------- OPES flow -----------------> | | <----------------- OPES flow -----------------> |
Figure 3: An OPES flow Figure 2: An OPES flow
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 3 depicts two data dispatchers that are present in the OPES Figure 2 depicts two data dispatchers that are present in the OPES
flow. However, the architecture allows for zero or more data flow. However, the architecture allows for zero or more data
dispatchers to be present in any flow. dispatchers to be present in any flow.
2.3 OPES Rules 2.3 OPES Rules
OPES policy regarding services and the data provided to them is OPES policy regarding services and the data provided to them is
determined by a ruleset consisting of OPES rules. The rules consist determined by a ruleset consisting of OPES rules. The rules consist
of a set of conditions and related actions. The ruleset is the of a set of conditions and related actions. The ruleset is the
superset of all OPES rules on the processor. The OPES ruleset superset of all OPES rules on the processor. The OPES ruleset
determines which service applications will operate on a data stream. determines which service applications will operate on a data stream.
The communication of data stream elements to an application is The communication of data stream elements to an application is
performed by data dispatchers. In this model, all data filters are performed by data dispatchers. In this model, all data filters are
invoked for all data. invoked for all flows.
In order to ensure predictable behavior the OPES architecture In order to ensure predictable behavior, the OPES architecture
requires the use of a standardized schema for the purpose of defining requires the use of a standardized schema for the purpose of defining
and interpreting the ruleset. The OPES architecture does not require and interpreting the ruleset. The OPES architecture does not require
a mechanism for configuring a ruleset into a data dispatcher. This a mechanism for configuring a ruleset into a data dispatcher. This
is treated as a local matter for each implementation (e.g., through is treated as a local matter for each implementation (e.g., through
the use of a text editor, secure upload protocol, and so on). Future the use of a text editor, secure upload protocol, and so on). Future
revisions of the architecture may introduce such a requirement. revisions of the architecture may introduce such a requirement.
2.4 Callout Servers 2.4 Callout Servers
The evaluation of OPES ruleset determines which service applications The evaluation of OPES ruleset determines which service applications
will operate on a data stream. How the ruleset is evaluated is not will operate on a data stream. How the ruleset is evaluated is not
the subject of the architecture, except to note that it must result the subject of the architecture, except to note that it must result
in the same unambiguous result in all implementations. in the same unambiguous result in all implementations.
In some cases it may be useful for the OPES processor to distribute In some cases it may be useful for the OPES processor to distribute
the responsibility of service evaluation by communicating with one or the responsibility of service evaluation by communicating with one or
more callout servers (cf., [7]). The situation is illustrated in more callout servers. A data dispatcher invokes the services of a
Figure 4, which shows a data dispatcher communicating with multiple callout server by using the OPES callout protocol (OCP). The
callout servers as it processes an OPES flow. requirements for the OCP are given in [7]. The OCP is application-
agnostic, being unaware of the semantics of the encapsulated
--------------------------------------------------------------------- application protocol (e.g., HTTP). However, the OCP must
incorporate a service aware vectoring capability that parses the data
data callout callout callout flow according to the ruleset and delivers the data to the OPES
dispatcher server server server service application that can be local or remote.
+----------+ +---------+ +---------+ +---------+
| | | | | | | |
| OCP | | OCP | | OCP | ... | OCP |
| | | | | | | |
+----------+ +---------+ +---------+ +---------+
| Lower | | Lower | | Lower | | Lower |
| Layer | | Layer | | Layer | | Layer |
|Protocols | |Protocols| |Protocols| |Protocols|
| . | | . | | . | | . |
| . | | . | | . | | . |
+----------+ +---------+ +---------+ +---------+
|| || || ||
||================ || ... ||
|| || ||
||============================== ||
|| ||
================================================
Figure 4: An OPES flow with Callout servers
---------------------------------------------------------------------
In Figure 4, a data dispatcher invokes the services of a callout
server by using the OPES callout protocol (OCP). The requirements
for the OCP are given in [7]. The OCP is application-agnostic, being
unaware of the semantics of the encapsulated application protocol
(e.g., HTTP). However, the OCP must incorporate a service aware
vectoring capability that parses the data flow according to the
ruleset and delivers the data to the OPES service application that
can be local or remote.
In this model, OPES applications may be executed either on the same In this model, OPES applications may be executed either on the same
processor (or even in the same application environment) with the processor (or even in the same application environment) with the
dispatcher or on a different OPES processor through OCP. The general dispatcher or on a different OPES processor through OCP. The general
interaction situation is depicted in Figure 5, which illustrates the interaction situation is depicted in Figure 3, which illustrates the
positions and interaction of different components of OPES positions and interaction of different components of OPES
architecture. architecture.
--------------------------------------------------------------------- ---------------------------------------------------------------------
+--------------------------+ +--------------------------+
| +----------+ | | +----------+ |
| | OPES | | | | OPES | |
| | service | | +----------------+ | | service | | +---------------+ +-----------+
| | appl | | | Callout Server | | | appl | | |Callout Server | | Callout |
| +----------+ | | | | +----------+ | | A | | Server |
| || | | +--------+ | | || | | +--------+ | | X |
| +----------------------+ | | | OPES | | | +----------------------+ | | | OPES | | | |
| | data dispatcher | | | | Service| | | | data dispatcher | | | | Service| | | +--------+|
| +----------------------+ | | | App2 | | | +----------------------+ | | | App2 | | | | OPES ||
| | HTTP | OCP | | | +--------+ | | || | | +--------+ | | |Service ||
| +------------| |==========| OCP | | | +-------+ | | || | | | AppX ||
| | |---------+ | | +--------+ | | +---------+ | | | | +--------+ | ... | +--------||
| | TCP/IP | | +----------------+ | | HTTP | | OCP |=========| | OCP | | | || |
=========| |=============== OPES Data Flow ==== | +---------| +-------+ | | +--------+ | | +------+ |
| +------------+ | | +---------+ || | +---------------+ | | OCP | |
| | | =======================================| | |
| | | | | +------+ |
| | TCP/IP | | | |
=====| | |============== OPES ====== | |
| +---------+ | Data Flow +-----------+
+--------------------------+ +--------------------------+
Figure 5: Interaction of OPES Entities Figure 3: Interaction of OPES Entities
--------------------------------------------------------------------- ---------------------------------------------------------------------
2.5 Tracing Facility 2.5 Tracing Facility
The OPES architecture requires that each data dispatcher to provide The OPES architecture requires that each data dispatcher to provide
tracing facilities that allow the appropriate verification of its tracing facilities that allow the appropriate verification of its
operation. The OPES architecture requires that tracing be feasible operation. The OPES architecture requires that tracing be feasible
on the OPES flow per OPES processor using in-band annotation. One on the OPES flow per OPES processor using in-band annotation. One
of those annotations could be a URL with more detailed information on of those annotations could be a URI with more detailed information on
the transformation that occurred to the data on the OPES flow. the transformation that occurred to the data on the OPES flow.
Providing the ability for in-band annotation MAY require header Providing the ability for in-band annotation MAY require header
extensions on the application protocol that is used (e.g., HTTP). extensions on the application protocol that is used (e.g., HTTP).
However, the presence of an OPES processor in the data request/ However, the presence of an OPES processor in the data request/
response flow SHALL NOT interfere with the operations of non-OPES response flow SHALL NOT interfere with the operations of non-OPES
aware clients and servers. OPES processors, content server and aware clients and servers. The support of these extensions to the
content consumer MAY use OPES extensions to the base protocol (HTTP), base protocol HTTP is not required by non-OPES clients and servers.
but support of these extensions SHALL NOT be required.
OPES processors must obey tracing, reporting and notification OPES processors must obey tracing, reporting and notification
requirements set by the center of authority in the trust domain to requirements set by the center of authority in the trust domain to
which OPES processor belongs. As part of these requirements OPES which OPES processor belongs. As part of these requirements OPES
processor may be instructed to reject or ignore such requirements processor may be instructed to reject or ignore such requirements
that originate from other trust domains. that originate from other trust domains.
3. Security and Privacy Considerations 3. Security and Privacy Considerations
Each data flow must be secured in accordance with several policies. Each data flow must be secured in accordance with several policies.
The primary stakeholders are the data consumer and the data provider. The primary stakeholders are the data consumer and the data provider.
The secondary stakeholders are the entities to which they may have The secondary stakeholders are the entities to which they may have
delegated their trust. The other stakeholders are the owners of the delegated their trust. The other stakeholders are the owners of the
callout servers. Any of these parties may be participants in the callout servers. Any of these parties may be participants in the
OPES architecture. OPES flow.
These parties must have a model, explicit or implicit, describing These parties must have a model, explicit or implicit, describing
their trust policy; which of the other parties are trusted to operate their trust policy; which of the other parties are trusted to operate
on data, and what security enhancements are required for on data, and what security enhancements are required for
communication. The trust might be delegated for all data, or it communication. The trust might be delegated for all data, or it
might be restricted to granularity as small as an application data might be restricted to granularity as small as an application data
unit. unit.
All parties that are involved in enforcing policies must communicate All parties that are involved in enforcing policies must communicate
the policies to the parties that are involved. These parties are the policies to the parties that are involved. These parties are
skipping to change at page 13, line 14 skipping to change at page 11, line 14
privilege to it. privilege to it.
3.2 Callout protocol 3.2 Callout protocol
The determination of whether or not OPES processors will use the The determination of whether or not OPES processors will use the
measures that are described in the previous section during their measures that are described in the previous section during their
communication with callout servers depends on the details of how the communication with callout servers depends on the details of how the
primary parties delegated trust to the OPES processors and the trust primary parties delegated trust to the OPES processors and the trust
relationship between the OPES processors and the callout server. If relationship between the OPES processors and the callout server. If
the OPES processors are in a single administrative domain with strong the OPES processors are in a single administrative domain with strong
confidentiality guarantees, then encryption may be optional. In confidentiality guarantees, then encryption may be optional.
other cases, encryption and strong authentication would be at least However, it is recommended that for all cases that encryption and
strongly recommended. strong authentication be used.
If the delegation mechanism names the trusted parties and their If the delegation mechanism names the trusted parties and their
privileges in some way that permits authentication, then the OPES privileges in some way that permits authentication, then the OPES
processors will be responsible for enforcing the policy and for using processors will be responsible for enforcing the policy and for using
authentication as part of that enforcement. authentication as part of that enforcement.
The callout servers must be aware of the policy governing the The callout servers must be aware of the policy governing the
communication path. They must not, for example, communicate communication path. They must not, for example, communicate
confidential information to auxiliary servers outside the trust confidential information to auxiliary servers outside the trust
domain. domain.
skipping to change at page 15, line 17 skipping to change at page 13, line 17
Although the architecture supports a wide range of cooperative Although the architecture supports a wide range of cooperative
transformation services, it has few requirements for transformation services, it has few requirements for
interoperability. interoperability.
The necessary and sufficient elements are specified in the following The necessary and sufficient elements are specified in the following
documents: documents:
o the OPES ruleset schema [6] which defines the syntax and semantics o the OPES ruleset schema [6] which defines the syntax and semantics
of the rules interpreted by a data dispatcher; and, of the rules interpreted by a data dispatcher; and,
o the OPES callout protocol (OCP) [7] which defines the protocol o the OPES callout protocol (OCP) [7] which defines the requirements
between a data dispatcher and a callout server. for the protocol between a data dispatcher and a callout server.
References References
[1] McHenry, S., et. al, "OPES Scenarios and Use Cases", Internet- [1] McHenry, S., et. al, "OPES Scenarios and Use Cases", Internet-
Draft TBD, May 2002. Draft TBD, May 2002.
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238, Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002. January 2002.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/