SPRING WG B. Khasnabish Internet-Draft ZTE TX Inc. Intended status: Informational F. Hu Expires: December 31, 2014 ZTE Corporation M. Luis Telefonica I+D June 29, 2014 Segment Routing in IP RAN use case draft-kh-spring-ip-ran-use-case-01.txt Abstract Segment Routing (SR) leverages the source routing paradigm. An ingress node steers a packet through a controlled set of instructions, called segments, by pre-pending the packet with an SR header. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to an SR node or global within an SR domain. SR allows one to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. This document introduces the segment routing in IP Radio Access Network (IP RAN, mobile backhaul network) use case. Additional requirements to support segment routing in the IP RAN scenarios are discussed. 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 December 31, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Khasnabish, et al. Expires December 31, 2014 [Page 1] Internet-Draft SR IP RAN use case June 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Abbreviations . . . . . . . . . . . . . . . . 3 3. IP RAN Network Architecture . . . . . . . . . . . . . . . . . 3 3.1. IP RAN Network Scenario . . . . . . . . . . . . . . . . . 3 3.2. Requirements for IP RAN network . . . . . . . . . . . . . 4 4. Benefit for segment routing in IP RAN network . . . . . . . . 5 5. Unified Service Deployment . . . . . . . . . . . . . . . . . 6 5.1. Requirement for Control Node . . . . . . . . . . . . . . 8 5.2. Requirement for Forwarding Node . . . . . . . . . . . . . 8 5.2.1. Forwarding Node Structure . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Segment Routing (SR) leverages the source routing paradigm. An ingress node steers a packet through a controlled set of instructions, called segments, by pre-pending the packet with an SR header. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to an SR node or global within an SR domain. Segment Routing allows one to enforce a flow through any topological path and service chaining while maintaining per-flow state only at the ingress node to the Segment Routing domain The Segment Routing architecture is described in ([I-D.filsfils-rtgwg-segment-routing]) The Segment Routing control plane is agnostic to the data plane, and hence it can be applied to both MPLS (and its many variants) and IPv6. Seamless MPLS([I-D.ietf-mpls-seamless-mpls])describes an architecture which can be used to extend MPLS networks to integrate access and core/aggregation networks into a single MPLS domain. It provides a Khasnabish, et al. Expires December 31, 2014 [Page 2] Internet-Draft SR IP RAN use case June 2014 highly flexible and a scalable architecture and the possibility to integrate hundreds of thousands of nodes. This document describes the possibility of applying the segment routing technology to the IP RAN scenario. The segment routing could simplify the network complexity in case of IP RAN. LDP and RSVP-TE signaling protocols are not required, and the end-to-end service deployment can be achieved very easily. 2. Conventions and Abbreviations 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]. The following notations and abbreviations are used throughout this draft. o ASG: Aggregation Site/Service Gateway o BS: Base Station o CSG: Cell Site Gateway o FRR: Fast Re-Routing o IP RAN: Internet Protocol RAN o LTE: Long Term Evolution o RAN: Radio Access Network o RNC: Radio Network Controller o RSG: Radio Service Gateway o SR: Segment Routing 3. IP RAN Network Architecture 3.1. IP RAN Network Scenario Khasnabish, et al. Expires December 31, 2014 [Page 3] Internet-Draft SR IP RAN use case June 2014 ---------------- / \ / \ +------+ +----+ +----+ +----+ +----+ | BS |---|CSG1| |ASG1|-------|RSG1|-----|RNC1| +------+ +-+--+ +----+ +----+ +----+ | Access | Aggregation | | Domain | Domain | +------+ +-+--+ +----+ +----+ +----+ | BS |---|CSG2| |ASG2|----- -|RSG2|-----|RNC2| +------+ +----+ +----+ +----+ +----+ \ / \ / -------------- Figure 1: IP RAN Network Scenario A typical mobile backhaul network is shown as figure 1. In the mobile backhaul network, being different from the typical access devices(DSLAM, MSAN), CSGs and RSGs of the mobile backhaul network needs to support rich MPLS features such as path design, protection switch, OAM, etc. 3.2. Requirements for IP RAN network (1) End-to-end transport LSP: MPLS based forwarding SHALL be provided by the Seamless MPLS based infrastructure between any nodes. The MPLS based service could be setup by L3VPN, L2VPN or pseudo wire. (2) OAM: The Seamless MPLS architecture should propose unified OAM mechanisms to satisfy the requirements of the end-to-end services. (3) Protection: The protection switch mechanism has been provided in IP RAN network to achieve convergence in 50 ms. (4) Scalability: With the proliferation of 3G/LTE, more and more node-Bs are deployed. IP/MPLS equipment in IP RAN network are very huge. In addition, there is more complex configuration for IP RAN network, because of the richer MPLS TE properties/ features requirements. So there is more challenge in scaling the IP RAN network. (5) Security: The session security should be better or at least as good as in traditional IP/MPLS network. Khasnabish, et al. Expires December 31, 2014 [Page 4] Internet-Draft SR IP RAN use case June 2014 (6) Survivability: The survivability should be better or at least as good as in traditional IP/MPLS network. (7) Flexibility and Overheads: The additional overheads, if any, due to using SR should be offset by the flexibility provided by the SR in IP RANs. 4. Benefit for segment routing in IP RAN network (1) Simplify end-to-end LSP tunnel establishment: The data plane in IP RAN network is MPLS based forwarding. Segment routing technology is based on MPLS data plane, and there is no change for MPLS forwarding, so the data plane in IP RAN could use the segment routing forwarding technology. Segment routing simplify the control plane by IGP protocol distribution, there is no need for RSVP-TE and LDP signaling protocol. RSVP-TE, LDP protocol usually run in an AS, while IP-RAN network may cross AS domains. Therefore the cross-AS issue should be considered in the IP-RAN, and this is a very complex issue. Segment routing uses IGP protocol to distribute SID, and hence there is no cross-AS issue for segment routing. The BGP protocol could be extended to distribute SID in ([I-D.gredler-idr-bgp-ls-segment-routing-extension]) SR as well. The segment routing technology can simplify end-to-end LSP tunnel establishment. (2) Network virtualization: Service chaining could be introduced into SR domain. An SR header could be used to carry the set of forwarding or services that need to be applied to the packet. This can be achieved by creating an SR header with the desired sequence of service IDs that need to be applied to the packet. (3) Unified OAM mechanism: OAM mechanism could be implemented across AS by IGP and BGP extension of SID flooding. This is an easy- to-implement the cross-AS OAM mechanism. If the control plane is one or several centralized controller, the OAM policy can be determined by the controller, and the related OAM policy can be downloaded to the SR nodes seamlessly (4) Traffic engineering: Traffic Engineering has been widely addressed by using the IGP protocol extensions (for resources information propagation) and RSVP-TE for signaling explicit paths. Different contexts and modes have been defined (single vs. multiple domains, with or without bandwidth admission control, centralized vs. distributed path computation, etc), segment routing can help to implement traffic engineering in IP RAN network. Khasnabish, et al. Expires December 31, 2014 [Page 5] Internet-Draft SR IP RAN use case June 2014 (5) FRR: FRR technologies have been deployed by network operators in order to cope with link or node failures through pre-computation of backup paths. Segment routing can use the IP FRR technology to simplify MPLS-TE FRR([I-D.francois-spring-resiliency-use-case]). (6) Flexible policy deployment: A key goal for SR is to steer a packet to follow a specific path through the network. It is possible to control the service performed at each SR node that is forwarding the packets. Forwarding is one such service provided by an SR node. The service policy can be applied to the packets in each SR node. (7) Simplification of management and operations: The complex RSVP-TE and LDP signaling protocol are not required in the IP RAN network anymore. Therefore, the configuration and operation management become much simple than tradition RSVP-TE based IP RAN network. (8) Centralization controller or distribution protocol: the control plane in IP RAN network can be IGP/BGP distribution protocol or centralization controller. 5. Unified Service Deployment The centralization controller is supported in problem statement draft ([I-D.previdi-spring-problem-statement]) this section describe how centralization controller is applied to the IP RAN network for unified service deployment. Khasnabish, et al. Expires December 31, 2014 [Page 6] Internet-Draft SR IP RAN use case June 2014 +----------+ +----------+ | App | |Network | | | |Management| +----+-----+ +----------+ | | | | +---+------+ | |Controller|----------------+ +----------+ | ........./....|....|...|.\........ | . / | | | \ +------+ . / | | | \ . +------+ . +----+ +----+ | | +----+ . +----+ | BS |-----.--|CSG1| |ASG1| |- -|--|RSG1|-.----|RNC1| +------+ . +-+--+ +----+ | | +----+ . +----+ . | | | . . | / \ . +------+ . +-+--+ +----+ +----+ . +----+ | BS |-----.-|CSG2| |ASG2|--------|RSG2|--.---|RNC2| +------+ . +----+ +----+ +----+ . +----+ . MPLS Stacked forwarding . .................................. Figure 2: Centralization of Controller Figure 2 shows an architecture for centralization of controller. The control plane is separated from the forwarding plane. IP RAN Controller is a software system that can be deployed either in a network device or a separate computer server. IP RAN controllers control the entire IP RAN network domain, the size of the domain can be defined by Network Operator based on the actual network planning and use cases. IP RAN controllers manage the IP RAN network based on the network topology, actual states and status, which are operated by the network administrator. The controller provide the northbound interface to network management system used for service deployment, monitoring, troubleshooting, fault location, etc. CSG, ASG and RSG (we call them forwarding nodes) are only responsible for MPLS stack forwarding. RSVP-TE and LDP signaling protocol are not required in these forwarding nodes. They only need to support topology collecting and report them to controller. Forwarding nodes keep the basic routing functions in order to establish control and management channel between IP RAN Controller/NMG and all the forwarding nodes accepts network resources and states from the controller. Khasnabish, et al. Expires December 31, 2014 [Page 7] Internet-Draft SR IP RAN use case June 2014 5.1. Requirement for Control Node The logical centralization controller is introduced in the IP RAN network. Centralization controller is responsible for network topology collecting and label distribution based on the service. Requirement for control node: (1) Control node should support collecting network topology, and managing network resource, route computing, and MPLS label distribution. (2) Control node support service chaining. (3) Control node support secure channel, and it should establish the secure connection between forwarding node. 5.2. Requirement for Forwarding Node 5.2.1. Forwarding Node Structure The forwarding node structure in segment routing based IP RAN network is as following: +-----------------------------------------+ | | | +---------+ +--------+ | | | Control | | Config | | | | Agent | | | | | +---------+ +--------+ | | | | +-----------+ +----------------+ | | | Routing | |Topo management | | | +-----------+ +----------------+ | | | | +---------+ +----------+ | | | TEDB | |policy DB | | | +---------+ +----------+ | +-----------------------------------------+ Figure 3: Forwarding node structure The forwarding node simplifies the signaling related components, such as signal protocol component, signal label database, and a new component Control Agent is introduced to communicate with the centralization Controller. Khasnabish, et al. Expires December 31, 2014 [Page 8] Internet-Draft SR IP RAN use case June 2014 Control Agent: control agent is used to communicate with the centralization controller. The forwarding node reports its topology and resource information, and receives the label distributed and policy through control agent. The control agent establishes the secure channel with controller. The BGP-LS protocol is recommended to use as the communication protocol between control agent and controller in this document. Config: the config component is used for management and configuration. It is the interface with network management. Routing: is the traditional component, is used for route computing. The routing protocol (ISIS, OSPF, and BGP) is required for the forwarding node. Topo management: Topology management is responsible for topology computing, and topology status reporting. TEDB: The label database. Policy DB: policy database. 6. Security Considerations TBD. 7. Acknowledgements In progress. 8. IANA Considerations This is no IANA request for this document. 9. Normative References [I-D.filsfils-rtgwg-segment-routing] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, "Segment Routing Architecture", draft-filsfils-rtgwg- segment-routing-01 (work in progress), October 2013. [I-D.francois-spring-resiliency-use-case] Francois, P., Filsfils, C., Decraene, B., and R. Shakir, "Use-cases for Resiliency in SPRING", draft-francois- spring-resiliency-use-case-02 (work in progress), April 2014. Khasnabish, et al. Expires December 31, 2014 [Page 9] Internet-Draft SR IP RAN use case June 2014 [I-D.gredler-idr-bgp-ls-segment-routing-extension] Gredler, H., Ray, S., Previdi, S., Filsfils, C., Chen, M., and J. Tantsura, "BGP Link-State extensions for Segment Routing", draft-gredler-idr-bgp-ls-segment-routing- extension-01 (work in progress), February 2014. [I-D.ietf-mpls-seamless-mpls] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., and D. Steinberg, "Seamless MPLS Architecture", draft- ietf-mpls-seamless-mpls-07 (work in progress), June 2014. [I-D.previdi-spring-problem-statement] Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., Horneffer, M., Geib, R., Shakir, R., and R. Raszuk, "SPRING Problem Statement and Requirements", draft- previdi-spring-problem-statement-04 (work in progress), April 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Bhumip Khasnabish ZTE TX Inc. 55 Madison Avenue, Suite 160 Morristown, New Jersey 07960 USA Phone: +001-781-752-8003 Email: bhumip.khasnabish@ztetx.com, vumip1@gmail.com Fangwei Hu ZTE Corporation No.889 Bibo Rd Shanghai 201203 China Phone: +86 21 68897637 Email: hu.fangwei@zte.com.cn Khasnabish, et al. Expires December 31, 2014 [Page 10] Internet-Draft SR IP RAN use case June 2014 LUIS MIGUEL CONTRERAS MURILLO Telefonica I+D Distrito Telefonica, Edificio Sur 3, Planta 3 Madrid 28050 Spain Phone: +86 21 68896273 Email: lmcm@tid.es Khasnabish, et al. Expires December 31, 2014 [Page 11]