draft-ietf-pce-dste-00.txt   draft-ietf-pce-dste-01.txt 
Network Working Group S. Sivabalan, Ed. Network Working Group S. Sivabalan, Ed.
Internet Draft J. Parker Internet Draft J. Parker
Intended status: Standards Track S. Boutros Intended status: Standards Track S. Boutros
Expires: April 15, 2008 Cisco Systems, Inc. Expires: November 23, 2008 Cisco Systems, Inc.
K. Kumaki K. Kumaki
KDDI Corporation KDDI Corporation
October 23, 2007 May 23, 2008
Diff-Serv Aware Class Type Object for Path Computation Element Diff-Serv Aware Class Type Object for
Communication Protocol Path Computation Element Communication Protocol
draft-ietf-pce-dste-00.txt draft-ietf-pce-dste-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
This document may not be modified, and derivative works of it Internet-Drafts are working documents of the Internet Engineering
may not be created, except to publish it as an RFC and to Task Force (IETF), its areas, and its working groups. Note that
translate it into languages other than English. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet- time. It is inappropriate to use Internet-Drafts as reference
Drafts as reference material or to cite them other than as "work material or to cite them other than as "work in progress."
in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 15, 2007. This Internet-Draft will expire on November 23, 2008.
Abstract Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document specifies a CLASSTYPE object to support Diff-Serve This document specifies a CLASSTYPE object to support Diff-Serve
Aware Traffic Engineering (DS-TE) where path computation is Aware Traffic Engineering (DS-TE) where path computation is performed
performed with an aid of Path Computation Element (PCE). with an aid of Path Computation Element (PCE).
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"OPTIONAL" in this document are to be interpreted as described document are to be interpreted as described in RFC-2119 Error!
in RFC-2119. Reference source not found..
Table of Contents Table of Contents
1. Introduction................................................2 1. Introduction...................................................2
2. Terminology.................................................3 2. Terminology....................................................3
3. CLASSTYPE object............................................3 3. CLASSTYPE Object...............................................4
3.1. Object definition.........................................4 3.1. Object Definition.........................................4
3.2. Path Computation Request Message with CLASSTYPE object....5 3.2. Path Computation Request message with CLASSTYPE Object....4
3.3. Handling of the CLASSTYPE object..........................5 3.3. Processing CLASSTYPE Object...............................5
3.4. Determination of Traffic Engineering Class (TE-Class).....6 3.4. Determination of Traffic Engineering Class (TE-Class).....6
3.5. Significance of Class-type and TE-Class...................6 3.5. Significance of Class-Type and TE-Class...................6
3.6. Error Codes for CLASSTYPE object..........................6 3.6. Error Codes for CLASSTYPE Object..........................6
4. Security Considerations.....................................7 4. Security Considerations........................................6
5. IANA Considerations.........................................7 5. IANA Considerations............................................7
6. Acknowledgments.............................................7 6. Acknowledgments................................................7
7. References..................................................7 6.1. Normative References......................................7
7.1. Normative References......................................7 6.2. Informative References....................................8
Author's Addresses.............................................8 Author's Addresses................................................8
Intellectual Property Statement................................9 Intellectual Property Statement...................................9
Disclaimer of Validity.........................................9 Disclaimer of Validity............................................9
1. Introduction 1. Introduction
The Internet Draft [PCEP-ID] specifies the Path Computation The Internet Draft [PCEP-ID] specifies the Path Computation Element
Element communication Protocol (PCEP) for communications between communication Protocol (PCEP) for communications between a Path
a Path Computation Client(PCC) and a Path Computation Element Computation Client (PCC) and a Path Computation Element (PCE), or
(PCE), or between two PCEs, in compliance with [RFC4657]. between two PCEs, in compliance with [RFC4657].
Differentiated Service aware MPLS Traffic Engineering (DS-TE) Differentiated Service aware MPLS Traffic Engineering (DS-TE)
addresses the fundamental requirement to be able to enforce addresses the fundamental requirement to be able to enforce different
different bandwidth constraints for different classes of traffic bandwidth constraints for different classes of traffic. It describes
and describes mechanisms to achieve per-class traffic mechanisms to achieve per-class traffic engineering, rather than on
engineering, rather than on an aggregate basis across all an aggregate basis across all classes by enforcing Bandwidth
classes by enforcing Bandwidth Constraints (BCs) on different Constraints (BCs) on different classes. Requirements for DS-TE and
classes. Requirements for DS-TE and the associated protocol the associated protocol extensions are specified in [RFC3564] and
extensions are specified in [RFC3564] and [RFC4124] [RFC4124] respectively.
respectively.
As per [RFC4657], PCEP must support traffic class-type as an As per [RFC4657], PCEP must support traffic class-type as an MPLS TE
MPLS TE specific constraint. However, in the present form, PCEP specific constraint. However, in the present form, PCEP [PCEP-ID]
[PCEP-ID] does not have the capability to specify the class-type does not have the capability to specify the class-type in the path
in the path computation request. computation request.
In this document, we define a new PCEP object called CLASSTYPE In this document, we define a new PCEP object called CLASSTYPE which
which carries the class-type of the TE LSP in the path carries the class-type of the TE LSP in the path computation request.
computation request. During path computation, a PCE uses the During path computation, a PCE uses the class-type to identify the
class-type to identify the bandwidth constraint of the TE-LSP. bandwidth constraint of the TE-LSP.
2. Terminology 2. Terminology
CT: Class type: A set of Traffic Trunks governed by a set of CT: Class type: A set of Traffic Trunks governed by a set of
bandwidth constraints. Used for the purpose of link bandwidth bandwidth constraints. Used for the purpose of link bandwidth
allocation, constraint based routing and admission control. A allocation, constraint based routing and admission control. A given
given Traffic Trunk belongs to the same CT on all links. Traffic Trunk belongs to the same CT on all links.
DS-TE: Diff-Serv Aware Traffic Engineering. DS-TE: Diff-Serv Aware Traffic Engineering.
LSR: Label Switching Router. LSR: Label Switching Router.
LSP: Label Switched Path. LSP: Label Switched Path.
PCC: Path Computation Client: any client application requesting PCC: Path Computation Client: any client application requesting a
a path computation to be performed by a Path Computation path computation to be performed by a Path Computation Element.
Element.
PCE: Path Computation Element: an entity (component, application PCE: Path Computation Element: an entity (component, application or
or network node) that is capable of computing a network path or network node) that is capable of computing a network path or route
route based on a network graph and applying computational based on a network graph and applying computational constraints.
constraints.
PCEP Peer: an element involved in a PCEP session (i.e. a PCC or PCEP Peer: an element involved in a PCEP session (i.e. a PCC or the
the PCE). PCE).
TE-Class: A pair consisting of a class-type and a preemption TE-Class: A pair consisting of a class-type and a preemption priority
priority allowed for that class type. An LSP transporting a allowed for that class type. An LSP transporting a Traffic Trunk from
Traffic Trunk from that class type can use that preemption that class type can use that preemption priority as the setup
priority as the setup priority, the holding priority, or both. priority, the holding priority, or both.
TE LSP: Traffic Engineering Label Switched Path. TE LSP: Traffic Engineering Label Switched Path.
Traffic Trunk: An aggregation of traffic flows of the same class Traffic Trunk: An aggregation of traffic flows of the same class
(i.e. treated equivalently from the DS-TE perspective) which is (i.e. treated equivalently from the DS-TE perspective) which is
placed inside a TE LSP. placed inside a TE LSP.
3. CLASSTYPE object 3. CLASSTYPE Object
The CLASSTYPE object is optional and is used to specify the The CLASSTYPE object is optional and is used to specify the class-
class-type of a TE LSP. This object is meaningful only within type of a TE LSP. This object is meaningful only within the path
the path computation request, and is ignored in the path reply computation request, and is ignored in the path reply message. If the
message. If the TE LSP for which path is to be computed belongs TE LSP for which the path is to be computed belongs to Class 0, the
to Class 0, the path computation request MUST not contain the path computation request MUST NOT contain the CLASSTYPE object. This
CLASSTYPE object. This allows backward compatibility with PCE allows backward compatibility with PCE that does not support the
that does not support CLASSTYPE object. CLASSTYPE object.
3.1. Object definition 3.1. Object Definition
The CLASSTYPE object contains a 32-bit word PCEP common object The CLASSTYPE object contains a 32-bit word PCEP common object header
header defined in [PCEP-ID] followed by another 32-bit word defined in [PCEP-ID] followed by another 32-bit word object body as
object body as shown in Figure 1. shown in Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | OT |Res|P|I| Object Length (bytes) | | PCEP common header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CT | | Reserved | CT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 CLASSTYPE object format. Figure 1 CLASSTYPE object format.
The fields in the object common header are processed as The fields in the object common header are processed as specified in
specified in [PCEP-ID]. We explain these fields again for [PCEP-ID]. The values of object class and object type are 22 and 1
completion. For more details, please refer to [PCEP-ID]. respectively. If included, CLASSTYPE object must be taken into
account by PCE. As such, the P flag MUST be set. I flag is ignored.
Object-Class is to be assigned by IANA (recommended value=16).
Object-Type (OT) is to be assigned by IANA (recommended
value=1).
Res flags (2 bits). Reserved field. This field MUST be set to
zero on transmission and MUST be ignored on receipt.
P flag (1 bit): When the P flag is set, the CLASSTYPE object
MUST be taken into account by the PCE. Conversely, when the P
flag is cleared, the object is optional and the PCE is free to
ignore it if not supported.
I flag (1 bit): The PCE MAY include the ignored optional object
in its reply and set the I flag to indicate that the optional
object was ignored during path computation.
Object Length (16 bits). Specifies the total object length
including the header, in bytes. The Object Length field MUST
always be a multiple of 4, and at least 4. The maximum object
content length is 65528 bytes.
The CLASSTYPE object body contains the following fields: The CLASSTYPE object body contains the following fields:
CT: 3-bit field that indicates the class-type. Values allowed CT: 3-bit field that indicates the class-type. Values allowed are 1,
are 1, 2, ... , 7. Value of 0 is Reserved. 2, ... , 7. Value of 0 is Reserved.
Reserved: 29-bit reserved field. It MUST be set to zero on Reserved: 29-bit reserved field. It MUST be set to zero on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
3.2. Path Computation Request Message with CLASSTYPE object 3.2. Path Computation Request message with CLASSTYPE Object
The draft [PCEP-ID] specifies the object orders in which objects [PCEP-ID] specifies the object orders in which objects must be
must be inserted in the PCEP messages. This document specifies inserted in the PCEP messages. This document specifies that the
that the CLASSTYPE object be inserted after the END-POINT CLASSTYPE object be inserted after the END-POINT objects as shown
objects as shown below: below:
The format of a PCReq message is as follows: The format of a PCReq message is as follows:
<PCReq Message>::= <Common Header> <PCReq Message>::= <Common Header>
[<SVEC-list>] [<SVEC-list>]
<request-list> <request-list>
where: where:
<svec-list>::=<SVEC>[<svec-list>] <svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>] <request-list>::=<request>[<request-list>]
<request>::= <RP> <request>::= <RP>
skipping to change at line 230 skipping to change at page 5, line 23
[<CLASSTYPE>] [<CLASSTYPE>]
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<RRO>] [<RRO>]
[<IRO>] [<IRO>]
[<LOAD-BALANCING>] [<LOAD-BALANCING>]
where: where:
<metric-list>::=<METRIC>[<metric-list>] <metric-list>::=<METRIC>[<metric-list>]
3.3. Handling of the CLASSTYPE object 3.3. Processing CLASSTYPE Object
If the LSP is associated with Class-Type N (1 <= N <= 7), the If the LSP is associated with Class-Type N (1 <= N <= 7), the PCC
PCC originating the path computation request MUST include the originating the path computation request MUST include the CLASSTYPE
CLASSTYPE object in the Path computation request message with object in the Path computation request message with the Class-Type
the Class-Type (CT) field set to N. (CT) field set to N.
If a path computation request contains multiple CLASSTYPE If a path computation request contains multiple CLASSTYPE objects,
objects, only the first one is meaningful; subsequent CLASSTYPE only the first one is meaningful; subsequent CLASSTYPE object(s) MUST
object(s) MUST be ignored and MUST NOT be forwarded. be ignored and MUST NOT be forwarded.
If the CLASSTYPE object is not present in the path computation If the CLASSTYPE object is not present in the path computation
request message, the LSR MUST associate the Class-Type 0 to the request message, the LSR MUST associate the Class-Type 0 to the LSP.
LSP.
Path computation reply message MUST NOT include a CLASSTYPE Path computation reply message MUST NOT include a CLASSTYPE object.
object. If a PCE needs to forward a path computation request If a PCE needs to forward a path computation request containing the
containing the CLASSTYPE object to another PCE, it MUST store CLASSTYPE object to another PCE, it MUST store the class-type of the
the class-type of the TE LSP in order to complete the path TE LSP in order to complete the path computation when the path
computation when the path computation reply arrives. computation reply arrives.
A PCE receiving a path computation request message with the A PCE that does not recognize the CLASSTYPE object MUST reject the
CLASSTYPE object with P flag set that does not recognize the entire PCEP message and MUST send a PCE error message with Error-
CLASSTYPE object MUST reject the entire PCEP message and MUST Type="Unknown Object" or "Not supported Object" defined in [PCEP-ID].
send a PCE error message with Error-Type="Unknown Object" or
"Not supported Object" defined in [PCEP-ID].
A PCE receiving a path computation request message with the A PCE that recognizes the CLASSTYPE object finds that P flag is not
CLASSTYPE object that recognizes the CLASSTYPE object, but set in the CLASSTYPE object, it MUST send PCE error message towards
does not support the particular Class-Type, MUST send a PCE the sender with the with the error type and error value specified in
error message towards the sender with the error type "Diff-Serv [PCEP-ID].
aware TE Error" and an error value of "Unsupported Class-Type"
(new error code provided below).
A PCE receiving a path computation request message with the A PCE that recognizes the CLASSTYPE object, but does not support the
CLASSTYPE object that recognizes the CLASSTYPE object, but particular Class-Type, MUST send a PCE error message towards the
determines that the Class-Type value is not valid (i.e., Class sender with the error type "Diff-Serv aware TE Error" and the error
Type value 0), MUST send a PCE error towards the sender with the value of "Unsupported Class-Type" (new error code provided below).
error type "Diff-Serve aware TE Error" and an error value of
"Invalid Class-Type value" (new error code provided below). A PCE that recognizes the CLASSTYPE object, but determines that the
Class-Type value is not valid (i.e., Class Type value 0), MUST send a
PCE error towards the sender with the error type "Diff-Serve aware TE
Error" and an error value of "Invalid Class-Type value" (new error
code provided below).
3.4. Determination of Traffic Engineering Class (TE-Class) 3.4. Determination of Traffic Engineering Class (TE-Class)
As specified in RFC4124, a CT and a Preemption priority map to a As specified in RFC4124, a CT and a Preemption priority map to a
Traffic Engineering Class (TE-Class), and there can be up to 8 Traffic Engineering Class (TE-Class), and there can be up to 8 TE-
TE-classes. The TE-class value is used to determine the classes. The TE-class value is used to determine the unreserved
unreserved bandwidth on the links during path computation. In bandwidth on the links during path computation. In the case of a PCE,
the case of a PCE, the CT value carried in the CLASSTYPE object the CT value carried in the CLASSTYPE object and the setup priority
and the setup priority in the LSP Attribute (LSPA) object are in the LSP Attribute (LSPA) object are used to determine the TE-class
used to determine the TE-class corresponding to the path corresponding to the path computation request. If LSPA object is
computation request. If LSPA object is absent, the setup absent, the setup priority is assumed to be 0.
priority is assumed to be 0.
3.5. Significance of Class-type and TE-Class 3.5. Significance of Class-Type and TE-Class
To ensure coherent DS-TE operation, a PCE and a PCC should have To ensure coherent DS-TE operation, a PCE and a PCC should have a
a common understanding of a particular DS-TE classtype and TE- common understanding of a particular DS-TE classtype and TE-Class.
Class. If a path computation request crosses an AS boundary, If a path computation request crosses an AS boundary, these should
these should have global significance in all domains. have global significance in all domains. Enforcement of this global
Enforcement of this global significance is outside the scope of significance is outside the scope of this document.
this document.
3.6. Error Codes for CLASSTYPE object 3.6. Error Codes for CLASSTYPE Object
This document defines the following error type and values: This document defines the following error type and values:
Error-Type Meaning Error-Type Meaning
11 Diff-Serve aware TE Error
12 Diff-Serve aware TE Error
Error-value=1: unsupported class-type. Error-value=1: unsupported class-type.
Error-value=2: invalid class-type. Error-value=2: invalid class-type.
Error-value=3: class-type and setup priority does Error-value=3: class-type and setup priority does not
not
form a configured TE class. form a configured TE class.
4. Security Considerations 4. Security Considerations
This document does not introduce new security issues. The This document does not introduce new security issues. The security
security considerations pertaining to PCEP [PCEP-ID] remain considerations pertaining to PCEP [PCEP-ID] remain relevant.
relevant.
5. IANA Considerations 5. IANA Considerations
IANA assigns value to PCEP parameters. Each PCEP object has an IANA maintains a registry of parameters for PCEP. This contains a
Object-Class and an Object-Type. For the CLASSTYPE object, the sub-registry for PCEP objects. IANA is requested to make new
suggested values for Object-Class and Object-Type are 16 and 1 allocation from this registry as follows:
respectively.
6. Acknowledgments Object-Class Name Reference
The authors would like to thank Jean Philippe Vasseur for his 22 CLASSTYPE draft-ietf-pce-dste-01.txt
valuable comments.
7. References Object-Type
7.1. Normative References 1: Class Type draft-ietf-pce-dste-01.txt
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate IANA is requested to make new allocation for error types and values
Requirement Levels", BCP 14, RFC 2119, March 1997. as follows:
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T.,Srinivasan, Error-Type Meaning Reference
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001. 12 Diff-Serv aware TE error draft-ietf-pce-dste-01.txt
Error-value = 1: draft-ietf-pce-dste-01.txt
Unsupported class-type
Error-value = 2: draft-ietf-pce-dste-01.txt
Invalid class-type
Error-value = 3: draft-ietf-pce-dste-01.txt
Class type and setup priority
does not form a configured TE class
6. Acknowledgments
The authors would like to thank Jean Philippe Vasseur, Adrian
Farrel and Zafar Ali for their valuable comments.
References
6.1. Normative References
[RFC4124]Le Faucheur, F. and W. Lai, "Protocol Extensions for [RFC4124]Le Faucheur, F. and W. Lai, "Protocol Extensions for
Support of Diffserv-aware MPLS Traffic Engineering", Support of Diffserv-aware MPLS Traffic Engineering", RFC
RFC 4124, June 2005. 4124, June 2005.
[PCEP-ID] Path Computation Element (PCE) communication Protocol [PCEP-ID] Path Computation Element (PCE) communication Protocol
(PCEP)", draft-ietf-pce-pcep-08.txt (work in (PCEP)", draft-ietf-pce-pcep-12.txt (work in progress),
progress), February 2007. September 2008.
7.2. Informative References 6.2. Informative References
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
(PCE) Communication Protocol Generic Requirements", Communication Protocol Generic Requirements", RFC 4657,
RFC 4657, September 2006. September 2006.
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of
of Differentiated Services-aware MPLS Traffic Differentiated Services-aware MPLS Traffic Engineering",
Engineering", RFC 3564, July 2003. RFC 3564, July 2003.
Author's Addresses Author's Addresses
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario, K2K 3E8 Kanata, Ontario, K2K 3E8
Canada Canada
Email: msiva@cisco.com Email: msiva@cisco.com
skipping to change at line 371 skipping to change at page 8, line 39
Jon Parker Jon Parker
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario, K2K 3E8 Kanata, Ontario, K2K 3E8
Canada Canada
Email: jdparker@cisco.com Email: jdparker@cisco.com
Sami Boutros Sami Boutros
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 3750 Cisco Way
Kanata, Ontario, K2K 3E8 San Jose, California 95134
Canada USA
Email: sboutros@cisco.com Email: sboutros@cisco.com
Kenji Kumaki Kenji Kumaki
KDDI Corporation KDDI Corporation
Garden Air Tower Iidabashi, Chiyoda-ku Garden Air Tower Iidabashi, Chiyoda-ku
Tokyo, 102-8460 Tokyo, 102-8460
Japan Japan
Email: ke-kumaki@kddi.com Email: ke-kumaki@kddi.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of The IETF takes no position regarding the validity or scope of any
any Intellectual Property Rights or other rights that might be Intellectual Property Rights or other rights that might be claimed to
claimed to pertain to the implementation or use of the pertain to the implementation or use of the technology described in
technology described in this document or the extent to which any this document or the extent to which any license under such rights
license under such rights might or might not be available; nor might or might not be available; nor does it represent that it has
does it represent that it has made any independent effort to made any independent effort to identify any such rights. Information
identify any such rights. Information on the procedures with on the procedures with respect to rights in RFC documents can be
respect to rights in RFC documents can be found in BCP 78 and found in BCP 78 and BCP 79.
BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the attempt made to obtain a general license or permission for the use of
use of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR specification can be obtained from the IETF on-line IPR repository at
repository at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention any
any copyrights, patents or patent applications, or other copyrights, patents or patent applications, or other proprietary
proprietary rights that may cover technology that may be rights that may cover technology that may be required to implement
required to implement this standard. Please address the this standard. Please address the information to the IETF at
information to the IETF at ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided This document and the information contained herein are provided on an
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 65 change blocks. 
233 lines changed or deleted 221 lines changed or added

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