draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-00.txt   draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt 
MPLS Working Group Zafar Ali MPLS Working Group Zafar Ali
Internet-Draft Rakesh Gandhi Internet-Draft Rakesh Gandhi
Intended status: Standards Track Tarek Saad Intended status: Standards Track Tarek Saad
Expires: May 12, 2013 Cisco Systems, Inc. Expires: October 14, 2013 Cisco Systems, Inc.
Robert H. Venator Robert H. Venator
Defense Information Systems Agency Defense Information Systems Agency
Yuji Kamite Yuji Kamite
NTT Communications Corporation NTT Communications Corporation
November 8, 2012 April 12, 2013
Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment
draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-00 draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01
Abstract Abstract
Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE
LSPs) are established using signaling procedures defined in LSPs) are established using signaling procedures defined in
[RFC4875]. However, [RFC4875] does not address several issues that [RFC4875]. However, [RFC4875] does not address several issues that
arise when a P2MP-TE LSP is signaled in inter-domain networks. One arise when a P2MP-TE LSP is signaled in inter-domain networks. One
such issue is the computation of a loosely routed inter-domain P2MP- such issue is the computation of a loosely routed inter-domain P2MP-
TE LSP paths that are re-merge free. Another issue is the TE LSP paths that are re-merge free. Another issue is the
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 12, 2013. This Internet-Draft will expire on October 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Summary of Solutions . . . . . . . . . . . . . . . . . . . 4 1.1. Summary of Solutions . . . . . . . . . . . . . . . . . . . 5
1.2. Path Computation Techniques . . . . . . . . . . . . . . . 5 1.2. Path Computation Techniques . . . . . . . . . . . . . . . 6
1.3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Conventions used in this document . . . . . . . . . . . . . . 6 2. Conventions used in this document . . . . . . . . . . . . . . 7
3. Control Plane Solution For Re-merge Handling . . . . . . . . . 6 3. Control Plane Solution For Re-merge Handling . . . . . . . . . 7
3.1. Single Border Node For All S2Ls . . . . . . . . . . . . . 6 3.1. Single Border Node For All S2Ls . . . . . . . . . . . . . 7
3.2. Crankback and PathErr Signaling Procedure . . . . . . . . 6 3.2. Crankback and PathErr Signaling Procedure . . . . . . . . 7
4. Data Plane Solution For Re-merge Handling . . . . . . . . . . 8 4. Data Plane Solution For Re-merge Handling . . . . . . . . . . 9
4.1. P2MP-TE Re-merge Recording Request Flag . . . . . . . . . 8 4.1. P2MP-TE Re-merge Recording Request Flag . . . . . . . . . 9
4.2. P2MP-TE Re-merge Present Flag . . . . . . . . . . . . . . 8 4.2. P2MP-TE Re-merge Present Flag . . . . . . . . . . . . . . 9
4.3. Signaling Procedure . . . . . . . . . . . . . . . . . . . 9 4.3. Signaling Procedure . . . . . . . . . . . . . . . . . . . 10
5. Intra-domain P2MP-TE LSP Re-merge Handling . . . . . . . . . . 10 5. Intra-domain P2MP-TE LSP Re-merge Handling . . . . . . . . . . 11
6. Reoptimization Handling . . . . . . . . . . . . . . . . . . . 11 6. Reoptimization Handling . . . . . . . . . . . . . . . . . . . 12
6.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 11 6.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 12
6.2. Preferable P2MP-TE Tree Exists Flag . . . . . . . . . . . 11 6.2. Preferable P2MP-TE Tree Exists sub-code . . . . . . . . . 12
6.3. Signaling Procedure . . . . . . . . . . . . . . . . . . . 11 6.3. Signaling Procedure . . . . . . . . . . . . . . . . . . . 12
7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9.1 P2MP-TE Re-merge Recording Request Flag . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.2 P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.3 P2MP-TE Re-merge Present Flag . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 15 9.4 Preferable P2MP-TE Tree Exists sub-code . . . . . . . . . . 15
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 16
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
[RFC4875] describes procedures to set up Point-to-Multipoint (P2MP) [RFC4875] describes procedures to set up Point-to-Multipoint (P2MP)
Traffic Engineering Label Switched Paths (TE LSPs) for use in Traffic Engineering Label Switched Paths (TE LSPs) for use in
MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
networks. networks.
As with Point-to-Point (P2P) TE LSPs, P2MP TE LSP state is managed As with Point-to-Point (P2P) TE LSPs, P2MP TE LSP state is managed
using RSVP messages. While the use of RSVP messages is mostly similar using RSVP messages. While the use of RSVP messages is mostly similar
skipping to change at page 11, line 25 skipping to change at page 12, line 25
In order to query border nodes to check if a preferable P2MP tree In order to query border nodes to check if a preferable P2MP tree
exists, a new flag is defined in Attributes Flags TLV of the exists, a new flag is defined in Attributes Flags TLV of the
LSP_ATTRIBUTES object [RFC5420] as follows: LSP_ATTRIBUTES object [RFC5420] as follows:
Bit Number (to be assigned by IANA): P2MP-TE Tree Re-evaluation Bit Number (to be assigned by IANA): P2MP-TE Tree Re-evaluation
Request flag Request flag
The "P2MP-TE Tree Re-evaluation Request" flag is meaningful in a Path The "P2MP-TE Tree Re-evaluation Request" flag is meaningful in a Path
message of an S2L sub-LSP and is inserted by the ingress node. message of an S2L sub-LSP and is inserted by the ingress node.
6.2. Preferable P2MP-TE Tree Exists Flag 6.2. Preferable P2MP-TE Tree Exists sub-code
In order to indicate to an ingress node that a preferable P2MP-TE In order to indicate to an ingress node that a preferable P2MP-TE
tree is available, following new sub-code for PathErr code 25 (notify tree is available, following new sub-code for PathErr code 25 (Notify
error) is defined: Error) [RFC3209] is defined:
Sub-code (to be assigned by IANA): Preferable P2MP-TE Tree Exists Sub-code (to be assigned by IANA): Preferable P2MP-TE Tree Exists
flag sub-code
When a preferable P2MP-TE tree is found, the border node MUST send When a preferable P2MP-TE tree is found, the border node MUST send
"Preferable P2MP-TE Tree Exists" to the ingress node in order to "Preferable P2MP-TE Tree Exists" PathErr to the ingress node in order
reoptimize the entire P2MP LSP. to reoptimize the entire P2MP LSP.
6.3. Signaling Procedure 6.3. Signaling Procedure
Using signaling procedure defined in [RFC4736], an ingress node MUST Using signaling procedure defined in [RFC4736], an ingress node MUST
initiate "path re-evaluation request" query to reoptimize a initiate "path re-evaluation request" query to reoptimize a
destination in a P2MP LSP. Note that this message MUST be used to destination in a P2MP LSP. Note that this message MUST be used to
reoptimize a single or a sub-set of the destinations in a P2MP LSP. reoptimize a single or a sub-set of the destinations in a P2MP LSP.
Ingress node MUST send this query in a Path message for each Ingress node MUST send this query in a Path message for each
destination it is reoptimizing. destination it is reoptimizing.
skipping to change at page 13, line 22 skipping to change at page 14, line 22
and unmodified, in all messages resulting from this message. and unmodified, in all messages resulting from this message.
8. Security Considerations 8. Security Considerations
This document does not introduce any additional security issues above This document does not introduce any additional security issues above
those identified in [RFC3209], [RFC4875], [RFC5151], [RFC4920] and those identified in [RFC3209], [RFC4875], [RFC5151], [RFC4920] and
[RFC5920]. [RFC5920].
9. IANA Considerations 9. IANA Considerations
IANA maintains a name space for RSVP-TE TE parameters "Resource
Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters". From
the registries in this name space "Attribute Flags" and "Record Route
Object Sub-object Flags" allocation of new flags are requested
(sections 9.1 - 9.3).
IANA also maintains a name space for RSVP protocol parameters
"Resource Reservation Protocol (RSVP) Parameters". From the sub-
registry "Sub-Codes - 25 Notify Error" in registry "Error Codes and
Globally-Defined Error Value Sub-Codes" allocation of a new error
code is requested (section 9.4).
9.1 P2MP-TE Re-merge Recording Request Flag
The following new flag is defined for the Attributes Flags TLV in the The following new flag is defined for the Attributes Flags TLV in the
LSP_ATTRIBUTES object [RFC5420]. The numeric values are to be LSP_ATTRIBUTES object [RFC5420]. The numeric values are to be
assigned by IANA. assigned by IANA.
o P2MP-TE Re-merge Recording Request Flag: o P2MP-TE Re-merge Recording Request Flag:
- Bit Number: To be assigned by IANA. - Bit Number: To be assigned by IANA.
- Attribute flag carried in Path message: Yes - Attribute flag carried in Path message: Yes
- Attribute flag carried in Resv message: No - Attribute flag carried in Resv message: No
The following new flag is defined for the RRO Attributes sub-object 9.2 P2MP-TE Tree Re-evaluation Request Flag
in the RECORD_ROUTE object [RFC5420]. The numeric values are to be
The following new flag is defined for the Attributes Flags TLV in the
LSP_ATTRIBUTES object [RFC5420]. The numeric values are to be
assigned by IANA. assigned by IANA.
o P2MP-TE Re-merge Present Flag: o P2MP-TE Tree Re-evaluation Request Flag:
- Bit Number: To be assigned by IANA. - Bit Number: To be assigned by IANA.
- Attribute flag carried in Path message: No - Attribute flag carried in Path message: Yes
- Attribute flag carried in RRO Attributes sub-object in RRO of - Attribute flag carried in Resv message: No
the Resv message: Yes
The following new flag is defined for the Attributes Flags TLV in the 9.3 P2MP-TE Re-merge Present Flag
LSP_ATTRIBUTES object [RFC5420]. The numeric values are to be
The following new flag is defined for the RRO Attributes sub-object
in the RECORD_ROUTE object [RFC5420]. The numeric values are to be
assigned by IANA. assigned by IANA.
o P2MP-TE Tree Re-evaluation Request Flag: o P2MP-TE Re-merge Present Flag:
- Bit Number: To be assigned by IANA. - Bit Number: To be assigned by IANA.
- Attribute flag carried in Path message: Yes - Attribute flag carried in Path message: No
- Attribute flag carried in Resv message: No - Attribute flag carried in RRO Attributes sub-object in RRO of
the Resv message: Yes
9.4 Preferable P2MP-TE Tree Exists sub-code
As defined in [RFC3209], the Error Code 25 in the ERROR SPEC object As defined in [RFC3209], the Error Code 25 in the ERROR SPEC object
corresponds to a Notify Error PathErr. This document adds a new sub- corresponds to a Notify Error PathErr. This document adds a new sub-
code as follows for this PathErr: code as follows for this PathErr:
o Preferable P2MP-TE Tree Exists sub-code: o Preferable P2MP-TE Tree Exists sub-code:
- Sub-code for Notify PathErr code 25. To be assigned by - Sub-code for Notify PathErr code 25. To be assigned by
IANA. IANA.
10. Acknowledgments 10. Acknowledgments
The authors would like to thank N. Neate for his contributions on the The authors would like to thank N. Neate for his contributions on the
draft. draft.
11. References 11. References
11.1. Normative References 11.1. Normative References
 End of changes. 20 change blocks. 
48 lines changed or deleted 72 lines changed or added

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