draft-ietf-pce-p2mp-req-03.txt   draft-ietf-pce-p2mp-req-04.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
Created: October 16, 2009 Old Dog Consulting Created: December 4, 2009 Old Dog Consulting
Expires: April 16, 2010 Expires: June 4, 2010
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-03.txt draft-ietf-pce-p2mp-req-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 4, line 17 skipping to change at page 4, line 17
R5: Since P2MP LSPs have more than one destination, it MUST be R5: Since P2MP LSPs have more than one destination, it MUST be
possible for a single Path Computation Request to list multiple possible for a single Path Computation Request to list multiple
destinations. destinations.
2.1.6. Indication of P2MP Paths 2.1.6. Indication of P2MP Paths
R6: The Path Computation Response MUST be able to carry the path of R6: The Path Computation Response MUST be able to carry the path of
a P2MP LSP. a P2MP LSP.
P2MP paths can be expressed as a compacted series of routes as P2MP paths can be expressed as a compressed series of routes as
described in [RFC4875]. The Path Computation Response MUST be able to described in [RFC4875]. The Path Computation Response MUST be able to
carry the P2MP path as either a compacted path (but not necessarily carry the P2MP path as either a compressed path (but not necessarily
using the identical encoding as described in [RFC4875]), or as a non- using the identical encoding as described in [RFC4875]), or as a non-
compacted path comprising a series of source-to-leaf point-to-point compressed path comprising a series of source-to-leaf point-to-point
(P2P) paths (known as S2L sub-paths). (P2P) paths (known as S2L sub-paths).
R7: By default, the path returned by the PCE SHOULD use the R7: By default, the path returned by the PCE SHOULD use the
compacted format. compressed format.
The request from the PCC MAY allow the PCC to express a The request from the PCC MAY allow the PCC to express a
preference for receiving a compacted or non-compacted P2MP path preference for receiving a compressed or non-compressed P2MP
in the response. path in the response.
2.1.7. Multi-Message Requests and Responses 2.1.7. Multi-Message Requests and Responses
R8: A single P2MP LSP may have very many destinations, and the R8: A single P2MP LSP may have very many destinations, and the
computed path (tree) may be very extensive. In these cases it is computed path (tree) may be very extensive. In these cases it is
possible that the entire Path Computation Request or Response possible that the entire Path Computation Request or Response
cannot fit within one PCE message. Therefore, it MUST be cannot fit within one PCE message. Therefore, it MUST be
possible for a single request or response to be conveyed by a possible for a single request or response to be conveyed by a
sequence of PCE messages. sequence of PCE messages.
skipping to change at page 5, line 14 skipping to change at page 5, line 14
destinations of a P2MP LSP within a single computation request. destinations of a P2MP LSP within a single computation request.
2.1.9. Path Modification and Path Diversity 2.1.9. Path Modification and Path Diversity
R10: No changes are made to the requirement to support path R10: No changes are made to the requirement to support path
modification and path diversity as described in [RFC4657]. Note, modification and path diversity as described in [RFC4657]. Note,
however, that a consequence of this requirement is that it MUST however, that a consequence of this requirement is that it MUST
be possible to supply an existing path on a Path Computation be possible to supply an existing path on a Path Computation
Request. This requirement is unchanged from [RFC4657], but it is Request. This requirement is unchanged from [RFC4657], but it is
a new requirement that such paths MUST be able to be P2MP paths. a new requirement that such paths MUST be able to be P2MP paths.
The PCC MUST be able to supply these paths as compacted paths or The PCC MUST be able to supply these paths as compressed paths
as a non-compacted paths (see Section 2.1.6) according to the or as a non-compressed paths (see Section 2.1.6) according to
preference of the PCC. the preference of the PCC.
2.1.10. Reoptimization of P2MP TE LSPs 2.1.10. Reoptimization of P2MP TE LSPs
R11: Reoptimization MUST be supported for P2MP TE LSPs as described R11: Reoptimization MUST be supported for P2MP TE LSPs as described
for P2P LSPs in [RFC4657]. To support this, the existing path for P2P LSPs in [RFC4657]. To support this, the existing path
MUST be supplied as described in Section 2.1.9. MUST be supplied as described in Section 2.1.9.
Because P2MP LSPs are more complex it is often the case that Because P2MP LSPs are more complex it is often the case that
small optimization improvements can be made after changes in small optimization improvements can be made after changes in
network resource availability. But re-signaling any LSP network resource availability. But re-signaling any LSP
 End of changes. 8 change blocks. 
12 lines changed or deleted 12 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/