draft-ietf-pce-p2mp-req-00.txt   draft-ietf-pce-p2mp-req-01.txt 
Network Working Group S. Yasukawa Network Working Group S. Yasukawa
Internet Draft NTT Internet Draft NTT
Category: Informational A. Farrel Category: Informational A. Farrel (Ed.)
Created: August 8, 2008 Old Dog Consulting Created: February 13, 2009 Old Dog Consulting
Expires: February 8, 2009 Expires: August 13, 2009
PCC-PCE Communication Requirements for Point to Multipoint PCC-PCE Communication Requirements for Point to Multipoint
Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Multiprotocol Label Switching Traffic Engineering (MPLS-TE)
draft-ietf-pce-p2mp-req-00.txt draft-ietf-pce-p2mp-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
applicable patent or other IPR claims of which he or she is aware the 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 other groups may also distribute working documents as
Internet-Drafts. 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 2, line 31 skipping to change at page 2, line 31
Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are
documented in [RFC4461] and signaling protocol extensions for documented in [RFC4461] and signaling protocol extensions for
setting up P2MP MPLS TE LSPs are defined in [RFC4875]. P2MP MPLS TE setting up P2MP MPLS TE LSPs are defined in [RFC4875]. P2MP MPLS TE
networks are considered in support of various features including networks are considered in support of various features including
layer 3 multicast VPNs [RFC4834]. layer 3 multicast VPNs [RFC4834].
Path computation for P2MP TE LSPs presents a significant challenge, Path computation for P2MP TE LSPs presents a significant challenge,
and network optimization of multiple P2MP TE LSPs requires and network optimization of multiple P2MP TE LSPs requires
considerable computational resources. PCE offers a way to offload considerable computational resources. PCE offers a way to offload
such path computations from Label Swiching Routers (LSRs). such path computations from Label Switching Routers (LSRs).
The applicability of the PCE-based path computation architecture to The applicability of the PCE-based path computation architecture to
P2MP MPLS TE is described in a companion document [PCE-P2MP-APP]. No P2MP MPLS TE is described in a companion document [PCE-P2MP-APP]. No
further attempt is made to justify the use of PCE for P2MP MPLS TE further attempt is made to justify the use of PCE for P2MP MPLS TE
within this document. within this document.
This document presents a set of PCC-PCE communication protocol This document presents a set of PCC-PCE communication protocol
(PCECP) requirements for P2MP MPLS traffic engineering. It (PCECP) requirements for P2MP MPLS traffic engineering. It
supplements the generic requirements documented in [RFC4657]. supplements the generic requirements documented in [RFC4657].
skipping to change at page 5, line 20 skipping to change at page 5, line 31
Because P2MP LSPs are more complex it is often the case that small Because P2MP LSPs are more complex it is often the case that small
optimization improvements can be made after changes in network optimization improvements can be made after changes in network
resource availability. But re-signaling any LSP introduces risks to resource availability. But re-signaling any LSP introduces risks to
the stability of the service provided to the customer and the the stability of the service provided to the customer and the
stability of the network even when techniques like make-before-break stability of the network even when techniques like make-before-break
[RFC3209] are used. Therefore, a P2MP Path Computation Request SHOULD [RFC3209] are used. Therefore, a P2MP Path Computation Request SHOULD
contain a parameter that allows the PCC to express a cost-benefit contain a parameter that allows the PCC to express a cost-benefit
reoptimization threshold for the whole LSP as well as per reoptimization threshold for the whole LSP as well as per
destination. The setting of this parameter is subject to local policy destination. The setting of this parameter is subject to local policy
at the PCC and SHOULD be subject to policy at the PCE [PCE-POLICY]. at the PCC and SHOULD be subject to policy at the PCE [RFC5394].
Path reoptimization responses SHOULD indicate which of the routes (as Path reoptimization responses SHOULD indicate which of the routes (as
supplied according to Section 2.1.6) have been modified from the supplied according to Section 2.1.6) have been modified from the
paths supplied on the request. paths supplied on the request.
2.1.11. Addition and Removal of Destinations from Existing Paths 2.1.11. Addition and Removal of Destinations from Existing Paths
A variation of path modification described in Section 2.1.9 is that A variation of path modification described in Section 2.1.9 is that
destinations may be added to, or removed from, existing P2MP TE LSPs. destinations may be added to, or removed from, existing P2MP TE LSPs.
skipping to change at page 6, line 17 skipping to change at page 6, line 31
before the deletion of the destinations) on the Path Computation before the deletion of the destinations) on the Path Computation
Request. Request.
For both addition and deletion of destinations, the Path Computation For both addition and deletion of destinations, the Path Computation
Response SHOULD indicate which of the routes (as supplied according Response SHOULD indicate which of the routes (as supplied according
to Section 2.1.6) have been modified from the paths supplied on the to Section 2.1.6) have been modified from the paths supplied on the
request as described in Section 2.1.10. request as described in Section 2.1.10.
Note that the selection of all of these options is subject to local Note that the selection of all of these options is subject to local
policy at the PCC, and SHOULD be subject to policy at the PCE policy at the PCC, and SHOULD be subject to policy at the PCE
[PCE-POLICY]. [RFC5394].
2.1.12. Specification of Applicable Branch Nodes 2.1.12. Specification of Applicable Branch Nodes
For administrative or security reasons, or for other policy reasons, For administrative or security reasons, or for other policy reasons,
it may be desirable to limit the set of nodes within the network that it may be desirable to limit the set of nodes within the network that
may be used as branch points for a given LSP. That is, to provide to may be used as branch points for a given LSP. That is, to provide to
the path computation a limiting set of nodes that can be used as the path computation a limiting set of nodes that can be used as
branches for a P2MP path computation, or to provide a list of nodes branches for a P2MP path computation, or to provide a list of nodes
that must not be used as branch points. that must not be used as branch points.
The PCC MUST be able to specify on a Path Computation Request a list The PCC MUST be able to specify on a Path Computation Request a list
of nodes that constitues a limiting superset of the branch nodes for of nodes that constitutes a limiting superset of the branch nodes for
a P2MP path computation. a P2MP path computation.
A PCC MUST be able to specify on a Path Computation Request a list of A PCC MUST be able to specify on a Path Computation Request a list of
nodes that must not be used as branch nodes for a P2MP path nodes that must not be used as branch nodes for a P2MP path
computation. computation.
2.1.13. Capabilities Exchange 2.1.13. Capabilities Exchange
PCE capabilities exchange forms part of PCE discovery [RFC4674], but PCE capabilities exchange forms part of PCE discovery [RFC4674], but
may also be included in the PCECP message exchanges [RFC4657]. may also be included in the PCECP message exchanges [RFC4657].
skipping to change at page 7, line 38 skipping to change at page 8, line 10
control and monitoring or MAY be provided in a new MIB module. control and monitoring or MAY be provided in a new MIB module.
The MIB objects SHOULD provide the ability to control and monitor all The MIB objects SHOULD provide the ability to control and monitor all
aspects of PCECP relevant to P2MP MPLS TE path computation. aspects of PCECP relevant to P2MP MPLS TE path computation.
3.3. Liveness Detection and Monitoring 3.3. Liveness Detection and Monitoring
No changes are necessary to the liveness detection and monitoring No changes are necessary to the liveness detection and monitoring
requirements as already embodied in [RFC4657]. It should be noted, requirements as already embodied in [RFC4657]. It should be noted,
however, that in general P2MP computations are likely to take longer however, that in general P2MP computations are likely to take longer
than P2P computations. The liveness detection and molnitoring than P2P computations. The liveness detection and monitoring features
features of the PCECP SHOULD take this into account. of the PCECP SHOULD take this into account.
3.4. Verifying Correct Operation 3.4. Verifying Correct Operation
There are no additional requirements beyond those expressed in There are no additional requirements beyond those expressed in
[RFC4657] for verifying the correct operation of the PCECP. Note that [RFC4657] for verifying the correct operation of the PCECP. Note that
verification of the correct operation of the PCE and its algorithms verification of the correct operation of the PCE and its algorithms
is out of scope for the protocol requirements, but a PCC MAY send the is out of scope for the protocol requirements, but a PCC MAY send the
same request to more than one PCE and compare the results. same request to more than one PCE and compare the results.
3.5. Requirements on Other Protocols and Functional Components 3.5. Requirements on Other Protocols and Functional Components
skipping to change at page 9, line 9 skipping to change at page 9, line 31
7.1. Normative Reference 7.1. Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate [RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997. requirements levels", RFC 2119, March 1997.
[RFC4657] Ash, J., and Le Roux, J.L., "Path Computation Element [RFC4657] Ash, J., and Le Roux, J.L., "Path Computation Element
(PCE) Communication Protocol Generic Requirements", (PCE) Communication Protocol Generic Requirements",
RFC 4657, September 2006. RFC 4657, September 2006.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and Ash,
J., "Policy-Enabled Path Computation Framework",
RFC 5394, December 2008.
[PCE-P2MP-APP] S. Yasukawa et al., "Applicability of the Path [PCE-P2MP-APP] S. Yasukawa et al., "Applicability of the Path
Computation Element to Point-to-Multipoint Traffic Computation Element to Point-to-Multipoint Traffic
Engineering", draft-ietf-pce-p2mp-app, work in Engineering", draft-ietf-pce-p2mp-app, work in
progress. progress.
[PCE-POLICY] Bryskin, I., Papadimitriou, D., and Berger, L.,
"Policy-Enabled Path Computation Framework",
draft-ietf-pce-policy-enabled-path-comp, work in
progress.
7.2. Informative Reference 7.2. Informative Reference
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001. LSP Tunnels", RFC 3209, December 2001.
[RFC4461] S. Yasukawa, Editor "Signaling Requirements for [RFC4461] S. Yasukawa, Editor "Signaling Requirements for
Point-to-Multipoint Traffic Engineered MPLS LSPs", Point-to-Multipoint Traffic Engineered MPLS LSPs",
RFC4461, April 2006. RFC4461, April 2006.
skipping to change at page 10, line 18 skipping to change at page 10, line 45
NTT Corporation (R&D Strategy Department) NTT Corporation (R&D Strategy Department)
3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan
Email: s.yasukawa@hco.ntt.co.jp Email: s.yasukawa@hco.ntt.co.jp
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
9. Intellectual Property Statement 9. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF Trust takes no position regarding the validity or scope of
Intellectual Property Rights or other rights that might be claimed to any Intellectual Property Rights or other rights that might be
pertain to the implementation or use of the technology described in claimed to pertain to the implementation or use of the technology
this document or the extent to which any license under such rights described in any IETF Document or the extent to which any license
might or might not be available; nor does it represent that it has under such rights might or might not be available; nor does it
made any independent effort to identify any such rights. Information represent that it has made any independent effort to identify any
on the procedures with respect to rights in RFC documents can be such rights.
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- any 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.
10. Full Copyright Statement 10. 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
retain all their rights. (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. 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. 16 change blocks. 
39 lines changed or deleted 58 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/