idnits 2.17.1 draft-hu-spring-sr-tp-use-case-01.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 (Mar 4, 2018) is 2244 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5654' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'RFC5921' is defined on line 366, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-cheng-spring-mpls-path-segment-00 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-04 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-15 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-24 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-12 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING WG Fangwei Hu 3 Internet-Draft Quan Xiong 4 Intended status: Informational Greg Mirsky 5 Expires: September 5, 2018 ZTE Corporation 6 Weiqiang Cheng 7 China Mobile 8 Mar 4, 2018 10 Segment Routing Transport Profile Use Case 11 draft-hu-spring-sr-tp-use-case-01.txt 13 Abstract 15 This document discusses the use case and requirement of segment 16 routing is used in MPLS-TP network. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 5, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions used in this document . . . . . . . . . . . . . . 3 54 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 3. SRTP Requirement . . . . . . . . . . . . . . . . . . . . . . 3 57 4. SRTP Use Case . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4.1. SRTP Scenario . . . . . . . . . . . . . . . . . . . . . . 3 59 4.2. SRTP Loose Constraints Path . . . . . . . . . . . . . . . 5 60 4.3. SRTP Strict Constraints Path . . . . . . . . . . . . . . 6 61 5. Bi-direction SRTP Tunnel Binding . . . . . . . . . . . . . . 7 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 With the wide spread adoption of virtualization and cloud computing, 71 the east-west traffic is greatly increased in the current MPLS-TP 72 network. This trend brought the new requirements for the MPLS-TP 73 networks: 75 (1) The access layer nodes should be meshed to provide the east-west 76 traffic forwarding capability. 78 (2) The access nodes should support signaling protocol and maintain 79 large volume of state for traffic engineering and tunnel 80 connection, which is very challenging for the access nodes in 81 the current MPLS-TP networks. 83 Segment Routing(SR)[I-D.ietf-spring-segment-routing] allows a node to 84 steer a packet through a controlled set of instructions, called 85 segments, by prepending an SR header to the packet. The transit 86 nodes forward the packet based on the segment list, and do not need 87 to maintain the service status. There is no need to run signaling 88 protocol in the traffic engineering network, which simplifies the 89 network deployment and operation. The Segment Routing architecture 90 can be directly applied to the MPLS dataplane with no change on the 91 forwarding plane [I-D.ietf-spring-segment-routing-mpls]. It requires 92 a minor extension to the existing link-state routing protocols. 94 If the segment routing technology is deployed in the current MPLS-TP 95 network, the challenge for the access layer nodes could be addressed. 96 The access layer nodes only need to support IGP protocol (ISIS, 97 OSPF), and they do not need to support signaling protocol and 98 maintain traffic engineering status and tunnel information, which 99 simplifies the access layer nodes. The segment routing technology 100 being deployed in the MPLS-TP network is referred to as SRTP 101 technology. This document discusses uses case and requirements for 102 the SR-TP. 104 2. Conventions used in this document 106 2.1. Terminology 108 SRTP: segment routing transport profile. The segment routing is 109 deployed in the packet-switched transport networks. 111 2.2. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 3. SRTP Requirement 121 The requirement of SRTP are as following: 123 (1) It is required to support bi-direction tunnel to fit for the 124 requirement of packet-switched transport networks. The SR nodes 125 are required to announce the related capability and parameters 126 information to the centralized controller. 128 (2) It is required to support SRTP loose constraints traffic 129 engineering path for packet-switched transport networks. 131 (3) It is required to support SRTP strict constraints traffic 132 engineering path for packet-switched transport networks. The 133 data forwarding path is usually maintained by centralized 134 controller. 136 4. SRTP Use Case 138 4.1. SRTP Scenario 140 Figure 1 is a typical SRTP deployment scenario. The SR nodes run IGP 141 protocol extension for segment routing 142 ([I-D.ietf-isis-segment-routing-extensions] or 143 [I-D.ietf-ospf-segment-routing-extensions]), and flood the SR 144 parameters to the network. The nodes maintain local SR information, 145 and receiving the other nodes' SR information through IGP protocol. 147 They create the RIB and SR label forwarding table for traffic 148 forwarding. A centralized controller can be used to configure and 149 manage the nodes in the transport network. The segment routing nodes 150 report their topology information to the centralized controller, e.g. 151 through [I-D.ietf-idr-bgp-ls-segment-routing-ext]. The centralized 152 controller creates the RIB and synchronizes the forwarding table 153 among segment routing nodes. The centralized controller also 154 calculates the end to end SR paths, and creates the ordered segment 155 list, then downloads it to the ingress segment routing nodes. 157 Both the loose constraints path and strict constraints path are 158 support in the packet-switched transport networks. The SRTP loose 159 constraints path is usually used in the access rings or access and 160 aggregation rings for the east-west data flows (the synchronized data 161 among eNodeB) in the packet-switched transport, and the SRTP strict 162 constraints path is usually used for the south-north data flows 163 (e.g., the data from eNodeB to core network). 165 ************************ 166 * * 167 * Controller * 168 * * 169 ************************ 170 / ^ 171 / \ 172 / \ 173 v \ 174 +---+ +---+ +----+ +----+ 175 |SR2|--------|SR3| |SR9 |-------|SR10| 176 +---+ +---+ +----+ +----+ 177 / \ / \ 178 / \ / \ 179 +---+ +---+ +---+ +----+ 180 |BS1|------|SR1| |SR4| |SR11| 181 +---+ +---+ +---+ +----+ 182 | | | 183 | | | 184 +---+ +---+ +---+ +----+ 185 |BS2|------|SR8| |SR5| |SR12| 186 +---+ +---+ +---+ +----+ 187 \ / \ / 188 \ / \ / 189 +---+ +---+ +----+ +----+ 190 |SR7|--------|SR6| |SR14|-------|SR13| 191 +---+ +---+ +----+ +----+ 193 Figure 1 SRTP Scenario 195 4.2. SRTP Loose Constraints Path 197 Figure 2 shows the typical SRTP loose constraints path application 198 scenario. A and F is the ingress SR node and egress node 199 respectively, and D is the gateway of the access ring. The data 200 traffic will be forwarded to go across access ring and aggregation 201 ring from A to F. The F node's Node SID and D's Node SID are flooded 202 in the access ring and aggregation ring (The access ring and 203 aggregation ring belong to the same IGP area). Node A encapsulates 204 the SID D and SID F in the segment routing data packet. The data 205 traffic is forwarded along the best path from A to D, and then is 206 forwarded from D to F. 208 In the SRTP loose constraints path mechanism, the SR nodes in the IGP 209 area are assigned a global unique node SID, and all the SR nodes 210 should run IGP protocol(ISIS OR OSPF) to advertise their Node SIDs. 212 The SR packets forwarding is based on the best route to the 213 destination SR nodes calculated at each node. 215 +-----------+ +-----------+ 216 | B | | SR | 217 +-----------+ +-----------+ 218 / \ / \ 219 / \ / \ 220 +-----+ +----+ +-----+ 221 | A | | C | |SR11 | 222 +-----+ +----+ +-----+ 223 | | | 224 | | | 225 +---+ +---+ +------+ 226 |SR | | D | | F | 227 +---+ +---+ +------+ 228 \ / \ / 229 \ / \ / 230 +-------------+ +------------+ 231 | SR | | E | 232 +-------------+ +------------+ 234 +--------+ +--------+ 235 | node D | | node D | 236 +--------+ +--------+ +--------+ +--------+ 237 | node E | | node E | | node E | | node E | 238 +--------+ +--------+ +--------+ +--------+ +--------+ 239 |payload | |payload | |payload | |payload | |payload | 240 +--------+ +--------+ +--------+ +--------+ +--------+ 242 Figure 2 SRTP Loose Constraints Path 244 4.3. SRTP Strict Constraints Path 246 Figure 3 shows the SRTP strict constraints path. The SR nodes are 247 assigned the Adjacent SIDs(local SID) by the centralized controller. 248 The centralized controller collects the global topology and TE 249 information, and calculates the end-to-end path based on the service 250 requirement and the routing policy (minimum hop count, minimum delay, 251 load balancing, etc.) to form the strictly constrained path. The 252 ingress SR nodes (PE nodes) push the SID list to encapsulate the SR 253 packet. The transit SR nodes (P nodes) forward the SR packets based 254 on the SID list. Egress SR nodes (PE nodes) decapsulate the SR 255 packet and forwards to the destination. 257 Because there is no label or only the last label in the MPLS label 258 stack when the packet reaches the egress node, the egress node cannot 259 determine from which ingress node or SR path the packet comes. A 260 path segment is introduced to address this issue(Section 5 for 261 details). 263 +-----------+ +-----------+ 264 | A | | SR | 265 +-----------+ +-----------+ 266 / \ / \ 267 / adj A adj B\ / \ 268 +-----+ +----+ +-----+ 269 | PE1 | | B | |SR11 | 270 +-----+ +----+ +-----+ 271 | | | 272 | adj C | | 273 +---+ +---+ +-----+ 274 |SR | | C | | PE2 | 275 +---+ +---+ +-----+ 276 \ / \ adj D / 277 \ / \ / adj E 278 +-------------+ +------------+ 279 | SR | | D | 280 +-------------+ +------------+ 282 +--------+ 283 | adj A | 284 +--------+ +--------+ 285 | adj B | | adj B | 286 +--------+ +--------+ +--------+ 287 | adj C | | adj C | | adj C | 288 +--------+ +--------+ +--------+ 289 | adj D | | adj D | | adj D | 290 +--------+ +--------+ +--------+ +--------+ 291 | adj E | | adj E | | adj E | | adj E | 292 +--------+ +--------+ +--------+ +--------+ +--------+ 293 |path SID| |path SID| |path SID| |path SID| |path SID| 294 +--------+ +--------+ +--------+ +--------+ +--------+ 295 |payload | |payload | |payload | |payload | |payload | 296 +--------+ +--------+ +--------+ +--------+ +--------+ 298 Figure 3 SRTP Strict Constraints Path 300 5. Bi-direction SRTP Tunnel Binding 302 It is required to establish the bi-direction tunnel, for some use 303 cases, such as end-to-end 1+1 path protection, bidirectional path 304 correlation or performance measurement (PM) in MPLS-TP network . But 305 the SR is a one direction tunnel, so when deploying the SR to packet- 306 switched transport networks, it is necessary to binding two direction 307 tunnel as a bi-direction tunnel to meet the requirement of MPLS-TP. 308 [I-D.cheng-spring-mpls-path-segment] provides the solution to binding 309 the bi-direction SRTP tunnel. 311 6. Security Considerations 313 7. Acknowledgements 315 8. IANA Considerations 317 9. Normative References 319 [I-D.cheng-spring-mpls-path-segment] 320 Cheng, W., Wang, L., Li, H., Chen, M., Zigler, R., and S. 321 Zhan, "Path Segment in MPLS Based Sement Routing Network", 322 draft-cheng-spring-mpls-path-segment-00 (work in 323 progress), October 2017. 325 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 326 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 327 and M. Chen, "BGP Link-State extensions for Segment 328 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-04 329 (work in progress), January 2018. 331 [I-D.ietf-isis-segment-routing-extensions] 332 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 333 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 334 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 335 segment-routing-extensions-15 (work in progress), December 336 2017. 338 [I-D.ietf-ospf-segment-routing-extensions] 339 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 340 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 341 Extensions for Segment Routing", draft-ietf-ospf-segment- 342 routing-extensions-24 (work in progress), December 2017. 344 [I-D.ietf-spring-segment-routing] 345 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 346 Litkowski, S., and R. Shakir, "Segment Routing 347 Architecture", draft-ietf-spring-segment-routing-15 (work 348 in progress), January 2018. 350 [I-D.ietf-spring-segment-routing-mpls] 351 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 352 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 353 data plane", draft-ietf-spring-segment-routing-mpls-12 354 (work in progress), February 2018. 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, 358 DOI 10.17487/RFC2119, March 1997, 359 . 361 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 362 Sprecher, N., and S. Ueno, "Requirements of an MPLS 363 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 364 September 2009, . 366 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 367 L., and L. Berger, "A Framework for MPLS in Transport 368 Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, 369 . 371 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 372 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 373 May 2017, . 375 Authors' Addresses 377 Fangwei Hu 378 ZTE Corporation 379 No.889 Bibo Rd 380 Shanghai 201203 381 China 383 Phone: +86 21 68896273 384 Email: hu.fangwei@zte.com.cn 386 Quan Xiong 387 ZTE Corporation 388 No.6 Huashi Park Rd 389 Wuhan, Hubei 430223 390 China 392 Phone: +86 27 83531060 393 Email: xiong.quan@zte.com.cn 394 Greg Mirsky 395 ZTE Corporation 396 USA 398 Email: gregimirsky@gmail.com 400 Weiqiang Cheng 401 China Mobile 402 Beijing 403 China 405 Email: chengweiqiang@chinamobile.com