draft-ietf-mpls-rsvp-te-p2mp-04.txt   draft-ietf-mpls-rsvp-te-p2mp-05.txt 
Network Working Group R. Aggarwal (Editor) Network Working Group R. Aggarwal (Editor)
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: October 2006 Expiration Date: November 2006
D. Papadimitriou (Editor) D. Papadimitriou (Editor)
Alcatel Alcatel
S. Yasukawa (Editor) S. Yasukawa (Editor)
NTT NTT
April 2006 May 2006
Extensions to RSVP-TE for Point to Multipoint TE LSPs Extensions to RSVP-TE for Point to Multipoint TE LSPs
draft-ietf-mpls-rsvp-te-p2mp-04.txt draft-ietf-mpls-rsvp-te-p2mp-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 5, line 9 skipping to change at page 5, line 9
25.1 Editor Information .................................... 49 25.1 Editor Information .................................... 49
25.2 Contributor Information ............................... 49 25.2 Contributor Information ............................... 49
26 Intellectual Property ................................. 52 26 Intellectual Property ................................. 52
27 Full Copyright Statement .............................. 52 27 Full Copyright Statement .............................. 52
28 Acknowledgement ....................................... 53 28 Acknowledgement ....................................... 53
1. Conventions used in this document 1. 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 [KEYWORDS]. document are to be interpreted as described in RFC-2119 [RFC2119].
2. Terminology 2. Terminology
This document uses terminologies defined in [RFC3031], [RFC2205], This document uses terminologies defined in [RFC3031], [RFC2205],
[RFC3209], [RFC3473] and [RFC4461]. [RFC3209], [RFC3473] and [RFC4461].
3. Introduction 3. Introduction
[RFC3209] defines a mechanism for setting up P2P TE LSPs in MPLS [RFC3209] defines a mechanism for setting up P2P TE LSPs in MPLS
networks. [RFC3473] defines extensions to [RFC3209] for setting up networks. [RFC3473] defines extensions to [RFC3209] for setting up
P2P TE LSPs in GMPLS networks. However these specifications do not P2P TE LSPs in GMPLS networks. However these specifications do not
provide a mechanism for building P2MP TE LSPs. provide a mechanism for building P2MP TE LSPs.
This document defines extensions to the RSVP-TE protocol [RFC3209, This document defines extensions to the RSVP-TE protocol [RFC3209],
RFC3473 to support P2MP TE LSPs satisfying the set of requirements [RFC3473] to support P2MP TE LSPs satisfying the set of requirements
described in [RFC4461]. described in [RFC4461].
This document relies on the semantics of RSVP that RSVP-TE inherits This document relies on the semantics of RSVP that RSVP-TE inherits
for building P2MP LSPs. A P2MP LSP is comprised of multiple S2L sub- for building P2MP LSPs. A P2MP LSP is comprised of multiple S2L sub-
LSPs. These S2L sub-LSPs are set up between the ingress and egress LSPs. These S2L sub-LSPs are set up between the ingress and egress
LSRs and are appropriately combined by the branch LSRs using RSVP LSRs and are appropriately combined by the branch LSRs using RSVP
semantics to result in a P2MP TE LSP. One Path message may signal one semantics to result in a P2MP TE LSP. One Path message may signal one
or multiple S2L sub-LSPs. Hence the S2L sub-LSPs belonging to a P2MP or multiple S2L sub-LSPs. Hence the S2L sub-LSPs belonging to a P2MP
LSP can be signaled using one Path message or split across multiple LSP can be signaled using one Path message or split across multiple
Path messages. Path messages.
skipping to change at page 13, line 40 skipping to change at page 13, line 40
if the ERO is present. If one or more SEROs are present an ERO MUST if the ERO is present. If one or more SEROs are present an ERO MUST
be present. The first S2L sub-LSP MUST be propagated in a Path be present. The first S2L sub-LSP MUST be propagated in a Path
message by each LSR along the explicit route specified by the ERO, if message by each LSR along the explicit route specified by the ERO, if
the ERO is present. Else it MUST be propagated using hop-by-hop the ERO is present. Else it MUST be propagated using hop-by-hop
routing towards the destination identified by the <S2L_SUB_LSP> routing towards the destination identified by the <S2L_SUB_LSP>
object. object.
A LSR MUST process a S2L sub-LSP descriptor for a subsequent S2L sub- A LSR MUST process a S2L sub-LSP descriptor for a subsequent S2L sub-
LSP as follows: LSP as follows:
If the <S2L_SUB_LSP> object is followed by an SERO, the LSR MUST check If the <S2L_SUB_LSP> object is followed by an SERO, the LSR MUST
the first hop in the SERO: check the first hop in the SERO:
- If the first hop of the SERO identifies a local address of the - If the first hop of the SERO identifies a local address of the
LSR, and the LSR is also the egress identified by the LSR, and the LSR is also the egress identified by the
<S2L_SUB_LSP> object, the descriptor MUST NOT be propagated <S2L_SUB_LSP> object, the descriptor MUST NOT be propagated
downstream, but the SERO may be used for egress control per downstream, but the SERO may be used for egress control per
[RFC4003]. [RFC4003].
- If the first hop of the SERO identifies a local address of the - If the first hop of the SERO identifies a local address of the
LSR, and the LSR is not the egress as identified by the LSR, and the LSR is not the egress as identified by the
<S2L_SUB_LSP> object the S2L sub-LSP descriptor MUST be <S2L_SUB_LSP> object the S2L sub-LSP descriptor MUST be
included in a Path message sent to the next-hop determined included in a Path message sent to the next-hop determined
from the SERO. from the SERO.
- If the first hop of the SERO is not a local address of the LSR - If the first hop of the SERO is not a local address of the LSR
the S2L sub-LSP descriptor MUST be included in the Path message the S2L sub-LSP descriptor MUST be included in the Path message
sent to LSR that is the next hop to reach the first hop in the sent to LSR that is the next hop to reach the first hop in the
SERO. This next hop is determined by using the ERO or other SERO. This next hop is determined by using the ERO or other
SEROs that encode the path to the SERO's first hop. SEROs that encode the path to the SERO's first hop.
If the <S2L_SUB_LSP> object is not followed by an SERO, the LSR MUST If the <S2L_SUB_LSP> object is not followed by an SERO, the LSR MUST
examine the <S2L_SUB_LSP> object: examine the <S2L_SUB_LSP> object:
- If this LSR is the egress as identified by the <S2L_SUB_LSP> - If this LSR is the egress as identified by the
object, the S2L sub-LSP descriptor MUST NOT be propagated <S2L_SUB_LSP> object, the S2L sub-LSP descriptor MUST
downstream. NOT be propagated downstream.
- If this LSR is not the egress as identified by the <S2L_SUB_LSP> - If this LSR is not the egress as identified by the
object, the LSR MUST make a routing decision to determine the <S2L_SUB_LSP> object, the LSR MUST make a routing decision
next hop towards the egress, and MUST include the S2L sub-LSP to determine the next hop towards the egress, and MUST
descriptor in a Path message sent to the next-hop towards the include the S2L sub-LSP descriptor in a Path message sent
egress. In this case, the LSR MAY insert an SERO into the to the next-hop towards the egress. In this case, the LSR
S2L sub-LSP descriptor. MAY insert an SERO into the S2L sub-LSP descriptor.
Hence a branch LSR MUST only propagate the relevant S2L sub-LSP Hence a branch LSR MUST only propagate the relevant S2L sub-LSP
descriptors on each downstream link. A S2L sub-LSP descriptor list descriptors on each downstream link. A S2L sub-LSP descriptor list
that is propagated on a downstream link MUST only contain those S2L that is propagated on a downstream link MUST only contain those S2L
sub-LSPs that are routed using that link. This processing MAY result sub-LSPs that are routed using that link. This processing MAY result
in a subsequent S2L sub-LSP in an incoming Path message to become the in a subsequent S2L sub-LSP in an incoming Path message to become the
first S2L sub-LSP in an outgoing Path message. first S2L sub-LSP in an outgoing Path message.
Note that if one or more SEROs contain loose hops, expansion of such Note that if one or more SEROs contain loose hops, expansion of such
loose hops MAY result in overflowing the Path message size. Section loose hops MAY result in overflowing the Path message size. Section
skipping to change at page 15, line 48 skipping to change at page 15, line 48
5.2.4. Control of Branch Fate Sharing 5.2.4. Control of Branch Fate Sharing
An ingress LSR can control the behavior of an LSP if there is a An ingress LSR can control the behavior of an LSP if there is a
failure during LSP setup or after an LSP has been established. The failure during LSP setup or after an LSP has been established. The
default behavior is that only the branches downstream of the failure default behavior is that only the branches downstream of the failure
are not established, but the ingress may request 'LSP integrity' such are not established, but the ingress may request 'LSP integrity' such
that any failure anywhere within the LSP tree causes the entire P2MP that any failure anywhere within the LSP tree causes the entire P2MP
LSP to fail. LSP to fail.
The ingress LSP may request 'LSP integrity' by setting bit [TBA] of The ingress LSP may request 'LSP integrity' by setting bit (TBA) of
the Attributes Flags TLV. The bit is set if LSP integrity is the Attributes Flags TLV. The bit is set if LSP integrity is
required. required.
It is RECOMMENDED to use the LSP_REQUIRED_ATTRIBUTES Object. It is RECOMMENDED to use the LSP_REQUIRED_ATTRIBUTES Object.
A branch LSR that supports the Attributes Flags TLV and recognizes A branch LSR that supports the Attributes Flags TLV and recognizes
this bit MUST support LSP integrity or reject the LSP setup with a this bit MUST support LSP integrity or reject the LSP setup with a
PathErr message carrying the error "Routing Error"/"Unsupported LSP PathErr message carrying the error "Routing Error"/"Unsupported LSP
Integrity" Integrity"
skipping to change at page 33, line 37 skipping to change at page 33, line 37
The corresponding explicit route contains a list of objects upto the The corresponding explicit route contains a list of objects upto the
P2MP capable LSR that is adjacent to a legacy LSR followed by a loose P2MP capable LSR that is adjacent to a legacy LSR followed by a loose
object with the address of the next P2MP capable LSR. The P2MP object with the address of the next P2MP capable LSR. The P2MP
capable LSR expands the loose hop using its TED. When doing this it capable LSR expands the loose hop using its TED. When doing this it
determines that the loose hop expansion requires a P2P LSP to tunnel determines that the loose hop expansion requires a P2P LSP to tunnel
through the legacy LSR. If such a P2P LSP exists, it uses that P2P through the legacy LSR. If such a P2P LSP exists, it uses that P2P
LSP. Else it establishes the P2P LSP. The P2MP Path message is sent LSP. Else it establishes the P2P LSP. The P2MP Path message is sent
to the next P2MP capable LSR using non-adjacent signaling. The P2MP to the next P2MP capable LSR using non-adjacent signaling. The P2MP
capable LSR that initiates the non-adjacent signaling message to the capable LSR that initiates the non-adjacent signaling message to the
next P2MP capable LSR may have to employ a fast detection mechanism next P2MP capable LSR may have to employ a fast detection mechanism
such as [BFD] to the next P2MP capable LSR. such as [BFD] [BFD-MPLS] to the next P2MP capable LSR.
This may be needed for the directed Path message Head-End to use node This may be needed for the directed Path message Head-End to use node
protection FRR when the protected node is the directed Path message protection FRR when the protected node is the directed Path message
tail. tail.
Note that legacy LSRs along a P2P LSP segment cannot perform node Note that legacy LSRs along a P2P LSP segment cannot perform node
protection of the tail of the P2P LSP segment. protection of the tail of the P2P LSP segment.
17. Reduction in Control Plane Processing with LSP Hierarchy 17. Reduction in Control Plane Processing with LSP Hierarchy
skipping to change at page 45, line 8 skipping to change at page 45, line 8
The Error Value "P2MP Re-Merge Parameter Mismatch" is described in The Error Value "P2MP Re-Merge Parameter Mismatch" is described in
section 18. IANA is requested to assign value 26 to this Error Value. section 18. IANA is requested to assign value 26 to this Error Value.
The Error Value "ERO Resulted in Remerge" is described in section 18. The Error Value "ERO Resulted in Remerge" is described in section 18.
IANA is requested to assign value 27 to this Error Value. IANA is requested to assign value 27 to this Error Value.
20.4. LSP Attributes Flags 20.4. LSP Attributes Flags
IANA has been asked to manage the space of flags in the Attibutes IANA has been asked to manage the space of flags in the Attibutes
Flags TLV carried in the LSP_REQUIRED_ATTRIBUTES Object [LSP-ATTRIB]. Flags TLV carried in the LSP_REQUIRED_ATTRIBUTES Object [LSP-ATTR].
This document defines a new flag as follows: This document defines a new flag as follows:
Suggested Bit Number: 3 Suggested Bit Number: 3
Meaning: LSP Integrity Required Meaning: LSP Integrity Required
Used in Attributes Flags on Path: Yes Used in Attributes Flags on Path: Yes
Used in Attributes Flags on Resv: No Used in Attributes Flags on Resv: No
Used in Attributes Flags on RRO: No Used in Attributes Flags on RRO: No
Referenced Section of this Doc: 10 Referenced Section of this Doc: 10
21. Security Considerations 21. Security Considerations
skipping to change at page 47, line 26 skipping to change at page 47, line 26
work in progress. work in progress.
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan,
G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC3209, December 2001, work in progress. RFC3209, December 2001, work in progress.
[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, work in Requirement Levels", BCP 14, RFC 2119, March 1997, work in
progress. progress.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and
"Resource ReSerVation Protocol (RSVP) -- Version 1, S. Jamin, "Resource ReSerVation Protocol (RSVP)
Functional Specification", RFC 2205, September 1997, work in -- Version 1, Functional Specification", RFC 2205,
progress. September 1997, work in progress.
[RFC3471] Lou Berger, et al., "Generalized MPLS - Signaling Functional [RFC3471] Lou Berger, et al., "Generalized MPLS - Signaling
Description", RFC 3471, January 2003, work in progress. Functional Description", RFC 3471, January 2003, work in
progress.
[RFC3473] L. Berger et.al., "Generalized MPLS Signaling - RSVP-TE [RFC3473] L. Berger et.al., "Generalized MPLS Signaling - RSVP-TE
Extensions", RFC 3473, January 2003, work in progress. Extensions", RFC 3473, January 2003, work in progress.
[RFC2961] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, [RFC2961] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi,
S. Molendini, "RSVP Refresh Overhead Reduction Extensions", S. Molendini, "RSVP Refresh Overhead Reduction Extensions"
RFC 2961, April 2001, work in progress. , RFC 2961, April 2001, work in progress.
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001, work in Label Switching Architecture", RFC 3031, January 2001,
progress. work in progress.
[RFC4090] P. Pan, G. Swallow, A. Atlas (Editors), "Fast Reroute Extensions [RFC4090] P. Pan, G. Swallow, A. Atlas (Editors), "Fast Reroute
to RSVP-TE for LSP Tunnels", work in progress. Extensions to RSVP-TE for LSP Tunnels", work in progress.
[RFC3477] K. Kompella, Y. Rekther, "Signalling Unnumbered Links in [RFC3477] K. Kompella, Y. Rekther, "Signalling Unnumbered Links in
Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", Resource ReSerVation Protocol - Traffic Engineering
work in progress. (RSVP-TE)", work in progress.
[RFC4461] S. Yasukawa, Editor "Signaling Requirements for [RFC4461] S. Yasukawa, Editor "Signaling Requirements for
Point-to-Multipoint Traffic Engineered MPLS LSPs", RFC4461. Point-to-Multipoint Traffic Engineered MPLS LSPs", RFC4461.
[RECOVERY] "GMPLS Based Segment Recovery", [RECOVERY] "GMPLS Based Segment Recovery",
draft-ietf-ccamp-gmpls-segment-recovery-02.txt draft-ietf-ccamp-gmpls-segment-recovery-02.txt
24.2. Informative References 24.2. Informative References
[BFD] D. Katz, D. Ward, "Bidirectional Forwarding Detection", [BFD] D. Katz, D. Ward, "Bidirectional Forwarding Detection",
draft-ietf-bfd-02.txt, work in progress. draft-ietf-bfd-02.txt, work in progress.
[BFD-MPLS] R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow, "BFD for MPLS [BFD-MPLS] R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow, "BFD for
LSPs", draft-ietf-bfd-mpls-01.txt, work in progress. MPLS LSPs", draft-ietf-bfd-mpls-01.txt, work in progress.
[IPR-1] Bradner, S., "IETF Rights in Contributions", BCP 78, [IPR-1] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004, work in progress. RFC 3667, February 2004, work in progress.
[IPR-2] Bradner, S., Ed., "Intellectual Property Rights in IETF [IPR-2] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004, work in progress. Technology", BCP 79, RFC 3668, February 2004, work in
progress.
[INT-REG] A. Farrel, J.P. Vasseur, and A. Ayyangar, "A Framework for [INT-REG] A. Farrel, J.P. Vasseur, and A. Ayyangar, "A Framework for
Inter-Domain MPLS Traffic Engineering", Inter-Domain MPLS Traffic Engineering",
draft-ietf-ccamp-inter-domain-framework-04.txt, work in draft-ietf-ccamp-inter-domain-framework-04.txt, work in
progress. progress.
[RFC2209] R. Braden, L. Zhang, "Resource Reservation Protocol (RSVP) [RFC2209] R. Braden, L. Zhang, "Resource Reservation Protocol (RSVP)
Version 1 Message Processing Rules", RFC 2209, work in progress. Version 1 Message Processing Rules", RFC 2209, work in
progress.
[LSP-STITCH] A. Ayyanger, J.P. Vasseur, "Label Switched Path Stitching [LSP-STITCH] A. Ayyanger, J.P. Vasseur, "Label Switched Path
with Generalized MPLS Traffic Engineering", Stitching with Generalized MPLS Traffic Engineering",
draft-ietf-ccamp-lsp-stitching-00.txt, April 2005 draft-ietf-ccamp-lsp-stitching-00.txt, April 2005
work in progress work in progress
[TE-NODE-CAP] JP Vasseur, JL Le Roux, et al. "Routing extensions for [TE-NODE-CAP] JP Vasseur, JL Le Roux, et al. "Routing extensions for
discovery of Traffic Engineering Node Capabilities", discovery of Traffic Engineering Node Capabilities",
draft-vasseur-ccamp-te-node-cap-00.txt, February 2005, draft-vasseur-ccamp-te-node-cap-00.txt, February 2005,
work in progress work in progress
[RFC4003] L. Berger, "GMPLS Signaling Procedure for Egress
Control", February, 2005.
25. Author Information 25. Author Information
25.1. Editor Information 25.1. Editor Information
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: rahul@juniper.net Email: rahul@juniper.net
 End of changes. 21 change blocks. 
40 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.30. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/