draft-ietf-pce-pcep-p2mp-extensions-05.txt   draft-ietf-pce-pcep-p2mp-extensions-06.txt 
Internet Engineering Task Force Q. Zhao, Ed. Internet Engineering Task Force Q. Zhao, Ed.
Internet-Draft Huawei Technology Internet-Draft Huawei Technology
Intended Status: Standards Track Daniel King, Ed. Intended Status: Standards Track Daniel King, Ed.
Created: October 25, 2009 Old Dog Consulting Created: December 30, 2009 Old Dog Consulting
Expires: March 25, 2010 Expires: May 1, 2010
Extensions to the Path Computation Element Communication Protocol Extensions to the Path Computation Element Communication Protocol
(PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
draft-ietf-pce-pcep-p2mp-extensions-05.txt draft-ietf-pce-pcep-p2mp-extensions-06.txt
Abstract Abstract
Point-to-point Multiprotocol Label Switching (MPLS) and Generalized Point-to-point Multiprotocol Label Switching (MPLS) and Generalized
MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may
be established using signaling techniques, but their paths may first be established using signaling techniques, but their paths may first
need to be determined. The Path Computation Element (PCE) has been need to be determined. The Path Computation Element (PCE) has been
identified as an appropriate technology for the determination of the identified as an appropriate technology for the determination of the
paths of P2MP TE LSPs. paths of P2MP TE LSPs.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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."
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 January 28, 2010. This Internet-Draft will expire on May 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 4, line 5 skipping to change at page 4, line 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5. Security Considerations . . . . . . . . . . . . . . . . . . .
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .
6.1. P2MP Capability TLV . . . . . . . . . . . . . . . . . . . 6.1. P2MP Capability TLV . . . . . . . . . . . . . . . . . . .
6.2. Request Parameter Bit Flags . . . . . . . . . . . . . . . 6.2. Request Parameter Bit Flags . . . . . . . . . . . . . . .
6.3. Object Function . . . . . . . . . . . . . . . . . . . . . 6.3. Object Function . . . . . . . . . . . . . . . . . . . . .
6.4. Metric Object Types . . . . . . . . . . . . . . . . . . . 6.4. Metric Object Types . . . . . . . . . . . . . . . . . . .
6.5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 6.5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . .
6.6. PCEP Error Objects and Types . . . . . . . . . . . . . . . 6.6. PCEP Error Objects and Types . . . . . . . . . . . . . . .
6.7. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . 6.7. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7. Acknowledgement's. . . . . . . . . . . . . . . . . . . . . . .
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8. References . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8.1. Normative References . . . . . . . . . . . . . . . . . . .
8.2. Informative References . . . . . . . . . . . . . . . . . . 8.2. Informative References . . . . . . . . . . . . . . . . . .
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .
9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . .
Appendix A. RBNF Code Fragments . . . . . . . . . . . . . . . . . Appendix A. RBNF Code Fragments . . . . . . . . . . . . . . . . .
1. Introduction 1. Introduction
The Path Computation Element (PCE) defined in [RFC4655] is an entity The Path Computation Element (PCE) defined in [RFC4655] is an entity
that is capable of computing a network path or route based on a that is capable of computing a network path or route based on a
network graph, and applying computational constraints. A Path network graph, and applying computational constraints. A Path
Computation Client (PCC) may make requests to a PCE for paths to be Computation Client (PCC) may make requests to a PCE for paths to be
computed. computed.
[RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic
Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
The PCE has been identified as a suitable application for the The PCE has been identified as a suitable application for the
computation of paths for P2MP TE LSPs [PCE-P2MP-APP]. computation of paths for P2MP TE LSPs [RFC5671].
The PCE communication protocol (PCEP) is designed as a communication The PCE communication protocol (PCEP) is designed as a communication
protocol between PCCs and PCEs for point-to-point (P2P) path protocol between PCCs and PCEs for point-to-point (P2P) path
computations and is defined in [RFC5440]. However, that computations and is defined in [RFC5440]. However, that
specification does not provide a mechanism to request path specification does not provide a mechanism to request path
computation of P2MP TE LSPs. computation of P2MP TE LSPs.
This document presents extensions to PCEP to support P2MP path This document presents extensions to PCEP to support P2MP path
computation satisfying the set of requirements described in [PCE- computation satisfying the set of requirements described in [PCE-
P2MP-REQ]. P2MP-REQ].
skipping to change at page 7, line 10 skipping to change at page 7, line 10
existing P2MP LSP route information between the PCC and PCE in the existing P2MP LSP route information between the PCC and PCE in the
request and reply message. In each of these scenarios, we need new request and reply message. In each of these scenarios, we need new
path objects for efficiently passing the existing P2MP LSP between path objects for efficiently passing the existing P2MP LSP between
the PCE and PCC. the PCE and PCC.
We specify the use of the Explicit Route Object (ERO) We specify the use of the Explicit Route Object (ERO)
to encode the explicit route of a TE LSP through the network. The to encode the explicit route of a TE LSP through the network. The
Secondary Explicit Route Object (SERO) is used to specify the Secondary Explicit Route Object (SERO) is used to specify the
explicit route of a S2L sub-LSP. The Reported Route Object (RRO) and explicit route of a S2L sub-LSP. The Reported Route Object (RRO) and
Secondary Reported Route Object (SERO) are used to report Secondary Reported Route Object (SERO) are used to report
the routes of existing TE LSP for which a reoptimization is the routes of an existing TE LSP for which a reoptimization is
desired. The format and contents of the ERO and RRO are defined in desired. The format and contents of the ERO and RRO are defined in
[RFC5440]. The format and contents of the SERO and SRRO are [RFC5440]. The format and contents of the SERO and SRRO are
defined in [RFC4875]. A new class and type are requested for SERO defined in [RFC4875]. A new class and type are requested for SERO
and SRRO in the IANA Considerations section of this document. and SRRO in the IANA Considerations section of this document.
3.3. P2MP Path Computation Request/Reply Message Extensions 3.3. P2MP Path Computation Request/Reply Message Extensions
The existing P2P RP (Request Parameters) object is extended so that The existing P2P RP (Request Parameters) object has been extended so
it can signal to the receiver of the PCEP request that it is for that a PCC can signal a P2MP path computation request to the PCE
P2P or P2MP path computation. Also the END-POINT object is receiving the PCEP request. The END-POINT object is also extended
extended to improve the efficiency of the message exchange between to improve the efficiency of the message exchange between PCC and PCE
PCC and PCE in the case of P2MP path computation. in the case of P2MP path computation.
3.3.1. The Extension of the RP Object 3.3.1. The Extension of the RP Object
The PCE path computation request and reply message will need the The PCE path computation request and reply message will need the
following additional parameters to allow a receiving PCE to following additional parameters to allow a receiving PCE to
identify that the request and reply message has been fragmented identify that the request and reply message has been fragmented
across multiple messages, has been requested for a P2MP path and to across multiple messages, has been requested for a P2MP path and to
specify if the route is represented in the compressed or uncompressed specify if the route is represented in the compressed or uncompressed
format. format.
The F bit is added to the flag bits of the RP object to indicate The F bit is added to the flag bits of the RP object to indicate
to the receiver that the request is part of a fragmented request, or to the receiver that the request is part of a fragmented request, or
is not a fragmented request. is not a fragmented request.
The M bit is added in the flag bits field of the RP object to signal The N bit is added in the flag bits field of the RP object to signal
the receiver of the message that the request/reply is for P2MP or the receiver of the message that the request/reply is for P2MP or
not. not.
The E bit is added in the flag bits field of the RP object to signal The E bit is added in the flag bits field of the RP object to signal
the receiver of the message that the route is in the compress format the receiver of the message that the route is in the compressed
or not. format or not. By default, the path returned by the PCE will use the
compressed format.
The extended format of the RP object body to include the F bit, M The extended format of the RP object body to include the F bit, N
bit and the E bit is as follows: bit and the E bit is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |F|N|E| |O|B|R| Pri | | Reserved | Flags |F|N|E| |O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number | | Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 8, line 33 skipping to change at page 8, line 33
0: This indicates that the RP is not fragmented or it is the 0: This indicates that the RP is not fragmented or it is the
last piece of the fragmented RP. last piece of the fragmented RP.
1: This indicates that the RP is fragmented and this is not 1: This indicates that the RP is fragmented and this is not
the last piece of the fragmented RP and the receiver the last piece of the fragmented RP and the receiver
needs to wait until it receives an RP with the same RP-ID needs to wait until it receives an RP with the same RP-ID
and with the F bit is set to 0. and with the F bit is set to 0.
o N ( P2MP bit - 1 bit): o N ( P2MP bit - 1 bit):
0: This indicates that this is not PCReq/PCRrep for P2MP. 0: This indicates that this is not PCReq/PCRep for P2MP.
1: This indicates that this is PCReq or PCRep message for P2MP. 1: This indicates that this is PCReq or PCRep message for P2MP.
o E ( ERO-compression bit - 1 bit): o E ( ERO-compression bit - 1 bit):
0: This indicates that the route is not in the compressed 0: This indicates that the route is not in the compressed
format. format.
1: This indicates that the route is in the compressed format. 1: This indicates that the route is in the compressed format.
skipping to change at page 9, line 29 skipping to change at page 9, line 29
3. Old leaves whose path can be modified/reoptimized; 3. Old leaves whose path can be modified/reoptimized;
4. Old leaves whose path must be left unchanged. 4. Old leaves whose path must be left unchanged.
With the new END-POINTS object, the END-POINTS portion of a request With the new END-POINTS object, the END-POINTS portion of a request
message for the multiple destinations can be reduced by up to 50% for message for the multiple destinations can be reduced by up to 50% for
a P2MP path where a single source address has a very large number of a P2MP path where a single source address has a very large number of
destinations. destinations.
Note that a P2MP path computation request can mix the different types Note that a P2MP path computation request can mix the different types
of leaves by including several END-POINTS object per RP object as of leaves by including several END-POINTS object per RP object as
shown in PCReq Routing Backus-Naur Format (RBNF) [RFC5511] format in shown in the PCReq Routing Backus-Naur Format (RBNF) [RFC5511] format
following Request Message Formats section (Section 3.4). in following Request Message Formats section (Section 3.4).
The format of the new END-POINTS object body for IPv4 (Object-Type 3) The format of the new END-POINTS object body for IPv4 (Object-Type 3)
is as follows: is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type | | Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address | | Source IPv4 address |
skipping to change at page 10, line 35 skipping to change at page 10, line 35
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The New P2MP END-POINTS Object Body Format for IPv6 Figure 3: The New P2MP END-POINTS Object Body Format for IPv6
The END-POINTS object body has a variable length. These are multiples The END-POINTS object body has a variable length. These are multiples
of 4 bytes for IPv4, and multiples of 16 bytes for IPv6. of 4 bytes for IPv4, and multiples of 16 bytes for IPv6.
3.4. Request Message Format 3.4. Request Message Format
As per [RFC5511] the RBNF format of the PCReq message is as follows. As per [RFC5511] the RBNF format of the PCReq message is as follows:
Please see Appendix A for a full set of RBNF fragments defined in
this document and the necessary code license.
Below is the message format for the request message: Below is the message format for the request message:
<PCReq Message>::= <Common Header> <PCReq Message>::= <Common Header>
<request> <request>
where: where:
<request>::= <RP> <request>::= <RP>
<end-point-rro-pair-list> <end-point-rro-pair-list>
[<OF>] [<OF>]
[<LSPA>] [<LSPA>]
skipping to change at page 11, line 20 skipping to change at page 11, line 20
<RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>] <RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>] <metric-list>::=<METRIC>[<metric-list>]
Figure 4: The Message Format for the Request Message Figure 4: The Message Format for the Request Message
Note we preserve compatibility with the [RFC5440] definition of Note we preserve compatibility with the [RFC5440] definition of
<request>. At least one instance of <endpoints> must be present <request>. At least one instance of <endpoints> must be present
in this definition. in this definition.
3.5. Reply Message Format
As per [RFC5511] the RBNF format of the PCRep message is as follows.
Please see Appendix A for a full set of RBNF fragments defined in Please see Appendix A for a full set of RBNF fragments defined in
this document and the necessary code license. this document and the necessary code license.
3.5. Reply Message Format
As per [RFC5511] the RBNF format of the PCRep message is as follows:
Below is the message format for the reply message: Below is the message format for the reply message:
<PCRep Message>::= <Common Header> <PCRep Message>::= <Common Header>
<response> <response>
<response>::=<RP> <response>::=<RP>
[<end-point-path-pair-list>] [<end-point-path-pair-list>]
[<NO-PATH>] [<NO-PATH>]
[<attribute-list>] [<attribute-list>]
where: where:
skipping to change at page 12, line 5 skipping to change at page 12, line 5
[<metric-list>] [<metric-list>]
[<IRO>] [<IRO>]
Figure 5: The Message Format for the Reply Message Figure 5: The Message Format for the Reply Message
The optional END-POINTS in the reply message is used to specify which The optional END-POINTS in the reply message is used to specify which
paths are removed, changed, not changed, or added for the request. paths are removed, changed, not changed, or added for the request.
The path is only needed for the end points which are added or The path is only needed for the end points which are added or
changed. changed.
If the ERO-Compress bit was set to 1 in the request then the path If the E bit (ERO-Compress bit) was set to 1 in the request then the
will be formed by an ERO followed by a list of SERO. Otherwise it path will be formed by an ERO followed by a list of SEROs.
is a list of ERO.
Note that we preserve compatibility with the [RFC5440] definition of Note that we preserve compatibility with the [RFC5440] definition of
<response> and the optional <end-point-pair-list> and <path>. <response> and the optional <end-point-pair-list> and <path>.
Please see Appendix A for a full set of RBNF fragments defined in
this document and the necessary code license.
3.6. P2MP Objective Functions and Metric Types 3.6. P2MP Objective Functions and Metric Types
3.6.1. New Object Functions 3.6.1. New Object Functions
Six objective functions have been defined in [RFC5541] for P2P path Six objective functions have been defined in [RFC5541] for P2P path
computation. computation.
This document defines two additional objective functions, namely SPT This document defines two additional objective functions, namely SPT
(Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to P2MP (Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to P2MP
path computation. Hence two new objective function codes have to be path computation. Hence two new objective function codes have to be
skipping to change at page 12, line 48 skipping to change at page 12, line 50
the costs of tree links, with respect to a specific metric or to the the costs of tree links, with respect to a specific metric or to the
TE metric used as the default metric when the metric is not TE metric used as the default metric when the metric is not
specified. specified.
Processing these two new objective functions is subject to the rules Processing these two new objective functions is subject to the rules
defined in [RFC5541]. defined in [RFC5541].
3.6.2. New Metric Object Types 3.6.2. New Metric Object Types
There are three types defined for the <METRIC> object in [RFC5440], There are three types defined for the <METRIC> object in [RFC5440],
namely, the IGP metric, the TE metric and the Hop Count metric. This namely, the IGP metric, the TE metric and the Hop Count metric. This
document defines three other types for the <METRIC> object: the P2MP document defines three additional types for the <METRIC> object: the
IGP metric, the P2MP TE metric, and the P2MP hop count metric. They P2MP IGP metric, the P2MP TE metric, and the P2MP hop count metric.
encode the sum of the metrics of all links of the tree. We propose They encode the sum of the metrics of all links of the tree. We
the following values for these new metric types: propose the following values for these new metric types:
o P2MP IGP metric: T=8 (suggested value, to be assigned by IANA) o P2MP IGP metric: T=8 (suggested value, to be assigned by IANA)
o P2MP TE metric: T=9 (suggested value, to be assigned by IANA) o P2MP TE metric: T=9 (suggested value, to be assigned by IANA)
o P2MP hop count metric: T=10 (suggested value, to be assigned by o P2MP hop count metric: T=10 (suggested value, to be assigned by
IANA) IANA)
3.7. Non-Support of P2MP Path Computation. 3.7. Non-Support of P2MP Path Computation.
skipping to change at page 13, line 30 skipping to change at page 13, line 30
this document. this document.
o If the PCE does not understand the P2MP flag in the RP object, o If the PCE does not understand the P2MP flag in the RP object,
then the PCE MUST send a PCErr message with a new error type then the PCE MUST send a PCErr message with a new error type
"Unknown RP flag". "Unknown RP flag".
3.8. Non-Support by Back-Level PCE Implementations. 3.8. Non-Support by Back-Level PCE Implementations.
If a PCC inadvertently sends a P2MP request to a PCE which does not If a PCC inadvertently sends a P2MP request to a PCE which does not
support P2MP path computation and therefore the PCEP P2MP extensions, support P2MP path computation and therefore the PCEP P2MP extensions,
then the PCE SHOULD reject the request, then the PCE SHOULD reject the request.
because it cannot understand the new P2MP END-POINTS object.
3.9. P2MP TE Path Reoptimization Request 3.9. P2MP TE Path Reoptimization Request
A reoptimization request for a P2MP TE path is specified by the use A reoptimization request for a P2MP TE path is specified by the use
of the R bit within the RP object as defined in [RFC5440] and is of the R bit within the RP object as defined in [RFC5440] and is
similar to the reoptimization request for a P2P TE path. The only similar to the reoptimization request for a P2P TE path. The only
difference is that the user must insert the list of RROs and SRROs difference is that the user must insert the list of RROs and SRROs
after each type of END-POINTS in the PCReq message, as described in after each type of END-POINTS in the PCReq message, as described in
the Request Message Format section (Section 3.4) of this document. the Request Message Format section (Section 3.4) of this document.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
is described below: is described below:
Common Header Common Header
RP with P2MP flag/R bits set RP with P2MP flag/R bits set
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
OF (optional) OF (optional)
Figure 6: PCReq Message Example 1 for Optimization Figure 6: PCReq Message Example 1 for Optimization
In this example, we request reoptimization of path to all leaves In this example, we request reoptimization of the path to all leaves
without adding or pruning leaves. That is only one END-POINT of type without adding or pruning leaves. The reoptimization request would
3. The RRO list is representing the P2MP LSP before the optimization use an END-POINT type 3. The RRO list would represent the P2MP LSP
and the modifiable path leaves are indicated in the END-POINTS before the optimization and the modifiable path leaves would be
object. indicated in the END-POINTS object.
Optionally it is possible to specify specific leaves whose path cannot It is also possible to specify specific leaves whose path cannot
be modified. An example of the PCReq message in this scenario would be modified. An example of the PCReq message in this scenario would
be: be:
Common Header Common Header
RP with P2MP flag/R bits set RP with P2MP flag/R bits set
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
END-POINTS for leaf type 4 END-POINTS for leaf type 4
RRO list RRO list
OF (optional) OF (optional)
Figure 7: PCReq Message Example 2 for Optimization Figure 7: PCReq Message Example 2 for Optimization
A P2MP reoptimization request could contain a parameter that allows
the PCC to express a cost-benefit reoptimization threshold for the
whole LSP as well as per destination. This function would be set by
the local PCC and subject to the PCE policy [RFC5394]. This
specification does not provide a mechanism to address this threshold
function. The function may be addressed in a future document.
3.10. Adding and Pruning Leaves to the P2MP Tree 3.10. Adding and Pruning Leaves to the P2MP Tree
When adding new leaves or removing old leaves to the existing P2MP When adding new leaves or removing old leaves to the existing P2MP
tree, by supplying a list of existing leaves, it SHOULD be possible tree, by supplying a list of existing leaves, it SHOULD be possible
to optimize the existing P2MP tree. This section explains the to optimize the existing P2MP tree. This section explains the
methods to add new leaves or remove old leaves to the existing methods to add new leaves or remove old leaves to the existing
P2MP tree. P2MP tree.
To add new leaves the user must build a P2MP request with an END- To add new leaves the user must build a P2MP request using
POINTS with leaf type 1. END-POINTS with leaf type 1.
To remove old leaves the user must build a P2MP request with an END- To remove old leaves the user must build a P2MP request using
POINTS with leaf type 2. END-POINTS with leaf type 2.
The PCC must also provide the list of old leaves and indicate if they The PCC must also provide the list of old leaves and indicate if
should be reoptimized or not by including END-POINTS with leaf type 3 they should be reoptimized or not by including END-POINTS with leaf
or 4 or both. The error values when the conditions are not type 3, leaf type 4 or both. The error values when the conditions
satisfied (i.e., when there is no END-POINTS with leaf type 3 or are not satisfied (i.e., when there is no END-POINTS with leaf type
4, in the presence of END-POINTS with leaf type 1 or 2), are 3 or 4, in the presence of END-POINTS with leaf type 1 or 2), are
documented in the IANA Considerations section (Section 6) of this documented in the IANA Considerations section (Section 6) of this
document. document.
For old leaves the user must provide the old path as list of RROs For old leaves the user must provide the old path as a list of RROs
that immediately follows each END-POINTS object. This document that immediately follows each END-POINTS object. This document
specifies error values when specific conditions are not satisfied. specifies error values when specific conditions are not satisfied.
The following examples demonstrate full and partial reoptimization of The following examples demonstrate full and partial reoptimization
existing P2MP LSPs: of existing P2MP LSPs:
Case 1: Adding leaves with full reoptimization of existing paths Case 1: Adding leaves with full reoptimization of existing paths
Common Header Common Header
RP with P2MP flag/R bits set RP with P2MP flag/R bits set
END-POINTS for leaf type 1 END-POINTS for leaf type 1
RRO list RRO list
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
OF (optional) OF (optional)
skipping to change at page 17, line 41 skipping to change at page 17, line 41
RRO list RRO list
OF (optional) OF (optional)
Figure 16: Adding and Pruning Leaves without Reoptimization Figure 16: Adding and Pruning Leaves without Reoptimization
3.11. Discovering Branch Nodes 3.11. Discovering Branch Nodes
Before computing the P2MP path, a PCE must be provided means to know Before computing the P2MP path, a PCE must be provided means to know
which nodes in the network are capable of acting as branch LSRs. A which nodes in the network are capable of acting as branch LSRs. A
PCE can discover such capabilities by using the mechanisms defined in PCE can discover such capabilities by using the mechanisms defined in
[PCE-P2MP-REQ. [RFC5073].
3.11.1 Branch Node Object 3.11.1 Branch Node Object
The PCC can specify a list of nodes that can be used as branch The PCC can specify a list of nodes that can be used as branch
nodes or a list of nodes that cannot be used as branch nodes by nodes or a list of nodes that cannot be used as branch nodes by
using the a BRANCH NODE Capability (BNC) Object. The BNC Object has using the a BRANCH NODE Capability (BNC) Object. The BNC Object has
the same format as the IRO object defined in [RFC5440] except that the same format as the IRO object defined in [RFC5440] except that
it only supports IPv4 and IPv6 prefix sub-objects. Two Object- it only supports IPv4 and IPv6 prefix sub-objects. Two Object-
types are also defined: types are also defined:
skipping to change at page 18, line 19 skipping to change at page 18, line 19
nodes. nodes.
The object can only be carried in a PCReq message. A Path Request The object can only be carried in a PCReq message. A Path Request
may carry at most one BRANCH NODE Object. may carry at most one BRANCH NODE Object.
The Object-Class and Object-types will need to allocated by IANA. The The Object-Class and Object-types will need to allocated by IANA. The
IANA request is documented in Section 6.5. IANA request is documented in Section 6.5.
3.12. Synchronization of P2MP TE Path Computation Requests 3.12. Synchronization of P2MP TE Path Computation Requests
There are cases when multiple P2MP LSPs' computations need to be There are cases when multiple P2MP LSPs computations need to be
synchronized. For example, one P2MP LSP is the designated backup of synchronized. For example, one P2MP LSP is the designated backup of
another P2MP LSP. In this case, path diversity for these dependent another P2MP LSP. In this case, path diversity for these dependent
LSPs may need to be considered during the path computation. LSPs may need to be considered during the path computation.
The synchronization can be done by just using the existing SVEC The synchronization can be done by just using the existing SVEC
functionality. functionality.
An example of synchronizing two P2MP LSPs, each has two leaves for An example of synchronizing two P2MP LSPs, each has two leaves for
Path Computation Request Messages is illustrated as below: Path Computation Request Messages is illustrated as below:
Common Header Common Header
SVEC for sync of LSP1 and LSP2 SVEC for sync of LSP1 and LSP2
OF (optional) OF (optional)
END-POINTS1 for P2MP END-POINTS1 for P2MP
RRO1 list RRO1 list
END-POINTS2 for P2MP END-POINTS2 for P2MP
RRO2 list RRO2 list
Figure 17: PCReq Message Example for Synchronization Figure 17: PCReq Message Example for Synchronization
We propose that two new flags are also added to the SVEC object for This specification also defines two new flags to the SVEC object
P2MP path dependent computation requests. The first new flag is to for P2MP path dependent computation requests. The first new flag is
allow the PCC to request that the PCE should compute a secondary to allow the PCC to request that the PCE should compute a secondary
P2MP path tree with partial path diversity for specific leaves or P2MP pathtree with partial path diversity for specific leaves or a
a specific S2L sub-path to the primary P2MP path tree. The second specific S2L sub-path to the primary P2MP path tree. The second flag,
flag, would allow the PCC to request that partial paths should be would allow the PCC to request that partial paths should be link
link direction diverse. direction diverse.
The format of the SVEC object body is as follows: The format of the SVEC object body is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |S|N|L|P|D| | Reserved | Flags |S|N|L|P|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number #1 | | Request-ID-number #1 |
// // // //
| Request-ID-number #M | | Request-ID-number #M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: SVEC Body Object Format with Additional Flags Figure 19: SVEC Body Object Format with Additional Flags
The following flags are added to the SVEC object body in this draft: The following flags are added to the SVEC object body in this draft:
o P ( Partial Path Diversity bit - 1 bit): o P ( Partial Path Diversity bit - 1 bit):
When set this would indicate a request for partial path When set this would indicate a request for path diversity
diversity for a specific leave or set of leaves. for a specific leaf, a set of leaves or all leaves.
o D ( Link Direction Diverse bit - 1 bit): o D ( Link Direction Diverse bit - 1 bit):
When set this would indicate a request that a partial path or When set this would indicate a request that a partial path or
paths should be link direction diverse. paths should be link direction diverse.
3.13. Request and Response Fragmentation 3.13. Request and Response Fragmentation
In certain scenarios the P2MP computation request may not fit into a In certain scenarios the P2MP computation request may not fit into a
single request or response message. For example, if a tree has many single request or response message. For example, if a tree has many
skipping to change at page 19, line 49 skipping to change at page 19, line 49
(Section 3.3.1) of this document. The F bit is used in the RP object (Section 3.3.1) of this document. The F bit is used in the RP object
header to signal that the initial request or response was too large header to signal that the initial request or response was too large
to fit into a single message and will be fragmented into multiple to fit into a single message and will be fragmented into multiple
messages. In order to indentify the single request or response, each messages. In order to indentify the single request or response, each
message will use the same request ID. message will use the same request ID.
3.13.1 Request Fragmentation Procedure 3.13.1 Request Fragmentation Procedure
If the initial request is too large to fit into a single request If the initial request is too large to fit into a single request
message the PCC will split the request over multiple messages. Each message the PCC will split the request over multiple messages. Each
messagesent to the PCE, except the last one, will have the F bit set message sent to the PCE, except the last one, will have the F bit set
in the RP object to signify that the request has been fragmented in the RP object to signify that the request has been fragmented
into multiple messages. In order to indentify that a series of into multiple messages. In order to indentify that a series of
request messages represents a single request, each message will request messages represents a single request, each message will
use the same request ID. use the same request ID.
The assumption is that request messages are reliably delivered The assumption is that request messages are reliably delivered
and in sequence since PCEP relies on TCP. and in sequence since PCEP relies on TCP.
3.13.2 Response Fragmentation Procedure 3.13.2 Response Fragmentation Procedure
Once the PCE computes a path based on the initial request, a response Once the PCE computes a path based on the initial request, a response
is sent back to the PCC. If the response is too large to fit into a is sent back to the PCC. If the response is too large to fit into a
single response message the PCE will split the request over multiple single response message the PCE will split the request over multiple
messages. Each message sent to the PCE, except the last one, will messages. Each message sent to the PCE, except the last one, will
have the F bit set in the RP object to signify that the response have the F bit set in the RP object to signify that the response
has been fragmented into multiple messages. In order to identify has been fragmented into multiple messages. In order to identify
that a series of response messages represents a single request, that a series of response messages represents a single request,
each message will use the same request ID. each message will use the same request ID.
The assumption is that response messages are reliably delivered Again, the assumption is that response messages are reliably
and in sequence since PCEP relies on TCP. delivered and in sequence since PCEP relies on TCP.
3.13.3 Fragmentation Examples 3.13.3 Fragmentation Examples
The following example illustrates the PCC sending a request message The following example illustrates the PCC sending a request message
with Req-ID1 to the PCE, in order to add one leaf to an existing tree with Req-ID1 to the PCE, in order to add one leaf to an existing tree
with 1200 leaves. The assumption is that the one request message can with 1200 leaves. The assumption is that the one request message can
hold up to 800 leaves. In this scenario, the original one message hold up to 800 leaves. In this scenario, the original single message
needs to be fragmented and sent over by two small messages, which needs to be fragmented and sent using two smaller messages, which
have the Req-ID1 specified in the RP object and F bit set for the have the Req-ID1 specified in the RP object, and with the F bit set on
first message. the first message.
Common Header Common Header
RP1 with Req-ID1 and P2MP flag and F bit set RP1 with Req-ID1 and P2MP flag and F bit set
OF (optional) OF (optional)
END-POINTS1 for P2MP END-POINTS1 for P2MP
RRO1 list RRO1 list
Common Header Common Header
RP2 with Req-ID1 and P2MP flag and F bit cleared RP2 with Req-ID1 and P2MP flag and F bit cleared
OF (optional) OF (optional)
skipping to change at page 22, line 44 skipping to change at page 22, line 44
3.16. PCEP NO-PATH Indicator 3.16. PCEP NO-PATH Indicator
To communicate the reasons for not being able to find P2MP path To communicate the reasons for not being able to find P2MP path
computation, the NO-PATH object can be used in the PCRep message. computation, the NO-PATH object can be used in the PCRep message.
The format of the NO-PATH object body is as follows: The format of the NO-PATH object body is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Flags | Reserved | |Nature of Issue|C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: The Format of the NO-PATH Object Body Figure 22: The Format of the NO-PATH Object Body
One new bit is defined in the NO-PATH-VECTOR TLV carried in One new bit is defined in the NO-PATH-VECTOR TLV carried in
the NO-PATH Object: the NO-PATH Object:
skipping to change at page 24, line 8 skipping to change at page 24, line 8
4.5. Requirements on Other Protocols and Functional Components 4.5. Requirements on Other Protocols and Functional Components
As described in [PCE-P2MP-REQ], the PCE MUST obtain information As described in [PCE-P2MP-REQ], the PCE MUST obtain information
about the P2MP signaling and branching capabilities of each LSR in about the P2MP signaling and branching capabilities of each LSR in
the network. the network.
Protocol extensions specified in this document does not provide such Protocol extensions specified in this document does not provide such
capability. Other mechanisms MUST be present. capability. Other mechanisms MUST be present.
The PCE Discovery mechanisms ([RFC5088] and [RFC5089]) is used to The PCE Discovery mechanisms ([RFC5088] and [RFC5089]) can be used to
advertise capabilities to PCCs. A new flag (value=10) could be advertise capabilities to PCCs. A new flag (value=10) could be
defined in PCE-CAP-FLAGs Sub-TLV to indicate P2MP path computation defined in PCE-CAP-FLAGs Sub-TLV to indicate P2MP path computation
capability. Extensions for PCE discovery are out of scope of this capability. Extensions for PCE discovery are out of scope of this
document. document.
4.6. Impact on Network Operation 4.6. Impact on Network Operation
It is expected that use of PCEP extensions specified in this document It is expected that use of PCEP extensions specified in this document
does not have significant impact on network operations. does not have significant impact on network operations.
5. Security Considerations 5. Security Considerations
As described in [PCE-P2MP-REQ], P2MP path computation requests are As described in [PCE-P2MP-REQ], P2MP path computation requests are
more CPU-intensive and also use more link bandwidth. Therefore, it more CPU-intensive and also use more link bandwidth. Therefore, it
may be more vulnerable to denial of service attacks. Therefore it is may be more vulnerable to denial of service attacks. Therefore it is
more important that implementations conform to security requirements more important that implementations conform to security requirements
of [RFC5440], and the implementer utilize those security features of [RFC5440], and the implementer utilize those security features.
6. IANA Considerations 6. IANA Considerations
IANA maintains a registry of PCEP parameters. A number of IANA IANA maintains a registry of PCEP parameters. A number of IANA
considerations have been highlighted in previous sections of this considerations have been highlighted in previous sections of this
document. IANA is requested to make the following allocations. document. IANA is requested to make the following allocations.
6.1 P2MP Capability TLV 6.1 P2MP Capability TLV
As described in Section 3.1.2, the newly defined P2MP capability TLV As described in Section 3.1.2, the newly defined P2MP capability TLV
skipping to change at page 25, line 14 skipping to change at page 25, line 14
Bit Description Reference Bit Description Reference
18 Fragmentation(F-bit) This.I-D 18 Fragmentation(F-bit) This.I-D
19 P2MP (N-bit) This.I-D 19 P2MP (N-bit) This.I-D
20 ERO-compression (E-bit) This.I-D 20 ERO-compression (E-bit) This.I-D
6.3 Objective Function 6.3 Objective Function
As described in Section 3.6.1., two new Objective Funtions have been As described in Section 3.6.1., two new Objective Funtions have been
defined. IANA is requested to make the following allocations defined. IANA is requested to make the following allocations from the
from the "Objective Function" sub-registry: "Objective Function" sub-registry:
Code Point Name Reference Code Point Name Reference
7 SPT This.I-D 7 SPT This.I-D
8 MCT This.I-D 8 MCT This.I-D
6.4 Metric Object Types 6.4 Metric Object Types
As described in Section 3.6.2., three new metric object T fields have As described in Section 3.6.2., three new metric object T fields have
been defined. IANA is requested to make the following allocations been defined. IANA is requested to make the following allocations
from the "METRIC Object T Field" sub-reigstry: from the "METRIC Object T Field" sub-registry:
Value Description Reference Value Description Reference
8 P2MP IGP metric This.I-D 8 P2MP IGP metric This.I-D
9 P2MP TE metric This.I-D 9 P2MP TE metric This.I-D
10 P2MP hop count metric This.I-D 10 P2MP hop count metric This.I-D
6.5 PCEP Objects 6.5 PCEP Objects
As described in Section 3.2, 3.4 and 3.11.1, six PCE Objects have As described in Section 3.2, 3.4 and 3.11.1, six PCE Objects have
skipping to change at page 27, line 18 skipping to change at page 27, line 18
has been defined. IANA is requested to make the following has been defined. IANA is requested to make the following
allocation from the "NO-PATH-VECTOR TLV Flag Field" sub-registry: allocation from the "NO-PATH-VECTOR TLV Flag Field" sub-registry:
Bit Description Reference Bit Description Reference
24 P2MP Reachability Problem This.I-D 24 P2MP Reachability Problem This.I-D
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Adrian Farrel, Young Lee, Dan The authors would like to thank Adrian Farrel, Young Lee, Dan
Tappan, Autumn Liu, Huaimo Chen, and Eiji Oki for their valuable Tappan, Autumn Liu, Huaimo Chen, Eiji Okim, Nick Neate, Suresh
comments on this draft. Babu K,Dhruv Dhody, Udayasree Palle, Gaurav Agrawal and Vishwas
Manral for their valuable comments and input on this draft.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
"Path Computation Element (PCE) Communication Protocol "Path Computation Element (PCE) Communication Protocol
(PCEP)", RFC 5440, March 2009. (PCEP)", RFC 5440, March 2009.
[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.
[RFC5073] Vasseur, JP., Le Roux, JL., "IGP Routing Protocol
Extensions for Discovery of Traffic Engineering Node
Capabilities", RFC 5073, December 2007.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element "OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008. (PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
skipping to change at page 28, line 15 skipping to change at page 28, line 19
[RFC5541] [RFC5541]
Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective
Functions in the Path Computation Element Communication Functions in the Path Computation Element Communication
Protocol (PCEP)", RFC5541, December 2008. Protocol (PCEP)", RFC5541, December 2008.
8.2. Informative References 8.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[PCE-P2MP-APP] [RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the Path
Yasukawa, S. and A. Farrel, Computation Element (PCE) to Point-to-Multipoint (P2MP)
"draft-ietf-pce-p2mp-app-02.txt", MPLS and GMPLS Traffic Engineering (TE)" RFC 5671,
draft-ietf-pce-p2mp-app-02 (work in progress),
October 2009. October 2009.
[PCE-P2MP-REQ] [PCE-P2MP-REQ]
Yasukawa, S. and A. Farrel, "PCC-PCE Communication Yasukawa, S. and A. Farrel, "PCC-PCE Communication
Requirements for Point to Multipoint Multiprotocol Label Requirements for Point to Multipoint Multiprotocol Label
Switching Traffic Engineering (MPLS-TE)", Switching Traffic Engineering (MPLS-TE)",
draft-ietf-pce-p2mp-req-03 (work in progress), draft-ietf-pce-p2mp-req-04 (work in progress),
October 2009. December 2009.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and Ash,
J., "Policy-Enabled Path Computation Framework",
RFC 5394, December 2008.
9. Authors' Addresses 9. Authors' Addresses
Quintin Zhao (editor) Quintin Zhao (editor)
Huawei Technology Huawei Technology
125 Nagog Technology Park 125 Nagog Technology Park
Acton, MA 01719 Acton, MA 01719
US US
Email: qzhao@huawei.com Email: qzhao@huawei.com
 End of changes. 44 change blocks. 
87 lines changed or deleted 103 lines changed or added

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