Internet DRAFT - draft-li-sdnrg-sdni-seamless-mpls-mbh

draft-li-sdnrg-sdni-seamless-mpls-mbh






Network Working Group                                              Z. Li
Internet-Draft                                                    R. Tao
Intended status: Informational                       Huawei Technologies
Expires: April 30, 2015                                 October 27, 2014


             Inter-SDN in Seamless MPLS for Mobile Backhaul
                draft-li-sdnrg-sdni-seamless-mpls-mbh-00

Abstract

   This document introduces the inter-SDN framework of Seamless MPLS to
   integrate the mobile backhaul network with the core network.

Requirements Language

   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 RFC 2119 [RFC2119].

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 April 30, 2015.

Copyright Notice

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

   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



Li & Tao                 Expires April 30, 2015                 [Page 1]

Internet-Draft        SDNi in Seamless MPLS for MBH         October 2014


   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Framework . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Inter-SDN Architecture  . . . . . . . . . . . . . . . . .   4
     4.2.  Procedures  . . . . . . . . . . . . . . . . . . . . . . .   5
       4.2.1.  Traffic Optimization in Each Domain . . . . . . . . .   5
       4.2.2.  End-to-End Traffic Optimization . . . . . . . . . . .   7
       4.2.3.  End-to-End Service Provision  . . . . . . . . . . . .   8
       4.2.4.  Auto Discovery  . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   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
   highly flexible and a scalable architecture and the possibility to
   integrate 100.000 of nodes.  One of the key elements of Seamless MPLS
   is the separation of the service and transport plane: it can reduce
   the service specific configurations in network transport node.

   The main purpose of Seamless MPLS is to deal with the integration of
   access networks and core/aggregation networks.  The typical access
   devices taken into account are DSLAM(Digital Subscriber Link Access
   Multiplexer), etc.  Now the mobile backhaul service has been deployed
   widely, the requirement of the integration of mobile backhaul
   networks and core networks has been proposed.  At the same time, SDN
   is being developed to facilitate network operation and management.
   In the seamless MPLS for mobile backhaul, since there are multiple
   domains including the core network and multiple mobile backhaul
   networks, when SDN is introduced, for each domain there maybe one
   controller.  In order to implement the end-to-end network service
   provision, there should be orchestration among multiple controllers.
   Thus the inter-SDN requirements are proposed in the Seamless MPLS
   architecture for mobile backhaul networks.

   This document describes new requirements and framework for inter-SDN
   in the Seamless MPLS architecture for mobile backhaul network



Li & Tao                 Expires April 30, 2015                 [Page 2]

Internet-Draft        SDNi in Seamless MPLS for MBH         October 2014


2.  Terminology

   This document uses the following terminology:

   o  ABR: Area Border Router

   o  ASBR: AS Border Router

   o  PE: Provider Edge

   o  PCE: Path Calculation Element

   o  PCC: Path Calculation Client

3.  Requirements

   The framework of Seamless MPLS for mobile backhaul is introduced in
   [I-D.li-mpls-seamless-mpls-mbh].  There are following requirements
   for SDN in Seamless MPLS for mobile backhaul network:

   1.  Network Traffic Optimization in each Domain

   For mobile service, there are different SLA requirement.  For each
   domain, in order to satisfy the SLA requirement for the traffic in
   each domain, the path optimization is necessary.  This means in each
   domain the MPLS traffic engineering based on SDN can be introduced to
   optimize the traffic path.

   2.  End-to-End Traffic Optimization

   For seamless MPLS, the end-to-end label BGP LSP should be set up to
   bear the mobile service.  In order to satisfy the SLA requirement for
   the traffic, it is necessary to implement the end-to-end traffic
   optimization.  This means the SDN can be introduced to optimize the
   end-to-end BGP LSP.

   3.  End-to-End Service Provision

   In the seamless MPLS, there may be complex provision work including
   MPLS LDP/TE, label BGP, L2VPN/L3VPN, etc.  The SDN can be introduced
   to facilitate the service provision.

4.  Framework








Li & Tao                 Expires April 30, 2015                 [Page 3]

Internet-Draft        SDNi in Seamless MPLS for MBH         October 2014


4.1.  Inter-SDN Architecture

                         +--------------+
                         | Orchestrator |
                         +--------------+
                                |
                                |
                                |
                             +------+
              |--------------|SUPER |-------------|
              |              |CTRLER|             |
              |              +------+             |
              |                 |                 |
              |                 |                 |
              |                 |                 |
          +------+           +------+          +------+
     |----| SUB- |----|  |---| SUB- |--|  |----| SUB- |---|
     |    |CTRLER|    |  |   |CTRLER|  |  |    |CTRLER|   |
     |    +------+    |  |   +------+  |  |    +------+   |
     |                |  |             |  |               |
     |                |  |             |  |               |
     |                |  |             |  |               |
     |               +----+           +----+              |
     |           ....|ABR1|...........|ABR3|....          |
   +----+   .....    +----+           +----+    .....   +----+
   | PE |...                                         ...| PE |
   +----+   .....                                       +----+
                 ....+----+           +----+    .....
                     |ABR2|...........|ABR4|....
                     +----+           +----+

     |      IGP-X1     |      IGP-Y     |       IGP-X2     |
     |       (MBH)     |      (Core)    |       (MBH)      |
     |                 |                |                  |
     |-----BGP LSP-----|-----BGP LSP----|------BGP LSP-----|
     |                 |                |                  |
     |---LDP/TE LSP----|----LDP/TE LSP--|-----LDP/TE LSP---|
     |                 |                |                  |

            Figure 1  Inter-SDN Architecture

   In the inter-SDN architecture, there are multiple components.  The
   functionalities of components are introduced as follows:

   1.  Orchestrator






Li & Tao                 Expires April 30, 2015                 [Page 4]

Internet-Draft        SDNi in Seamless MPLS for MBH         October 2014


   -- Provides E2E cross-controller orchestration, and downloads path
   optimization policy to manage traffic on demand.  Orchestrator
   connects to the Super Controller by Netconf.

   2.  Super Controller

   -- Network model management: Service/Network model abstraction.
   Report the network model to Orchestrator by Netconf interface.

   -- Inter-domain topology management: domain edge topology management

   -- Inter-domain LSP path management: Inter-domain BGP LSP path
   management.  Calculate and establish BGP LSP path across different
   domain based on inter-domain topology, and inform sub-controller to
   establish LSP inside the domain.  Super-controller communicate with
   sub-controller by Netconf Interface, getting inter-routing/link
   information, and transmitting LSP modification information.

   -- Network configuration: Configuration according to the network
   model (Netconf).

   3.  Sub-Controller:

   -- Network model management: network model abstraction.  Report the
   network model to Super Controller by Netconf interface.

   -- Intra-domain topology management: Collect Inner-domain topology by
   IGP-TE/BGP LS.  Identify domain edge topology and report it to Super
   Controller by Netconf interface.

   -- Intra-domain path management: Intra-domain service path
   management.  Calculate/establish LSP path Inner-domain based on
   Inter-domain topology collected by BGP/BGP LS.

   -- Network configuration: Configuration according to the network
   model (Netconf).

4.2.  Procedures

4.2.1.  Traffic Optimization in Each Domain

   1.  Topology Information Collection

   The topology information needs to be collected for the traffic
   optimization.  Both IGP and BGP LS [I-D.ietf-idr-ls-distribution]can
   satisfy the requirements.  If there are multiple IGP areas in each
   mobile backhaul network and the end-to-end MPLS TE tunnels needs to
   set up, when IGP is adopted for topology collection, the Sub-



Li & Tao                 Expires April 30, 2015                 [Page 5]

Internet-Draft        SDNi in Seamless MPLS for MBH         October 2014


   Controller needs to set up multiple IGP adjacencies to collect
   topology information of multiple IGP areas.

   2.  Traffic Optimization

   When Sub-Controller is used for the path optimization in each domain,
   It can be acted as the PCE server.  There are two different scenarios
   for the traffic optimization in each domain:

   o Scenario 1: There is only MPLS TE tunnel optimization.

   The MPLS TE tunnel optimization requirement can be sent from the
   Orchestrator to the Super Controller to the Sub-Controller.  The
   protocol can be Netconf.  The Yang model needs to be defined based on
   the [I-D.ji-i2rs-usecases-ccne-service].

   There are two cases for Sub-Controller to optimize MPLS TE path:

   Case 1: PCE will initiate the new path calculation.  Then it will
   send the new path from the PCE to the PCC through PCEP to re-optimize
   the path for the existing tunnel in the distributed devices.

   Case 2: PCE will initiate the new path calculation.  And it will
   initiate setup of the new MPLS TE tunnel from the PCE to the PCC.
   The new tunnel will be created in the ingress LSR without
   configuration.

   o Scenario 2: Label BGP LSP optimization triggers dynamic MPLS TE.

   Label BGP LSP optimization requirement can be sent from the
   orchestrator to the Super Controller to the Sub-Controller.  The
   protocol can be Netconf.  The Yang model needs to be defined based on
   the [I-D.ji-i2rs-usecases-ccne-service].

   The label BGP LSP optimization requirement will trigger the MPLS TE
   tunnel optimization in Sub-Controller.  There are two cases:

   Case 1: label BGP LSP reuses the existing MPLS TE tunnel.  PCE will
   initiate the new path calculation.  Then it will send the new path
   from the PCE to the PCC through PCEP to re-optimize the path for the
   existing tunnel in the distributed devices.

   Case 2: There is no existing MPLS TE tunnel for the optimized label
   BGP route.  PCE will initiate the new path calculation.  And it will
   initiate setup of the new MPLS TE tunnel from the PCE to the PCC.
   The new tunnel will be created in the ingress LSR without
   configuration.




Li & Tao                 Expires April 30, 2015                 [Page 6]

Internet-Draft        SDNi in Seamless MPLS for MBH         October 2014


4.2.2.  End-to-End Traffic Optimization

   1.  Label BGP Route Collection

   BGP should run between the Sub-Controller and the distributed
   devices.  And BGP should also run betweens the Super Controller and
   the Sub-Controllers.  BGP Add-Paths [I-D.ietf-idr-add-paths] is
   enabled for all BGP peers.  Then the Super Controller and the Sub-
   Controller can collect all the label BGP routes.

   2.  Topology Information Collection

   IGP can be run between the Sub-Controller and the distributed devices
   to collect network topology.

   There are two options for the Super Controller to collect topology
   information from the Sub-Controller.

   Option 1: Collect all topology information from the Sub-Controller by
   the Super Controller: If so, for the reason of performance and
   scalability, it needs to run BGP-LS for the Super Controller to
   collect the topology information from the Sub-Controller.

   Option 2: Collect abstract topology information from the Sub-
   Controller by the Super Controller: In this method, the Sub-
   Controller needs to abstract the network topology which means the
   whole network topology will not leak to the Super Controller.  This
   is for the better scalability and to comply with the hierarchy
   principle.  If the abstract topology information is reported, both
   BGP-LS and Netconf can be adopted owing to limited topology
   information.

   3.  Traffic Optimization for Label BGP LSP

   -- The orchestrator can determine what label BGP LSP should be
   optimized and the constraints and the policy.

   -- When Super Controller receives the optimization requirement, it
   can calculate the optimal path for the label BGP LSP based on the
   global network topology information.  The result is that it may
   change to another BGP nexthop for the specific label BGP LSP.  Or it
   need not change the nexthop for the specific label BGP LSP, but need
   to optimize the TE tunnel which bear the label BGP LSP.  Then the
   Super Controller will download the different network optimization
   requirement to the Sub-Controller.

   -- If only MPLS TE tunnel needs to optimize, please refer to the
   above process of traffic optimization in each domain.  If the dynamic



Li & Tao                 Expires April 30, 2015                 [Page 7]

Internet-Draft        SDNi in Seamless MPLS for MBH         October 2014


   TE result is to do LSP optimization for the tunnel (This means the
   label BGP LSP still uses the existing MPLS TE tunnel.  It is just to
   do LSP make-before-break for the tunnel), there is nothing about the
   change of the label BGP route.  If the result is to set up new MPLS
   TE tunnel (This means the BGP route will use the new MPLS TE tunnel),
   it will use the Netconf or BGP extensions to make the corresponding
   label BGP route in the network devices will use the new MPLS TE
   tunnel.

   -- If the label BGP route needs to optimize and it may use the
   alternative nexthop, it will trigger the dynamic MPLS TE optimization
   firstly.  Please refer to the above process of traffic optimization
   in each domain.  Then the Sub-Controller will use the Netconf or BGP
   extensions to make the corresponding label BGP route to change the
   nexthop and correspondingly reuse the existing MPLS TE tunnel or use
   the new tunnel to the new nextop.

4.2.3.  End-to-End Service Provision

   1.  MPLS TE Tunnel in Each Domain

   For dynamic traffic engineering, the MPLS TE tunnel is not necessary
   to configure.  As the PCE initiated LSP is adopted, the configuration
   for MPLS TE tunnel in the network devices can be reduced.  And
   through the above process we can see that the MPLS TE tunnel can be
   triggered by label BGP LSP, the static MPLS TE tunnel will be removed
   gradually.

   2.  Label BGP Route

   According to the principle of Seamless MPLS, the connectivity between
   any pair of nodes should exist to facilitate the service provision.
   So the BGP peer should always set up between the Super Controller and
   the Sub-Controller and set up between the Sub-Controller and the PE/
   ABR.  This should be static configuration and need not to change
   frequently.

   The challenge for the label BGP route provision is the limited
   capability of access nodes.  In this case, BGP PUSH mode can not be
   adopted since the advertised routes may exceed the capability
   limitation of the access nodes.  Then BGP PULL mode based on the BGP
   ORF extensions should be introduced between the Sub-Controller and
   the access node.  It need depend on the L3VPN/L2VPN service provision
   which will be introduced in the next section.

   3.  L3VPN/L2VPN Service Provision





Li & Tao                 Expires April 30, 2015                 [Page 8]

Internet-Draft        SDNi in Seamless MPLS for MBH         October 2014


   1) The Orchestrator will provide the simplified user-oriented VPN
   provision method based on the abstract topology information collected
   from the Super Controller.  Then the VPN provision requirement will
   be downloaded to Super Controller through Netconf.  The Yang model
   should be defined according to the user-oriented VPN.

   2) When Super Controller receives the VPN provision requirement, it
   will convert the user-based VPN model to device-based VPN model.
   Then the following configuration can be calculated by the Super
   Controller:

   -- the VPN configuration in PEs in different domains.

   -- the BGP configuration for VPN in different domains.

   -- the VPN interface configuration between PE and CE in different
   domains.

   The configuration can be distributed through the Netconf from Super
   Controller to the Sub-Controller to the distributed devices.

   3) When the device receives the BGP/VPN configuration, it can
   determine the remote BGP peers for the specific VPN service.  If BGP
   PULL mode is adopted for the access node, it can trigger BGP ORF to
   get the corresponding label BGP route from the Sub-Controllers for
   the access node.

4.2.4.  Auto Discovery

   As the increasing of controller and network nodes, IGP and BGP
   extensions can be introduced for auto discovery.  IGP-based PCE auto-
   discovery method ([RFC5088] and [RFC5089]) can be introduced between
   the PCE and the PCC.  But the functionality of the Sub-Controller is
   not confined to PCE, these auto-discovery needs to be extended for
   the purpose of central control.  [I-D.li-rtgwg-igp-cc-reqs]
   requirement defines the possible extensions requirements for auto-
   discovery, including:

   o Advertisement of the role info of different components.

   o Advertisement of the capability info of different components.

   When BGP peer needs to setup between the Super Controller and the
   Sub-Controller, the BGP extension which is similar as the IGP
   extensions should be introduced for the auto-discovery.






Li & Tao                 Expires April 30, 2015                 [Page 9]

Internet-Draft        SDNi in Seamless MPLS for MBH         October 2014


5.  IANA Considerations

   This document makes no request of IANA.

6.  Security Considerations

   TBD.

7.  Informative References

   [I-D.ietf-idr-add-paths]
              Walton, D., Retana, A., Chen, E., and J. Scudder,
              "Advertisement of Multiple Paths in BGP", draft-ietf-idr-
              add-paths-10 (work in progress), October 2014.

   [I-D.ietf-idr-ls-distribution]
              Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
              Ray, "North-Bound Distribution of Link-State and TE
              Information using BGP", draft-ietf-idr-ls-distribution-06
              (work in progress), September 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.ji-i2rs-usecases-ccne-service]
              Ji, X., Zhuang, S., Huang, T., and S. Hares, "I2RS Use
              Cases for Control of Forwarding Path by Central Control
              Network Element (CCNE)", draft-ji-i2rs-usecases-ccne-
              service-02 (work in progress), July 2014.

   [I-D.li-mpls-seamless-mpls-mbh]
              Li, Z., Li, L., Morillo, M., Yang, T., and L. Contreras,
              "Seamless MPLS for Mobile Backhaul Network", draft-li-
              mpls-seamless-mpls-mbh-00 (work in progress), July 2014.

   [I-D.li-rtgwg-igp-cc-reqs]
              Li, Z. and H. Chen, "Requirements of Interior Gateway
              Protocol (IGP) for Central Control", draft-li-rtgwg-igp-
              cc-reqs-00 (work in progress), July 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5088]  Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
              "OSPF Protocol Extensions for Path Computation Element
              (PCE) Discovery", RFC 5088, January 2008.



Li & Tao                 Expires April 30, 2015                [Page 10]

Internet-Draft        SDNi in Seamless MPLS for MBH         October 2014


   [RFC5089]  Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
              "IS-IS Protocol Extensions for Path Computation Element
              (PCE) Discovery", RFC 5089, January 2008.

Authors' Addresses

   Zhenbin Li
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com


   Rober Tao
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Email: roberttao@huawei.com





























Li & Tao                 Expires April 30, 2015                [Page 11]