draft-ietf-pce-dste-02.txt   rfc5455.txt 
Network Working Group S. Sivabalan, Ed. Network Working Group S. Sivabalan, Ed.
Internet Draft J. Parker Request for Comments: 5455 J. Parker
Intended status: Standards Track S. Boutros Category: Standards Track S. Boutros
Expires: May 2, 2009 Cisco Systems, Inc. Cisco Systems, Inc.
K. Kumaki K. Kumaki
KDDI Corporation KDDI R&D Laboratories, Inc.
November 3, 2008
Diff-Serv Aware Class Type Object for
Path Computation Element Communication Protocol
draft-ietf-pce-dste-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
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
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
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 months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Diffserv-Aware Class-Type Object for
http://www.ietf.org/ietf/1id-abstracts.txt the Path Computation Element Communication Protocol
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 2, 2009. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Abstract This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document specifies a CLASSTYPE object to support Diff-Serve This document may contain material from IETF Documents or IETF
Aware Traffic Engineering (DS-TE) where path computation is performed Contributions published or made publicly available before November
with an aid of Path Computation Element (PCE). 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Conventions used in this document Abstract
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document specifies a CLASSTYPE object to support Diffserv-Aware
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Traffic Engineering (DS-TE) where path computation is performed with
document are to be interpreted as described in RFC-2119 Error! the aid of a Path Computation Element (PCE).
Reference source not found..
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction ....................................................2
2. Terminology....................................................3 1.1. Conventions Used in This Document ..........................3
3. CLASSTYPE Object...............................................4 2. Terminology .....................................................3
3.1. Object Definition.........................................4 3. CLASSTYPE Object ................................................3
3.2. Path Computation Request message with CLASSTYPE Object....4 3.1. Object Definition ..........................................4
3.3. Processing CLASSTYPE Object...............................5 3.2. Path Computation Request Message with CLASSTYPE Object .....4
3.4. Determination of Traffic Engineering Class (TE-Class).....6 3.3. Processing CLASSTYPE Object ................................5
3.5. Significance of Class-Type and TE-Class...................6 3.4. Determination of Traffic Engineering Class (TE-Class) ......6
3.6. Error Codes for CLASSTYPE Object..........................6 3.5. Significance of Class-Type and TE-Class ....................6
4. Security Considerations........................................7 3.6. Error Codes for CLASSTYPE Object ...........................6
5. IANA Considerations............................................7 4. Security Considerations .........................................7
6. Acknowledgments................................................7 5. IANA Considerations .............................................7
6.1. Normative References......................................8 6. Acknowledgments .................................................7
6.2. Informative References....................................8 7. References ......................................................8
Author's Addresses................................................8 7.1. Normative References .......................................8
Intellectual Property Statement...................................9 7.2. Informative References .....................................8
Disclaimer of Validity............................................9
1. Introduction 1. Introduction
The Internet Draft [PCEP-ID] specifies the Path Computation Element [RFC5440] specifies the Path Computation Element Communication
communication Protocol (PCEP) for communications between a Path Protocol (PCEP) for communications between a Path Computation Client
Computation Client (PCC) and a Path Computation Element (PCE), or (PCC) and a Path Computation Element (PCE), or between two PCEs, in
between two PCEs, in compliance with [RFC4657]. compliance with [RFC4657].
Differentiated Service aware MPLS Traffic Engineering (DS-TE) Diffserv-aware MPLS Traffic Engineering (DS-TE) addresses the
addresses the fundamental requirement to be able to enforce different fundamental requirement to be able to enforce different bandwidth
bandwidth constraints for different classes of traffic. It describes constraints for different classes of traffic. It describes
mechanisms to achieve per-class traffic engineering, rather than on mechanisms to achieve per-class traffic engineering, rather than on
an aggregate basis across all classes by enforcing Bandwidth an aggregate basis across all classes by enforcing Bandwidth
Constraints (BCs) on different classes. Requirements for DS-TE and Constraints (BCs) on different classes. Requirements for DS-TE and
the associated protocol extensions are specified in [RFC3564] and the associated protocol extensions are specified in [RFC3564] and
[RFC4124] respectively. [RFC4124], respectively.
As per [RFC4657], PCEP must support traffic class-type as an MPLS TE As per [RFC4657], PCEP must support traffic Class-Type as an MPLS-
specific constraint. However, in the present form, PCEP [PCEP-ID] TE-specific constraint. However, in the present form, PCEP [RFC5440]
does not have the capability to specify the class-type in the path does not have the capability to specify the Class-Type in the path
computation request. computation request.
In this document, we define a new PCEP object called CLASSTYPE which In this document, we define a new PCEP object called CLASSTYPE, which
carries the class-type of the TE LSP in the path computation request. carries the Class-Type of the TE LSP in the path computation request.
During path computation, a PCE uses the class-type to identify the During path computation, a PCE uses the Class-Type to identify the
bandwidth constraint of the TE-LSP. bandwidth constraint of the TE LSP.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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 given allocation, constraint-based routing and admission control. A 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: Diffserv-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 a PCC (Path Computation Client): any client application requesting a
path computation to be performed by a Path Computation Element. path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: an entity (component, application or PCE (Path Computation Element): an entity (component, application, or
network node) that is capable of computing a network path or route network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints. based on a network graph and applying computational constraints.
PCEP Peer: an element involved in a PCEP session (i.e. a PCC or the PCEP Peer: an element involved in a PCEP session (i.e., a PCC or the
PCE). PCE).
TE-Class: A pair consisting of a class-type and a preemption priority TE-Class: A pair consisting of a Class-Type and a preemption priority
allowed for that class type. An LSP transporting a Traffic Trunk from allowed for that Class-Type. An LSP transporting a Traffic Trunk
that class type can use that preemption priority as the setup from that Class-Type can use that preemption 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 class- The CLASSTYPE object is optional and is used to specify the Class-
type of a TE LSP. This object is meaningful only within the path Type of a TE LSP. This object is meaningful only within the path
computation request, and is ignored in the path reply message. If the computation request, and is ignored in the path reply message. If
TE LSP for which the path is to be computed belongs to Class 0, the the TE LSP for which the path is to be computed belongs to Class 0,
the
path computation request MUST NOT contain the CLASSTYPE object. This path computation request MUST NOT contain the CLASSTYPE object. This
allows backward compatibility with PCE that does not support the allows backward compatibility with a PCE that does not support the
CLASSTYPE object. CLASSTYPE object.
3.1. Object Definition 3.1. Object Definition
The CLASSTYPE object contains a 32-bit word PCEP common object header The CLASSTYPE object contains a 32-bit word PCEP common object header
defined in [PCEP-ID] followed by another 32-bit word object body as defined in [RFC5440] followed by another 32-bit word 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCEP common header | | 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 specified in The fields in the common object header are processed as specified in
[PCEP-ID]. The values of object class and object type are 22 and 1 [RFC5440]. The values of object class and object type are 22 and 1,
respectively. If included, CLASSTYPE object must be taken into respectively. If included, the CLASSTYPE object must be taken into
account by PCE. As such, the P flag MUST be set. I flag is ignored. account by the PCE. As such, the P flag MUST be set. The I flag is
ignored.
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 are 1, CT: 3-bit field that indicates the Class-Type. Values allowed are 1,
2, ... , 7. Value of 0 is Reserved. 2, ... , 7. The 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
[PCEP-ID] specifies the object orders in which objects must be [RFC5440] specifies the order in which objects must be inserted in
inserted in the PCEP messages. This document specifies that the the PCEP messages. This document specifies that the CLASSTYPE object
CLASSTYPE object be inserted after the END-POINT objects as shown be inserted after the END-POINT objects as shown below:
below:
The format of a PCReq message is as follows: The format of a Path Computation Request (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>
<END-POINTS> <END-POINTS>
[<CLASSTYPE>] [<CLASSTYPE>]
skipping to change at page 5, line 25 skipping to change at page 5, line 28
[<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>]
Note that an implementation MUST form the PCEP messages using the Note that an implementation MUST form the PCEP messages using the
object ordering rules specified using Backus-Naur Form. Please refer object ordering rules specified using Backus-Naur Form. Please refer
[OBJ-ORD] for more details. to [OBJ-ORD] for more details.
3.3. Processing CLASSTYPE Object 3.3. Processing CLASSTYPE Object
If the LSP is associated with Class-Type N (1 <= N <= 7), the PCC If the LSP is associated with Class-Type N (1 <= N <= 7), the PCC
originating the path computation request MUST include the CLASSTYPE originating the PCReq MUST include the CLASSTYPE object in the PCReq
object in the Path computation request message with the Class-Type message with the Class-Type (CT) field set to N.
(CT) field set to N.
If a path computation request contains multiple CLASSTYPE objects, If a path computation request contains multiple CLASSTYPE objects,
only the first one is meaningful; subsequent CLASSTYPE object(s) MUST only the first one is meaningful; subsequent CLASSTYPE 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 LSP. request message, the LSR MUST associate the Class-Type 0 to the LSP.
Path computation reply message MUST NOT include a CLASSTYPE object. A path computation reply message MUST NOT include a CLASSTYPE object.
If a PCE needs to forward a path computation request containing the If a PCE needs to forward a path computation request containing the
CLASSTYPE object to another PCE, it MUST store the class-type of the CLASSTYPE object to another PCE, it MUST store the Class-Type of the
TE LSP in order to complete the path computation when the path TE LSP in order to complete the path computation when the path
computation reply arrives. computation reply arrives.
A PCE that does not recognize the CLASSTYPE object MUST reject the A PCE that does not recognize the CLASSTYPE object MUST reject the
entire PCEP message and MUST send a PCE error message with Error- entire PCEP message and MUST send a PCE error message with Error-
Type="Unknown Object" or "Not supported Object" defined in [PCEP-ID]. Type="Unknown Object" or "Not supported object", defined in
[RFC5440].
A PCE that recognizes the CLASSTYPE object finds that P flag is not A PCE that recognizes the CLASSTYPE object, but finds that the P flag
set in the CLASSTYPE object, it MUST send PCE error message towards is not set in the CLASSTYPE object, MUST send PCE error message
the sender with the with the error type and error value specified in towards the sender with the error type and error value specified in
[PCEP-ID]. [RFC5440].
A PCE that recognizes the CLASSTYPE object, but does not support the A PCE that recognizes the CLASSTYPE object, but does not support the
particular Class-Type, MUST send a PCE error message towards the particular Class-Type, MUST send a PCE error message towards the
sender with the error type "Diff-Serv aware TE Error" and the error sender with the error type "Diffserv-aware TE error" and the error
value of "Unsupported Class-Type" (new error code provided below). value of "Unsupported Class-Type" (Error-value 1).
A PCE that recognizes the CLASSTYPE object, but determines that the 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 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 PCE error towards the sender with the error type "Diffserv-aware TE
Error" and an error value of "Invalid Class-Type value" (new error error" and an error value of "Invalid Class-Type" (Error-value 2).
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 RFC 4124, a CT and a preemption priority map to a
Traffic Engineering Class (TE-Class), and there can be up to 8 TE- Traffic Engineering Class (TE-class), and there can be up to 8
classes. The TE-class value is used to determine the unreserved TE-classes. The TE-class value is used to determine the unreserved
bandwidth on the links during path computation. In the case of a PCE, bandwidth on the links during path computation. In the case of a
the CT value carried in the CLASSTYPE object and the setup priority PCE, the CT value carried in the CLASSTYPE object and the setup
in the LSP Attribute (LSPA) object are used to determine the TE-class priority in the LSP Attribute (LSPA) object are used to determine the
corresponding to the path computation request. If LSPA object is TE-class corresponding to the path computation request. If the LSPA
absent, the setup priority is assumed to be 0. object is absent, the setup 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 a To ensure coherent DS-TE operation, a PCE and a PCC should have a
common understanding of a particular DS-TE classtype and TE-Class. common understanding of a particular DS-TE Class-Type and TE-class.
If a path computation request crosses an AS boundary, these should If a path computation request crosses an Autonomous System (AS)
have global significance in all domains. Enforcement of this global boundary, these should have global significance in all domains.
significance is outside the scope of this document. Enforcement of this global significance is outside the scope of 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
12 Diff-Serve aware TE Error 12 Diffserv-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 not Error-value=3: Class-Type and setup priority do
form a configured TE class. not form a configured TE-class
4. Security Considerations 4. Security Considerations
This document does not introduce new security issues. The security This document does not introduce new security issues. The security
considerations pertaining to PCEP [PCEP-ID] remain relevant. considerations pertaining to PCEP [RFC5440] remain relevant.
5. IANA Considerations 5. IANA Considerations
IANA maintains a registry of parameters for PCEP. This contains a IANA maintains a registry of parameters for PCEP. This contains a
sub-registry for PCEP objects. IANA is requested to make new sub-registry for PCEP objects. IANA has made allocations from this
allocation from this registry as follows: registry as follows:
Object-Class Name Reference Object-Class Name Reference
22 CLASSTYPE draft-ietf-pce-dste-02.txt 22 CLASSTYPE RFC 5455
Object-Type Object-Type
1: Class Type draft-ietf-pce-dste-02.txt 1: Class-Type RFC 5455
IANA is requested to make new allocation for error types and values IANA has allocated error types and values as follows:
as follows:
Error-Type Meaning Reference Error-Type Meaning Reference
12 Diff-Serv aware TE error draft-ietf-pce-dste-02.txt 12 Diffserv-aware TE error RFC 5455
Error-value = 1: draft-ietf-pce-dste-02.txt
Unsupported class-type Error-value = 1: RFC 5455
Error-value = 2: draft-ietf-pce-dste-02.txt Unsupported Class-Type
Invalid class-type Error-value = 2: RFC 5455
Error-value = 3: draft-ietf-pce-dste-02.txt Invalid Class-Type
Class type and setup priority Error-value = 3: RFC 5455
does not form a configured TE class Class-Type and setup priority
do not form a configured TE-class
6. Acknowledgments 6. Acknowledgments
The authors would like to thank Jean Philippe Vasseur, Adrian The authors would like to thank Jean Philippe Vasseur, Adrian Farrel,
Farrel and Zafar Ali for their valuable comments. and Zafar Ali for their valuable comments.
References 7. References
6.1. Normative References 7.1. Normative References
[RFC4124] Le Faucheur, F. and W. Lai, "Protocol Extensions for [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Support of Diffserv-aware MPLS Traffic Engineering", RFC Requirement Levels", BCP 14, RFC 2119, March 1997.
4124, June 2005.
[PCEP-ID] Path Computation Element (PCE) communication Protocol [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of
(PCEP)", draft-ietf-pce-pcep-18.txt (work in progress), Diffserv-aware MPLS Traffic Engineering", RFC 4124, June
November 2008. 2005.
6.2. Informative References [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 7.2. Informative References
Communication Protocol Generic Requirements", RFC 4657,
September 2006. [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic Requirements",
RFC 4657, September 2006.
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineering", Differentiated Services-aware MPLS Traffic Engineering",
RFC 3564, July 2003. RFC 3564, July 2003.
[OBJ-ORD] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used [OBJ-ORD] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used
in Various Protocol Specifications", draft-farrel-rtg- in Various Protocol Specifications", Work in Progress,
common-bnf-07.txt, November 2008. November 2008.
Author's Addresses Authors' Addresses
Siva Sivabalan Siva Sivabalan (editor)
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
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.
3750 Cisco Way 3750 Cisco Way
San Jose, California 95134 San Jose, California 95134
USA USA
Email: sboutros@cisco.com EMail: sboutros@cisco.com
Kenji Kumaki Kenji Kumaki
KDDI Corporation KDDI R&D Laboratories, Inc.
Garden Air Tower Iidabashi, Chiyoda-ku 2-1-15 Ohara Fujimino
Tokyo, 102-8460 Saitama 356-8502, JAPAN
Japan
Email: ke-kumaki@kddi.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the EMail: ke-kumaki@kddi.com
Internet Society.
 End of changes. 71 change blocks. 
225 lines changed or deleted 178 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/