draft-ietf-mpls-tp-cc-cv-rdi-04.txt   draft-ietf-mpls-tp-cc-cv-rdi-05.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Expires: December 2011 George Swallow Ed. Expires: December 2011 George Swallow Ed.
Cisco Systems, Inc Cisco Systems, Inc
John Drake Ed. John Drake Ed.
Juniper Juniper
June 2011 June 2011
Proactive Connectivity Verification, Continuity Check and Remote Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile Defect indication for MPLS Transport Profile
draft-ietf-mpls-tp-cc-cv-rdi-04 draft-ietf-mpls-tp-cc-cv-rdi-05
Abstract Abstract
Continuity Check, Proactive Connectivity Verification and Remote Continuity Check, Proactive Connectivity Verification and Remote
Defect Indication functionalities are required for MPLS-TP OAM. Defect Indication functionalities are required for MPLS-TP OAM.
Continuity Check monitors the integrity of the continuity of the Continuity Check monitors the integrity of the continuity of the
label switched path for any loss of continuity defect. Connectivity label switched path for any loss of continuity defect. Connectivity
verification monitors the integrity of the routing of the label verification monitors the integrity of the routing of the label
switched path between sink and source for any connectivity issues. switched path between sink and source for any connectivity issues.
skipping to change at page 2, line 39 skipping to change at page 2, line 39
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 carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License. without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Authors......................................................4
2. Conventions used in this document..............................4 2. Conventions used in this document..............................4
2.1. Terminology..................................................4 2.1. Terminology..................................................4
3. MPLS CC, proactive CV and RDI Mechanism using BFD..............5 3. MPLS CC, proactive CV and RDI Mechanism using BFD..............5
3.1. Existing Capabilities........................................5 3.1. Existing Capabilities........................................5
3.2. CC, CV, and RDI Overview.....................................5 3.2. CC, CV, and RDI Overview.....................................5
3.3. ACH code points for CC and proactive CV......................6 3.3. ACH code points for CC and proactive CV......................6
3.4. MPLS BFD CC Message format...................................7 3.4. MPLS BFD CC Message format...................................7
3.5. MPLS BFD proactive CV Message format.........................7 3.5. MPLS BFD proactive CV Message format.........................7
3.5.1. ICC-based MEP-ID...........................................9 3.5.1. Section MEP-ID.............................................9
3.5.2. Section MEP-ID.............................................9 3.5.2. LSP MEP-ID.................................................9
3.5.3. LSP MEP-ID.................................................9 3.5.3. PW Endpoint MEP-ID........................................10
3.5.4. PW Endpoint MEP-ID........................................10
3.6. BFD Session in MPLS-TP terminology..........................11 3.6. BFD Session in MPLS-TP terminology..........................11
3.7. BFD Profile for MPLS-TP.....................................11 3.7. BFD Profile for MPLS-TP.....................................11
3.7.1. Session initiation and Modification.......................13 3.7.1. Session initiation and Modification.......................13
3.7.2. Defect entry criteria.....................................13 3.7.2. Defect entry criteria.....................................13
3.7.3. Defect entry consequent action............................14 3.7.3. Defect entry consequent action............................14
3.7.4. Defect exit criteria......................................15 3.7.4. Defect exit criteria......................................15
3.7.5. State machines............................................15 3.7.5. State machines............................................15
3.7.6. Configuration of MPLS-TP BFD sessions.....................18 3.7.6. Configuration of MPLS-TP BFD sessions.....................18
3.7.7. Discriminator values......................................18 3.7.7. Discriminator values......................................18
4. Configuration Considerations..................................18 4. Configuration Considerations..................................18
5. Acknowledgments...............................................19 5. Acknowledgments...............................................19
6. IANA Considerations...........................................19 6. IANA Considerations...........................................19
7. Security Considerations.......................................19 7. Security Considerations.......................................20
8. References....................................................20 8. References....................................................20
8.1. Normative References........................................20 8.1. Normative References........................................20
8.2. Informative References......................................20 8.2. Informative References......................................21
1. Introduction 1. Introduction
In traditional transport networks, circuits are provisioned on two or In traditional transport networks, circuits are provisioned on two or
more switches. Service Providers (SP) need OAM tools to detect mis- more switches. Service Providers (SP) need OAM tools to detect mis-
connectivity and loss of continuity of transport circuits. Both connectivity and loss of continuity of transport circuits. Both
pseudo wires (PWs) and MPLS-TP label switched paths (LSPs) [10] pseudo wires (PWs) and MPLS-TP label switched paths (LSPs) [12][12]
emulating traditional transport circuits need to provide the same emulating traditional transport circuits need to provide the same
continuity check (CC) proactive continuity verification (CV) and continuity check (CC) proactive continuity verification (CV) and
remote defect indication (RDI) capabilities as required in RFC remote defect indication (RDI) capabilities as required in RFC
5860[3]. This document describes the use of BFD for CC, proactive CV, 5860[3]. This document describes the use of Bidirectional Forwarding
and RDI of a PW, LSP or sub path maintenance entity (SPME) between Detection (BFD)[4] for CC, proactive CV, and RDI of a PW, LSP or sub-
two Maintenance Entity Group End Points (MEPs). path maintenance entity (SPME) between two Maintenance Entity Group
End Points (MEPs).
As described in [11], CC and CV functions are used to detect loss of As described in [13][13], CC and CV functions are used to detect loss
continuity (LOC), and unintended connectivity between two MEPs (e.g. of continuity (LOC), and unintended connectivity between two MEPs
mis-merging or mis-connectivity or unexpected MEP). (e.g. mis-merging or mis-connectivity or unexpected MEP).
RDI is an indicator that is transmitted by a MEP to communicate to RDI is an indicator that is transmitted by a MEP to communicate to
its peer MEP that a signal fail condition exists. RDI is only used its peer MEP that a signal fail condition exists. RDI is only used
for bidirectional LSPs and is associated with proactive CC & CV BFD for bidirectional LSPs and is associated with proactive CC & CV BFD
control packet generation. control packet generation.
This document specifies the BFD extension and behavior to satisfy the This document specifies the BFD extension and behavior to satisfy the
CC, proactive CV monitoring and the RDI functional requirements for CC, proactive CV monitoring and the RDI functional requirements for
both co-routed and associated bi-directional LSPs. Supported both co-routed and associated bi-directional LSPs. Supported
encapsulations include generic alert label (GAL)/G-ACh, virtual encapsulations include generic alert label (GAL)/generic associated
circuit connectivity verification (VCCV) and UDP/IP. Procedures for channel (G-ACh), virtual circuit connectivity verification (VCCV) and
uni-directional p2p and p2mp LSPs are for further study. UDP/IP. Procedures for uni-directional point-to-point (p2p) and
point-to-multipoint (p2mp) LSPs are for further study.
This document utilizes identifiers for MPLS-TP systems as defined in
[9]. Work is on-going in the ITU-T to define a globally-unique
semantic for ITU Carrier Codes (ICCs), and future work may extend
this document to utilize ICCs as identifiers for MPLS-TP systems.
The mechanisms specified in this document are restricted to BFD The mechanisms specified in this document are restricted to BFD
asynchronous mode. asynchronous mode.
1.1. Authors
David Allan, John Drake, George Swallow, Annamaria Fulignoli, Sami
Boutros, Siva Sivabalan, David Ward, Martin Vigoureux and Robert
Rennison.
2. Conventions used in this document 2. Conventions used in this document
2.1. Terminology 2.1. Terminology
ACH: Associated Channel Header ACH: Associated Channel Header
BFD: Bidirectional Forwarding Detection BFD: Bidirectional Forwarding Detection
CV: Connectivity Verification CV: Connectivity Verification
GAL: Generalized Alert Label GAL: Generalized Alert Label
G-ACh: Generic Associated Channel G-ACh: Generic Associated Channel
LDI: Link Down Indication LDI: Link Down Indication
LKI: Lock Instruct LKI: Lock Instruct
LKR: Lock Report LKR: Lock Report
LSP: Label Switched Path
LSR: Label Switching Router LSR: Label Switching Router
ME: Maintenance Entity ME: Maintenance Entity
MEG: Maintenance Entity Group MEG: Maintenance Entity Group
MEP: Maintenance Entity Group End Point MEP: Maintenance Entity Group End Point
MIP: Maintenance Entity Group Intermediate Point MIP: Maintenance Entity Group Intermediate Point
MPLS-OAM: MPLS Operations, Administration and Maintenance MPLS-OAM: MPLS Operations, Administration and Maintenance
MPLS-TP: MPLS Transport Profile MPLS-TP: MPLS Transport Profile
MPLS-TP LSP: Uni-directional or Bidirectional Label Switch Path
representing a circuit
MPLS-TP LSP: Uni-directional or Bidirectional Label Switched Path
representing a circuit
MS-PW: Multi-Segment PseudoWire MS-PW: Multi-Segment PseudoWire
NMS: Network Management System NMS: Network Management System
PW: Pseudo Wire PW: Pseudo Wire
RDI: Remote Defect Indication RDI: Remote Defect Indication
SPME: Sub-Path Maintenance Entity SPME: Sub-Path Maintenance Entity
skipping to change at page 5, line 34 skipping to change at page 5, line 31
This document describes procedures for achieve combined CC, CV and This document describes procedures for achieve combined CC, CV and
RDI functionality within a single MPLS-TP MEG using BFD. This RDI functionality within a single MPLS-TP MEG using BFD. This
augments the capabilities that can be provided for MPLS-TP LSPs using augments the capabilities that can be provided for MPLS-TP LSPs using
existing specified tools and procedures. existing specified tools and procedures.
3.1. Existing Capabilities 3.1. Existing Capabilities
A CC-only mode may be provided via protocols and procedures described A CC-only mode may be provided via protocols and procedures described
in RFC 5885[7] with ACH channel 7. These procedures may be applied to in RFC 5885[7] with ACH channel 7. These procedures may be applied to
bi-directional LSPs as well as PWs. bi-directional LSPs (via the use of the GAL), as well as PWs.
Implementations MAY also interoperate with existing equipment by Implementations may also interoperate with legacy equipment by
implementing [2], or [8] in addition to the procedures documented in implementing RFC 5884[8] for LSPs and RFC 5085[10] for PWs, in
this memo. In accordance with RFC 5586[2], when BFD control packets addition to the procedures documented in this memo. In accordance
are encapsulated in an IP header, the fields in the IP header are set with RFC 5586[2], when BFD control packets are encapsulated in an IP
as defined in RFC 5884[8]. When IP encapsulation is used CV mis- header, the fields in the IP header are set as defined in RFC
connectivity defect detection can be performed by inferring a 5884[8]. When IP encapsulation is used CV mis-connectivity defect
globally unique source on the basis of the combination of the source detection can be performed by inferring a globally unique source on
IP address and "my discriminator" fields. the basis of the combination of the source IP address and "my
discriminator" fields.
3.2. CC, CV, and RDI Overview 3.2. CC, CV, and RDI Overview
The combined CC, CV, and RDI functionality for MPLS-TP is achieved by The combined CC, CV, and RDI functionality for MPLS-TP is achieved by
multiplexing CC and CV PDUs within a single BFD session. The CV PDUs multiplexing CC and CV PDUs within a single BFD session. The CV PDUs
are augmented with a source MEP ID TLV to permit mis-connectivity are augmented with a source MEP ID TLV to permit mis-connectivity
detection to be performed by sink MEPs. detection to be performed by sink MEPs.
The interleaving of PDUs is achieved via the use of distinct The interleaving of PDUs is achieved via the use of distinct
encapsulations and code points for generic associated channel (G-ACh) encapsulations and code points for generic associated channel (G-ACh)
skipping to change at page 6, line 20 skipping to change at page 6, line 20
Header (ACH) described in RFC 5586[2].This format supports Header (ACH) described in RFC 5586[2].This format supports
Continuity Check and RDI functionalities. Continuity Check and RDI functionalities.
o CV format: defines a new code point in the Associated Channel o CV format: defines a new code point in the Associated Channel
Header (ACH) described in RFC 5586[2]. The ACH with "MPLS Header (ACH) described in RFC 5586[2]. The ACH with "MPLS
Proactive CV" code point indicates that the message is an MPLS BFD Proactive CV" code point indicates that the message is an MPLS BFD
proactive CV message, and information for CV processing is proactive CV message, and information for CV processing is
appended in the form of the source MEP ID TLV. appended in the form of the source MEP ID TLV.
RDI is communicated via the BFD diagnostic field in BFD CC messages. RDI is communicated via the BFD diagnostic field in BFD CC messages.
It is not a distinct PDU. A sink MEP will encode a diagnostic code of It is not a distinct PDU. As per [4], a sink MEP SHOULD encode a
"1 - Control detection time expired" when the interval times detect diagnostic code of "1 - Control detection time expired" when the
multiplier have been exceeded, and with "5 - Path Down" as a interval times detect multiplier have been exceeded. A sink MEP
consequence of the sink MEP receiving AIS with LDI set. A sink MEP SHOULD encode a diagnostic code of "5 - Path Down" as a consequence
that has started sending diagnostic code 5 SHOULD NOT change it to 1 of the sink MEP receiving LDI. A sink MEP that has started sending
when the detection timer expires. diagnostic code 5 SHOULD NOT change it to 1 when the detection timer
expires.
3.3. ACH code points for CC and proactive CV 3.3. ACH code points for CC and proactive CV
Figure 1 illustrates the G-ACh encoding for BFD CC-CV-RDI
functionality.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Flags | BFD CC/CV Code Point | |0 0 0 1|Version| Flags | BFD CC/CV Code Point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH Indication of MPLS-TP Connectivity Verification Figure 1: ACH Indication of MPLS-TP Connectivity Verification
The first nibble (0001b) indicates the ACH. The first nibble (0001b) indicates the G-ACh as per RFC 5586[2].
The version and the flags are set to 0 as specified in [2]. The version and the flags are set to 0 as specified in [2].
The code point is either The code point is either
- BFD CC code point = 0xXX. [HH to be assigned by IANA from the PW - BFD CC code point = XX1. [XX1 to be assigned by IANA from the PW
Associated Channel Type registry.] or, Associated Channel Type registry.] or,
- BFD proactive CV code point = XX2. [XX2 to be assigned by IANA from
- BFD proactive CV code point = 0xXX+1. [HH to be assigned by IANA the PW Associated Channel Type registry.]
from the PW Associated Channel Type registry.]
CC and CV PDUs apply to all pertinent MPLS-TP structures, including CC and CV PDUs apply to all pertinent MPLS-TP structures, including
PWs, MPLS LSPs (including SPMEs), and Sections. PWs, MPLS LSPs (including SPMEs), and Sections.
CC and CV operation is simultaneously employed on a maintenance CC and CV operation is simultaneously employed on a maintenance
entity (ME) within a single BFD session. The expected usage is entity (ME) within a single BFD session. The expected usage is
that normal operation is to send CC BFD protocol data units that normal operation is to send CC BFD protocol data units
(PDUs) interleaved with a CV BFD PDU (augmented with a (PDUs) interleaved with a CV BFD PDU (augmented with a
source MEP-ID and identified as requiring additional source MEP-ID and identified as requiring additional
processing by the different ACh channel type). The processing by the different ACh channel type). The
skipping to change at page 7, line 23 skipping to change at page 7, line 28
for the CC code point) times the session periodicity. Mis- for the CC code point) times the session periodicity. Mis-
connectivity defects are detected in a maximum of one second. connectivity defects are detected in a maximum of one second.
3.4. MPLS BFD CC Message format 3.4. MPLS BFD CC Message format
The format of an MPLS CC Message is shown below. The format of an MPLS CC Message is shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Flags | 0xXX BFD CC Code point | |0 0 0 1|Version| Flags | BFD CC Code point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ BFD Control Packet ~ ~ BFD Control Packet ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS CC Message Figure 2: MPLS CC Message
As shown in figure 2, the MPLS CC message consists of the BFD control As shown in figure 2, the MPLS CC message consists of the BFD control
packet as defined in [4] pre-pended by the ACh. packet as defined in [4] pre-pended by the G-ACh.
3.5. MPLS BFD proactive CV Message format 3.5. MPLS BFD proactive CV Message format
The format of an MPLS CV Message is shown below. The format of an MPLS CV Message is shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Flags | 0xXX+1 BFD CV Code Point | |0 0 0 1|Version| Flags | BFD CV Code Point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ BFD Control Packet ~ ~ BFD Control Packet ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ MEP Source ID TLV ~ ~ MEP Source ID TLV ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 30 skipping to change at page 8, line 30
As shown in figure 3, the MPLS CV message consists of the BFD control As shown in figure 3, the MPLS CV message consists of the BFD control
packet as defined in [4] pre-pended by the ACH, and appended by a MEP packet as defined in [4] pre-pended by the ACH, and appended by a MEP
source ID TLV. source ID TLV.
A MEP Source ID TLV is encoded as a 2 octet field that specifies a A MEP Source ID TLV is encoded as a 2 octet field that specifies a
Type, followed by a 2 octet Length Field, followed by a variable Type, followed by a 2 octet Length Field, followed by a variable
length Value field. A BFD session will only use one encoding of the length Value field. A BFD session will only use one encoding of the
Source ID TLV. Source ID TLV.
The length in the BFD control packet is as per [4], the MEP Source ID The length in the BFD control packet is as per [4]; the length of the
TLV is not included. There are 3 possible Source MEP TLVs MEP Source ID TLV is not included. There are 3 possible Source MEP
(corresponding to the MEP-IDs defined in [9]) [type fields to be TLVs (corresponding to the MEP-IDs defined in [9]) [type fields to be
assigned by IANA]. The type fields are: assigned by IANA]. The type fields are:
X1 - Section MEP-ID X1 - Section MEP-ID
X2 - LSP MEP-ID X2 - LSP MEP-ID
X3 - PW MEP-ID X3 - PW MEP-ID
When GAL label is used, the time to live (TTL) field of the GAL MUST When GAL label is used, the time to live (TTL) field of the GAL MUST
be set to at least 1, and the GAL will be the end of stack label be set to at least 1, and the GAL MUST be the end of stack label
(S=1). (S=1) as per [2].
A node MUST NOT change the value in the MEP Source ID TLV. A node MUST NOT change the value in the MEP Source ID TLV.
When digest based authentication is used, the Source ID TLV MUST NOT When digest based authentication is used, the Source ID TLV MUST NOT
be included in the digest be included in the digest
3.5.1. ICC-based MEP-ID 3.5.1. Section MEP-ID
ICC based MEP-IDs are for further study.
3.5.2. Section MEP-ID
The IP compatible MEP-IDs for MPLS-TP sections is the interface ID. The IP compatible MEP-IDs for MPLS-TP sections is the interface ID.
The format of the Section MEP-ID TLV is: The format of the Section MEP-ID TLV is:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global_ID | | MPLS-TP Global_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier | | MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Interface Number | | MPLS-TP Interface Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the type is of value 'xx' (to be assigned by IANA). The length Figure 4: Section MEP-ID TLV format
Where the type is of value 'X1' (to be assigned by IANA). The length
is the length of the value fields. The MPLS-TP Global ID, Node is the length of the value fields. The MPLS-TP Global ID, Node
Identifier and Interface Numbers are as per [9]. Identifier and Interface Numbers are as per [9].
3.5.3. LSP MEP-ID 3.5.2. LSP MEP-ID
The format for the LSP MEP-ID is as defined in [9]. This consists of The fields for the LSP MEP-ID is as defined in [9]. This consists of
32-bit MPLS-TP Global ID, the 32-bit Node Identifier, followed by the 32-bit MPLS-TP Global ID, the 32-bit Node Identifier, followed by the
16-bit Tunnel_Num (that MUST be unique within the context of the Node 16-bit Tunnel_Num (that MUST be unique within the context of the Node
Identifier), and the 16-bit LSP_NUM (that MUST be unique with the Identifier), and the 16-bit LSP_NUM (that MUST be unique with the
context of the Tunnel Num). The format of the TLV is: context of the Tunnel Num). The format of the TLV is:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global_ID | | MPLS-TP Global_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier | | MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel_Num | LSP_Num | | Tunnel_Num | LSP_Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the type is of value 'xx+1' (to be assigned by IANA). The Figure 5: LSP MEP-ID TLV format
length is the length of the value fields. The MPLS-TP Global ID, Node
Where the type is of value 'X2' (to be assigned by IANA). The length
is the length of the value fields. The MPLS-TP Global ID, Node
Identifier, Tunnel Num and LSP_Num are as per [9]. Identifier, Tunnel Num and LSP_Num are as per [9].
3.5.4. PW Endpoint MEP-ID 3.5.3. PW Endpoint MEP-ID
The format the MPLS_TP PW Endpoint MEP-ID is as defined in [9]. The The fields for the MPLS_TP PW Endpoint MEP-ID is as defined in [9].
format of the TLV is: The format of the TLV is:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global_ID | | MPLS-TP Global_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier | | MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC_ID | | AC_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | AGI Length | AGI Value | | AGI Type | AGI Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~ ~ AGI Value (contd.) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the type is value 'xx+2' (to be assigned by IANA). The length Figure 6: PW Endpoint MEP-ID TLV format
is the length of the following data. The Global ID, Node Identifier Where the type is value 'X3' (to be assigned by IANA). The length is
and Attachment Circuit (AC)_ID are as per [9]. The Attachment Group the length of the following data. The Global ID, Node Identifier and
Attachment Circuit (AC)_ID are as per [9]. The Attachment Group
Identifier (AGI) Type is as per [6], and the AGI length is the length Identifier (AGI) Type is as per [6], and the AGI length is the length
of the AGI value field. of the AGI value field.
3.6. BFD Session in MPLS-TP terminology 3.6. BFD Session in MPLS-TP terminology
A BFD session corresponds to a CC and proactive CV OAM instance in A BFD session corresponds to a CC and proactive CV OAM instance in
MPLS-TP terminology. A BFD session is enabled when the CC and MPLS-TP terminology. A BFD session is enabled when the CC and
proactive CV functionality is enabled on a configured Maintenance proactive CV functionality is enabled on a configured Maintenance
Entity (ME). Entity (ME).
skipping to change at page 14, line 42 skipping to change at page 14, line 43
5. Receiving BFD control packets in all discernable ways correct. 5. Receiving BFD control packets in all discernable ways correct.
3.7.3. Defect entry consequent action 3.7.3. Defect entry consequent action
Upon defect entry a sink MEP will assert signal fail into any client Upon defect entry a sink MEP will assert signal fail into any client
(sub-)layers. It will also communicate session DOWN to its session (sub-)layers. It will also communicate session DOWN to its session
peer using CC messages. peer using CC messages.
The blocking of traffic as a consequent action MUST be driven only by The blocking of traffic as a consequent action MUST be driven only by
a defect's consequent action as specified in draft-ietf-mpls-tp-oam- a defect's consequent action as specified in [13] section 5.1.1.2.
framework [11] section 5.1.1.2.
When the defect is mis-connectivity, the LSP termination will When the defect is mis-connectivity, the LSP termination will
silently discard all non-OAM traffic received. The sink MEP will also silently discard all non-OAM traffic received. The sink MEP will also
send a defect indication back to the source MEP via the use of a send a defect indication back to the source MEP via the use of a
diagnostic code of mis-connectivity defect. diagnostic code of mis-connectivity defect to be assigned by IANA.
3.7.4. Defect exit criteria 3.7.4. Defect exit criteria
3.7.4.1. Exit from a Loss of continuity defect 3.7.4.1. Exit from a Loss of continuity defect
For a coordinated session, exit from a loss of connectivity defect is For a coordinated session, exit from a loss of connectivity defect is
as described in figure 4 which updates [4]. as described in figure 4 which updates [4].
For an independent session, exit from a loss of connectivity defect For an independent session, exit from a loss of connectivity defect
occurs upon receipt of a well formed BFD control packet from the peer occurs upon receipt of a well formed BFD control packet from the peer
skipping to change at page 15, line 27 skipping to change at page 15, line 30
3.7.4.2. Exit from a mis-connectivity defect 3.7.4.2. Exit from a mis-connectivity defect
Exit from a mis-connectivity defect state occurs when no CV messages Exit from a mis-connectivity defect state occurs when no CV messages
with mis-connectivity defects have been received for a period of 3.5 with mis-connectivity defects have been received for a period of 3.5
seconds. seconds.
3.7.5. State machines 3.7.5. State machines
The following state machines update [4]. They have been modified to The following state machines update [4]. They have been modified to
include AIS with LDI set and LKI as specified in [5] as inputs to the include LDI and LKI as specified in [5] as inputs to the state
state machine and to clarify the behavior for independent mode. LKR machine and to clarify the behavior for independent mode. LKR is an
is an optional input. optional input.
The coordinated session state machine has been augmented to indicate The coordinated session state machine has been augmented to indicate
AIS with LDI set and optionally LKR as inputs to the state machine. LDI and optionally LKR as inputs to the state machine. For a session
For a session that is in the UP state, receipt of AIS with LDI set or that is in the UP state, receipt of LDI or optionally LKR will
optionally LKR will transition the session into the DOWN state. transition the session into the DOWN state.
+--+ +--+
| | UP, ADMIN DOWN, TIMER, AIS-LDI, LKR | | UP, ADMIN DOWN, TIMER, LDI, LKR
| V | V
DOWN +------+ INIT DOWN +------+ INIT
+------------| |------------+ +------------| |------------+
| | DOWN | | | | DOWN | |
| +-------->| |<--------+ | | +-------->| |<--------+ |
| | +------+ | | | | +------+ | |
| | | | | | | |
| | ADMIN DOWN,| | | | ADMIN DOWN,| |
| |ADMIN DOWN, DOWN,| | | |ADMIN DOWN, DOWN,| |
| |TIMER TIMER,| | | |TIMER TIMER,| |
V |AIS-LDI,LKR AIS-LDI,LKR | V V |LDI,LKR LDI,LKR | V
+------+ +------+ +------+ +------+
+----| | | |----+ +----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+ +--->| | INIT, UP | |<---+
+------+ +------+ +------+ +------+
Figure 4: MPLS CC state machine for coordinated session operation Figure 7: MPLS CC state machine for coordinated session operation
For independent mode, there are two state machines. One for the For independent mode, there are two state machines. One for the
source MEP (who requested bfd.MinRxInterval=0) and the sink MEP (who source MEP (which requested bfd.MinRxInterval=0) and the sink MEP
agreed to bfd.MinRxInterval=0). (which agreed to bfd.MinRxInterval=0).
The source MEP will not transition out of the UP state once The source MEP will not transition out of the UP state once
initialized except in the case of a forced ADMIN DOWN. Hence AIS-with initialized except in the case of a forced ADMIN DOWN. Hence LDI and
LDI set and optionally LKR do not enter into the state machine optionally LKR do not enter into the state machine transition from
transition from the UP state, but do enter into the INIT and DOWN the UP state, but do enter into the INIT and DOWN states.
states.
+--+ +--+
| | UP, ADMIN DOWN, TIMER, AIS-LDI, LKR | | UP, ADMIN DOWN, TIMER, LDI, LKR
| V | V
DOWN +------+ INIT DOWN +------+ INIT
+------------| |------------+ +------------| |------------+
| | DOWN | | | | DOWN | |
| +-------->| |<--------+ | | +-------->| |<--------+ |
| | +------+ | | | | +------+ | |
| | | | | | | |
| |ADMIN DOWN ADMIN DOWN | | | |ADMIN DOWN ADMIN DOWN | |
| |TIMER, | | | |TIMER, | |
| |AIS-LDI, | | | |LDI, | |
V |LKR | V V |LKR | V
+------+ +------+ +------+ +------+
+----| | | |----+ +----| | | |----+
DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN, DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN,
+--->| | INIT, UP | |<---+ AIS-LDI, LKR +--->| | INIT, UP | |<---+ LDI, LKR
+------+ +------+ +------+ +------+
Figure 5: MPLS CC State machine for source MEP for independent Figure 8: MPLS CC State machine for source MEP for independent
session operation session operation
The sink MEP state machine (for which the transmit interval has been The sink MEP state machine (for which the transmit interval has been
set to zero) is modified to: set to zero) is modified to:
1) Permit direct transition from DOWN to UP once the session has been 1) Permit direct transition from DOWN to UP once the session has been
initialized. With the exception of via the ADMIN DOWN state, the initialized. With the exception of via the ADMIN DOWN state, the
source MEP will never transition from the UP state, hence in normal source MEP will never transition from the UP state, hence in normal
unidirectional fault scenarios will never transition to the INIT unidirectional fault scenarios will never transition to the INIT
state. state.
+--+ +--+
| | ADMIN DOWN, TIMER, AIS-LDI, LKR | | ADMIN DOWN, TIMER, LDI, LKR
| V | V
DOWN +------+ INIT, UP DOWN +------+ INIT, UP
+------------| |------------+ +------------| |------------+
| | DOWN | | | | DOWN | |
| +-------->| |<--------+ | | +-------->| |<--------+ |
| | +------+ | | | | +------+ | |
| | | | | | | |
| | ADMIN DOWN,| | | | ADMIN DOWN,| |
| |ADMIN DOWN, TIMER, | | | |ADMIN DOWN, TIMER, | |
| |TIMER, DOWN, | | | |TIMER, DOWN, | |
| |AIS-LDI, AIS-LDI, | V | |LDI, LDI, | V
V |LKR LKR | | V |LKR LKR | |
+------+ +------+ +------+ +------+
+----| | | |----+ +----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+ +--->| | INIT, UP | |<---+
+------+ +------+ +------+ +------+
Figure 6: MPLS CC State machine for the sink MEP for independent Figure 9: MPLS CC State machine for the sink MEP for independent
session operation session operation
3.7.6. Configuration of MPLS-TP BFD sessions 3.7.6. Configuration of MPLS-TP BFD sessions
Configuration of MPLS-TP BFD session parameters and coordination of Configuration of MPLS-TP BFD session parameters and coordination of
same between the source and sink MEPs is out of scope of this memo. same between the source and sink MEPs is out of scope of this memo.
3.7.7. Discriminator values 3.7.7. Discriminator values
In the BFD control packet the discriminator values have either local In the BFD control packet the discriminator values have either local
skipping to change at page 18, line 24 skipping to change at page 18, line 24
My Discriminator field MUST be set to a nonzero value (it can be a My Discriminator field MUST be set to a nonzero value (it can be a
fixed value), the transmitted your discriminator value MUST reflect fixed value), the transmitted your discriminator value MUST reflect
back the received value of My discriminator field or be set to 0 if back the received value of My discriminator field or be set to 0 if
that value is not known. that value is not known.
Per RFC5884 Section 7 [8], a node MUST NOT change the value of the Per RFC5884 Section 7 [8], a node MUST NOT change the value of the
"my discriminator" field for an established BFD session. "my discriminator" field for an established BFD session.
4. Configuration Considerations 4. Configuration Considerations
The following is an exemplary set of configuration parameters for a The following is an example set of configuration parameters for a BFD
BFD session: session:
Mode and Encapsulation Mode and Encapsulation
RFC 5884 - BFD CC in UDP/IP/LSP RFC 5884 - BFD CC in UDP/IP/LSP
RFC 5885 - BFD CC in G-ACh RFC 5885 - BFD CC in G-ACh
RFC 5085 - UDP/IP in G-ACh RFC 5085 - UDP/IP in G-ACh
MPLS-TP - CC/CV in GAL/G-ACh or G-ACh MPLS-TP - CC/CV in GAL/G-ACh or G-ACh
For MPLS-TP, the following additional parameters need to be For MPLS-TP, the following additional parameters need to be
configured: configured:
1) Session mode, coordinated or independent 1) Session mode, coordinated or independent
skipping to change at page 19, line 15 skipping to change at page 19, line 15
And the following parameters can optionally be configured or locally And the following parameters can optionally be configured or locally
assigned: assigned:
1) The discriminators used by each MEP. Both bfd.LocalDiscr and 1) The discriminators used by each MEP. Both bfd.LocalDiscr and
bfd.RemoteDiscr. bfd.RemoteDiscr.
Finally the following is directly inferred: Finally the following is directly inferred:
1) Detect multiplier of 3 1) Detect multiplier of 3
5. Acknowledgments 5. Acknowledgments
Nitin Bahadur, Rahul Aggarwal, Dave Ward, Tom Nadeau, Nurit Sprecher Nitin Bahadur, Rahul Aggarwal, Tom Nadeau, Nurit Sprecher and Yaacov
and Yaacov Weingarten also contributed to this document. Weingarten also contributed to this document.
6. IANA Considerations 6. IANA Considerations
This draft requires the allocation of two channel types from the IANA This draft requires the allocation of two channel types from the IANA
"PW Associated Channel Type" registry in RFC4446 [6]. "PW Associated Channel Type" registry in RFC4446 [6].
XX MPLS-TP CC message XX1 MPLS-TP CC message
XX+1 MPLS-TP CV message XX2 MPLS-TP CV message
This draft requires the creations of a source MEP-ID TLV This draft requires the creations of a source MEP-ID TLV
registry with initial values of: registry. The parent registry will be the "PW Associated Channel
Type" registry of RFC4446 [6]. All code points within this
registry shall be allocated according to the "Standards Action"
procedures as specified in [11].
Xx - Section MEP-ID The initial values are:
Xx+1 - LSP MEP-ID X1 - Section MEP-ID
Xx+2 - PW MEP-ID X2 - LSP MEP-ID
The source MEP-ID TLV will require standards action registration X3 - PW MEP-ID
procedures for additional values.
The items tracked in the registry will be the type, and the
associated name and reference. The source MEP-ID TLV will require
standards action registration procedures for additional values.
This memo requests a code point from the registry for BFD This memo requests a code point from the registry for BFD
diagnostic codes [4]: diagnostic codes [4]:
Xx - - misconnectivity defect XX - - mis-connectivity defect
7. Security Considerations 7. Security Considerations
The use of CV improves network integrity by ensuring traffic is
not "leaking" between LSPs.
Base BFD foresees an optional authentication section (see [4] Base BFD foresees an optional authentication section (see [4]
section 6.7); that can be applied to this application. section 6.7); that can be applied to this application. Although
the source MEP-ID TLV is not included in the BFD authentication
digest, there is a chain of trust such that the discriminator
associated with the digest is also associated with the expected
MEP-ID which will prevent impersonation of CV messages in this
application.
8. References 8. References
8.1. Normative References 8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate [1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bocci, M. et al., " MPLS Generic Associated Channel ", RFC [2] Bocci, M. et al., " MPLS Generic Associated Channel ", RFC
5586 , June 2009 5586 , June 2009
skipping to change at page 20, line 39 skipping to change at page 21, line 5
(BFD) for the Pseudowire Virtual Circuit Connectivity (BFD) for the Pseudowire Virtual Circuit Connectivity
Verification (VCCV) ", IETF RFC 5885, June 2010 Verification (VCCV) ", IETF RFC 5885, June 2010
[8] Aggarwal, R. et.al., "Bidirectional Forwarding Detection [8] Aggarwal, R. et.al., "Bidirectional Forwarding Detection
(BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884,
June 2010 June 2010
[9] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft- [9] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft-
ietf-mpls-tp-identifiers-06 (work in progress), June 2011 ietf-mpls-tp-identifiers-06 (work in progress), June 2011
[10] Nadeau, T, et al., "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007
[11] Narten, T., Alvestrand, H., "Guidelines for Writing an
IANA Considerations Section in RFCs", IETF RFC 5226, May
2008
8.2. Informative References 8.2. Informative References
[10] Bocci, M., et al., "A Framework for MPLS in Transport [12] Bocci, M., et al., "A Framework for MPLS in Transport
Networks", RFC5921, July 2010 Networks", RFC5921, July 2010
[11] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft- [13] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft-
ietf-mpls-tp-oam-framework-11 (work in progress), February ietf-mpls-tp-oam-framework-11 (work in progress), February
2011 2011
[12] Nadeau, T, et al., "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007
Authors' Addresses Authors' Addresses
Dave Allan Dave Allan
Ericsson Ericsson
Email: david.i.allan@ericsson.com Email: david.i.allan@ericsson.com
John Drake John Drake
Juniper Juniper
Email: jdrake@juniper.net Email: jdrake@juniper.net
 End of changes. 70 change blocks. 
125 lines changed or deleted 145 lines changed or added

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