MPLS WG K. Kompella
Internet-Draft Juniper Networks, Inc.
Intended status: Standards Track October 26, 2014
Expires: April 29, 2015
Resilient MPLS Rings
draft-kompella-mpls-rmr-00
Abstract
This document describes the use of the MPLS control and data planes
on ring topologies. It describes the special nature of rings, and
proceeds to show how MPLS can be effectively used in such topologies.
It describes how MPLS rings are configured, auto-discovered and
signaled, as well as how the data plane works. Companion documents
describe the details of discovery and signaling for specific
protocols.
Requirements Language
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 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 29, 2015.
Copyright Notice
Copyright (c) 2014 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
Kompella Expires April 29, 2015 [Page 1]
Internet-Draft Resilient MPLS Rings October 2014
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Configuration . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Auto-discovery . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Installing Primary LFIB Entries . . . . . . . . . . . . . . 5
3.5. Installing FRR LFIB Entries . . . . . . . . . . . . . . . . 5
3.6. Protection . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Kompella Expires April 29, 2015 [Page 2]
Internet-Draft Resilient MPLS Rings October 2014
1. Introduction
Rings are a very common topology in transport networks. A ring is
the simplest topology offering link and node resilience. Rings are
nearly ubiquitous in access and aggregation networks. As MPLS
increases its presence in such networks, and takes on a greater role
in transport, it is imperative that MPLS handles rings well; this is
not the case today.
This document describes the special nature of rings, and the special
needs of MPLS on rings. It then shows how these needs can be met in
several ways, some of which involve extensions to protocols such as
IS-IS [RFC1195], OSPF[RFC2328], RSVP-TE [RFC3209] and LDP [RFC5036].
1.1. Definitions
A (directed) graph G = (V, E) consists of a set of vertices (or
nodes) V and a set of edges (or links) E. An edge is an ordered pair
of nodes (a, b), where a and b are in V. (In this document, the terms
node and link will be used instead of vertex and edge.)
A ring is a subgraph of G. A ring consists of a subset of nodes {R_i,
1 <= i <= n} of V. For convenience, we define R_0 = R_n. The edges
{(R_i, R_i+1) and (R_i+1, R_i), 0 <= i < n} must be a subset of E. We
define the direction from node R_i to R_i+1 (0 <= i < n) (and hence
from R_n = R_0 to R_1) as "downstream" (DS) and the reverse direction
as "upstream" (US). As there may be several rings in a graph, we
number each ring with a distinct "Ring ID" RID.
R1 . . . R2
. .
R8 R3
| . Ring . |
Upstream | . . | Downstream
v . RID = 17 . v
R7 R4
. .
R6 . . . R5
Figure 1: Ring with 8 nodes
The following terminology is used for ring LSPs:
RL_k: A Ring LSP anchored on node R_k is denoted RL_k.
Kompella Expires April 29, 2015 [Page 3]
Internet-Draft Resilient MPLS Rings October 2014
DL_jk (UL_jk): A label allocated by R_j for RL_k in the DS (US)
direction.
P_jk (Q_jk): A Path (Resv) message sent by R_j for RL_k.
2. Motivation
A ring is the simplest topology that offers resilience. This is
perhaps the main reason to lay out fiber in a ring. Thus, effective
mechanisms for fast failover on rings are needed. Furthermore, there
are large numbers of rings. Thus, configuration of rings needs to be
as simple as possible. Finally, bandwidth management on access rings
is very important, as bandwidth is generally quite constrained here.
The goals of this document are to present mechanisms for improved
MPLS-based resilience in ring networks (using ideas that are
reminiscent of Bidirectional Line Switched Rings), automatic bring-up
of LSPs, better bandwidth management and auto-hierarchy. These goals
can be achieved using extensions to existing IGP and MPLS signaling
protocols, using central provisioning, or in other ways.
3. Theory of Operation
Say a ring has n nodes R_i, 0 <= i <= n, where R_0 = R_n. Each node
is the anchor of one or more Ring LSPs. A Ring LSP RL_i anchored on
node R_i consists of two counter-rotating LSPs that start and end at
R_i. A ring LSP is "multipoint"; any node R_j can use RL_i to send
traffic to R_i in either direction. Bidirectional connectivity
between nodes R_i and R_j is achieved by using ring LSPs RL_j (to
reach R_j) and RL_i (to reach R_i); each can be used in either
direction.
3.1. Configuration
An MPLS ring is configured by assigning RIDs to all the nodes in the
ring. The links between adjacent ring nodes are ring links (unless
told otherwise); this may also be configured, or it may be
discovered, say by means of IGP hellos. Once ring nodes and ring
links are identified, the ring has been defined.
Ring LSPs are not provisioned; they are created automatically when an
MPLS ring is defined. Each node R_j allocates DS and US labels for
each ring LSP RL_k and sends these to its ring neighbors. The
signaling protocol used to send labels can be RSVP-TE or LDP; these
extensions will be described later. When R_j receives DS and US
labels for RL_k, it can install LFIB entries for RL_k.
Kompella Expires April 29, 2015 [Page 4]
Internet-Draft Resilient MPLS Rings October 2014
3.2. Auto-discovery
A link-state IGP such as IS-IS or OSPF can be used to simplify the
configuration of MPLS rings. Details will be given in a companion
document.
3.3. Signaling
Both RSVP-TE and LDP, with appropriate extensions, can be used to
signal ring LSPs. Details will be given in companion documents.
3.4. Installing Primary LFIB Entries
In setting up RL_k, a node R_j sends out two labels: DL_jk to R_j-1
and UL_jk to R_j+1. R_j also receives two labels: DL_j+1,k from
R_j+1, and UL_j-1,k from R_j-1. R_j can now set up the forwarding
entries for RL_k. In the DS direction, R_j swaps incoming label
DL_jk with DL_j+1,k with next hop R_j+1. In the US direction, R_j
swaps incoming label UL_jk with UL_j-1,k with next hop R_j-1. R_k
does not install LFIB entries in this manner.
3.5. Installing FRR LFIB Entries
At the same time that R_j sets up its DS and US LFIB entries, it can
also set up the protection forwarding entries for RL_k. In the DS
direction, R_j sets up an FRR LFIB entry to swap incoming label DL_jk
with UL_j-1,k with next hop R_j-1. In the US direction, R_j sets up
an FRR LFIB entry to swap incoming label UL_jk with DL_j+1,k with
next hop R_j+1. Again, R_k does not install FRR LFIB entries in this
manner.
3.6. Protection
Note that in this scheme, there are no protection LSPs as such -- no
node or link bypasses, nor detours, nor LFA-type protection.
Protection is via the "other" direction around the ring, which is why
ring LSPs are in counter-rotating pairs.
If a node R_j detects a failure DS from R_j+1, it switches traffic on
all DS ring LSPs to the US direction using the FRR LFIB entries.
This switchover can be very fast, as the FRR LFIB entries can be
preprogrammed. If the detection is fast too, then traffic loss is
minimal.
R_j then sends an indication to R_j-1 that the DS direction is not
working, so that R_j-1 can similarly switch traffic to the US
direction. These indications propagate US until each traffic source
on the ring uses the US direction. Thus, within a short period,
Kompella Expires April 29, 2015 [Page 5]
Internet-Draft Resilient MPLS Rings October 2014
traffic will be flowing in the optimal path, given that there is a
failure on the ring. This contrasts with (say) bypass protection,
where until the ingress recomputes a new path, traffic will be
suboptimal.
4. Security Considerations
It is not anticipated that either the notion of MPLS rings or the
extensions to various protocols to support them will cause new
security loopholes. As this document is updated, this section will
also be updated.
5. IANA Considerations
There are no requests to IANA for this document.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[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.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
Kompella Expires April 29, 2015 [Page 6]
Internet-Draft Resilient MPLS Rings October 2014
Author's Address
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
USA
Email: kireeti.kompella@gmail.com
Kompella Expires April 29, 2015 [Page 7]