draft-ietf-pce-gmpls-aps-req-00.txt   draft-ietf-pce-gmpls-aps-req-01.txt 
Network Working Group Tomohiro Otani
INTERNET-DRAFT Tomohiro Otani Internet-Draft KDDI
Intended status: Informational Kenichi Ogaki Intended status: Informational Kenichi Ogaki
Expires:March 2009 KDDI R&D Labs Expires: January, 2010 KDDI R&D Labs
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Sept 17, 2008 Fatai Zhang
Huawei
July 8, 2009
Requirements for GMPLS applications of PCE Requirements for GMPLS applications of PCE
Document: draft-ietf-pce-gmpls-aps-req-00.txt Document: draft-ietf-pce-gmpls-aps-req-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 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 Internet-Drafts. other groups may also distribute working documents as Internet-Drafts.
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."
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Abstract Abstract
The initial effort of PCE WG is specifically focused on MPLS (Multi- The initial effort of PCE WG is specifically focused on MPLS (Multi-
protocol label switching). As a next step, this draft describes protocol label switching). As a next step, this draft describes
functional requirements for GMPLS (Generalized MPLS) application of functional requirements for GMPLS (Generalized MPLS) application of
PCE (Path computation element). PCE (Path computation element).
Table of Contents Table of Contents
Status of this Memo................................................ 1 Status of this Memo..............................................1
Abstract........................................................... 1 Abstract.........................................................1
1. Introduction.................................................... 3 1. Introduction..................................................3
2. Conventions used in this document............................... 3 2. Conventions used in this document.............................3
3. GMPLS applications of PCE....................................... 3 3. GMPLS applications of PCE.....................................3
4. Requirement for GMPLS application of PCE........................ 4 4. Requirement for GMPLS application of PCE......................5
5. Security consideration.......................................... 5 5. Security consideration........................................6
6. IANA Considerations............................................. 5 6. IANA Considerations...........................................7
7. Acknowledgement................................................. 5 7. Acknowledgement...............................................7
8. Intellectual property considerations............................ 5 8. Intellectual Property.........................................7
9. Informative references.......................................... 6 9. Informative references........................................8
Author's Addresses................................................. 7 Author's Addresses...............................................9
Document expiration................................................ 7 Full Copyright statement.........................................9
Copyright statement................................................ 7
1. Introduction 1. Introduction
The initial effort of PCE WG is focused on solving the path The initial effort of PCE WG is focused on solving the path
computation problem over domains in MPLS networks. As the same case computation problem over different domains in MPLS networks. As the
with MPLS, service providers (SPs) have also come up with same case with MPLS, service providers (SPs) have also come up with
requirements for path computation in GMPLS networks such as photonics, requirements for path computation in GMPLS networks such as photonics,
TDM-based or Ethernet-based networks as well. TDM-based or Ethernet-based networks as well.
[PCE-ARCH] and [PCECP-REQ] discuss the framework and requirements for [PCE-ARCH] and [PCECP-REQ] discuss the framework and requirements for
PCE on both packet MPLS networks and (non-packet switch capable) PCE on both packet MPLS networks and (non-packet switch capable)
GMPLS networks. This document complements these documents by GMPLS networks. This document complements these documents by
providing some consideration of GMPLS applications in the inter- providing some consideration of GMPLS applications in the intra-
domain networking environment and indicating a set of requirements domain and inter-domain networking environments and indicating a set
for the extended definition of series of PCE related protocols. of requirements for the extended definition of series of PCE related
protocols.
Constraint based shortest path first (CSPF) computation within a Constraint based shortest path first (CSPF) computation within a
domain or over domains for signaling GMPLS Label Switched Paths domain or over domains for signaling GMPLS Label Switched Paths
(LSPs) is more stringent than that of MPLS LSPs [MPLS-AS], because (LSPs) is more stringent than that of MPLS LSPs [MPLS-AS], because
the additional constraints, e.g., interface switching capability, the additional constraints, e.g., interface switching capability,
link encoding, link protection capability and so forth need to be link encoding, link protection capability and so forth need to be
considered to establish GMPLS LSPs [CSPF]. GMPLS signaling protocol considered to establish GMPLS LSPs [CSPF]. GMPLS signaling protocol
[RFC3471, RFC3473] is designed taking into account bi-directionality, [RFC3471, RFC3473] is designed taking into account bi-directionality,
switching type, encoding type, SRLG, and protection attributes of the switching type, encoding type, SRLG, and protection attributes of the
TE links spanned by the path, as well as LSP encoding type and TE links spanned by the path, as well as LSP encoding and switching
switching type for the end points, appropriately. type for the end points, appropriately.
This document provides the investigated results of GMPLS applications This document provides the investigated results of GMPLS applications
of PCE especially for the support of GMPLS inter-domain path of PCE for the support of GMPLS path computation. This document also
computation. This document also outlines GMPLS inter-domain provides requirements for GMPLS applications of PCE in the GMPLS
architecture, and provides requirements for GMPLS applications of PCE intra-domain and inter-domain environments.
in the GMPLS inter-domain environment.
2. Conventions used in this document 2. 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].
3. GMPLS applications of PCE 3. GMPLS applications of PCE
3.1 GMPLS network model 3.1 GMPLS network model
skipping to change at page 4, line 14 skipping to change at page 4, line 19
|GMPLS D1| | |GMPLS D4|---|GMPLS D5| |GMPLS D1| | |GMPLS D4|---|GMPLS D5|
+----+----+ | +----+----+ +---------+ +----+----+ | +----+----+ +---------+
| +----+----+ | | +----+----+ |
+---------|GMPLS D3|----------+ +---------|GMPLS D3|----------+
+---------+ +---------+
Figure 1: GMPLS Inter-domain network model. Figure 1: GMPLS Inter-domain network model.
Each domain is configured using various switching and link Each domain is configured using various switching and link
technologies defined in [Arch] and an end-to-end route needs to technologies defined in [Arch] and an end-to-end route needs to
respect TE link attributes like multiplexing type, encoding type, respect TE link attributes like switching capability, encoding type,
etc., making the problem a bit different from the case of classical etc., making the problem a bit different from the case of classical
(packet) MPLS. In order to route from one GMPLS domain to another (packet) MPLS. In order to route from one GMPLS domain to another
GMPLS domain appropriately, each domain manages traffic engineering GMPLS domain appropriately, each domain manages traffic engineering
database (TED) by PCE, and exchanges or provides route information of database (TED) by PCE, and exchanges or provides route information of
paths, while concealing its internal topology information. paths, while concealing its internal topology information.
3.2 Path computation in GMPLS network 3.2 Path computation in GMPLS network
[CSPF] describes consideration of GMPLS TE attributes during path [CSPF] describes consideration of GMPLS TE attributes during path
computation. computation.
skipping to change at page 4, line 38 skipping to change at page 4, line 43
|Node1|------------>|Node2|------------>|Node3|------------>|Node4| |Node1|------------>|Node2|------------>|Node3|------------>|Node4|
| |<------------| |<------------| |<------------| | | |<------------| |<------------| |<------------| |
+-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+ +-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+
Figure 2: Path computation in GMPLS networks. Figure 2: Path computation in GMPLS networks.
For the simplicity in consideration, the below basic assumptions are For the simplicity in consideration, the below basic assumptions are
made when the LSP is created. made when the LSP is created.
(1) Switching capabilities of outgoing links from the ingress (1) Switching capabilities of outgoing links from the ingress
and egress nodes (link1-2 and link4-3 in Figure .) must be and egress nodes (link1-2 and link4-3 in Figure 2) must be
consistent with each other. consistent with each other.
(2) SC of all transit links including incoming links to the (2) Switching capabilities of all transit links including
ingress and egress nodes (link2-1 and link3-4) should be incoming links to the ingress and egress nodes (link2-1 and
consistent with switching type of a LSP to be created. link3-4) should be consistent with switching type of a LSP
to be created.
(3) Encoding-types of all transit links should be consistent (3) Encoding-types of all transit links should be consistent
with encoding type of a LSP to be created. with encoding type of a LSP to be created.
[CSPF] indicates the possible table of switching capability, encoding [CSPF] indicates the possible table of switching capability, encoding
type and bandwidth at the ingress link, transiting links and the type and bandwidth at the ingress link, transiting links and the
egress link which need to be satisfied with the created LSP. egress link which need to be satisfied with the created LSP.
The non-packet GMPLS networks (e.g., TDM networks) are usually
responsible for transmitting data for the client layer. These GMPLS
networks can provide different types of connections for customer
services based on different service bandwidth requests.
The applications and the corresponding additional requirements for
applying PCE in non-packet networks, for example, GMPLS-based TDM
networks, are described in Figure 3. In order to simplify the
description, this document just discusses the scenario in SDH
networks as an example. The scenarios in SONET or G.709 ODUk layer
networks are similar.
N1 N2
+-----+ +------+ +------+
| |-------| |--------------| | +-------+
+-----+ | |---| | | | |
A1 +------+ | +------+ | |
| | | +-------+
| | | PCE
| | |
| +------+ |
| | | |
| | |-----| |
| +------+ | |
| N5 | |
| | |
+------+ +------+
| | | | +-----+
| |--------------| |--------| |
+------+ +------+ +-----+
N3 N4 A2
Figure 3: A simple SDH network
Figure 3 shows a simple network topology, where N1, N2, N3, N4, and
N5 are all SDH switches. Assume that one Ethernet service with 100M
bandwidth is required from A1 to A2 over this network. The client
Ethernet service could be provided by a VC4 connection from N1 to N4,
and it could also be provided by three concatenated VC3 connections
(Contiguous or Virtual concatenation) from N1 to N4.
The type of connection(s) (one VC4 or three concatenated VC3) that is
required needs to be specified by PCC (e.g., N1 or NMS), but could
also be determined by PCE automatically based on policy [RFC5394].
Therefore, the signal type, the type of the concatenation and the
number of the concatenation should also be considered during path
computation for PCE.
4. Requirement for GMPLS application of PCE 4. Requirement for GMPLS application of PCE
In this section, we describe requirements for GMPLS applications of In this section, we describe requirements for GMPLS applications of
PCE in order to establish GMPLS LSP over domains. PCE in order to establish GMPLS LSP.
4.1 PCE requirements 4.1 PCE requirements
As for path computation in GMPLS networks as discussed in section 3, As for path computation in GMPLS networks as discussed in section 3,
the PCE needs to consider the GMPLS TE attributes appropriately the PCE needs to consider the GMPLS TE attributes appropriately
according to tables in [CSPF] once a PCC or another PCE requests a according to tables in [CSPF] once a PCC or another PCE requests a
path computation. Indeed, the path calculation request message from path computation. Indeed, the path calculation request message from
the PCC or the PCE needs to contain the information specifying the PCC or the PCE needs to contain the information specifying
appropriate attributes. Additional attributes to those already appropriate attributes. Additional attributes to those already
defined in [PCECP] are as follows. defined in [PCECP] are as follows.
(1) Switching capability: PSC1-4, L2SC, TDM, lambda, LSC, FSC (1) Switching capability: PSC1-4, L2SC, TDM, LSC, FSC
(2) Encoding type: as defined in [RFC4202], [RFC4203], e.g., Ethernet, (2) Encoding type: as defined in [RFC4202], [RFC4203], e.g.,
SONET/SDH, Lambda, etc. Ethernet, SONET/SDH, Lambda, etc.
(3) e2e Path protection type: as defined in [RFC4872], e.g., 1+1 (3) Signal Type: Indicates the type of elementary signal that
constitutes the requested LSP. A lot of signal types with
different granularity have been defined in SONET/SDH and
G.709 ODUk, such as VC11, VC12, VC2, VC3 and VC4 in SDH, and
ODU1, ODU2 and ODU3 in G.709 ODUk. See [RFC4606] and
[RFC4328].
(4) Concatenation Type: In SDH/SONET and G.709 ODUk networks,
two kinds of concatenation modes are defined: contiguous
concatenation which requires co-route for each member signal
and requires all the interfaces along the path to support
this capability, and virtual concatenation which allows
diverse routes for the member signals and only requires the
ingress and egress interfaces to support this capability.
Note that for the virtual concatenation, it also may specify
co-routed or separated-routed. See [RFC4606] and [RFC4328]
about Concatenation information.
(5) Concatenation Number: Indicates the number of signals that
are requested to be contiguously or virtually concatenated.
Also see [RFC4606] and [RFC4328].
(6) Wavelength Label: as defined in [Lambda-label]
(7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1
protection, 1:1 protection, (pre-planned) rerouting, etc. protection, 1:1 protection, (pre-planned) rerouting, etc.
(4) Administrative group: as defined in [RFC3630] (8) Administrative group: as defined in [RFC3630]
(5) Link Protection type: as defined in [RFC4203] (9) Link Protection type: as defined in [RFC4203]
4.2 PCC requirements 4.2 PCC requirements
As described above, a PCC needs to support to initiate path As described above, a PCC needs to support to initiate path
computation request specifying abovementioned attributes. Afterwards, computation request specifying abovementioned attributes. Afterwards,
GMPLS signaling will be invoked according to the responded messages GMPLS signaling will be invoked according to the responded messages
from the PCE. from the PCE.
4.3 GMPLS PCE Management 4.3 GMPLS PCE Management
skipping to change at page 5, line 49 skipping to change at page 7, line 17
6. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. Acknowledgement 7. Acknowledgement
The author would like to express the thanks to Shuichi Okamoto for The author would like to express the thanks to Shuichi Okamoto for
his comments. his comments.
8. Intellectual property considerations 8. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights any IETF Document or the extent to which any license under such
might or might not be available; nor does it represent that it has rights might or might not be available; nor does it represent that it
made any independent effort to identify any such rights. Information has made any independent effort to identify any such rights.
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 Copies of Intellectual Property disclosures made to the IETF
assurances of licenses to be made available, or the result of an Secretariat and any assurances of licenses to be made available, or
attempt made to obtain a general license or permission for the use of the result of an attempt made to obtain a general license or
such proprietary rights by implementers or users of this permission for the use of such proprietary rights by implementers or
specification can be obtained from the IETF on-line IPR repository at users of this specification can be obtained from the IETF on-line IPR
http://www.ietf.org/ipr. repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard or specification contained in an IETF Document. Please
ipr@ietf.org. address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
9. Informative references 9. Informative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[PCE-ARCH] A. Farrel, et al, "A Path Computation Element (PCE)- [PCE-ARCH] A. Farrel, et al, "A Path Computation Element (PCE)-
Based Architecture", RFC4655, Aug., 2006. Based Architecture", RFC4655, Aug., 2006.
[PCECP-REQ] J. Ash, et al, "Path computation element (PCE) [PCECP-REQ] J. Ash, et al, "Path computation element (PCE)
communication protocol generic requirements", RFC4657, communication protocol generic requirements", RFC4657,
Sept., 2007. Sept., 2007.
[MPLS-AS] R. Zhan, et al, "MPLS Inter-Autonomous System (AS) [MPLS-AS] R. Zhan, et al, "MPLS Inter-Autonomous System (AS)
skipping to change at page 6, line 51 skipping to change at page 8, line 32
RFC 3471, January 2003. RFC 3471, January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label [RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (MPLS) Signaling - Resource ReserVation Switching (MPLS) Signaling - Resource ReserVation
Protocol Traffic Engineering (RSVP-TE) Extensions", Protocol Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003. RFC 3473, January 2003.
[RFC4726] A. Farrel, et al, "A framework for inter-domain MPLS [RFC4726] A. Farrel, et al, "A framework for inter-domain MPLS
traffic engineering", RFC4726, November 2006. traffic engineering", RFC4726, November 2006.
[Arch] E. Mannie, et al, "Generalized Multi-Protocol Label [Arch] E. Mannie, et al, "Generalized Multi-Protocol Label
Switching Architecture", RFC3945, October, 2004. Switching Architecture", RFC3945, October, 2004.
[PCECP] J.P. Vasseur, et al, "Path Computation Element (PCE) [PCECP] J.P. Vasseur, et al, "Path Computation Element (PCE)
Communication Protocol (PCEP)", draft-ietf-pce-pcep- Communication Protocol (PCEP)", RFC5440, March 2009.
15.txt, March 2008.
[RFC4202] K. Kompella, and Y. Rekhter, "Routing Extensions in [RFC4202] K. Kompella, and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Support of Generalized Multi-Protocol Label
Switching", RFC4202, Oct. 2005. Switching", RFC4202, Oct. 2005.
[RFC4203] K. Kompella, and Y. Rekhter, "OSPF Extensions in [RFC4203] K. Kompella, and Y. Rekhter, "OSPF Extensions in
Support of Generalized Multi-Protocol Label Support of Generalized Multi-Protocol Label
Switching", RFC4203, Oct. 2005. Switching", RFC4203, Oct. 2005.
[RFC4872] J.P. Lang, Ed., "RSVP-TE Extensions in Support of [RFC4872] J.P. Lang, Ed., "RSVP-TE Extensions in Support of
End-to-End Generalized Multi-Protocol Label Switching End-to-End Generalized Multi-Protocol Label Switching
(GMPLS) Recovery", RFC4872, May 2007. (GMPLS) Recovery", RFC4872, May 2007.
[GMPLS-TEMIB] T. Nadeau and A. Farrel, Ed., "Generalized [GMPLS-TEMIB] T. Nadeau and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Traffic Multiprotocol Label Switching (GMPLS) Traffic
Engineering Management Information Base", RFC4802, Engineering Management Information Base", RFC4802,
Feb. 2007. Feb. 2007.
skipping to change at page 7, line 15 skipping to change at page 8, line 46
[RFC4203] K. Kompella, and Y. Rekhter, "OSPF Extensions in [RFC4203] K. Kompella, and Y. Rekhter, "OSPF Extensions in
Support of Generalized Multi-Protocol Label Support of Generalized Multi-Protocol Label
Switching", RFC4203, Oct. 2005. Switching", RFC4203, Oct. 2005.
[RFC4872] J.P. Lang, Ed., "RSVP-TE Extensions in Support of [RFC4872] J.P. Lang, Ed., "RSVP-TE Extensions in Support of
End-to-End Generalized Multi-Protocol Label Switching End-to-End Generalized Multi-Protocol Label Switching
(GMPLS) Recovery", RFC4872, May 2007. (GMPLS) Recovery", RFC4872, May 2007.
[GMPLS-TEMIB] T. Nadeau and A. Farrel, Ed., "Generalized [GMPLS-TEMIB] T. Nadeau and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Traffic Multiprotocol Label Switching (GMPLS) Traffic
Engineering Management Information Base", RFC4802, Engineering Management Information Base", RFC4802,
Feb. 2007. Feb. 2007.
[RFC3630] D. Katz et al, "Traffic Engineering (TE) Extensions [RFC3630] D. Katz et al., "Traffic Engineering (TE) Extensions
to OSPF Version 2", RFC3630, September 2003. to OSPF Version 2", RFC3630, September 2003.
[Lambda-label] T. Otani, Ed., "Generalized Labels for G.694 Lambda-
Switching Capable Label Switching Routers", draft-
ietf-ccamp-gmpls-g-694-lambda-labels-04.txt, Mar.
2009.
[RFC5394] I. Bryskin et al., " Policy-Enabled Path Computation
Framework", RFC5394, December 2008.
[RFC4606] E. Mannie and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC4606, August
2006.
[RFC4328] D. Papadimitriou, Ed., "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Extensions for
G.709 Optical Transport Networks Control", RFC4328,
January 2006.
Author's Addresses Author's Addresses
Tomohiro Otani Tomohiro Otani
KDDI R&D Laboratories, Inc. KDDI Corporation
2-1-15 Ohara Kamifukuoka Saitama, 356-8502. Japan 2-3-2 Nishi-shinjuku Shinjuku-ku, Tokyo 163-8003 Japan
Phone: +81-49-278-7357 Phone: +81-3-3347-6006
Email: otani@kddilabs.jp Email: tm-otani@kddi.com
Kenichi Ogaki Kenichi Ogaki
KDDI R&D Laboratories, Inc. KDDI R&D Laboratories, Inc.
2-1-15 Ohara Kamifukuoka Saitama, 356-8502. Japan 2-1-15 Ohara Fujimino-shi, Saitama 356-8502 Japan
Phone: +81-49-278-7897 Phone: +81-49-278-7897
Email: ogaki@kddilabs.jp Email: ogaki@kddilabs.jp
Diego Caviglia Diego Caviglia
Ericsson Ericsson
16153 Genova Cornigliano, ITALY 16153 Genova Cornigliano, ITALY
Phone: +390106003736 Phone: +390106003736
Email: diego.caviglia@ericsson.com Email: diego.caviglia@ericsson.com
Document expiration Fatai Zhang
Huawei Technologies Co., Ltd.
This document will be expired in March 31, 2009, unless it is updated. F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Copyright statement Full Copyright statement
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to the rights, licenses and restrictions This document is subject to BCP 78 and the IETF Trust's Legal
contained in BCP 78, and except as set forth therein, the authors Provisions Relating to IETF Documents in effect on the date of
retain all their rights. 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 and the information contained herein are provided on an All IETF Documents and the information contained therein are provided
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
 End of changes. 32 change blocks. 
77 lines changed or deleted 183 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/