draft-ietf-mpls-rmr-11.txt   draft-ietf-mpls-rmr-12.txt 
MPLS WG K. Kompella MPLS WG K. Kompella
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Intended status: Standards Track L. Contreras Intended status: Standards Track L. Contreras
Expires: December 10, 2019 Telefonica Expires: April 25, 2020 Telefonica
June 8, 2019 October 23, 2019
Resilient MPLS Rings Resilient MPLS Rings
draft-ietf-mpls-rmr-11 draft-ietf-mpls-rmr-12
Abstract Abstract
This document describes the use of the MPLS control and data planes This document describes the use of the MPLS control and data planes
on ring topologies. It describes the special nature of rings, and on ring topologies. It describes the special nature of rings, and
proceeds to show how MPLS can be effectively used in such topologies. proceeds to show how MPLS can be effectively used in such topologies.
It describes how MPLS rings are configured, auto-discovered and It describes how MPLS rings are configured, auto-discovered and
signaled, as well as how the data plane works. Companion documents signaled, as well as how the data plane works. Companion documents
describe the details of discovery and signaling for specific describe the details of discovery and signaling for specific
protocols. protocols.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 December 10, 2019. This Internet-Draft will expire on April 25, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 28 skipping to change at page 2, line 28
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5
3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Ring Nodes . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Ring Nodes . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Ring Links and Directions . . . . . . . . . . . . . . . . 6 3.3. Ring Links and Directions . . . . . . . . . . . . . . . . 6
3.3.1. Express Links . . . . . . . . . . . . . . . . . . . . 6 3.3.1. Express Links . . . . . . . . . . . . . . . . . . . . 6
3.4. Ring LSPs . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Ring LSPs . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Installing Primary LFIB Entries . . . . . . . . . . . . . 7 3.5. Installing Primary LFIB Entries . . . . . . . . . . . . . 7
3.6. Protection . . . . . . . . . . . . . . . . . . . . . . . 7 3.6. Protection . . . . . . . . . . . . . . . . . . . . . . . 7
3.7. Installing FRR LFIB Entries . . . . . . . . . . . . . . . 9 3.7. Installing FRR LFIB Entries . . . . . . . . . . . . . . . 8
4. Autodiscovery . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Autodiscovery . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Ring Announcement Phase . . . . . . . . . . . . . . . . . 10 4.2. Ring Announcement Phase . . . . . . . . . . . . . . . . . 10
4.3. Mastership Phase . . . . . . . . . . . . . . . . . . . . 11 4.3. Mastership Phase . . . . . . . . . . . . . . . . . . . . 11
4.4. Ring Identification Phase . . . . . . . . . . . . . . . . 11 4.4. Ring Identification Phase . . . . . . . . . . . . . . . . 11
4.5. Ring Changes . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Ring Changes . . . . . . . . . . . . . . . . . . . . . . 12
5. Ring Signaling . . . . . . . . . . . . . . . . . . . . . . . 12 5. Ring OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Ring OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 13
7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Half-rings . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Half-rings . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Hub Node Resilience . . . . . . . . . . . . . . . . . . . 13
7.2. Hub Node Resilience . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Rings are a very common topology in transport networks. A ring is Rings are a very common topology in transport networks. A ring is
the simplest topology offering link and node resilience. Rings are the simplest topology offering link and node resilience. Rings are
nearly ubiquitous in access and aggregation networks. As MPLS nearly ubiquitous in access and aggregation networks. As MPLS
increases its presence in such networks, and takes on a greater role increases its presence in such networks, and takes on a greater role
in transport, it is imperative that MPLS handles rings well; this is in transport, it is imperative that MPLS handles rings well; this is
not the case today. not the case today.
skipping to change at page 6, line 36 skipping to change at page 6, line 36
Ring links must be MPLS-capable. They are by default unnumbered, Ring links must be MPLS-capable. They are by default unnumbered,
point-to-point (from the IGP point of view) and "auto-bundled". The point-to-point (from the IGP point of view) and "auto-bundled". The
"auto-bundled" attribute means that parallel links between ring "auto-bundled" attribute means that parallel links between ring
neighbors are considered as a single link, without the need for neighbors are considered as a single link, without the need for
explicit configuration for bundling (such as a Link Aggregation explicit configuration for bundling (such as a Link Aggregation
Group). Note that each component may be advertised separately in the Group). Note that each component may be advertised separately in the
IGP; however, signaling messages and labels across one component link IGP; however, signaling messages and labels across one component link
apply to all components. Parallel links between a pair of ring nodes apply to all components. Parallel links between a pair of ring nodes
is often the result of having multiple lambdas or fibers between is often the result of having multiple lambdas or fibers between
those nodes. RMR is primarily intended for operation at the packet those nodes. RMR is primarily intended for operation at the packet
layer; however, parallel links at the lambda or fiber layer result in layer; however, parallel links at the lambda or fiber layer may
parallel links at the packet layer. result in parallel links at the packet layer.
A ring link is not provisioned as belonging to the ring; it is A ring link is not provisioned as belonging to the ring; it is
discovered to belong to ring RID if both its adjacent nodes belong to discovered to belong to ring RID if both its adjacent nodes belong to
RID. A ring link's direction (CW or AC) is also discovered; this RID. A ring link's direction (CW or AC) is also discovered; this
process is initiated by the ring's ring master. Note that the above process is initiated by the ring's ring master. Note that the above
two attributes can be overridden by provisioning if needed; it is two attributes can be overridden by provisioning if needed; it is
then up to the provisioning system to maintain consistency across the then up to the provisioning system to maintain consistency across the
ring. ring.
3.3.1. Express Links 3.3.1. Express Links
skipping to change at page 7, line 13 skipping to change at page 7, line 13
result of optically bypassing ring nodes. result of optically bypassing ring nodes.
3.4. Ring LSPs 3.4. Ring LSPs
Ring LSPs are not provisioned. Once a ring node R_i knows its RID, Ring LSPs are not provisioned. Once a ring node R_i knows its RID,
its ring links and directions, it kicks off ring LSP signaling its ring links and directions, it kicks off ring LSP signaling
automatically. R_i allocates CW and AC labels for each ring LSP automatically. R_i allocates CW and AC labels for each ring LSP
RL_k. R_i also initiates the creation of RL_i. As the signaling RL_k. R_i also initiates the creation of RL_i. As the signaling
propagates around the ring, CW and AC labels are exchanged. When R_i propagates around the ring, CW and AC labels are exchanged. When R_i
receives CW and AC labels for RL_k from its ring neighbors, primary receives CW and AC labels for RL_k from its ring neighbors, primary
and fast reroute (FRR) paths for RL_k are installed at R_i. More and fast reroute (FRR) paths for RL_k are installed at R_i.
details are given in Section 5.
For RSVP-TE LSPs, bandwidths may be signaled in both directions. For RSVP-TE LSPs, bandwidths may be signaled in both directions.
However, these are not provisioned either; rather, one does "reverse However, these are not provisioned either; rather, one does "reverse
call admission control". When a service needs to use an LSP, the call admission control". When a service needs to use an LSP, the
ring node where the traffic enters the ring attempts to increase the ring node where the traffic enters the ring attempts to increase the
bandwidth on the LSP to the egress. If successful, the service is bandwidth on the LSP to the egress. If successful, the service is
admitted to the ring. admitted to the ring.
3.5. Installing Primary LFIB Entries 3.5. Installing Primary LFIB Entries
skipping to change at page 9, line 15 skipping to change at page 9, line 8
3.7. Installing FRR LFIB Entries 3.7. Installing FRR LFIB Entries
At the same time that R_j sets up its primary CW and AC LFIB entries, At the same time that R_j sets up its primary CW and AC LFIB entries,
it can also set up the protection forwarding entries for RL_k. In it can also set up the protection forwarding entries for RL_k. In
the CW direction, R_j sets up an FRR LFIB entry to swap incoming the CW direction, R_j sets up an FRR LFIB entry to swap incoming
label CL_jk with AL_j-1,k with next hop R_j-1. In the AC direction, label CL_jk with AL_j-1,k with next hop R_j-1. In the AC direction,
R_j sets up an FRR LFIB entry to swap incoming label AL_jk with R_j sets up an FRR LFIB entry to swap incoming label AL_jk with
CL_j+1,k with next hop R_j+1. Again, R_k does not install FRR LFIB CL_j+1,k with next hop R_j+1. Again, R_k does not install FRR LFIB
entries in this manner. entries in this manner.
Say R1 receives label L42 from R2 to reach R4 in the clockwise
direction, and receives label L40 from R0 to reach R4 in the anti-
clockwise direction. Say R1 also receives label L52 from R2 to reach
R5 in the clockwise direction, and receives label L50 from R0 to
reach R5 in the anti-clockwise direction. R1 makes the following
LFIB entries:
+------+--------+-----------+--------+-----------+
| Dest | CW/NH | CW FRR/NH | AC/NH | AC FRR/NH |
+------+--------+-----------+--------+-----------+
| ... | | | | |
| R4 | L42/R2 | L40/R0 | L40/R0 | L42/R2 |
| R5 | L52/R2 | L50/R0 | L50/R0 | L52/R2 |
| ... | | | | |
+------+--------+-----------+--------+-----------+
R1's LFIB
4. Autodiscovery 4. Autodiscovery
4.1. Overview 4.1. Overview
Auto-discovery proceeds in three phases. The first phase is the Auto-discovery proceeds in three phases. The first phase is the
announcement phase. The second phase is the mastership phase. The announcement phase. The second phase is the mastership phase. The
third phase is the ring identification phase. third phase is the ring identification phase.
S1 S1
/ \ / \
skipping to change at page 11, line 30 skipping to change at page 11, line 39
values, and N1 has the lowest loopback address, while N2 has the values, and N1 has the lowest loopback address, while N2 has the
second lowest loopback address. If N1 makes its ring announcement second lowest loopback address. If N1 makes its ring announcement
just as N2's T1 timer fires, both N1 and N2 will think they are the just as N2's T1 timer fires, both N1 and N2 will think they are the
master (since N2 will not have heard N1's announcment in time). master (since N2 will not have heard N1's announcment in time).
However, in the next round, N2 will realize that N1 is indeed the However, in the next round, N2 will realize that N1 is indeed the
master. In the worst case, the mastership phase will occur as many master. In the worst case, the mastership phase will occur as many
times as there are nodes in the ring. times as there are nodes in the ring.
4.4. Ring Identification Phase 4.4. Ring Identification Phase
When there is exactly one ring master M, M enters the Ring R0 . . . R1 <------ 3. Anti-clockwise neighbor
. .
R7 R2 <--- 0. Ring Master
. Ring / .
. / . 1. Maximal ring includes R3
. / .
R6 / R3 <--- 2. Clockwise neighbor
. / .
R5 . . . R4 <------ 4. R4 is express neighbor
Figure 3: Ring Identification
When there is exactly one ring master M (here, R2), M enters the Ring
Identification Phase. M indicates that it has successfully completed Identification Phase. M indicates that it has successfully completed
this phase by advertising ring link TLVs. This is the trigger for this phase by advertising ring link TLVs. This is the trigger for
M's CW neighbor to enter the Ring Identification Phase. This phase M's CW neighbor to enter the Ring Identification Phase. This phase
passes CW until all ring nodes have completed ring identification. passes CW until all ring nodes have completed ring identification.
In the Ring Identification Phase, a node X that has two or more IGP In the Ring Identification Phase, a node X that has two or more IGP
neighbors that belong to the ring picks one of them to be its CW ring neighbors that belong to the ring picks one of them to be its CW ring
neighbor. If X is the ring master, it also picks a node as its AC neighbor. If X is the ring master, it also picks a node as its AC
ring neighbor. If there are exactly two such nodes, this step is ring neighbor. If there are exactly two such nodes, this step is
trivial. If not, X computes a ring that includes all nodes that have trivial. If not, X computes a ring that includes all nodes that have
completed the Ring Identification Phase (as seen by their ring link completed the Ring Identification Phase (as seen by their ring link
TLVs) and further contains the maximal number of nodes that belong to TLVs) and further contains the maximal number of nodes that belong to
the ring. Based on that, X picks a CW neighbor and inserts ring link the ring. Based on that, X picks a CW neighbor and inserts ring link
TLVs with ring direction CW for each link to its CW neighbor; X also TLVs with ring direction CW for each link to its CW neighbor; X also
inserts a ring link TLV with direction AC for each link to its AC inserts a ring link TLV with direction AC for each link to its AC
neighbor. Then, X determines its express links. These are links neighbor. Then, X determines its express links. These are links
connected to ring nodes that are not ring neighbors. X advertises connected to ring nodes that are not ring neighbors. X advertises
ring link TLVs for express links by setting the link direction to ring link TLVs for express links by setting the link direction to
"express link". "express link".
Here, R2 has R1 as its neighbor on one side; it has two choices, R3
and R4 on the other. It picks R3 to get a maximal ring (Step 1). It
then picks R3 as its CW neighbor (Step 2) and R1 as its AC neighbor
(Step 3). Finally, it declares the link to R4 as an express link.
4.5. Ring Changes 4.5. Ring Changes
The main changes to a ring are: The main changes to a ring are:
ring link addition; ring link addition;
ring link deletion; ring link deletion;
ring node addition; and ring node addition; and
skipping to change at page 12, line 33 skipping to change at page 13, line 10
(until the last link in the bundle is removed.) (until the last link in the bundle is removed.)
The removal of the last ring link between two nodes, or the removal The removal of the last ring link between two nodes, or the removal
of a ring node is an event that triggers protection switching. In a of a ring node is an event that triggers protection switching. In a
simple ring, the result is a broken ring. However, if a ring has simple ring, the result is a broken ring. However, if a ring has
express links, then it may be able to converge to a smaller ring with express links, then it may be able to converge to a smaller ring with
protection. protection.
The addition of a new ring node can also be handled incrementally. The addition of a new ring node can also be handled incrementally.
5. Ring Signaling 5. Ring OAM
The ring LSP signaling procedures will be described in separate
documents describing signaling solution options.
6. Ring OAM
Each ring node should advertise in its ring node TLV the OAM Each ring node should advertise in its ring node TLV the OAM
protocols it supports. Each ring node is expected to run a link- protocols it supports. Each ring node is expected to run a link-
level OAM over each ring link. This should be an OAM protocol that level OAM over each ring link. This should be an OAM protocol that
both neighbors agree on. The default hello time is 3.3 millisecond. both neighbors agree on. The default hello time is 3.3 millisecond.
Each ring node also sends OAM messages over each direction of its Each ring node also sends OAM messages over each direction of its
ring LSP. This is a multi-hop OAM to check LSP liveness; typically, ring LSP. This is a multi-hop OAM to check LSP liveness; typically,
BFD would be used for this. The node chooses the hello interval; the BFD would be used for this. The node chooses the hello interval; the
default is once a second. default is once a second.
7. Advanced Topics 6. Advanced Topics
7.1. Half-rings 6.1. Half-rings
In some cases, a ring H may be incomplete, either because H is In some cases, a ring H may be incomplete, either because H is
permanently missing a link (not just because of a failure), or permanently missing a link (not just because of a failure), or
because the link required to complete H is in a different IGP area. because the link required to complete H is in a different IGP area.
Either way, the ring discovery algorithm will fail. We call such a Either way, the ring discovery algorithm will fail. We call such a
ring a "half-ring". Half-rings are sufficiently common that finding ring a "half-ring". Half-rings are sufficiently common that finding
a way to deal with them effectively is a useful problem to solve. a way to deal with them effectively is a useful problem to solve.
This topic will not be addressed in this document; that task is left This topic will not be addressed in this document; that task is left
for a future document. for a future document.
7.2. Hub Node Resilience 6.2. Hub Node Resilience
Let's call the node(s) that connect a ring to the rest of the network Let's call the node(s) that connect a ring to the rest of the network
"hub node(s)" (usually, there are a pair of hub nodes.) Suppose a "hub node(s)" (usually, there are a pair of hub nodes.) Suppose a
ring has two hub nodes H1 and H2. Suppose further that a non-hub ring has two hub nodes H1 and H2. Suppose further that a non-hub
ring node X wants to send traffic to some node Z outside the ring. ring node X wants to send traffic to some node Z outside the ring.
This could be done, say, by having targeted LDP (T-LDP) sessions from This could be done, say, by having targeted LDP (T-LDP) sessions from
H1 and H2 to X advertising LDP reachability to Z via H1 (H2); there H1 and H2 to X advertising LDP reachability to Z via H1 (H2); there
would be a two-label stack from X to reach Z. Say that to reach Z, X would be a two-label stack from X to reach Z. Say that to reach Z, X
prefers H1; thus, traffic from X to Z will first go to H1 via a ring prefers H1; thus, traffic from X to Z will first go to H1 via a ring
LSP, then to Z via LDP. LSP, then to Z via LDP.
If H1 fails, traffic from X to Z will drop until the T-LDP session If H1 fails, traffic from X to Z will drop until the T-LDP session
from H1 to Z fails, the IGP reconverges, and H2's label to Z is from H1 to Z fails, the IGP reconverges, and H2's label to Z is
chosen. Thereafter, traffic will go from X to H2 via a ring LSP, chosen. Thereafter, traffic will go from X to H2 via a ring LSP,
then to Z via LDP. However, this convergence could take a long time. then to Z via LDP. However, this convergence could take a long time.
Since this is a very common and important situation, it is again a Since this is a very common and important situation, it is again a
useful problem to solve. However, this topic too will not be useful problem to solve. However, this topic too will not be
addressed in this document; that task is left for a future document. addressed in this document; that task is left for a future document.
8. Security Considerations 7. Security Considerations
This document proposes extensions to IS-IS, OSPF, LDP and RSVP-TE, This document proposes extensions to IS-IS, OSPF, LDP and RSVP-TE,
all of which have mechanisms to secure them. The extensions proposed all of which have mechanisms to secure them. The extensions proposed
do not represent per se a compromise to network security when the do not represent per se a compromise to network security when the
control plane is secured, since any manipulation of the content of control plane is secured, since any manipulation of the content of
the messages or even the control plane misinterpretation of the the messages or even the control plane misinterpretation of the
semantics are avoided. semantics are avoided.
9. Acknowledgments 8. Acknowledgments
Many thanks to Pierre Bichon whose exemplar of self-organizing Many thanks to Pierre Bichon whose exemplar of self-organizing
networks and whose urging for ever simpler provisioning led to the networks and whose urging for ever simpler provisioning led to the
notion of promiscuous nodes. notion of promiscuous nodes.
10. IANA Considerations 9. IANA Considerations
There are no requests as yet to IANA for this document. There are no requests as yet to IANA for this document.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
11.2. Informative References 10.2. Informative References
[I-D.ietf-mpls-rfc4379bis] [I-D.ietf-mpls-rfc4379bis]
Kompella, K., Swallow, G., Pignataro, C., Kumar, N., Kompella, K., Swallow, G., Pignataro, C., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multi-Protocol Label Aldrin, S., and M. Chen, "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures", draft-ietf-mpls- Switched (MPLS) Data Plane Failures", draft-ietf-mpls-
rfc4379bis-09 (work in progress), October 2016. rfc4379bis-09 (work in progress), October 2016.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
 End of changes. 20 change blocks. 
36 lines changed or deleted 64 lines changed or added

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