[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

SPRING WG                                                  B. Khasnabish
Internet-Draft                                               ZTE TX Inc.
Intended status: Informational                                     F. Hu
Expires: May 14, 2015                                    ZTE Corporation
                                                            L. Contreras
                                                          Telefonica I+D
                                                       November 10, 2014


                   Segment Routing in IP RAN use case
                 draft-kh-spring-ip-ran-use-case-02.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 May 14, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Khasnabish, et al.        Expires May 14, 2015                  [Page 1]


Internet-Draft             SR IP RAN use case              November 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 May 14, 2015                  [Page 2]


Internet-Draft             SR IP RAN use case              November 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 May 14, 2015                  [Page 3]


Internet-Draft             SR IP RAN use case              November 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 May 14, 2015                  [Page 4]


Internet-Draft             SR IP RAN use case              November 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.

   (8)  Reduction configuration for CSGs and ASGs: The number of CSGs
        and ASGs in the IP RAN domain are very huge now, and with the
        increase of mobile Internet traffic, more CSGs could be added to
        the Access Domain, and CSGs could be installed in wide area.
        There is a great need to do little or no configuration on CSGs
        to avoid configuration operation.

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



Khasnabish, et al.        Expires May 14, 2015                  [Page 5]


Internet-Draft             SR IP RAN use case              November 2014


        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.

   (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.

   (9)  Zero-configuration for CSGs and ASGs: The CSGs and ASGs could do
        little or zero-configuration by SID allocation mechanism
        ([I-D.lw-spring-sid-allocation]).  One of the ASGs in the IP RAN
        domain is selected as SRMN (segment routing management node),
        which advertise the SID mapping information for the various
        prefix associated with the SR nodes in the SR domain, and all
        the other ASGs and CSGs could get the SID automatically from the
        SRMN.  There are zero-configuration for the CSGs and ASGs.

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 May 14, 2015                  [Page 6]


Internet-Draft             SR IP RAN use case              November 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 May 14, 2015                  [Page 7]


Internet-Draft             SR IP RAN use case              November 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 May 14, 2015                  [Page 8]


Internet-Draft             SR IP RAN use case              November 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 May 14, 2015                  [Page 9]


Internet-Draft             SR IP RAN use case              November 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-02 (work in progress), October 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.lw-spring-sid-allocation]
              Liao, T., Bo, W., hu, f., and B. Khasnabish, "SPRING SID
              Allocation", draft-lw-spring-sid-allocation-00 (work in
              progress), October 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 May 14, 2015                 [Page 10]


Internet-Draft             SR IP RAN use case              November 2014


   Luis M. Contreras
   Telefonica I+D
   Ronda de la Comunicacion, s/n
   Sur-3 building, 3rd floor
   Madrid  28050
   Spain

   Email: luismiguel.contrerasmurillo@telefonica.com
   URI:   http://people.tid.es/LuisM.Contreras/










































Khasnabish, et al.        Expires May 14, 2015                 [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/