MPLS Working Group Z. Ali, Ed.
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track N. Neate
Expires: September 7, 2010 Data Connection Ltd
March 08, 2010
Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment
draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-04.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. This document may contain
material from IETF Documents or IETF Contributions published or
made publicly available before November 10, 2008. The person(s)
controlling the copyright in some of this material may not have
granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process. Without obtaining
an adequate license from the person(s) controlling the copyright
in such materials, this document may not be modified outside the
IETF Standards Process, and derivative works of it may not be
created outside the IETF Standards Process, except to format it
for publication as an RFC or to translate it into languages other
than English.
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 September 7, 2010.
Ali & Neate Expires September 2010 [Page 1]
Internet-Draft RSVP-TE P2MP Inter-domain LSPs October 2009
Copyright
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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. Code Components extracted from this
document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
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 address issues that arise
when a P2MP-TE LSP is signaled in multi-domain networks.
Specifically, it does not provide a mechanism to avoid re-merges in
inter-domain P2MP TE LSPs. This document provides a framework and
protocol extensions 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).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 4
2. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. RSVP-TE signaling extensions . . . . . . . . . . . . . . . . . 4
3.1. SIBLING_S2L object . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Format . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Processing . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Grafting . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Crankback and Path Error . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Ali & Neate Expires September 2010 [Page 2]
Internet-Draft RSVP-TE P2MP Inter-domain LSPs October 2009
1. Introduction
[RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic
Engineering Label Switched Paths (TE LSPs) for use in 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. In particular, the P2MP LSP must also handle
the "re-merge" problem described in [RFC4875] section 18.
The term "re-merge" refers to the situation when two S2L sub-LSPs
branch at some point in the P2MP tree, and then intersect again at a
another node further down the tree. This may occur due to
discrepencies in the routing algorithms used by different nodes,
errors in path calculation or manual configuration, or network
topology changes during the establishment of the P2MP LSP. Such re-
merges are inefficient due to the unnecessary duplication of data.
Consequently one of the requirements for signaling P2MP LSPs is
choose a P2MP path that is re-merge free. In some deployments, it
may also be required to signal P2MP LSPs that are both re-merge 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 that case, the border node for a new domain
will be given one or more loose next hops for the P2MP LSP. When
processing a path message, it may not have knowledge of all of the
destinations of the P2MP LSP, either because S2L sub-LSPs are split
between multiple Path messages, or because not all S2L sub-LSPs pass
through this border node. In that case, existing protocol mechanisms
do not provide sufficient information for it to be able to expand the
loose hop(s) in such a way that the overall P2MP path is guaranteed
to be optimal and re-merge free.
This document proposes a simple procedure such that overall P2MP LSP is
re-merge free.
Ali & Neate Expires September 2010 [Page 3]
Internet-Draft RSVP-TE P2MP Inter-domain LSPs October 2009
The need for finding an end-to-end path that is re-merge free also
increases chances of crankbacks during setting up P2MP LSPs as
compared to their P2P counterparts. Nonetheless, crankback
mechanisms for P2MP LSPs are not addressed by [RFC4875]. This
document also describes how crankback signaling extensions for MPLS
and GMPLS RSVP-TE defined in [RFC4920] apply to setting up P2MP TE
LSPs.
The solution also does not guarantee optimization of the overall P2MP
tree across all domains. PCE can be used, instead, to address
optimization of the overall P2MP tree.
1.1. Conventions used in this document
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.
2. Framework
TBA
3. signaling procedure
The ingress node can make sure that overall P2MP path traveling
multiple domain is remerge free by choosing single Ingress ABR/ ASBR
for loose hop expension for all siblings of a P2MP LSPs.
Ali & Neate Expires September 2010 [Page 4]
Internet-Draft RSVP-TE P2MP Inter-domain LSPs October 2009
3.3. Crankback and Path Error
Crankback procedures for rerouting around failures for P2P RSVP-TE
LSPs are defined in [RFC4920]. These techniques can also be applied
to P2MP LSPs, as decribed in this section.
It is RECOMMENDED that boundary re-routing or segment-based re-
routing is requested for P2MP LSPs traversing multiple domains. This
is because border nodes that are expanding loose hops are typically
best placed to correct any re-merge errors that occur within their
domain, not the ingress node.
If a node on the path of the P2MP LSP is unable to find a route that
can supply the required resources or is not re-merge free, it SHOULD
generate a Path Error message for the subset of the S2L sub-LSPs
which it is not able to route. For this purpose the node SHOULD try
to find a minimum subset of S2L sub-LSPs for which the 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 to the
case where a single S2L Sub-LSP is signaled in each Path message.
GMPLS Notify messages do not include S2L_SUB_LSP objects and cannot
be used to send errors for a subset of the S2L sub-LSPs in a Path
message. For that reason, the node SHOULD use a Path Error message
rather than a Notify message to communicate the error. In the case
of a re-merge error, the node SHOULD use the Error Code "Routing
Problem" and the Error Value "ERO resulted in re-merge" as specified
in [RFC4875].
A border node receiving a Path Error should attempt to re-route
according to the crankback procedures defined in [RFC4920]. In the
case of a re-merge error for which some of the re-merging S2L sub-
LSPs do not pass through the border node, it should propagate the
Path Error usptream. The first node through which all S2L sub-LSPs
concerned transit which receives the Path Error and is allowed to
perform crankback procedures should re-route the S2L sub-LSPs
concerned to all use the same border node.
4. Security Considerations
Security considerations and requirements from [RFC4875] 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.
Ali & Neate Expires September 2010 [Page 5]
Internet-Draft RSVP-TE P2MP Inter-domain LSPs October 2009
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] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4920] Farrel, A., Satyanarayana, A., Iwata, A., Fujita, N., and
G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS
RSVP-TE", RFC 4920, July 2007.
6.2. Informative References
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for
Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
Authors' Addresses
Zafar Ali (editor)
Cisco Systems, Inc.
Email: zali@cisco.com
Nic Neate
Data Connection Ltd
100 Church Street
Enfield EN2 6BQ
United Kingdom
Email: nhn@dataconnection.com
Ali & Neate Expires September 2010 [Page 6]