idnits 2.17.1 draft-kompella-mpls-rmr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 26, 2014) is 3470 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS WG K. Kompella 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track October 26, 2014 5 Expires: April 29, 2015 7 Resilient MPLS Rings 8 draft-kompella-mpls-rmr-00 10 Abstract 12 This document describes the use of the MPLS control and data planes 13 on ring topologies. It describes the special nature of rings, and 14 proceeds to show how MPLS can be effectively used in such topologies. 15 It describes how MPLS rings are configured, auto-discovered and 16 signaled, as well as how the data plane works. Companion documents 17 describe the details of discovery and signaling for specific 18 protocols. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in [RFC2119]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 29, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Configuration . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. Auto-discovery . . . . . . . . . . . . . . . . . . . . . . 5 66 3.3. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.4. Installing Primary LFIB Entries . . . . . . . . . . . . . . 5 68 3.5. Installing FRR LFIB Entries . . . . . . . . . . . . . . . . 5 69 3.6. Protection . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 74 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 Rings are a very common topology in transport networks. A ring is 80 the simplest topology offering link and node resilience. Rings are 81 nearly ubiquitous in access and aggregation networks. As MPLS 82 increases its presence in such networks, and takes on a greater role 83 in transport, it is imperative that MPLS handles rings well; this is 84 not the case today. 86 This document describes the special nature of rings, and the special 87 needs of MPLS on rings. It then shows how these needs can be met in 88 several ways, some of which involve extensions to protocols such as 89 IS-IS [RFC1195], OSPF[RFC2328], RSVP-TE [RFC3209] and LDP [RFC5036]. 91 1.1. Definitions 93 A (directed) graph G = (V, E) consists of a set of vertices (or 94 nodes) V and a set of edges (or links) E. An edge is an ordered pair 95 of nodes (a, b), where a and b are in V. (In this document, the terms 96 node and link will be used instead of vertex and edge.) 98 A ring is a subgraph of G. A ring consists of a subset of nodes {R_i, 99 1 <= i <= n} of V. For convenience, we define R_0 = R_n. The edges 100 {(R_i, R_i+1) and (R_i+1, R_i), 0 <= i < n} must be a subset of E. We 101 define the direction from node R_i to R_i+1 (0 <= i < n) (and hence 102 from R_n = R_0 to R_1) as "downstream" (DS) and the reverse direction 103 as "upstream" (US). As there may be several rings in a graph, we 104 number each ring with a distinct "Ring ID" RID. 106 R1 . . . R2 107 . . 108 R8 R3 109 | . Ring . | 110 Upstream | . . | Downstream 111 v . RID = 17 . v 112 R7 R4 113 . . 114 R6 . . . R5 116 Figure 1: Ring with 8 nodes 118 The following terminology is used for ring LSPs: 120 RL_k: A Ring LSP anchored on node R_k is denoted RL_k. 122 DL_jk (UL_jk): A label allocated by R_j for RL_k in the DS (US) 123 direction. 125 P_jk (Q_jk): A Path (Resv) message sent by R_j for RL_k. 127 2. Motivation 129 A ring is the simplest topology that offers resilience. This is 130 perhaps the main reason to lay out fiber in a ring. Thus, effective 131 mechanisms for fast failover on rings are needed. Furthermore, there 132 are large numbers of rings. Thus, configuration of rings needs to be 133 as simple as possible. Finally, bandwidth management on access rings 134 is very important, as bandwidth is generally quite constrained here. 136 The goals of this document are to present mechanisms for improved 137 MPLS-based resilience in ring networks (using ideas that are 138 reminiscent of Bidirectional Line Switched Rings), automatic bring-up 139 of LSPs, better bandwidth management and auto-hierarchy. These goals 140 can be achieved using extensions to existing IGP and MPLS signaling 141 protocols, using central provisioning, or in other ways. 143 3. Theory of Operation 145 Say a ring has n nodes R_i, 0 <= i <= n, where R_0 = R_n. Each node 146 is the anchor of one or more Ring LSPs. A Ring LSP RL_i anchored on 147 node R_i consists of two counter-rotating LSPs that start and end at 148 R_i. A ring LSP is "multipoint"; any node R_j can use RL_i to send 149 traffic to R_i in either direction. Bidirectional connectivity 150 between nodes R_i and R_j is achieved by using ring LSPs RL_j (to 151 reach R_j) and RL_i (to reach R_i); each can be used in either 152 direction. 154 3.1. Configuration 156 An MPLS ring is configured by assigning RIDs to all the nodes in the 157 ring. The links between adjacent ring nodes are ring links (unless 158 told otherwise); this may also be configured, or it may be 159 discovered, say by means of IGP hellos. Once ring nodes and ring 160 links are identified, the ring has been defined. 162 Ring LSPs are not provisioned; they are created automatically when an 163 MPLS ring is defined. Each node R_j allocates DS and US labels for 164 each ring LSP RL_k and sends these to its ring neighbors. The 165 signaling protocol used to send labels can be RSVP-TE or LDP; these 166 extensions will be described later. When R_j receives DS and US 167 labels for RL_k, it can install LFIB entries for RL_k. 169 3.2. Auto-discovery 171 A link-state IGP such as IS-IS or OSPF can be used to simplify the 172 configuration of MPLS rings. Details will be given in a companion 173 document. 175 3.3. Signaling 177 Both RSVP-TE and LDP, with appropriate extensions, can be used to 178 signal ring LSPs. Details will be given in companion documents. 180 3.4. Installing Primary LFIB Entries 182 In setting up RL_k, a node R_j sends out two labels: DL_jk to R_j-1 183 and UL_jk to R_j+1. R_j also receives two labels: DL_j+1,k from 184 R_j+1, and UL_j-1,k from R_j-1. R_j can now set up the forwarding 185 entries for RL_k. In the DS direction, R_j swaps incoming label 186 DL_jk with DL_j+1,k with next hop R_j+1. In the US direction, R_j 187 swaps incoming label UL_jk with UL_j-1,k with next hop R_j-1. R_k 188 does not install LFIB entries in this manner. 190 3.5. Installing FRR LFIB Entries 192 At the same time that R_j sets up its DS and US LFIB entries, it can 193 also set up the protection forwarding entries for RL_k. In the DS 194 direction, R_j sets up an FRR LFIB entry to swap incoming label DL_jk 195 with UL_j-1,k with next hop R_j-1. In the US direction, R_j sets up 196 an FRR LFIB entry to swap incoming label UL_jk with DL_j+1,k with 197 next hop R_j+1. Again, R_k does not install FRR LFIB entries in this 198 manner. 200 3.6. Protection 202 Note that in this scheme, there are no protection LSPs as such -- no 203 node or link bypasses, nor detours, nor LFA-type protection. 204 Protection is via the "other" direction around the ring, which is why 205 ring LSPs are in counter-rotating pairs. 207 If a node R_j detects a failure DS from R_j+1, it switches traffic on 208 all DS ring LSPs to the US direction using the FRR LFIB entries. 209 This switchover can be very fast, as the FRR LFIB entries can be 210 preprogrammed. If the detection is fast too, then traffic loss is 211 minimal. 213 R_j then sends an indication to R_j-1 that the DS direction is not 214 working, so that R_j-1 can similarly switch traffic to the US 215 direction. These indications propagate US until each traffic source 216 on the ring uses the US direction. Thus, within a short period, 217 traffic will be flowing in the optimal path, given that there is a 218 failure on the ring. This contrasts with (say) bypass protection, 219 where until the ingress recomputes a new path, traffic will be 220 suboptimal. 222 4. Security Considerations 224 It is not anticipated that either the notion of MPLS rings or the 225 extensions to various protocols to support them will cause new 226 security loopholes. As this document is updated, this section will 227 also be updated. 229 5. IANA Considerations 231 There are no requests to IANA for this document. 233 6. References 235 6.1. Normative References 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, March 1997. 240 6.2. Informative References 242 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 243 dual environments", RFC 1195, December 1990. 245 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 247 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 248 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 249 Tunnels", RFC 3209, December 2001. 251 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 252 Specification", RFC 5036, October 2007. 254 Author's Address 256 Kireeti Kompella 257 Juniper Networks, Inc. 258 1194 N. Mathilda Avenue 259 Sunnyvale, CA 94089 260 USA 262 Email: kireeti.kompella@gmail.com