MPLS Working Group Z. Ali
Internet Draft Cisco Systems, Inc.
Intended status: Standard Track November 02, 2008
Expires: May 02, 2009
Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment
draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any 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 aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 02, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
Point-to-MultiPoint (P2MP) Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label
Switched Paths (TE LSPs) may be established using signaling
techniques described in [RFC4875]. However, [RFC4875] does not
Expires May 2009 [Page 1]
Internet-Draft draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt
address many issues that comes when a P2MP-TE LSP is signaled in
a multi-domain networks. Specifically, one of the issues in
multi-domain networks is how to allow computation of a loosely
routed P2MP-TE LSP such that it is remerge free. This document
provides a framework and required protocol extensions needed for
establishing and controlling P2MP MPLS and GMPLS TE LSPs in
multi-domain networks.
This document borrows inter-domain TE terminology from
[RFC4726], e.g., for the purposes of this document, a domain
is considered to be any collection of network elements within
a common sphere of address management or path computational
responsibility. Examples of such domains include Interior
Gateway Protocol (IGP) areas and Autonomous Systems (ASes).
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC-2119.
Table of Contents
1. Introduction...............................................2
2. Framework..................................................4
3. RSVP-TE signaling extensions...............................4
3.1. Multiple S2L Sub-LSPs in One Path Message.............4
3.2. Single S2L Sub-LSPs in One Path Message...............4
3.3. Grafting..............................................7
3.4. Crankback and Path Error..............................7
4. Security Considerations....................................7
5. IANA Considerations........................................8
6. References.................................................8
6.1. Normative References..................................8
6.2. Informative References................................8
Author's Addresses............................................8
Intellectual Property Statement...............................8
Disclaimer of Validity........................................9
1. Introduction
[RFC4875] describes how to set up point-to-multipoint (P2MP)
Traffic Engineering Label Switched Paths (TE LSPs) for use in
Expires May 2009 [Page 2]
Internet-Draft draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt
MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
networks.
As with all other RSVP controlled LSPs, P2MP LSP state is
managed using RSVP messages. While the use of RSVP messages is
mostly similar to their P2P counterpart, P2MP LSP state differs
from P2P LSP in a number of ways. E.g., the P2MP LSP must also
handle the state "re-merge" problem, see [RFC4875]. The term "re-
merge" refers to the case of an ingress or transit node that
creates a branch of a P2MP LSP, a re-merge branch that intersects
the P2MP LSP at another node farther down the tree. This may
occur due to such events as an error in path calculation, an
error in manual configuration, or network topology changes during
the establishment of the P2MP LSP. Consequently one of the
requirements for signaling P2MP LSP is for the Ingress node to
compute a P2MP path that is re-merge free. In some deployments,
it may also be requires to signal P2MP LSPs that are both remerge
and crossover free [RFC4875].
This requirement becomes more acute to address when P2MP LSP
spans multiple domains. For the purposes of this document, a
domain is considered to be any collection of network elements
within a common sphere of address management or path
computational responsibility. Examples of such domains include
Interior Gateway Protocol (IGP) areas and Autonomous Systems
(ASes). This is because in an inter-domain environment, the
ingress node may not have topological visibility into other
domains to be able to compute and signal a re-merge free P2MP
LSP. In an inter-domain environment, signaling for a given
(Source-to-Leaf) S2L or a set of S2Ls may contain MPLS Traffic
Engineering loosely routed explicit LSPs. A loosely routed
explicit LSP path is a path specified as a combination of strict
and loose hop(s) that contains at least one loose hop and zero or
more strict hop(s). When a border node is presented with a loose
ERO (for a given S2L or a subset of S2Ls), it may not have full
visibility on the P2MP LSP destinations to be able to expend the
ERO such that overall P2MP LSP is remerge free. The issue becomes
even more acute when one path message per S2L is used.
The document propose a simple extension to allow border nodes
with just enough information about the P2MP LSP so that they can
expand EROs for individual S2Ls such that overall P2MP LSP is
remerge free. Specifically, this document proposes a notion of
passing a list of addresses to a border node, for all S2Ls of a
P2MP LSP that transits from that border node. This list of
addresses contains addresses for which the given border node
needs to expend the EROs to, for all S2L of the P2MP LSP that
transit through the border router. Alternatively, if aggregated
signaling is used, path messages for all S2Ls that transit
Expires May 2009 [Page 3]
Internet-Draft draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt
through a given domain can be aggregated into a single Path
message using signaling option specified in [RFC4875]. In either
case, the idea is provide a border node with the knowledge of
other IP addresses w.r.t. which the route has to be re-merge
free. This enables the border node to expend route for a given
P2MP LSP in a re-merge free manner. This also allows a border
node to find an overall better P2MP path for the LSP.
Need for finding an end-to-end path that is remerge free also
increases chances for crankbacks during setting up a P2MP LSP
from their P2P counterpart. Nonetheless, crankback mechanisms for
P2MP LSP are not addressed by [RFC4875]. The document also
describes how crankback signaling extensions for MPLS and GMPLS
RSVP-TE defined in [RFC4920] applies to setting up P2MP TE LSPs.
The solution also does not guarantee optimization of the overall
P2MP tree. PCE can be used, instead, to address optimization of
the overall P2MP tree [PCE-P2MP-BRPC].
2. Framework
TBA
3. RSVP-TE signaling extensions
This section describes the signaling extensions required to
address the above-mentioned functionality.
3.1. Multiple S2L Sub-LSPs in One Path Message
When multiple S2Ls are carried in the single Path messages it is
RECOMMENDED that P2MP LSP is partitioned in such a way that the
Path message to a border node, where ERO expansion is desired,
contains all S2Ls of the P2MP LSP that transit through that
border router. This enabled border node to get the information
about all nodes this border node needs to expend EROs to. Hence,
the border node to expend all routes in a re-merged free and a
more cost effective manner without any protocol expansion.
When multiple S2Ls are carried in the single Path messages but
the above mentioned criteria cannot be or is not satisfied, is to
be addressed in a later version of the document.
3.2. Single S2L Sub-LSPs in One Path Message
When a Path message contains only one S2L sub-LSP, the following
extension MAY be followed to achieve ERO expansion in a remerge
free and a more cost effective manner. As specified in [RFC3209],
Expires May 2009 [Page 4]
Internet-Draft draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt
loose hops are listed in the ERO object of the RSVP Path message
with the L flag of the IPv4 or the IPv6 prefix sub-object set.
When ERO in the Path message of a P2MP LSP contains a loose hop,
the Path message MAY (optionally) contain a "Related Addresses
for Sibling S2L sub-LSP" object for each loose hop specified in
the ERO.
Class = TBA, C_Type = TBA
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address of the border node |
| IPv4 address from related sibling S2L sub-LSP 1 |
| IPv4 address from related sibling S2L sub-LSP 2 |
| IPv4 address from related sibling S2L sub-LSP 1 |
// //
| IPv4 address from related sibling S2L sub-LSP last |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
0x01 IPv4 address
Length
The Length contains the total length of the object in bytes,
including the Type and Length fields. The Length is variable
depending on the addresses in the list.
IPv4 address of the border node
IPv4 address of the target border node, where ERO extension
for this and related S2L sub-LSPs of the P2MP LSP is desired.
This address MUST match with on of the IPv4 addresses contained
in the ERO with L flag.
IPv4 address from related sibling S2L sub-LSP x
IPv4 address of a node on another sibling S2L sub-LSP x, which
is signaled in a separate Path message but which also require ERO
extension at the border node contained in IPv4 address of the
border node field. Together this list contains all addresses on a
given P2MP LSP to which the border node needs to expend the EROs.
Expires May 2009 [Page 5]
Internet-Draft draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address of the border node |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address from related sibling S2L sub-LSP 1 |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address from related sibling S2L sub-LSP 2 |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address from related sibling S2L sub-LSP 1 |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
| IPv6 address from related sibling S2L sub-LSP last |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
0x02 IPv6 address
Length
The Length contains the total length of the object in bytes,
including the Type and Length fields. The Length is variable
depending on the addresses in the list.
Expires May 2009 [Page 6]
Internet-Draft draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt
IPv6 address of the border node
IPv6 address of the target border node, where ERO extension
for this and related S2L sub-LSPs of the P2MP LSP is desired.
This address MUST match with on of the IPv6 addresses contained
in the ERO with L flag.
IPv6 address from related sibling S2L sub-LSP x
IPv6 address of a node on another sibling S2L sub-LSP x, which
is signaled in a separate Path message but which also require ERO
extension at the border node contained in IPv6 address of the
border node field. Together this list contains all addresses on a
given P2MP LSP to which the border node needs to expend the EROs.
3.3. Grafting
Grafting for an S2L sub-LSP achieved by the Ingress node
signaling it with the same P2MP ID and LSP ID, via existing or
new border nodes with loose hop expansion. If an existing border
node is used along the path, the border node locally finds how
ERO expansions for other siblings of the P2MP LSP transiting
through this border node is done and expends the route of new S2L
such that it's remerge free.
3.4. Crankback and Path Error
If a (border) node is unable to find a route that can supply the
required resources or is not remerge free, it can generate
crankback or Path Error for a subset of S2L it's not able to
expend the Path. For this purpose the (border) node SHOULD try to
find a minimum subset of S2L for which crankback or Path Error
needs to be generated. This rule applies equally to the case
where Multiple S2L Sub-LSPs are signaled using one Path message,
as well as to the case where a single S2L Sub-LSPs is signaled
using one Path message. More details on crankback signaling
extensions for P2MP-TE LSP are to be added in a later version.
4. Security Considerations
Security considerations and requirements from [RFC3209] and
[RFC4875] apply equally to this document. Furthermore, there are
some additional security considerations that may be induced by
the use of "Related Addresses for Sibling S2L sub-LSP" object
defined in this document. These security considerations will be
added in a later version of the draft.
Expires May 2009 [Page 7]
Internet-Draft draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt
5. IANA Considerations
Code points for "Related Addresses for Sibling S2L sub-LSP"
object defined in this document will be required. Much of the
details here are TBA.
6. References
6.1. Normative References
[RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et al,
"Extensions to RSVP-TE for Point-to-Multipoint TE
LSPs", RFC4875.
[RFC4920] A. Farrel, et al,
"Crankback Signaling Extensions for MPLS and GMPLS
RSVP-TE", RFC4920.
6.2. Informative References
[RFC4726] A. Farrel, J.-P. Vasseur, A. Ayyangar, "A Framework for
Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006.
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[PCE-P2MP-BRPC] Z. Ali, et al, "BRPC extensions for computation
of Point-to-Multipoint Traffic Engineering Label Switched Paths",
draft-ali-pce-brpc-p2mp-extension, work in progress.
Author's Addresses
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Expires May 2009 [Page 8]
Internet-Draft draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to
the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Expires May 2009 [Page 9]