draft-ietf-mpls-p2mp-lsp-ping-09.txt   draft-ietf-mpls-p2mp-lsp-ping-10.txt 
Network Working Group S. Saxena, Ed. Network Working Group S. Saxena, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended Status: Standards Track A. Farrel Intended Status: Standards Track A. Farrel
Updates: RFC4379 Old Dog Consulting Updates: 4379 (if approved) Old Dog Consulting
Created: December 14, 2009 S. Yasukawa Created: March 07, 2010 S. Yasukawa
Expires: June 14, 2010 NTT Corporation Expires: Septemeber 07, 2010 NTT Corporation
Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol
Label Switching (MPLS) - Extensions to LSP Ping Label Switching (MPLS) - Extensions to LSP Ping
draft-ietf-mpls-p2mp-lsp-ping-09.txt draft-ietf-mpls-p2mp-lsp-ping-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
fault detection and isolation commonly referred to as "LSP Ping". fault detection and isolation commonly referred to as "LSP Ping".
The scope of this document is fault detection and isolation for P2MP The scope of this document is fault detection and isolation for P2MP
MPLS LSPs. This documents does not replace any of the mechanisms of MPLS LSPs. This documents does not replace any of the mechanisms of
LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and
extends the techniques and mechanisms of LSP Ping to the MPLS P2MP extends the techniques and mechanisms of LSP Ping to the MPLS P2MP
environment. environment.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Contents Contents
1. Introduction.................................................. 5 1. Introduction.................................................... 5
1.1. Design Considerations....................................... 6 1.1. Design Considerations......................................... 6
2. Notes on Motivation........................................... 6 2. Notes on Motivation............................................. 6
2.1. Basic Motivations for LSP Ping.............................. 6 2.1. Basic Motivations for LSP Ping................................ 6
2.2. Motivations for LSP Ping for P2MP LSPs...................... 7 2.2. Motivations for LSP Ping for P2MP LSPs........................ 7
2.3. Bootstrapping Other OAM Procedures Using LSP Ping........... 9 3. Packet Format................................................... 9
3. Packet Format................................................. 9 3.1. Identifying the LSP Under Test................................ 9
3.1. Identifying the LSP Under Test.............................. 9 3.1.1. Identifying a P2MP MPLS TE LSP.............................. 9
3.1.1. Identifying a P2MP MPLS TE LSP............................ 9 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV............................ 9
3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV......................... 10 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV........................... 10
3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV......................... 10 3.1.2. Identifying a Multicast LDP LSP............................ 11
3.1.2. Identifying a Multicast LDP LSP.......................... 11 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs......................... 11
3.1.2.1. Multicast LDP FEC Stack Sub-TLVs....................... 11 3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs........... 12
3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs......... 12 3.2. Limiting the Scope of Responses.............................. 13
3.2. Limiting the Scope of Responses............................ 13 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs.......... 13
3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs........ 14 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs............ 14
3.2.2. Node Address P2MP Responder Identifier Sub-TLVs.......... 14 3.3. Preventing Congestion of Echo Responses...................... 14
3.3. Preventing Congestion of Echo Responses.................... 14 3.4. Respond Only If TTL Expired Flag............................. 15
3.4. Respond Only If TTL Expired Flag........................... 15 3.5. Downstream Detailed Mapping TLV.............................. 15
3.5. Downstream Detailed Mapping TLV............................ 15 4. Operation of LSP Ping for a P2MP LSP........................... 16
4. Operation of LSP Ping for a P2MP LSP......................... 16 4.1. Initiating Router Operations................................. 16
4.1. Initiating Router Operations............................... 16 4.1.1. Limiting Responses to Echo Requests........................ 16
4.1.1. Limiting Responses to Echo Requests...................... 16 4.1.2. Jittered Responses to Echo Requests........................ 17
4.1.2. Jittered Responses to Echo Requests...................... 17 4.2. Responding Router Operations................................. 18
4.2. Responding Router Operations............................... 18 4.2.1. Echo Response Reporting.................................... 18
4.2.1. Echo Response Reporting.................................. 19 4.2.1.1. Responses from Transit and Branch nodes.................. 19
4.2.1.1. Responses from Transit and Branch nodes................ 19 4.2.1.2. Responses from Egress Nodes.............................. 20
4.2.1.2. Responses from Egress Nodes............................ 20 4.2.1.3. Responses from Bud Nodes................................. 20
4.2.1.3. Responses from Bud Nodes............................... 20 4.3. Special Considerations for Traceroute........................ 22
4.3. Special Considerations for Traceroute...................... 22 4.3.1. End of Processing for Traceroutes.......................... 22
4.3.1. End of Processing for Traceroutes........................ 22 4.3.2. Multiple responses from Bud and Egress Nodes............... 22
4.3.2. Multiple responses from Bud and Egress Nodes............. 22 4.3.3. Non-Response to Traceroute Echo Requests................... 23
4.3.3. Non-Response to Traceroute Echo Requests................. 23 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request..... 23
4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request... 23 5. Non-compliant Routers.......................................... 23
5. Non-compliant Routers........................................ 23 6. OAM Considerations............................................. 24
6. OAM Considerations........................................... 24 7. IANA Considerations............................................ 24
7. IANA Considerations.......................................... 24 7.1. New Sub-TLV Types............................................ 24
7.1. New Sub-TLV Types.......................................... 25 7.2. New TLVs..................................................... 25
7.2. New TLVs................................................... 25 8. Security Considerations........................................ 25
8. Security Considerations...................................... 25 9. Acknowledgements............................................... 25
9. Acknowledgements............................................. 25 10. References.................................................... 26
10. References.................................................. 26 10.1. Normative References........................................ 26
10.1. Normative References...................................... 26 10.2. Informative References...................................... 26
10.2. Informative References.................................... 26 11. Authors' Addresses............................................ 27
11. Authors' Addresses.......................................... 27 12. Full Copyright Statement...................................... 28
12. Full Copyright Statement.................................... 28
0. Change Log 0. Change Log
This section to be removed before publication as an RFC. This section to be removed before publication as an RFC.
0.1 Changes from 00 to 01 0.1 Changes from 00 to 01
- Update references. - Update references.
- Fix boilerplate. - Fix boilerplate.
skipping to change at page 5, line 22 skipping to change at page 5, line 20
- Removed Section 4. as it was a duplicate of Section 2.3. - Removed Section 4. as it was a duplicate of Section 2.3.
0.9 Changes from 08 to 09 0.9 Changes from 08 to 09
- Reformatted the document to follow the RFC4379 style. After the - Reformatted the document to follow the RFC4379 style. After the
Motivations section is the Packet Format section, followed by the Motivations section is the Packet Format section, followed by the
Operations section. The sections on Ping and Traceroute have been Operations section. The sections on Ping and Traceroute have been
merged. merged.
- Added a Respond if TTL Expired Flag. - Added a Respond if TTL Expired Flag.
- Removed reference to [MCAST-CV]. - Removed reference to [MCAST-CV].
0.10 Changes from 09 to 10
- Removed references to bootstrapping other OAM protocols. This draft
does not provide any details of such methods. Hence it is cleaner
to remove such references.
- Minor edits based on comments.
1. Introduction 1. Introduction
Simple and efficient mechanisms that can be used to detect data plane Simple and efficient mechanisms that can be used to detect data plane
failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS) failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS)
Label Switched Paths (LSP) are described in [RFC4379]. The Label Switched Paths (LSP) are described in [RFC4379]. The
techniques involve information carried in MPLS "Echo Request" and techniques involve information carried in MPLS "Echo Request" and
"Echo Reply" messages, and mechanisms for transporting them. The "Echo Reply" messages, and mechanisms for transporting them. The
echo request and reply messages provide sufficient information to echo request and reply messages provide sufficient information to
check correct operation of the data plane, as well as a mechanism to check correct operation of the data plane, as well as a mechanism to
verify the data plane against the control plane, and thereby localize verify the data plane against the control plane, and thereby localize
skipping to change at page 5, line 50 skipping to change at page 6, line 6
The requirements for point-to-multipoint extensions to the Label The requirements for point-to-multipoint extensions to the Label
Distribution Protocol (LDP) are stated in [P2MP-LDP-REQ]. [P2MP-LDP] Distribution Protocol (LDP) are stated in [P2MP-LDP-REQ]. [P2MP-LDP]
specifies extensions to LDP for P2MP MPLS. specifies extensions to LDP for P2MP MPLS.
P2MP MPLS LSPs are at least as vulnerable to data plane faults or to P2MP MPLS LSPs are at least as vulnerable to data plane faults or to
discrepancies between the control and data planes as their P2P discrepancies between the control and data planes as their P2P
counterparts. Therefore, mechanisms are needed to detect such data counterparts. Therefore, mechanisms are needed to detect such data
plane faults in P2MP MPLS LSPs as described in [RFC4687]. plane faults in P2MP MPLS LSPs as described in [RFC4687].
This document extends the techniques described in [RFC4379] such that This document extends the techniques described in [RFC4379] such that
they may be applied to P2MP MPLS LSPs and so that they can be used to they may be applied to P2MP MPLS LSPs. This document stresses the
bootstrap other Operations and Management (OAM) procedures such as reuse of existing LSP Ping mechanisms used for P2P LSPs, and applies
them to P2MP MPLS LSPs in order to simplify implementation and
[MPLS-BFD]. This document stresses the reuse of existing LSP Ping network operation.
mechanisms used for P2P LSPs, and applies them to P2MP MPLS LSPs in
order to simplify implementation and network operation.
1.1. Design Considerations 1.1. Design Considerations
An important consideration for designing LSP Ping for P2MP MPLS LSPs An important consideration for designing LSP Ping for P2MP MPLS LSPs
is that every attempt is made to use or extend existing mechanisms is that every attempt is made to use or extend existing mechanisms
rather than invent new mechanisms. rather than invent new mechanisms.
As for P2P LSPs, a critical requirement is that the echo request As for P2P LSPs, a critical requirement is that the echo request
messages follow the same data path that normal MPLS packets traverse. messages follow the same data path that normal MPLS packets traverse.
However, it can be seen this notion needs to be extended for P2MP However, it can be seen this notion needs to be extended for P2MP
skipping to change at page 8, line 31 skipping to change at page 8, line 36
In "ping" mode (basic connectivity check), the echo request should In "ping" mode (basic connectivity check), the echo request should
reach the end of the path, at which point it is sent to the control reach the end of the path, at which point it is sent to the control
plane of the egress LSRs, which verify that they are indeed an egress plane of the egress LSRs, which verify that they are indeed an egress
(leaf) of the P2MP LSP. An echo response message is sent by an (leaf) of the P2MP LSP. An echo response message is sent by an
egress to the ingress to confirm the successful receipt (or announce egress to the ingress to confirm the successful receipt (or announce
the erroneous arrival) of the echo request. the erroneous arrival) of the echo request.
In "traceroute" mode (fault isolation), the echo request is sent to In "traceroute" mode (fault isolation), the echo request is sent to
the control plane at each transit LSR, and the control plane checks the control plane at each transit LSR, and the control plane checks
that it is indeed a transit LSR for this P2MP MPLS LSP. The transit that it is indeed a transit LSR for this P2MP MPLS LSP. The transit
LSR also returns information on an echo response that helps verify LSR returns information about the outgoing paths. This
the control plane against the data plane. That is, the information information can be used by ingress LSR to build topology or by
is used by the ingress to check that the data plane forwarding downstream LSRs to do extra label verification.
matches what is signaled by the control plane.
P2MP MPLS LSPs may have many egresses, and it is not necessarily the P2MP MPLS LSPs may have many egresses, and it is not necessarily the
intention of the initiator of the ping or traceroute operation to intention of the initiator of the ping or traceroute operation to
collect information about the connectivity or path to all egresses. collect information about the connectivity or path to all egresses.
Indeed, in the event of pinging all egresses of a large P2MP MPLS Indeed, in the event of pinging all egresses of a large P2MP MPLS
LSP, it might be expected that a large number of echo responses would LSP, it might be expected that a large number of echo responses would
arrive at the ingress independently but at approximately the same arrive at the ingress independently but at approximately the same
time. Under some circumstances this might cause congestion at or time. Under some circumstances this might cause congestion at or
around the ingress LSR. The procedures described in this document around the ingress LSR. The procedures described in this document
provide two mechanisms to control echo responses. provide two mechanisms to control echo responses.
skipping to change at page 9, line 12 skipping to change at page 9, line 15
LSP Ping can be used to periodically ping a P2MP MPLS LSP to ensure LSP Ping can be used to periodically ping a P2MP MPLS LSP to ensure
connectivity to any or all of the egresses. If the ping fails, the connectivity to any or all of the egresses. If the ping fails, the
operator or an automated process can then initiate a traceroute to operator or an automated process can then initiate a traceroute to
determine where the fault is located within the network. A determine where the fault is located within the network. A
traceroute may also be used periodically to verify that data plane traceroute may also be used periodically to verify that data plane
forwarding matches the control plane state; however, this places an forwarding matches the control plane state; however, this places an
increased burden on transit LSRs and should be used infrequently and increased burden on transit LSRs and should be used infrequently and
with caution. with caution.
2.3. Bootstrapping Other OAM Procedures Using LSP Ping
[MPLS-BFD] describes a process where LSP Ping [RFC4379] is used to
bootstrap the Bidirectional Forwarding Detection (BFD) mechanism
[BFD] for use to track the liveliness of an MPLS LSP. In particular
BFD can be used to detect a data plane failure in the forwarding path
of an MPLS LSP.
3. Packet Format 3. Packet Format
The basic structure of the LSP Ping packet remains the same as The basic structure of the LSP Ping packet remains the same as
described in [RFC4379]. Some new TLVs and sub-TLVs are required to described in [RFC4379]. Some new TLVs and sub-TLVs are required to
support the new functionality. They are described in the following support the new functionality. They are described in the following
sections. sections.
3.1. Identifying the LSP Under Test 3.1. Identifying the LSP Under Test
3.1.1. Identifying a P2MP MPLS TE LSP 3.1.1. Identifying a P2MP MPLS TE LSP
skipping to change at page 11, line 34 skipping to change at page 11, line 14
3.1.2. Identifying a Multicast LDP LSP 3.1.2. Identifying a Multicast LDP LSP
[RFC4379] defines how a P2P LDP LSP under test may be identified in [RFC4379] defines how a P2P LDP LSP under test may be identified in
an echo request. A Target FEC Stack TLV is used to carry one or more an echo request. A Target FEC Stack TLV is used to carry one or more
sub-TLVs (for example, an IPv4 Prefix FEC sub-TLV) that identify the sub-TLVs (for example, an IPv4 Prefix FEC sub-TLV) that identify the
LSP. LSP.
In order to identify a multicast LDP LSP under test, the echo request In order to identify a multicast LDP LSP under test, the echo request
message MUST carry a Target FEC Stack TLV, and this MUST carry message MUST carry a Target FEC Stack TLV, and this MUST carry
exactly one new sub-TLV: the Multicast LDP FEC Stack sub-TLV. This exactly one of two new sub-TLVs: either a Multicast P2MP LDP FEC
sub-TLV uses fields from the multicast LDP messages [P2MP-LDP] and so Stack sub-TLV or a Multicast MP2MP LDP FEC Stack sub-TLV. These
sub-TLVs use fields from the multicast LDP messages [P2MP-LDP] and so
provides sufficient information to uniquely identify the LSP. provides sufficient information to uniquely identify the LSP.
The new sub-TLV is assigned a sub-type identifier as follows, and is The new sub-TLVs are assigned a sub-type identifiers as follows, and
described in the following section. are described in the following section.
Sub-Type # Length Value Field Sub-Type # Length Value Field
---------- ------ ----------- ---------- ------ -----------
TBD Variable Multicast P2MP LDP FEC Stack TBD Variable Multicast P2MP LDP FEC Stack
TBD Variable Multicast MP2MP LDP FEC Stack TBD Variable Multicast MP2MP LDP FEC Stack
3.1.2.1. Multicast LDP FEC Stack Sub-TLVs 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs
Both Multicast P2MP and MP2MP LDP FEC Stack have the same format, as Both Multicast P2MP and MP2MP LDP FEC Stack have the same format, as
specified in the following figure. specified in the following figure.
skipping to change at page 12, line 39 skipping to change at page 12, line 17
Length of the Root LSR Address in octets. Length of the Root LSR Address in octets.
Root LSR Address Root LSR Address
Address of the LSR at the root of the P2MP LSP encoded according Address of the LSR at the root of the P2MP LSP encoded according
to the Address Family field. to the Address Family field.
Opaque Length Opaque Length
The length of the Opaque Value, in octets. The length of the Opaque Value, in octets. Depending on length of
the Root LSR Address, this field may not be aligned to a word
boundary.
Opaque Value Opaque Value
An opaque value element which uniquely identifies the P2MP LSP in An opaque value element which uniquely identifies the P2MP LSP in
the context of the Root LSR. the context of the Root LSR.
If the Address Family is IPv4, the Address Length MUST be 4. If the If the Address Family is IPv4, the Address Length MUST be 4. If the
Address Family is IPv6, the Address Length MUST be 16. No other Address Family is IPv6, the Address Length MUST be 16. No other
Address Family values are defined at present. Address Family values are defined at present.
skipping to change at page 25, line 29 skipping to change at page 25, line 25
7.2. New TLVs 7.2. New TLVs
Two new LSP Ping TLV types are defined for inclusion in LSP Ping Two new LSP Ping TLV types are defined for inclusion in LSP Ping
messages. messages.
IANA is requested to assign a new value from the "Multi-Protocol IANA is requested to assign a new value from the "Multi-Protocol
Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Label Switching Architecture (MPLS) Label Switched Paths (LSPs)
Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry as Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry as
follows using a Standards Action value. follows using a Standards Action value.
P2MP Responder Identifier TLV (see Section 3.2.4) is a mandatory P2MP Responder Identifier TLV (see Section 3.2) is a mandatory
TLV. Suggested value 11. Four sub-TLVs are defined. TLV. Suggested value 11. Four sub-TLVs are defined.
- Type 1: IPv4 Egress Address P2MP Responder Identifier - Type 1: IPv4 Egress Address P2MP Responder Identifier
- Type 2: IPv6 Egress Address P2MP Responder Identifier - Type 2: IPv6 Egress Address P2MP Responder Identifier
- Type 3: IPv4 Node Address P2MP Responder Identifier - Type 3: IPv4 Node Address P2MP Responder Identifier
- Type 4: IPv6 Node Address P2MP Responder Identifier - Type 4: IPv6 Node Address P2MP Responder Identifier
Echo Jitter TLV (see Section 3.2.5) is a mandatory TLV. Suggested Echo Jitter TLV (see Section 3.3) is a mandatory TLV. Suggested
value 12. value 12.
8. Security Considerations 8. Security Considerations
This document does not introduce security concerns over and above This document does not introduce security concerns over and above
those described in [RFC4379]. Note that because of the scalability those described in [RFC4379]. Note that because of the scalability
implications of many egresses to P2MP MPLS LSPs, there is a stronger implications of many egresses to P2MP MPLS LSPs, there is a stronger
concern to regulate the LSP Ping traffic passed to the control plane concern to regulate the LSP Ping traffic passed to the control plane
by the use of a rate limiter applied to the LSP Ping well-known UDP by the use of a rate limiter applied to the LSP Ping well-known UDP
port. Note that this rate limiting might lead to false positives. port. Note that this rate limiting might lead to false positives.
skipping to change at page 27, line 11 skipping to change at page 27, line 6
[P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for [P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for
point-to-multipoint extensions to the Label Distribution point-to-multipoint extensions to the Label Distribution
Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress. Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress.
[P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol [P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol
Extensions for Point-to-Multipoint and Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths", Multipoint-to-Multipoint Label Switched Paths",
draft-ietf-mpls-ldp-p2mp, work in progress. draft-ietf-mpls-ldp-p2mp, work in progress.
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding
Detection", draft-ietf-bfd-base, work in progress.
[MPLS-BFD] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., [MPLS-BFD] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G.,
"BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in "BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in
progress. progress.
[IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org [IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org
11. Authors' Addresses 11. Authors' Addresses
Seisho Yasukawa Seisho Yasukawa
NTT Corporation NTT Corporation
skipping to change at page 28, line 14 skipping to change at page 28, line 7
Email: tom.nadeau@bt.com Email: tom.nadeau@bt.com
Shaleen Saxena Shaleen Saxena
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
Email: ssaxena@cisco.com Email: ssaxena@cisco.com
12. Full Copyright Statement 12. Full Copyright Statement
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
 End of changes. 16 change blocks. 
84 lines changed or deleted 82 lines changed or added

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