idnits 2.17.1 draft-kh-spring-ip-ran-use-case-02.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 date (November 10, 2014) is 3454 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-lw-spring-sid-allocation-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING WG B. Khasnabish 3 Internet-Draft ZTE TX Inc. 4 Intended status: Informational F. Hu 5 Expires: May 14, 2015 ZTE Corporation 6 L. Contreras 7 Telefonica I+D 8 November 10, 2014 10 Segment Routing in IP RAN use case 11 draft-kh-spring-ip-ran-use-case-02.txt 13 Abstract 15 Segment Routing (SR) leverages the source routing paradigm. An 16 ingress node steers a packet through a controlled set of 17 instructions, called segments, by pre-pending the packet with an SR 18 header. A segment can represent any instruction, topological or 19 service-based. A segment can have a local semantic to an SR node or 20 global within an SR domain. SR allows one to enforce a flow through 21 any topological path and service chain while maintaining per-flow 22 state only at the ingress node of the SR domain. This document 23 introduces the segment routing in IP Radio Access Network (IP RAN, 24 mobile backhaul network) use case. Additional requirements to 25 support segment routing in the IP RAN scenarios are discussed. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 14, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions and Abbreviations . . . . . . . . . . . . . . . . 3 63 3. IP RAN Network Architecture . . . . . . . . . . . . . . . . . 3 64 3.1. IP RAN Network Scenario . . . . . . . . . . . . . . . . . 3 65 3.2. Requirements for IP RAN network . . . . . . . . . . . . . 4 66 4. Benefit for segment routing in IP RAN network . . . . . . . . 5 67 5. Unified Service Deployment . . . . . . . . . . . . . . . . . 6 68 5.1. Requirement for Control Node . . . . . . . . . . . . . . 8 69 5.2. Requirement for Forwarding Node . . . . . . . . . . . . . 8 70 5.2.1. Forwarding Node Structure . . . . . . . . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 Segment Routing (SR) leverages the source routing paradigm. An 80 ingress node steers a packet through a controlled set of 81 instructions, called segments, by pre-pending the packet with an SR 82 header. A segment can represent any instruction, topological or 83 service-based. A segment can have a local semantic to an SR node or 84 global within an SR domain. Segment Routing allows one to enforce a 85 flow through any topological path and service chaining while 86 maintaining per-flow state only at the ingress node to the Segment 87 Routing domain 89 The Segment Routing architecture is described in 90 ([I-D.filsfils-rtgwg-segment-routing]) The Segment Routing control 91 plane is agnostic to the data plane, and hence it can be applied to 92 both MPLS (and its many variants) and IPv6. 94 Seamless MPLS([I-D.ietf-mpls-seamless-mpls])describes an architecture 95 which can be used to extend MPLS networks to integrate access and 96 core/aggregation networks into a single MPLS domain. It provides a 97 highly flexible and a scalable architecture and the possibility to 98 integrate hundreds of thousands of nodes. 100 This document describes the possibility of applying the segment 101 routing technology to the IP RAN scenario. The segment routing could 102 simplify the network complexity in case of IP RAN. LDP and RSVP-TE 103 signaling protocols are not required, and the end-to-end service 104 deployment can be achieved very easily. 106 2. Conventions and Abbreviations 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 The following notations and abbreviations are used throughout this 113 draft. 115 o ASG: Aggregation Site/Service Gateway 117 o BS: Base Station 119 o CSG: Cell Site Gateway 121 o FRR: Fast Re-Routing 123 o IP RAN: Internet Protocol RAN 125 o LTE: Long Term Evolution 127 o RAN: Radio Access Network 129 o RNC: Radio Network Controller 131 o RSG: Radio Service Gateway 133 o SR: Segment Routing 135 3. IP RAN Network Architecture 137 3.1. IP RAN Network Scenario 138 ---------------- 139 / \ 140 / \ 141 +------+ +----+ +----+ +----+ +----+ 142 | BS |---|CSG1| |ASG1|-------|RSG1|-----|RNC1| 143 +------+ +-+--+ +----+ +----+ +----+ 144 | Access | Aggregation | 145 | Domain | Domain | 146 +------+ +-+--+ +----+ +----+ +----+ 147 | BS |---|CSG2| |ASG2|----- -|RSG2|-----|RNC2| 148 +------+ +----+ +----+ +----+ +----+ 149 \ / 150 \ / 151 -------------- 153 Figure 1: IP RAN Network Scenario 155 A typical mobile backhaul network is shown as figure 1. In the 156 mobile backhaul network, being different from the typical access 157 devices(DSLAM, MSAN), CSGs and RSGs of the mobile backhaul network 158 needs to support rich MPLS features such as path design, protection 159 switch, OAM, etc. 161 3.2. Requirements for IP RAN network 163 (1) End-to-end transport LSP: MPLS based forwarding SHALL be 164 provided by the Seamless MPLS based infrastructure between any 165 nodes. The MPLS based service could be setup by L3VPN, L2VPN or 166 pseudo wire. 168 (2) OAM: The Seamless MPLS architecture should propose unified OAM 169 mechanisms to satisfy the requirements of the end-to-end 170 services. 172 (3) Protection: The protection switch mechanism has been provided in 173 IP RAN network to achieve convergence in 50 ms. 175 (4) Scalability: With the proliferation of 3G/LTE, more and more 176 node-Bs are deployed. IP/MPLS equipment in IP RAN network are 177 very huge. In addition, there is more complex configuration for 178 IP RAN network, because of the richer MPLS TE properties/ 179 features requirements. So there is more challenge in scaling 180 the IP RAN network. 182 (5) Security: The session security should be better or at least as 183 good as in traditional IP/MPLS network. 185 (6) Survivability: The survivability should be better or at least as 186 good as in traditional IP/MPLS network. 188 (7) Flexibility and Overheads: The additional overheads, if any, due 189 to using SR should be offset by the flexibility provided by the 190 SR in IP RANs. 192 (8) Reduction configuration for CSGs and ASGs: The number of CSGs 193 and ASGs in the IP RAN domain are very huge now, and with the 194 increase of mobile Internet traffic, more CSGs could be added to 195 the Access Domain, and CSGs could be installed in wide area. 196 There is a great need to do little or no configuration on CSGs 197 to avoid configuration operation. 199 4. Benefit for segment routing in IP RAN network 201 (1) Simplify end-to-end LSP tunnel establishment: The data plane in 202 IP RAN network is MPLS based forwarding. Segment routing 203 technology is based on MPLS data plane, and there is no change 204 for MPLS forwarding, so the data plane in IP RAN could use the 205 segment routing forwarding technology. Segment routing simplify 206 the control plane by IGP protocol distribution, there is no need 207 for RSVP-TE and LDP signaling protocol. RSVP-TE, LDP protocol 208 usually run in an AS, while IP-RAN network may cross AS domains. 209 Therefore the cross-AS issue should be considered in the IP-RAN, 210 and this is a very complex issue. Segment routing uses IGP 211 protocol to distribute SID, and hence there is no cross-AS issue 212 for segment routing. The BGP protocol could be extended to 213 distribute SID in 214 ([I-D.gredler-idr-bgp-ls-segment-routing-extension]) SR as well. 215 The segment routing technology can simplify end-to-end LSP 216 tunnel establishment. 218 (2) Network virtualization: Service chaining could be introduced 219 into SR domain. An SR header could be used to carry the set of 220 forwarding or services that need to be applied to the packet. 221 This can be achieved by creating an SR header with the desired 222 sequence of service IDs that need to be applied to the packet. 224 (3) Unified OAM mechanism: OAM mechanism could be implemented across 225 AS by IGP and BGP extension of SID flooding. This is an easy- 226 to-implement the cross-AS OAM mechanism. If the control plane 227 is one or several centralized controller, the OAM policy can be 228 determined by the controller, and the related OAM policy can be 229 downloaded to the SR nodes seamlessly 231 (4) Traffic engineering: Traffic Engineering has been widely 232 addressed by using the IGP protocol extensions (for resources 233 information propagation) and RSVP-TE for signaling explicit 234 paths. Different contexts and modes have been defined (single 235 vs. multiple domains, with or without bandwidth admission 236 control, centralized vs. distributed path computation, etc), 237 segment routing can help to implement traffic engineering in IP 238 RAN network. 240 (5) FRR: FRR technologies have been deployed by network operators in 241 order to cope with link or node failures through pre-computation 242 of backup paths. Segment routing can use the IP FRR technology 243 to simplify MPLS-TE 244 FRR([I-D.francois-spring-resiliency-use-case]). 246 (6) Flexible policy deployment: A key goal for SR is to steer a 247 packet to follow a specific path through the network. It is 248 possible to control the service performed at each SR node that 249 is forwarding the packets. Forwarding is one such service 250 provided by an SR node. The service policy can be applied to 251 the packets in each SR node. 253 (7) Simplification of management and operations: The complex RSVP-TE 254 and LDP signaling protocol are not required in the IP RAN 255 network anymore. Therefore, the configuration and operation 256 management become much simple than tradition RSVP-TE based IP 257 RAN network. 259 (8) Centralization controller or distribution protocol: the control 260 plane in IP RAN network can be IGP/BGP distribution protocol or 261 centralization controller. 263 (9) Zero-configuration for CSGs and ASGs: The CSGs and ASGs could do 264 little or zero-configuration by SID allocation mechanism 265 ([I-D.lw-spring-sid-allocation]). One of the ASGs in the IP RAN 266 domain is selected as SRMN (segment routing management node), 267 which advertise the SID mapping information for the various 268 prefix associated with the SR nodes in the SR domain, and all 269 the other ASGs and CSGs could get the SID automatically from the 270 SRMN. There are zero-configuration for the CSGs and ASGs. 272 5. Unified Service Deployment 274 The centralization controller is supported in problem statement draft 275 ([I-D.previdi-spring-problem-statement]) this section describe how 276 centralization controller is applied to the IP RAN network for 277 unified service deployment. 279 +----------+ +----------+ 280 | App | |Network | 281 | | |Management| 282 +----+-----+ +----------+ 283 | | 284 | | 285 +---+------+ | 286 |Controller|----------------+ 287 +----------+ | 288 ........./....|....|...|.\........ | 289 . / | | | \ +------+ 290 . / | | | \ . 291 +------+ . +----+ +----+ | | +----+ . +----+ 292 | BS |-----.--|CSG1| |ASG1| |- -|--|RSG1|-.----|RNC1| 293 +------+ . +-+--+ +----+ | | +----+ . +----+ 294 . | | | . 295 . | / \ . 296 +------+ . +-+--+ +----+ +----+ . +----+ 297 | BS |-----.-|CSG2| |ASG2|--------|RSG2|--.---|RNC2| 298 +------+ . +----+ +----+ +----+ . +----+ 299 . MPLS Stacked forwarding . 300 .................................. 302 Figure 2: Centralization of Controller 304 Figure 2 shows an architecture for centralization of controller. The 305 control plane is separated from the forwarding plane. IP RAN 306 Controller is a software system that can be deployed either in a 307 network device or a separate computer server. IP RAN controllers 308 control the entire IP RAN network domain, the size of the domain can 309 be defined by Network Operator based on the actual network planning 310 and use cases. IP RAN controllers manage the IP RAN network based on 311 the network topology, actual states and status, which are operated by 312 the network administrator. The controller provide the northbound 313 interface to network management system used for service deployment, 314 monitoring, troubleshooting, fault location, etc. 316 CSG, ASG and RSG (we call them forwarding nodes) are only responsible 317 for MPLS stack forwarding. RSVP-TE and LDP signaling protocol are 318 not required in these forwarding nodes. They only need to support 319 topology collecting and report them to controller. Forwarding nodes 320 keep the basic routing functions in order to establish control and 321 management channel between IP RAN Controller/NMG and all the 322 forwarding nodes accepts network resources and states from the 323 controller. 325 5.1. Requirement for Control Node 327 The logical centralization controller is introduced in the IP RAN 328 network. Centralization controller is responsible for network 329 topology collecting and label distribution based on the service. 331 Requirement for control node: 333 (1) Control node should support collecting network topology, and 334 managing network resource, route computing, and MPLS label 335 distribution. 337 (2) Control node support service chaining. 339 (3) Control node support secure channel, and it should establish the 340 secure connection between forwarding node. 342 5.2. Requirement for Forwarding Node 344 5.2.1. Forwarding Node Structure 346 The forwarding node structure in segment routing based IP RAN network 347 is as following: 349 +-----------------------------------------+ 350 | | 351 | +---------+ +--------+ | 352 | | Control | | Config | | 353 | | Agent | | | | 354 | +---------+ +--------+ | 355 | | 356 | +-----------+ +----------------+ | 357 | | Routing | |Topo management | | 358 | +-----------+ +----------------+ | 359 | | 360 | +---------+ +----------+ | 361 | | TEDB | |policy DB | | 362 | +---------+ +----------+ | 363 +-----------------------------------------+ 365 Figure 3: Forwarding node structure 367 The forwarding node simplifies the signaling related components, such 368 as signal protocol component, signal label database, and a new 369 component Control Agent is introduced to communicate with the 370 centralization Controller. 372 Control Agent: control agent is used to communicate with the 373 centralization controller. The forwarding node reports its topology 374 and resource information, and receives the label distributed and 375 policy through control agent. The control agent establishes the 376 secure channel with controller. The BGP-LS protocol is recommended 377 to use as the communication protocol between control agent and 378 controller in this document. 380 Config: the config component is used for management and 381 configuration. It is the interface with network management. 383 Routing: is the traditional component, is used for route computing. 384 The routing protocol (ISIS, OSPF, and BGP) is required for the 385 forwarding node. 387 Topo management: Topology management is responsible for topology 388 computing, and topology status reporting. 390 TEDB: The label database. 392 Policy DB: policy database. 394 6. Security Considerations 396 TBD. 398 7. Acknowledgements 400 In progress. 402 8. IANA Considerations 404 This is no IANA request for this document. 406 9. Normative References 408 [I-D.filsfils-rtgwg-segment-routing] 409 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 410 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 411 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 412 "Segment Routing Architecture", draft-filsfils-rtgwg- 413 segment-routing-01 (work in progress), October 2013. 415 [I-D.francois-spring-resiliency-use-case] 416 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 417 "Use-cases for Resiliency in SPRING", draft-francois- 418 spring-resiliency-use-case-02 (work in progress), April 419 2014. 421 [I-D.gredler-idr-bgp-ls-segment-routing-extension] 422 Gredler, H., Ray, S., Previdi, S., Filsfils, C., Chen, M., 423 and J. Tantsura, "BGP Link-State extensions for Segment 424 Routing", draft-gredler-idr-bgp-ls-segment-routing- 425 extension-02 (work in progress), October 2014. 427 [I-D.ietf-mpls-seamless-mpls] 428 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 429 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 430 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 432 [I-D.lw-spring-sid-allocation] 433 Liao, T., Bo, W., hu, f., and B. Khasnabish, "SPRING SID 434 Allocation", draft-lw-spring-sid-allocation-00 (work in 435 progress), October 2014. 437 [I-D.previdi-spring-problem-statement] 438 Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., 439 Horneffer, M., Geib, R., Shakir, R., and R. Raszuk, 440 "SPRING Problem Statement and Requirements", draft- 441 previdi-spring-problem-statement-04 (work in progress), 442 April 2014. 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, March 1997. 447 Authors' Addresses 449 Bhumip Khasnabish 450 ZTE TX Inc. 451 55 Madison Avenue, Suite 160 452 Morristown, New Jersey 07960 453 USA 455 Phone: +001-781-752-8003 456 Email: bhumip.khasnabish@ztetx.com, vumip1@gmail.com 458 Fangwei Hu 459 ZTE Corporation 460 No.889 Bibo Rd 461 Shanghai 201203 462 China 464 Phone: +86 21 68897637 465 Email: hu.fangwei@zte.com.cn 466 Luis M. Contreras 467 Telefonica I+D 468 Ronda de la Comunicacion, s/n 469 Sur-3 building, 3rd floor 470 Madrid 28050 471 Spain 473 Email: luismiguel.contrerasmurillo@telefonica.com 474 URI: http://people.tid.es/LuisM.Contreras/