draft-ietf-teas-pce-central-control-02.txt   draft-ietf-teas-pce-central-control-03.txt 
TEAS Working Group A. Farrel, Ed. TEAS Working Group A. Farrel, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational Q. Zhao, Ed. Intended status: Informational Q. Zhao, Ed.
Expires: November 15, 2017 R. Li Expires: December 17, 2017 R. Li
Huawei Technologies Huawei Technologies
C. Zhou C. Zhou
Cisco Systems Cisco Systems
May 14, 2017 June 15, 2017
An Architecture for Use of PCE and PCEP in a Network with Central An Architecture for Use of PCE and PCEP in a Network with Central
Control Control
draft-ietf-teas-pce-central-control-02 draft-ietf-teas-pce-central-control-03
Abstract Abstract
The Path Computation Element (PCE) has become established as a core The Path Computation Element (PCE) has become established as a core
component of Software Defined Networking (SDN) systems. It can component of Software Defined Networking (SDN) systems. It can
compute optimal paths for traffic across a network for any definition compute optimal paths for traffic across a network for any definition
of "optimal" and can also monitor changes in resource availability of "optimal" and can also monitor changes in resource availability
and traffic demands to update the paths. and traffic demands to update the paths.
Conventionally, the PCE has been used to derive paths for MPLS Label Conventionally, the PCE has been used to derive paths for MPLS Label
skipping to change at page 1, line 40 skipping to change at page 1, line 40
engineered networks, and the PCE may be used to determine paths in a engineered networks, and the PCE may be used to determine paths in a
wide range of use cases including static LSPs, segment routing, wide range of use cases including static LSPs, segment routing,
service function chaining (SFC), and indeed any form of routed or service function chaining (SFC), and indeed any form of routed or
switched network. It is, therefore, reasonable to consider PCEP as a switched network. It is, therefore, reasonable to consider PCEP as a
general southbound control protocol for use in these environments to general southbound control protocol for use in these environments to
allow the PCE to be fully enabled as a central controller. allow the PCE to be fully enabled as a central controller.
This document briefly introduces the architecture for PCE as a This document briefly introduces the architecture for PCE as a
central controller, examines the motivations and applicability for central controller, examines the motivations and applicability for
PCEP as a southbound interface, and introduces the implications for PCEP as a southbound interface, and introduces the implications for
the protocol. This document does not describe the use cases in the protocol. A PCE-based central controller can simplify the
detail and does not define protocol extensions: that work is left for processing of distributed control plane by blending it with elements
other documents. of SDN and without necessarily completely replacing it.
This document does not describe use cases in detail and does not
define protocol extensions: that work is left for other documents.
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 November 15, 2017. This Internet-Draft will expire on December 17, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 39 skipping to change at page 2, line 44
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Resilience and Scaling . . . . . . . . . . . . . . . . . 7 2.1. Resilience and Scaling . . . . . . . . . . . . . . . . . 7
2.1.1. Partitioned Network . . . . . . . . . . . . . . . . . 8 2.1.1. Partitioned Network . . . . . . . . . . . . . . . . . 8
2.1.2. Multiple Parallel Controllers . . . . . . . . . . . . 9 2.1.2. Multiple Parallel Controllers . . . . . . . . . . . . 9
2.1.3. Hierarchical Controllers . . . . . . . . . . . . . . 10 2.1.3. Hierarchical Controllers . . . . . . . . . . . . . . 12
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Technology-Oriented Applicability . . . . . . . . . . . . 12 3.1. Technology-Oriented Applicability . . . . . . . . . . . . 14
3.1.1. Applicability to Control Plane Operated Networks . . 12 3.1.1. Applicability to Control Plane Operated Networks . . 14
3.1.2. Static LSPs in MPLS . . . . . . . . . . . . . . . . . 12 3.1.2. Static LSPs in MPLS . . . . . . . . . . . . . . . . . 14
3.1.3. MPLS Multicast . . . . . . . . . . . . . . . . . . . 13 3.1.3. MPLS Multicast . . . . . . . . . . . . . . . . . . . 15
3.1.4. Transport SDN . . . . . . . . . . . . . . . . . . . . 13 3.1.4. Transport SDN . . . . . . . . . . . . . . . . . . . . 15
3.1.5. Segment Routing . . . . . . . . . . . . . . . . . . . 13 3.1.5. Segment Routing . . . . . . . . . . . . . . . . . . . 15
3.1.6. Service Function Chaining . . . . . . . . . . . . . . 14 3.1.6. Service Function Chaining . . . . . . . . . . . . . . 16
3.2. High-Level Applicability . . . . . . . . . . . . . . . . 14
3.2.1. Traffic Engineering . . . . . . . . . . . . . . . . . 14 3.2. High-Level Applicability . . . . . . . . . . . . . . . . 16
3.2.2. Traffic Classification . . . . . . . . . . . . . . . 15 3.2.1. Traffic Engineering . . . . . . . . . . . . . . . . . 16
3.2.3. Service Delivery . . . . . . . . . . . . . . . . . . 15 3.2.2. Traffic Classification . . . . . . . . . . . . . . . 17
4. Protocol Implications / Guidance for Solution Developers . . 16 3.2.3. Service Delivery . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4. Protocol Implications / Guidance for Solution Developers . . 18
6. Manageability Considerations . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Manageability Considerations . . . . . . . . . . . . . . . . 19
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The Path Computation Element (PCE) [RFC4655] was developed to offload The Path Computation Element (PCE) [RFC4655] was developed to offload
path computation function from routers in an MPLS traffic engineered path computation function from routers in an MPLS traffic engineered
network. Since then, the role and function of the PCE has grown to network. Since then, the role and function of the PCE has grown to
cover a number of other uses (such as GMPLS [RFC7025]) and to allow cover a number of other uses (such as GMPLS [RFC7025]) and to allow
delegated control [I-D.ietf-pce-stateful-pce] and PCE-initiated use delegated control [I-D.ietf-pce-stateful-pce] and PCE-initiated use
of network resources [I-D.ietf-pce-pce-initiated-lsp]. of network resources [I-D.ietf-pce-pce-initiated-lsp].
skipping to change at page 4, line 11 skipping to change at page 4, line 18
static LSPs, segment routing [I-D.ietf-spring-segment-routing], static LSPs, segment routing [I-D.ietf-spring-segment-routing],
service function chaining (SFC) [RFC7665], and indeed any form of service function chaining (SFC) [RFC7665], and indeed any form of
routed or switched network. It is, therefore, reasonable to consider routed or switched network. It is, therefore, reasonable to consider
PCEP as a general southbound control protocol for use in these PCEP as a general southbound control protocol for use in these
environments to allow the PCE to be fully enabled as a central environments to allow the PCE to be fully enabled as a central
controller. controller.
This document introduces the architecture for PCE as a central This document introduces the architecture for PCE as a central
controller, examines the motivations and applicability for PCEP as a controller, examines the motivations and applicability for PCEP as a
southbound interface, and introduces the implications for the southbound interface, and introduces the implications for the
protocol. This document does not describe the use cases in detail protocol. A PCE-based central controller can simplify the processing
and does not define protocol extensions: that work is left for other of distributed control plane by blending it with elements of SDN and
documents. without necessarily completely replacing it.
This document does not describe use cases in detail and does not
define protocol extensions: that work is left for other documents.
2. Architecture 2. Architecture
The architecture for the use of PCE within centralized control of a The architecture for the use of PCE within centralized control of a
network is based on the understanding that a PCE can determine how network is based on the understanding that a PCE can determine how
connections should be placed and how resources should be used within connections should be placed and how resources should be used within
the network, and that the PCE can then cause those connections to be the network, and that the PCE can then cause those connections to be
established. Figure 1 shows how this control relationship works in a established. Figure 1 shows how this control relationship works in a
network with an active control plane. This is a familiar view for network with an active control plane. This is a familiar view for
those who have read and understood [RFC4655] and those who have read and understood [RFC4655] and
skipping to change at page 9, line 32 skipping to change at page 9, line 32
| NE | | NE | | NE | :: | NE | | NE | | NE | | NE | | NE | | NE | :: | NE | | NE | | NE |
---- ---- ---- :: ---- ---- ---- ---- ---- ---- :: ---- ---- ----
:: ::
Domain 1 :: Domain 2 Domain 1 :: Domain 2
:: ::
Figure 4: Multiple Controllers on a Partitioned Network Figure 4: Multiple Controllers on a Partitioned Network
2.1.2. Multiple Parallel Controllers 2.1.2. Multiple Parallel Controllers
Multiple controllers may be deployed where each controller is capable
of controlling all of the network elements. Thus the failure of any
one controller will not leave the network unmanageable and, in normal
circumstances, the load can be distributed across the controllers.
Multiple parallel controllers may be deployed as shown in Figure 5. Multiple parallel controllers may be deployed as shown in Figure 5.
Each controller is capable of controlling all of the network elements Each controller is capable of controlling all of the network elements
thus the failure of any one controller will not leave the network thus the failure of any one controller will not leave the network
unmanageable and, in normal circumstances, the load can be unmanageable and, in normal circumstances, the load can be
distributed across the controllers. distributed across the controllers. In this model, the orchestrator
(or any requester) must select a controller to consume its request.
To achieve full redundancy and to be able to continue to provide full
function in the event of the failure a controller, the controllers
must synchronize with each other. This is nominally a simple task if
there are just two controllers, but can actually be quite complex if
state changes in the network are not to be lost. Furthermore, if
there are more than two controllers, the synchronization between
controllers can become a hard problem.
Synchronization issues are often off-loaded as "database
synchronization" problems because distributed database packages have
already had to address these challenges. In networking the problem
may also be addressed by collecting the state from the network
(effectively using the network as a database) using normal routing
protocols such as OSPF, IS-IS, and BGP.
-------------------------------------------- --------------------------------------------
| Orchestrator / Service Manager / OSS / NMS | | Orchestrator / Service Manager / OSS / NMS |
-------------------------------------------- --------------------------------------------
^ ^ ^ ^
| ___________________ | | ___________________ |
| | Synchronization | | | | Synchronization | |
v v v v v v v v
------------ ------------ ------------ ------------
| | ----- | | | | ----- | |
skipping to change at page 10, line 30 skipping to change at page 10, line 30
| |__:___ \___:_ \_:___ : | |__:___ \___:_ \_:___ :
| ....: | .....: | ..: | : | ....: | .....: | ..: | :
| : | : | : | : | : | : | : | :
v v v v v v v v v v v v v v v v
---- ---- ---- ---- ---- ---- ---- ----
| NE | | NE | | NE | | NE | | NE | | NE | | NE | | NE |
---- ---- ---- ---- ---- ---- ---- ----
Figure 5: Multiple Redundant Controllers Figure 5: Multiple Redundant Controllers
An alternate approach is to present the controllers as a "cluster"
that represents itself externally as a single controller as in
Figure 3 but which is actually comprised of multiple controllers.
The size of the cluster may be varied according to load in the manner
of network functions virtualization (NFV) and the cluster is
responsible for sharing load among the members of the cluster. This
approach is shown in Figure 6.
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
--------------------------+-------------------------
| Controller ______________|_____________ |
| Cluster | | |
| | ___________________ | |
| | | Synchronization | | |
| v v v v |
| ------------ ----- ------------ |
| | PCE-based |<---| TED |--->| PCE-based | |
| | Controller | ----- | Controller | |
| | Instance | | Instance | |
| ------------ ------------ |
| ^ ^ |
| |____________________________| |
| | |
--------------------------+-------------------------
_____________|_____________
| | | |
v v v v
---- ---- ---- ----
| NE | | NE | | NE | | NE |
---- ---- ---- ----
Figure 6: Multiple Controllers Presented as a Cluster
To achieve full redundancy and to be able to continue to provide full
function in the event of the failure a controller, the controllers
must synchronize with each other. This is nominally a simple task if
there are just two controllers, but can actually be quite complex if
state changes in the network are not to be lost. Furthermore, if
there are more than two controllers, the synchronization between
controllers can become a hard problem.
Synchronization issues are often off-loaded as "database
synchronization" problems because distributed database packages have
already had to address these challenges, or by using a shared
database. In networking the problem may also be addressed by
collecting the state from the network (effectively using the network
as a database) using normal routing protocols such as OSPF, IS-IS,
and BGP.
2.1.3. Hierarchical Controllers 2.1.3. Hierarchical Controllers
Figure 6 shows an approach with hierarchical controllers. This Figure 7 shows an approach with hierarchical controllers. This
approach was developed for PCEs in [RFC6805] and appears in various approach was developed for PCEs in [RFC6805] and appears in various
SDN architectures where a "parent PCE", an "orchestrator", or "super SDN architectures where a "parent PCE", an "orchestrator", or "super
controller" takes responsibility for a high-level view of the network controller" takes responsibility for a high-level view of the network
before distributing tasks to lower level PCEs or controllers. before distributing tasks to lower level PCEs or controllers.
On its own, this approach does little to protect against the failure On its own, this approach does little to protect against the failure
of a controller, but it can make significant improvements in loading of a controller, but it can make significant improvements in loading
and scaling of the individual controllers. It also offers a good way and scaling of the individual controllers. It also offers a good way
to support end-to-end connectivity across multiple administrative or to support end-to-end connectivity across multiple administrative or
technology-specific domains. technology-specific domains.
skipping to change at page 11, line 38 skipping to change at page 13, line 38
/ | | :: | | \ / | | :: | | \
| | | :: | | | | | | :: | | |
v v v :: v v v v v v :: v v v
---- ---- ---- :: ---- ---- ---- ---- ---- ---- :: ---- ---- ----
| NE | | NE | | NE | :: | NE | | NE | | NE | | NE | | NE | | NE | :: | NE | | NE | | NE |
---- ---- ---- :: ---- ---- ---- ---- ---- ---- :: ---- ---- ----
:: ::
Domain 1 :: Domain 2 Domain 1 :: Domain 2
:: ::
Figure 6: Hierarchical Controllers Figure 7: Hierarchical Controllers
3. Applicability 3. Applicability
This section gives a very high-level introduction to the This section gives a very high-level introduction to the
applicability of a PCE-based centralized controller. There is no applicability of a PCE-based centralized controller. There is no
attempt to explain each use case in detail, and the inclusion of a attempt to explain each use case in detail, and the inclusion of a
use case is not intended to suggest that deploying a PCE-based use case is not intended to suggest that deploying a PCE-based
controller is a mandatory or recommended approach. The sections controller is a mandatory or recommended approach. The sections
below are provided as a stimulus to discussion of the applicability below are provided as a stimulus to discussion of the applicability
of a PCE-based controller and it is expected that separate documents of a PCE-based controller and it is expected that separate documents
skipping to change at page 12, line 37 skipping to change at page 14, line 37
determines what LSPs are needed and where to place them. PCEP is determines what LSPs are needed and where to place them. PCEP is
used to instruct the head end of each LSP, and the head end signals used to instruct the head end of each LSP, and the head end signals
in the control plane to set up the LSP. in the control plane to set up the LSP.
3.1.2. Static LSPs in MPLS 3.1.2. Static LSPs in MPLS
Static LSPs are provisioned without the use of a control plane. This Static LSPs are provisioned without the use of a control plane. This
means that they are established using management plane or "manual" means that they are established using management plane or "manual"
configuration. configuration.
Static LSPs can be provisioned as 1-hop, micro-LSPs at each node Static LSPs can be provisioned as explicit label instructions at each
along the path of an end-to-end path LSP. Each router along the path hop on the end-to-end path LSP. Each router along the path must be
must be told what label forwarding instructions to program and what told what label forwarding instructions to program and what resources
resources to reserve. The PCE-based controller keeps a view of the to reserve. The PCE-based controller keeps a view of the network and
network and determines the paths of the end-to-end LSPs just as it determines the paths of the end-to-end LSPs just as it does for the
does for the use case described in Section 3.1.1, but the controller use case described in Section 3.1.1, but the controller uses PCEP to
uses PCEP to communicate with each router along the path of the end- communicate with each router along the path of the end-to-end LSP.
to-end LSP. In this case the PCE-based controller will take In this case the PCE-based controller will take responsibility for
responsibility for managing some part of the MPLS label space for managing some part of the MPLS label space for each of the routers
each of the routers that it controls, and may taker wider that it controls, and may taker wider responsibility for partitioning
responsibility for partitioning the label space for each router and the label space for each router and allocating different parts for
allocating different parts for different uses communicating the different uses communicating the ranges to the router using PCEP.
ranges to the router using PCEP.
3.1.3. MPLS Multicast 3.1.3. MPLS Multicast
Multicast LSPs may be provisioned with a control plane or as static Multicast LSPs may be provisioned with a control plane or as static
LSPs. No extra considerations apply above those in Section 3.1.1 and LSPs. No extra considerations apply above those in Section 3.1.1 and
Section 3.1.2 except, of course, to note that the PCE must also Section 3.1.2 except, of course, to note that the PCE must also
include the instructions about where the LSP branches, i.e., where include the instructions about where the LSP branches, i.e., where
packets must be copied. packets must be copied.
3.1.4. Transport SDN 3.1.4. Transport SDN
skipping to change at page 18, line 42 skipping to change at page 20, line 42
involved for opening the discussion. The individuals concerned are: involved for opening the discussion. The individuals concerned are:
King Ke, Luyuan Fang, Chao Zhou, Boris Zhang, Zhenbin Li. King Ke, Luyuan Fang, Chao Zhou, Boris Zhang, Zhenbin Li.
This document has benefited from the discussions within a small ad This document has benefited from the discussions within a small ad
hoc design team the members of which are listed as document hoc design team the members of which are listed as document
contributors. contributors.
Thanks to Michael Scharf and Andy Malis for a lively discussion of Thanks to Michael Scharf and Andy Malis for a lively discussion of
this document. this document.
Thanks to Phil Bedard and Aijun Wang for last call comments on this
document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>. <http://www.rfc-editor.org/info/rfc4655>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-pce-pce-initiated-lsp] [I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-09 (work in Model", draft-ietf-pce-pce-initiated-lsp-09 (work in
progress), March 2017. progress), March 2017.
[I-D.ietf-pce-pceps] [I-D.ietf-pce-pceps]
Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure
Transport for PCEP", draft-ietf-pce-pceps-12 (work in Transport for PCEP", draft-ietf-pce-pceps-14 (work in
progress), April 2017. progress), May 2017.
[I-D.ietf-pce-stateful-pce] [I-D.ietf-pce-stateful-pce]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful- Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-18 (work in progress), December 2016. pce-19 (work in progress), May 2017.
[I-D.ietf-pce-wson-rwa-ext] [I-D.ietf-pce-wson-rwa-ext]
Lee, Y. and R. Casellas, "PCEP Extension for WSON Routing Lee, Y. and R. Casellas, "PCEP Extension for WSON Routing
and Wavelength Assignment", draft-ietf-pce-wson-rwa-ext-06 and Wavelength Assignment", draft-ietf-pce-wson-rwa-ext-06
(work in progress), December 2016. (work in progress), December 2016.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and R. Shakir, "Segment Routing Architecture", draft-ietf- and R. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-11 (work in progress), February spring-segment-routing-11 (work in progress), February
 End of changes. 16 change blocks. 
67 lines changed or deleted 120 lines changed or added

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