Internet DRAFT - draft-ji-i2rs-usecases-ccne-service

draft-ji-i2rs-usecases-ccne-service







Network Working Group                                              X. Ji
Internet-Draft                                                 S. Zhuang
Intended status: Informational                                  T. Huang
Expires: January 5, 2015                                        S. Hares
                                                     Huawei Technologies
                                                            July 4, 2014


I2RS Use Cases for Control of Forwarding Path by Central Control Network
                             Element (CCNE)
                 draft-ji-i2rs-usecases-ccne-service-02

Abstract

   As networks expand bridging access, Data Center, and WAN, more
   networks have a central control point for the network elements in one
   administrative domain.  This document defines that network device as
   central control network element (CCNE).  The CCNE can be RR Router,
   PCE Server, or a federation of RR Router and PCE Server, or other
   devices.  This document describes use cases where the CCNE can
   utilize both these the traditional functions and the programmatic
   Interface to Routing System (I2RS) to communicate with devices in the
   network.  The I2RS use cases described in this document encompass:
   Control IP Network by RR Router, Control MPLS TE Network by PCE
   Server.

   The goal of this document is to increase the community's
   understanding of how CCNE extensions fit within the overall I2RS
   architecture.  It is intended to provide a basis for the solutions
   draft describing the set of interfaces for the CCNE device.

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





Ji, et al.               Expires January 5, 2015                [Page 1]

Internet-Draft           I2RS Use Cases for CCNE               July 2014


   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 January 5, 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
   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Teminology  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Requirements for I2RS from CCNE use cases . . . . . . . . . .   3
   4.  Use Case of I2RS in Control Forward Path by CCNE  . . . . . .   4
     4.1.  I2RS Use Cases for Control Path by RR . . . . . . . . . .   4
       4.1.1.  RR Provides Whole Network Views . . . . . . . . . . .   5
       4.1.2.  Explicit IP Path Configuration on RR  . . . . . . . .   5
       4.1.3.  RR based Traffic Steering . . . . . . . . . . . . . .   6
       4.1.4.  RR Events . . . . . . . . . . . . . . . . . . . . . .   8
     4.2.  I2RS Use Case for Control MPLS TE Network Path by PCE . .   8
       4.2.1.  PCE Server Provides Whole MPLS TE Network Views . . .   8
       4.2.2.  Global Concurrent Re-optimization . . . . . . . . . .   9
       4.2.3.  Failure Simulation  . . . . . . . . . . . . . . . . .  10
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11








Ji, et al.               Expires January 5, 2015                [Page 2]

Internet-Draft           I2RS Use Cases for CCNE               July 2014


1.  Introduction

   I2RS working group is chartered to define an interface to the routing
   system [I-D.ietf-i2rs-architecture] . This interface can be used to
   read topology and forwarding information of the routing system.  This
   document discusses the use cases of I2RS in controlling forward path
   scenarios by CCNE.

   With the development of network technologies, more and more
   applications need to have a central control point for the network
   elements in one administrative domain.  Such central control point is
   a central control network element (CCNE).  CCNE controls the network
   elements in its administrative domain, the type of CCNE can be RR
   Router, PCE Server, or a federation of RR Routers and PCE Servers,
   etc.  CCNE is developed from the traditional network element, which
   with some I2RS interfaces can provide both traditional network
   services and I2RS services.

   This document describes requirement and use cases for which I2RS can
   be used for CCNE device.  The use cases described in this document
   encompass: Control IP Network by RR Router, Control MPLS TE Network
   by PCE Server.  The goal is to increase the community's understanding
   of where the I2RS CCNE extensions fit within the overall I2RS
   architecture.  It is intended to provide a basis for the solutions
   draft describing the set of interfaces for the CCNE device.

2.  Teminology

   RIB: Routing Information Base

   I2RS: Interface to Routing System

   RR: Route Reflector

   PCE: Path Computation Element

   Central Controlled Network Element (CCNE):

3.  Requirements for I2RS from CCNE use cases

   This section list the I2RS requirements derived from these CCNE use
   cases.  The numbering of the requirements uses CCNE-REQ-nn to provide
   a global numbering for all I2RS requirements

   The use cases in this document show the following requirements for
   I2RS are the following:





Ji, et al.               Expires January 5, 2015                [Page 3]

Internet-Draft           I2RS Use Cases for CCNE               July 2014


   CCNE-REQ-01: I2RS interface should support I2RS client running on a
   CCNE to be able to pull information from both the BGP RR and the PCE.
   This information can include: BGP topology information, BGP routes,
   BGP statistics, BGP Peer topologies, PCE topology information, and
   PCE state information.  The I2RS Client's request for reading of the
   RR and PCE topology information needs to have timely and rapid
   response from the I2RS Agent.

   CCNE-REQ-02: I2RS client should be able to set resource constraints
   at the I2RS Agent, and receive status information on the setting of
   resource constraints.

   CCNE-REQ-03: I2RS interface should be able to set service goal value
   to CCNE.

   CCNE-REQ-04: I2RS client should be able support information models
   that allow re-optimization traffic model at at CCNE .

   CCNE-REQ-05: I2RS client should be able to receive notification at
   the CCNE, and be able to send status to the I2RS agent.

   CCNE-REQ-06: I2RS client should work in parallel with traditional
   network management or OAM protocols sent to the general NE.

   CCNE-REQ-07: I2RS clients should be able to to be light weight enough
   to be able to support running on a variety of devices (routers,
   centralized servers, or devices doing both).

4.  Use Case of I2RS in Control Forward Path by CCNE

4.1.  I2RS Use Cases for Control Path by RR

   A route reflector (RR) is a network routing component.  It offers an
   alternative to the logical full-mesh requirement of internal border
   gateway protocol (IBGP).  A RR acts as a focal point for IBGP
   sessions.  The purpose of the RR is concentration.  Multiple BGP
   routers can peer with a central point, the RR - acting as a route
   reflector server - rather than peer with every other router in a full
   mesh.  All the other IBGP routers become route reflector clients.

   Traditional IP network provides only Best Effort (BE) data
   transmission capacity without assuring reachability, and does not
   provide services with QOS assurance.  Traditional IP path is not
   explicit, and is difficult to monitor and tune.  At the moment IP
   Traffic Engineering usually is being implemented through complicated
   route policy, and does not efficiently use network bandwidth.





Ji, et al.               Expires January 5, 2015                [Page 4]

Internet-Draft           I2RS Use Cases for CCNE               July 2014


   With the IP network more and more widely used, users and applications
   are placing increased demands on Internet service providers (ISPs) to
   deliver explicit IP path configuration, flexible route control, IP
   Traffic Engineering, better QOS, efficient monitoring, and tuning
   method.  To assist network operators in addressing this challenge, we
   present some I2RS RR use cases, introduce a set of I2RS programmatic
   APIs for RR that allows a network operator to flexibly control
   routing between the traffic ingresses and egresses within an ISP's
   network.

      +---------------------+
      | APP + I2RS Client   |
      | (Central Controller)|
      +---------------------+
               |
   [Interface for control ip forward network path]
               |
          +----------+         +-----------+
          |RR Router |-[ BGP ]-| RR Router |
          +----------+         +-----------+
                |
              [BGP]
                |
            +--------+
            | Router |
            +--------+

      Figure 1. Control IP Network by RR

4.1.1.  RR Provides Whole Network Views

   For an IP network, if all routers run BGP and are connected by a
   centralized RR, and the RR has the topology, network capacity,
   network resource and customer policy etc information of the whole
   network.  Then APP or Controller can get the whole network views from
   RR.

   [[I-D.medved-i2rs-topology-im]] defines the information model for
   network topologies.

4.1.2.  Explicit IP Path Configuration on RR

   According to whole network views get from RR, applications can push
   an explicit IP path configuration on RR.  For example in Figure 2, a
   path from Source 1 (S1) to Destination 1 (D1): S1-A-B-C-D1.  The use
   of this path will be described in next Section.





Ji, et al.               Expires January 5, 2015                [Page 5]

Internet-Draft           I2RS Use Cases for CCNE               July 2014


                     +-------------------+
                     | APP-I2RS Client   |
                     |    (CCNE)         |
                     +-------------------+
                              |
        [Interface for control ip forward network path]
                              |
                             ----
                            /    \
                           |  RR  |
                            \    /
                            /-+-\
                           /  |  \
                          /   |   \
                         / +--+-+  \
                  +--+-+/| | B  |   +--+-+
       Source 1---| A  | | +----+   | C  |--- Destination 1
               \ /+----+ |          +----+\ /
                *    +---+----+-------+    *
               / \+--+-+      |     +-+--+/ \
       Source 2---| D  |   +--+-+   | F  |--- Destination 2
                  +----+   | E  |   +----+
                           +----+
       Figure 2: Route Reflection based Traffic Steering (RRTS)

4.1.3.  RR based Traffic Steering

   RR based Traffic Steering
   ([[I-D.chen-idr-rr-based-traffic-steering-usecase] ]) introduces the
   requirements and use cases of RRTS.

   For a production network, an acceptable solution should be able to
   smoothly and incrementally upgrade the network and should not affect
   the on-going services.  Route Reflection is widely deployed in the
   field, a Route Reflector (RR) has the ability to "install"/distribute
   a route to its client with the nexthop that can be either the RR
   itself or any other different BGP speakers.  Given this, for an IP
   network, if all routers run BGP and are connected by a centralized
   RR, and the RR has the topology, network capacity, network resource
   and customer policy etc information of the whole network.  Then the
   RR can compute the routes for every router and install/distribute the
   routes to corresponding routers.









Ji, et al.               Expires January 5, 2015                [Page 6]

Internet-Draft           I2RS Use Cases for CCNE               July 2014


       +-------------------+
       | APP-I2RS client   |
       | (CCNE)
       +-------------------+
                |
           [BGP RR API]
                |
         +------------+                  +------------------+
         | RR Router  |--[Topology API]--| Topology Manager |
         +------------+                  +------------------+
                |
            [BGP API]
                |
         +------------+
         |   Router   |
         +------------+
               Figure 3: An Architecture for RR

   Figure 3 shows an architecture for RR.  APP and RR gets topology
   information from Topology Manager via Topology API.  APP computes the
   IP Path and pushes the explicit IP Path Configuration to RR via BGP
   RR API.  RR transfers the IP Path into BGP routes and pushes them to
   its clients via BGP API.

   Figure 2 is a reference architecture of the Route Reflection based
   Traffic Steering (RRTS).  The RR and its route reflection clients
   form a RRTS domain.  The RR is a I2RS controller that is responsible
   for the BGP route decision of the whole domain.  All other routers in
   the domain are as route reflection clients of the RR, each router
   will establish an I-BGP session to the RR, and there is no direct BGP
   sessions among these routers.

   This looks no different from the current Route Reflector (RR) based
   architecture.  For each client, it will still run as current, when
   received BGP routes from outside, it will transparently distribute
   the routes to the RR.  For each route, the RR will make the decision
   for each relevant router and then install/distribute the route to
   each related router.

   For example, for a path from Source 1 (S1) to Destination 1 (D1), if
   the computed path is: S1-A-B-C-D1, then the RR will distribute a
   route (D1) to C with the nexthop set to D1; a route (D1) to B with
   the nexthop set to C, and a route (D1) to A with the nexthop set to
   B, and finally the route (D1) will be distributed to S1 by A.

   RRTS will not require the clients to make any changes.  All the
   changes are made on the RR, the RR can apply any route or traffic
   engineering algorithms.



Ji, et al.               Expires January 5, 2015                [Page 7]

Internet-Draft           I2RS Use Cases for CCNE               July 2014


4.1.4.  RR Events

4.1.4.1.  Notification of IP Path Events

   With I2RS, it is conceivable that applications could tell the status
   of an IP Path.

4.1.4.2.  Tracing IP Paths

   With I2RS, it would be possible for an I2RS controller to rapidly
   gather information from across a large set of BGP routers in the
   network via RR, then we can trace the state of IP path easily.

4.2.  I2RS Use Case for Control MPLS TE Network Path by PCE

   Path computation in large, multi-domain networks is complex and may
   require special computational components and cooperation between the
   elements in different domains.  PCE [[RFC4655]] is proposed to
   address this problem.

   With PCE, operator can make more services and traffic to be hold in
   the same MPLS TE network, and promote network resource utilization.

   The following describes set of use cases for which I2RS's
   programmatic interfaces can be used to control and analyze MPLS TE
   network.  PCE use cases described in this document cover the
   following aspects: TE Link attributes configuration, TE constraints
   configuration, global concurrent re-optimization, network topology or
   resource query and failure simulation.  The goal is to inform the
   community's understanding of where the I2RS PCE extensions fit within
   the overall I2RS architecture.  It is intended to provide a basis for
   the solutions draft describing the set of Interfaces to the PCE.

4.2.1.  PCE Server Provides Whole MPLS TE Network Views

   For MPLS TE network, if all routers run PCEP protocol and are
   connected with PCE server or router, PCE device has the TE topology
   and network resources of the whole network.

   With I2RS, the centralized I2RS client (attached to application) may
   get the whole TE topology and network resources from the PCE device.
   It is not necessary for PCC devices to update to support I2RS.

   Before upgrade a current network, network operator may need to check
   if it is necessary.  PCE makes it easy for operator to check network
   resource by providing some user query interfaces.





Ji, et al.               Expires January 5, 2015                [Page 8]

Internet-Draft           I2RS Use Cases for CCNE               July 2014


   With I2RS, the process may be put in I2RS Client, and connected with
   other applications like resource visualized toos, this will make it
   easy for operator do network management and maintenance.

4.2.2.  Global Concurrent Re-optimization

   The stateful PCE [[I-D.ietf-pce-stateful-pce]] specifies PCEP
   extensions to enable stateful control of LSPs to PCE.  With
   delegation of control over LSPs from PCC, an active stateful PCE can
   request a PCC to update one or more attributes of an LSP and to re-
   signal the LSP with updated attributes.  Global concurrent re-
   optimization is a concurrent path computation application where a set
   of TE paths are computed concurrently in order to efficiently utilize
   network resources.

   +-------------------+
   | APP -- I2RS Client|
   | (on CCNE)         |
   +-------------------+
           |
   [Interface for control mple TE network path]
           |
     +----------+          +--------+
     |PCE Server|--[PCEP]--| PCC    |
     |  Router  |          | Router |
     +----------+          +--------+
          |
        [PCEP]
          |
     +--------+
     | PCC    |
     | Router |
     +--------+

      Figure 4.  Control MPLS TE Network by PCE

4.2.2.1.  TE Link and TE LSP Constraint Configuration

   To adjust MPLS TE path more subtly, new link attributes such as
   latency may be proposed to gain the goal.  However, it is not a good
   way to upgrade devices or extends protocols.  It would be easy if PCE
   provide interfaces to set TE links' attributes and TE LSPs'
   constraints.

   With I2RS, The interfaces can be extended to conveniently adjust TE
   network logical topology.





Ji, et al.               Expires January 5, 2015                [Page 9]

Internet-Draft           I2RS Use Cases for CCNE               July 2014


4.2.2.2.  Calculated Path Approve and Disapprove

   With interfaces to set TE links' attributes and TE LSPs' constraints
   would be provided, network operator may trigger a global concurrent
   re-optimization after some modification.  He may want to check
   results before they take effect.  A confirmation mechanism is
   proposed for operator to confirm the calculated result, and paths
   would be sent to PCC if approved otherwise canceled.

   With I2RS, I2RS client can easily promote the network resource
   utilization by instructing the I2RS agent to triggering PCE to do
   global concurrent re-optimization, and report results.  The I2RS
   Client can then approve or disapprove with the calculated results
   based on internal logic, and then send any changs to the I2RS Agents
   on the appropriate nodes.

4.2.3.  Failure Simulation

   In network upgrade, operator typically fist find the traffic passing
   the node or link to be upgraded, estimate the affection.  If it is
   accepted, operator will switch over the traffic and switch back after
   the upgrade.  It is arduous for operator to estimate the affection of
   link or node failure, more ever, there is not only one failure.

   With I2RS, I2RS controller may easily address the problem.  I2RS
   client could ask all I2RS agents for appropriate nodes to send status
   information on the link failure links or nodes failures.  Based on
   this information, the I2RS client could pass information to a local
   PCE devices (via PCE protocol or I2RS updates) to do failure
   simulation based on the status information.  After the failure
   simulation, the I2RS client could then update adjusted pathways to
   the I2RS agent.

5.  IANA Considerations

   This document makes no request of IANA.

6.  Security Considerations

   Routing information is very critical and sensitive information for
   the operators.  I2RS should provide strong security mechanism to
   protect the routing information that it could not be accessed by the
   un-authorised users.  It should also protect the security and
   integrity protection of the routing data.







Ji, et al.               Expires January 5, 2015               [Page 10]

Internet-Draft           I2RS Use Cases for CCNE               July 2014


7.  References

7.1.  Normative References

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

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

7.2.  Informative References

   [I-D.chen-idr-rr-based-traffic-steering-usecase]
              Chen, M., Zhuang, S., Zhu, Y., and S. Wang, "Use Cases of
              Route Reflection based Traffic Steering", draft-chen-idr-
              rr-based-traffic-steering-usecase-00 (work in progress),
              July 2013.

   [I-D.ietf-i2rs-architecture]
              Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
              Nadeau, "An Architecture for the Interface to the Routing
              System", draft-ietf-i2rs-architecture-04 (work in
              progress), June 2014.

   [I-D.ietf-pce-stateful-pce]
              Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
              Extensions for Stateful PCE", draft-ietf-pce-stateful-
              pce-07 (work in progress), October 2013.

   [I-D.medved-i2rs-topology-im]
              Medved, J., Bahadur, N., Clemm, A., and H.
              Ananthakrishnan, "An Information Model for Network
              Topologies", draft-medved-i2rs-topology-im-01 (work in
              progress), October 2013.

Authors' Addresses

   Xiaofeng Ji
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: jixiaofeng@huawei.com







Ji, et al.               Expires January 5, 2015               [Page 11]

Internet-Draft           I2RS Use Cases for CCNE               July 2014


   Shunwan Zhuang
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: zhuangshunwan@huawei.com


   Tieying Huang
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: huangtieying@huawei.com


   Susan Hares
   Huawei Technologies
   7453 Hickory Hill
   Saline, MI  48176
   USA

   Email: shares@ndzh.com


























Ji, et al.               Expires January 5, 2015               [Page 12]