draft-ietf-mpls-gach-adv-00.txt   draft-ietf-mpls-gach-adv-01.txt 
MPLS D. Frost, Ed. MPLS D. Frost, Ed.
Internet-Draft S. Bryant, Ed. Internet-Draft S. Bryant, Ed.
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: July 30, 2012 M. Bocci, Ed. Expires: November 24, 2012 M. Bocci, Ed.
Alcatel-Lucent Alcatel-Lucent
January 27, 2012 May 23, 2012
MPLS Generic Associated Channel (G-ACh) Advertisement Protocol MPLS Generic Associated Channel (G-ACh) Advertisement Protocol
draft-ietf-mpls-gach-adv-00 draft-ietf-mpls-gach-adv-01
Abstract Abstract
The MPLS Generic Associated Channel (G-ACh) provides an auxiliary The MPLS Generic Associated Channel (G-ACh) provides an auxiliary
logical data channel associated with a Label Switched Path (LSP), a logical data channel associated with a Label Switched Path (LSP), a
pseudowire, or a section (link) over which a variety of protocols may pseudowire, or a section (link) over which a variety of protocols may
flow. These protocols are commonly used to provide Operations, flow. These protocols are commonly used to provide Operations,
Administration, and Maintenance (OAM) mechanisms associated with the Administration, and Maintenance (OAM) mechanisms associated with the
primary data channel. This document specifies simple procedures by primary data channel. This document specifies simple procedures by
which an endpoint of an LSP, pseudowire, or section may inform the which an endpoint of an LSP, pseudowire, or section may inform the
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 July 30, 2012. This Internet-Draft will expire on November 24, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 22 skipping to change at page 2, line 22
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5
4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 8 4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 8
4.1. Identifier TLVs . . . . . . . . . . . . . . . . . . . . . 8 4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . . 8
4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 8 4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 8
4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 9 4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 9
4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . . 9 4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . . 9
4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . . 9 4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . . 10
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. G-ACh Advertisement Message Transmission . . . . . . . . . 10 5.1. G-ACh Advertisement Message Transmission . . . . . . . . . 11
5.2. G-ACh Advertisement Message Reception . . . . . . . . . . 11 5.2. G-ACh Advertisement Message Reception . . . . . . . . . . 11
6. Message Authentication . . . . . . . . . . . . . . . . . . . . 11 6. Message Authentication . . . . . . . . . . . . . . . . . . . . 12
6.1. Authentication Key Identifiers . . . . . . . . . . . . . . 11 6.1. Authentication Key Identifiers . . . . . . . . . . . . . . 12
6.2. Authentication Process . . . . . . . . . . . . . . . . . . 12 6.2. Authentication Process . . . . . . . . . . . . . . . . . . 12
6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 13 6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 13
7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 14 7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Associated Channel Type Allocation . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.2. Allocation of Address Family Numbers . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.3. Creation of G-ACh Advertisement Protocol Application
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.4. Creation of G-ACh Advertisement Protocol TLV Registry . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The MPLS Generic Associated Channel (G-ACh) is defined and described The MPLS Generic Associated Channel (G-ACh) is defined and described
in [RFC5586]. It provides an auxiliary logical data channel in [RFC5586]. It provides an auxiliary logical data channel
associated with an MPLS Label Switched Path (LSP), a pseudowire, or a associated with an MPLS Label Switched Path (LSP), a pseudowire, or a
section (link) over which a variety of protocols may flow. A primary section (link) over which a variety of protocols may flow. A primary
purpose of the G-ACh and the protocols it supports is to provide purpose of the G-ACh and the protocols it supports is to provide
Operations, Administration, and Maintenance (OAM) capabilities Operations, Administration, and Maintenance (OAM) capabilities
associated with the underlying LSP, pseudowire, or section. Examples associated with the underlying LSP, pseudowire, or section. Examples
skipping to change at page 4, line 16 skipping to change at page 4, line 16
thus allows LSRs to exchange information of a similar sort to that thus allows LSRs to exchange information of a similar sort to that
supported by LLDP for Ethernet links. supported by LLDP for Ethernet links.
An important special case arises in networks based on the MPLS An important special case arises in networks based on the MPLS
Transport Profile (MPLS-TP) [RFC5921] that do not also support IP: Transport Profile (MPLS-TP) [RFC5921] that do not also support IP:
without IP, protocols for determining the Ethernet address of an without IP, protocols for determining the Ethernet address of an
adjacent MPLS node, such as the Address Resolution Protocol [RFC0826] adjacent MPLS node, such as the Address Resolution Protocol [RFC0826]
and IP version 6 Neighbor Discovery [RFC4861], are not available. and IP version 6 Neighbor Discovery [RFC4861], are not available.
The G-ACh advertisement protocol can be used to discover the Ethernet The G-ACh advertisement protocol can be used to discover the Ethernet
MAC addresses of MPLS nodes lacking IP capability MAC addresses of MPLS nodes lacking IP capability
[I-D.fbb-mpls-tp-ethernet-addressing]. [I-D.ietf-mpls-tp-ethernet-addressing].
The applicability of the G-ACh advertisement protocol is not limited The applicability of the G-ACh advertisement protocol is not limited
to link-layer adjacency, either in terms of message distribution or to link-layer adjacency, either in terms of message distribution or
message content. The G-ACh exists for any MPLS LSP or pseudowire, so message content. The G-ACh exists for any MPLS LSP or pseudowire, so
GAP messages can be exchanged with remote LSP or pseudowire GAP messages can be exchanged with remote LSP or pseudowire
endpoints. The content of GAP messages is extensible in a simple endpoints. The content of GAP messages is extensible in a simple
manner, and can include any kind of information that might be useful manner, and can include any kind of information that might be useful
to MPLS LSRs connected by links, LSPs, or pseudowires. For example, to MPLS LSRs connected by links, LSPs, or pseudowires. For example,
in networks that rely on the G-ACh for OAM functions, GAP messages in networks that rely on the G-ACh for OAM functions, GAP messages
might be used to inform adjacent LSRs of a node's OAM capabilities might be used to inform adjacent LSRs of a node's OAM capabilities
skipping to change at page 8, line 15 skipping to change at page 8, line 15
GAP messages do not contain a checksum. If validation of message GAP messages do not contain a checksum. If validation of message
integrity is desired, the authentication procedures in Section 6 integrity is desired, the authentication procedures in Section 6
should be used. should be used.
4. G-ACh Advertisement Protocol TLVs 4. G-ACh Advertisement Protocol TLVs
The GAP supports several TLV objects related to its own operation via The GAP supports several TLV objects related to its own operation via
the Application ID 0x0000. When an ADB element for the GAP is the Application ID 0x0000. When an ADB element for the GAP is
present in a GAP message, it MUST precede other elements. present in a GAP message, it MUST precede other elements.
4.1. Identifier TLVs 4.1. Source Address TLV
The following TLV objects are defined for purposes of conveying The Source Address object identifies the sending device and possibly
identification information associated with the transmitting device the transmitting interface and the channel; it has the following
and the data channel: format:
o Interface Identifier TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o LSP Identifier TLV Source Address TLV Format
o Pseudowire Path Identifier TLV The Address Family field indicates the type of the address; it SHALL
be set to one of the assigned values in the "IANA Address Family
Numbers" registry.
The Value portion of these identifier objects follows the format of In IP networks the Source Address SHOULD be included in GAP messages
the respective identifier as defined in [RFC6370]. and set to an IP address of the sending device; when the channel is a
link, this address SHOULD be an address of the transmitting
interface.
The LSP and Pseudowire Path Identifiers SHOULD be present in GAP In non-IP MPLS-TP networks the Source Address SHOULD be included in
messages transmitted over LSPs and pseudowires, respectively, and GAP messages and set to the endpoint identifier of the channel. The
MUST NOT be present for other data channel types. The Interface formats of these channel identifiers SHALL be as given in Sections
Identifier SHOULD be present in GAP messages transmitted over data- 3.5.1, 3.5.2, and 3.5.3 of [RFC6428] (excluding the initial Type and
link sections. Length fields shown in those sections).
4.2. GAP Request TLV 4.2. GAP Request TLV
This object is a request by the sender for the receiver to transmit This object is a request by the sender for the receiver to transmit
an immediate unicast GAP update to the sender. If the Length field an immediate unicast GAP update to the sender. If the Length field
is zero, this signifies that an update for all applications is is zero, this signifies that an update for all applications is
requested. Otherwise, the Value field specifies the applications for requested. Otherwise, the Value field specifies the applications for
which an update is requested, in the form of a sequence of which an update is requested, in the form of a sequence of
Application IDs: Application IDs:
skipping to change at page 9, line 24 skipping to change at page 9, line 28
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID N-1 | Application ID N | | Application ID N-1 | Application ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GAP Request TLV Format GAP Request TLV Format
4.3. GAP Flush TLV 4.3. GAP Flush TLV
This object is an instruction to the receiver to flush the GAP data This object is an instruction to the receiver to flush the GAP data
for all applications. It is a null object, i.e. its Length is set to for all applications associated with this sender. It is a null
zero. Note that data for a specific application can be flushed by object, i.e. its Length is set to zero. Note that data for a
sending an update for the application with the Lifetime set to zero. specific application can be flushed by sending an update for the
application with the Lifetime set to zero.
The GAP Flush instruction does not apply to data contained in the The GAP Flush instruction does not apply to data contained in the
message carrying the GAP Flush TLV object itself. Any application message carrying the GAP Flush TLV object itself. Any application
data contained in the same message SHALL be processed and retained by data contained in the same message SHALL be processed and retained by
the receiver as usual. the receiver as usual.
4.4. GAP Suppress TLV 4.4. GAP Suppress TLV
This object is a request to the receiver to cease sending GAP updates This object is a request to the receiver to cease sending GAP updates
to the transmitter over the current channel. The object format is to the transmitter over the current channel for the specified
the same as the GAP Request TLV object. If the Length is set to duration (in seconds). The request is strictly advisory: the
zero, suppression of all GAP messages is requested; otherwise receiver SHOULD accept and act on the request, but MAY override it at
suppression of only those updates pertaining to applications listed any time. The format of this object is as follows:
in the Value field is requested.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration | Application ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID N-1 | Application ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GAP Suppress TLV Format
If the Length is set to 2, i.e. if the list of Application IDs is
empty, then suppression of all GAP messages is requested; otherwise
suppression of only those updates pertaining to the listed
applications is requested.
This object makes sense only for point-to-point channels or when the This object makes sense only for point-to-point channels or when the
sender is receiving unicast GAP updates. sender is receiving unicast GAP updates.
4.5. GAP Authentication TLV 4.5. GAP Authentication TLV
This object is used to provide authentication and integrity This object is used to provide authentication and integrity
validation for a GAP message. It has the following format: validation for a GAP message. It has the following format:
0 1 2 3 0 1 2 3
skipping to change at page 15, line 17 skipping to change at page 15, line 44
messages in transit; this can disrupt the information receivers hold messages in transit; this can disrupt the information receivers hold
about legitimate senders. To protect against this threat, message about legitimate senders. To protect against this threat, message
authentication procedures are specified in this document that enable authentication procedures are specified in this document that enable
receivers to ensure the authenticity and integrity of GAP messages. receivers to ensure the authenticity and integrity of GAP messages.
These procedures include the means to protect against replay attacks, These procedures include the means to protect against replay attacks,
in which a third party captures a legitimate message and "replays" it in which a third party captures a legitimate message and "replays" it
to a receiver at some later time. to a receiver at some later time.
9. IANA Considerations 9. IANA Considerations
9.1. Associated Channel Type Allocation
This document requests that IANA allocate an entry in the Pseudowire This document requests that IANA allocate an entry in the Pseudowire
Associated Channel Types registry [RFC5586] for the G-ACh Associated Channel Types registry [RFC5586] for the G-ACh
Advertisement Protocol, as follows: Advertisement Protocol, as follows:
Value Description TLV Follows Reference Value Description TLV Follows Reference
----- ---------------------------- ----------- ------------ ----- ---------------------------- ----------- ------------
(TBD) G-ACh Advertisement Protocol No (this draft) (TBD) G-ACh Advertisement Protocol No (this draft)
This document also requests that IANA create a new registry, "G-ACh 9.2. Allocation of Address Family Numbers
Advertisement Protocol Applications and Data Types", with fields and
initial allocations as follows:
Application Description Type Name Type Reference This document requests that IANA allocate three entries in the
ID ID Address Family Numbers registry for MPLS-TP Section, LSP, and
----------- ------------------- -------------------- ------ --------- Pseudowire endpoint identifiers, based on Sections 3.5.1, 3.5.2, and
0x0000 G-ACh Advertisement GAP Request 0 (this 3.5.3 of [RFC6428]. The allocations are:
Protocol draft)
GAP Flush 1 (this Number Description Reference
draft) ------ -------------------------------------- ------------
GAP Suppress 2 (this (TBD) MPLS-TP Section Endpoint Identifier (this draft)
draft) (TBD) MPLS-TP LSP Endpoint Identifier (this draft)
GAP Authentication 3 (this (TBD) MPLS-TP Pseudowire Endpoint Identifier (this draft)
draft)
9.3. Creation of G-ACh Advertisement Protocol Application Registry
This document requests that IANA create a new registry, "G-ACh
Advertisement Protocol Applications", with fields and initial
allocations as follows:
Application ID Description Reference
-------------- ---------------------------- ------------
0x0000 G-ACh Advertisement Protocol (this draft)
The range of the Application ID field is 0x0000 - 0xFFFF.
The allocation policy for this registry is Specification Required.
9.4. Creation of G-ACh Advertisement Protocol TLV Registry
This document requests that IANA create a new registry, "G-ACh
Advertisement Protocol: GAP TLV Objects", with fields and initial
allocations as follows:
Type Name Type ID Reference
------------------ ------- ------------
Source Address 0 (this draft)
GAP Request 1 (this draft)
GAP Flush 2 (this draft)
GAP Suppress 3 (this draft)
GAP Authentication 4 (this draft)
The range of the Type ID field is 0 - 255.
The allocation policy for this registry is IETF Review. The allocation policy for this registry is IETF Review.
10. References 10. References
10.1. Normative References 10.1. Normative References
[FIPS-198] [FIPS-198]
US National Institute of Standards and Technology, "The US National Institute of Standards and Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
skipping to change at page 16, line 18 skipping to change at page 17, line 27
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", RFC 5332, August 2008. Multicast Encapsulations", RFC 5332, August 2008.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. Connectivity Verification, Continuity Check, and Remote
Defect Indication for the MPLS Transport Profile",
RFC 6428, November 2011.
10.2. Informative References 10.2. Informative References
[I-D.fbb-mpls-tp-ethernet-addressing] [I-D.ietf-mpls-tp-ethernet-addressing]
Frost, D., Bryant, S., and M. Bocci, "MPLS-TP Next-Hop Frost, D., Bocci, M., and S. Bryant, "MPLS-TP Next-Hop
Ethernet Addressing", Ethernet Addressing",
draft-fbb-mpls-tp-ethernet-addressing-01 (work in draft-ietf-mpls-tp-ethernet-addressing-00 (work in
progress), November 2011. progress), January 2012.
[LLDP] IEEE, "Station and Media Access Control Connectivity [LLDP] IEEE, "Station and Media Access Control Connectivity
Discovery (802.1AB)", September 2009. Discovery (802.1AB)", September 2009.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982. RFC 826, November 1982.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
 End of changes. 26 change blocks. 
58 lines changed or deleted 127 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/