Terminology and Models for Control of Traffic Engineered Networks with Provider-Customer Relationship
draft-dios-ccamp-control-models-customer-provider-00

Network Working Group                           O. Gonzalez de Dios, Ed.
Internet-Draft                                           Telefonica GCTO
Intended status: Informational                            J. Meuric, Ed.
Expires: August 18, 2014                                          Orange
                                                           D. Ceccarelli
                                                                Ericsson
                                                       February 14, 2014

 Terminology and Models for Control of Traffic Engineered Networks with
                     Provider-Customer Relationship
          draft-dios-ccamp-control-models-customer-provider-00

Abstract

   Different kinds of relationships can be established among
   interconnected Traffic Engineered Networks.  In particular, this
   document focuses on the case where there is a customer-provider
   relation between the network domains.  The domain interconnection is
   a policy and administrative boundary.  This informational document
   collects current terminology and provides a taxonomy for the posible
   control plane based operation models.

   Each control model defines, on the one hand, the level of information
   that the domain acting as customer receives by control plane means
   from the domain acting as provider and, on the other hand, the
   control model will determine what can be requested from the customer
   domain to the provider domain.

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 August 18, 2014.

Gonzalez de Dios, et al. Expires August 18, 2014                [Page 1]
Internet-Draft Control Models for customer-provider netwks February 2014

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
     1.1.  Examples of Customer-Provider TE Network Domain Scenarios   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Customer Domain - Provider Domain Interface . . . . . . .   4
       2.1.1.  UNI in IP over Optical Networks . . . . . . . . . . .   4
       2.1.2.  ITU-T Definition of UNI . . . . . . . . . . . . . . .   4
       2.1.3.  OIF Definition of UNI . . . . . . . . . . . . . . . .   5
       2.1.4.  Proposed Vocabulary . . . . . . . . . . . . . . . . .   5
     2.2.  Reachability  . . . . . . . . . . . . . . . . . . . . . .   6
       2.2.1.  Unqualified Reachability  . . . . . . . . . . . . . .   6
       2.2.2.  Qualified Reachability  . . . . . . . . . . . . . . .   6
       2.2.3.  Qualified Reachability with associated potential TE
               path  . . . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Control Models  . . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Signaling Only  . . . . . . . . . . . . . . . . . . . . .   7
       3.1.1.  Signaling with Requirements . . . . . . . . . . . . .   8
       3.1.2.  Signaling with Collection . . . . . . . . . . . . . .   8
     3.2.  Signaling and Reachability Model  . . . . . . . . . . . .   8
       3.2.1.  Signalling + Basic Reachability . . . . . . . . . . .   9
       3.2.2.  Signalling + Qualified Reachability . . . . . . . . .   9
       3.2.3.  Signalling + Qualified Reachability + Potential
               Services  . . . . . . . . . . . . . . . . . . . . . .   9
     3.3.  Other Models  . . . . . . . . . . . . . . . . . . . . . .   9
       3.3.1.  Multi-Layer Networks / Multi-Region Networks  . . . .   9
       3.3.2.  Management Model  . . . . . . . . . . . . . . . . . .  10
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   5.  Contributing Authors  . . . . . . . . . . . . . . . . . . . .  10
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10

Gonzalez de Dios, et al. Expires August 18, 2014                [Page 2]
Internet-Draft Control Models for customer-provider netwks February 2014

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Traffic Engineered Networks can be interconnected, establishing
   different types of relationships among them.  For example, both
   network can have a peering relation, where connections starting in
   one domain and end in the other domain.  This document is focused on
   the case where the interconnected network domains have a customer-
   provider relationship among them.  Such customer-provider relation
   comes from the two main points.  On the one hand, end-to-end services
   in the customer network can be set up using services of a network
   acting as provider.  On the other hand, the customer-provider
   relation comes from the fact that their interconnection is a policy
   and administrative boundary, limiting the amount of information
   allowed to be exchanged between networks.  In the case of
   interconnected TE domains where there is no administrative nor strict
   policy boundary between customer and provider (typically, just a
   technolgy change), the MLN/MRN model can be applied.

   The interface between the customer and the provider domain is
   typically called "User-to-Network Interface" (UNI), and regarded as
   signaling-only [RFC4208].  Due to the strict asociation of
   functionality to the UNI term, its exact scope has become highly
   controversial.  This document compiles different definitions of the
   term used so far and propose some terminology to serve as a
   foundation to move the work forward.

   What is more, the document compiles the possible operation models of
   customer-provider network from the control plane perspective.  Each
   control model defines, on the one hand, the level of information of
   the domain acting as customer provides through the control plane to
   the domain acting as provider.  On the other hand, the control model
   will determine what can be requested from the customer domain to the
   provider domain.

1.1.  Examples of Customer-Provider TE Network Domain Scenarios

   The most typical example of interconnected TE domains that follow a
   customer-provider relation is an IP/MPLS domain using the services of
   an optical OTN/WDM network.  Note that the interconnected domain can
   be part of the same organization, but with different administration.

   A particular network scenario that has attracted lot of attention
   from the industry is the IP/MPLS/OTN/WDM over WDM.  The customer
   network is based on multi-layer routers able to set up packet-based
   TE connections over wavelengths.  The provider network is a WDM

Gonzalez de Dios, et al. Expires August 18, 2014                [Page 3]
Internet-Draft Control Models for customer-provider netwks February 2014

   optical network that provides the switching for the wavelenghts as
   well as restoration capabilities of the optical channels.

   Another example is MPLS over MPLS, where both customer and provider
   networks are able to set up packet based TE connections.  This is the
   case, for example, of carrier-over-carrier scenarios.

   Summing up, there number of applicable scenarios is wide.

2.  Terminology

2.1.  Customer Domain - Provider Domain Interface

   The interface between the customer and the provider domain is
   typically called "User-to-Network Interface" (UNI).  However, the
   term "UNI" has been used in different contexts and SDOs.  As a
   consequence, the exact definition of UNI and the functionalities
   included depend on the application.  Bellow, as a reference, it is
   shown a set of the different definitions of UNI.

2.1.1.  UNI in IP over Optical Networks

   [RFC3717] says: "The client-optical internetwork interface (UNI)
   represents a service boundary between the client (e.g., IP router)
   and the optical network.  The client and server (optical network) are
   essentially two different roles: the client role requests a service
   connection from a server; the server role establishes the connection
   to fulfill the service request -- provided all relevant admission
   control conditions are satisfied."

   In other words, this definition refers to a signaling protocol
   between two administrative domains with a customer-provider
   relationship.  It is agnostic to the existence of a data plane
   client-server relationship and to the side(s) of the boundary where
   it may happen, if any.

2.1.2.  ITU-T Definition of UNI

   ITU-T has defined the term UNI in the context of control plane.
   [G.807] [G.8081]  (ITU-T): "User-Network Interface for the control
   plane (UNI): A bidirectional signaling interface between service
   requester and service provider control plane entities."

   The terms "requester/provider" are used to refer to the relationship.

Gonzalez de Dios, et al. Expires August 18, 2014                [Page 4]
Internet-Draft Control Models for customer-provider netwks February 2014

2.1.3.  OIF Definition of UNI

   UNI: "The service control interface between a client device and the
   transport network."

   UNI-C: "The logical entity that terminates UNI signalling on the
   client device side."

   UNI-N: "The logical entity that terminates UNI signalling on the
   transport network side."

   The terms "client/transport" and "client/network" are used to refer
   to the relationship.

2.1.4.  Proposed Vocabulary

   As listed above, the existing terminology is far from unique.  To
   avoid overloaded concepts, this document proposes to use the
   "customer/provider" terms.

   Unless stated, this document focuses on control protocol exchanges
   and their uses across administrative boundaries for customer-provider
   interconnection.  Data plane transition and/or client-server
   relationship may not be aligned with the boundary.

2.1.4.1.  Customer network

   A Customer network is defined as a network domain able to request a
   connectivity service to a provider network domain across an
   administrative boundary.

2.1.4.2.  Provider network

   A Provider network is defined as a network domain able to deliver
   connectivity services to a customer network domain across an
   administrative boundary.

2.1.4.3.  Customer-Provider Control Plane Interface

   The control plane interface between the customer network domain and
   the provider network domain convey a set of control functionalities
   that help to operate such kind of networks.  The exact
   functionalities of this Interface (and then the level of information
   exchanged) depend on the chosen control model.  This document
   presents a taxonomy with the possible control models.

Gonzalez de Dios, et al. Expires August 18, 2014                [Page 5]
Internet-Draft Control Models for customer-provider netwks February 2014

2.2.  Reachability

   In graph theory, reachability refers to the ability to get from one
   vertex to another within a graph.  Thus, a vertex can reach another
   vertex if there exists a sequence of adjacent vertices which starts
   with the source vertex and ends with the destination vertex.

   The document [draft-farrel-interconnected-te-info-exchange-02]
   provides the definition of what is reachability for client-server
   networks.  [EDITOR's note: Text from draft-farrel-interconnected-te-
   info-exchange has been borrowed for this first version.  Duplicated
   text will be deleted at later stages]

   In an IP network, reachability is the ability to deliver a packet to
   a specific address or prefix.  That is, the existence of an IP path
   to that address or prefix.  TE reachability is the ability to reach a
   specific address along a TE path.

   In the context of Traffic Engineered networks with customer and
   provider relationships, we can define several types of reachabiity:
   [draft-farrel-interconnected-te-info-exchange-02]

2.2.1.  Unqualified Reachability

   Two customer domain nodes are said to be reachable if, either there
   exists at least one path through the customer domain that connects
   both nodes, or, in the case that there is no path exclusively through
   the customer domain network, there exists al least one path
   connecting nodes of customer and provider domain by which both
   customer nodes can be connected.

   In the case of basic reachability, it is only known that it is
   possible to connect the nodes, but there is no notion of the details
   of such possible connections, such as, for example, bandwidth
   available or performance metrics.  Also, the exact path to connect
   both nodes is not known to the client network.  Note that, even if
   two nodes are reachable, there may not be enough resources for a
   desired TE connection with specific TE constraints.

2.2.2.  Qualified Reachability

   In this case, on top of the basic reachability, it is known some TE
   attributes of the possible connection (or connections).  Examples of
   such attributes are: TE metrics, hop count, available bandwidth,
   delay, SRLG list.  Note that this information is specific per
   connection.  Thus, if there are several posible TE paths, there are a
   set of attributes.

Gonzalez de Dios, et al. Expires August 18, 2014                [Page 6]
Internet-Draft Control Models for customer-provider netwks February 2014

2.2.3.  Qualified Reachability with associated potential TE path

   In this particular case, on top of the qualified reachability, there
   exists an associated potential TE path that satisfies the TE
   connection between two client nodes.  Thus, in this case, the
   customer Network has the information that there exists a TE path that
   can be set up at any time.

3.  Control Models

   The control of the networks formed by interconnected domains with a
   customer-provider relations between them can be done following
   different models.  Each control model defines, on the one hand, the
   level of information that the domain acting as customer recieves by
   control plane means about the services given by the domain acting as
   provider.  This information, for example, can vary from a complete
   lack of information, so the customer domain only knows that it could
   be possible to reach another point of its domain via the provider
   network, to a detailed view on the possibilities offered by the
   provider network.  The level of detail of this information will
   determine which information is exchanged between both networks.  On
   the other hand, the control model will determine what can be
   requested from the customer domain to the provider domain.  As an
   example, the most basic use is spcecifying just the end-points to
   connect.  Other cases may include the possibility to request a
   service specifying a set of constraints, like bandwidth, diversity,
   an optimization criteria, etc.

   Which control model to choose depends on several factors.  For the
   network operators, the main concern will be related to the level of
   trustness and relationship between customer and provider domains.
   Also, one key factor to take into account is the protocol
   interoperability.  Note that, equipment in the interconnected domains
   may be from different technologies (but not necessarily) and are
   likely to use different implementations.  The higher the level of
   functionality included in the control plane, the higher the protocol
   interoperability requirements, as it will force all implementations
   to support many functionality.  Finally, scalability, that is, the
   ability of the control plane to provide the same functionality
   regarding the number of equipment, needs to be taken into account:
   the amount of information in each option will have different limits
   in terms on number of interconnected nodes.

3.1.  Signaling Only

   This first model considers that the sole functionality allowed in the
   control plane is signaling, that is the ability to request services
   from customer to provider domain.

Gonzalez de Dios, et al. Expires August 18, 2014                [Page 7]
Internet-Draft Control Models for customer-provider netwks February 2014

   In this model, the control plane does not provide a priori hints to
   the customer domain about the state of the provider domain (e.g.,
   resource availability).  This model does not preclude that, by other
   means like the management plane, the customer domain know what is
   possible or not.  Such management actions are out of the scope of the
   control plane.  Thus, it perfectly feasible that the reachability
   information is provided either statically or by some management
   platform.

   The most basic case relies on sending a loose ERO from the customer,
   specifying the edges of the connection.

   In a trusted interconnection mode, the signalling allows the customer
   domain to provide a full ERO, given to client network by external
   tools.

3.1.1.  Signaling with Requirements

   The control plane may allow to express complex requests to the
   provider domain.  That is, through the signaling protocol, it is
   allowed to not only request a connection between two points of the
   customer domain, but also to include some constraints: e.g., minimum
   bandwidth, maximum delay, optimization criteria, or request diversity
   from another service.  The policy at the edged of the provider
   network will determine which constraints are accepted.  Note the many
   of the requirements that can be expressed in the request are similar
   to what would be asked to a path computation function.

3.1.2.  Signaling with Collection

   Even though the only protocol enabled is signaling, it may be
   beneficial for the customer domain to be able to know some updated
   information of the services that it has requested to the provider.
   Thus, this case considers the possibility that, through the signaling
   protocol, the customer domain can receive some information.  What
   information it is allowed to collect will be determined by the policy
   of the provider domain.

3.2.  Signaling and Reachability Model

   This second model considers that, in addition to signaling, the
   customer domain receives some reachability information through a
   control plane mechanism.

Gonzalez de Dios, et al. Expires August 18, 2014                [Page 8]
Internet-Draft Control Models for customer-provider netwks February 2014

3.2.1.  Signalling + Basic Reachability

   In this particular case, through control plane mechanisms, the
   customer domain knows whether it is possible to reach a remote end
   point.  The customer domain should also remain aware of this
   information if there are failures in the provider domain or if the
   associated capacity has been filled.

3.2.2.  Signalling + Qualified Reachability

   The control plane will provide information not only about the
   possibility to reach a remote end point, but also some TE information
   of possible connections.  For example, the customer domain will know
   that it is possible to reach another point with some bandwidth or
   delay.  Note that, in this case, such information is sent by control
   plane mechanisms (not statically configured by managament plane).

3.2.3.  Signalling + Qualified Reachability + Potential Services

   In addition to the TE information of the possible connections between
   two points, the control plane will also provide to the customer
   domain information about potential provider's services which could
   satisfy given requirements.  By control plane procedures, the
   customer domain can request, with respect to its needs, a service
   using such potential service and make high level path selection
   within the provider domain.

3.3.  Other Models

3.3.1.  Multi-Layer Networks / Multi-Region Networks

   MLN/MRN extensions to control protocols have been defined.  They are
   well scoped for client and server data plane domains without
   administrative boundary between them.  This allows MLN nodes to
   participate in common control protocol instances.  There is a full
   set of mechanisms to operate such networks [Editor's note: add refs
   to MLN/MRN)].  Typical use cases are switches combining both low- and
   high-order Sonet/SDH, or both ODUk and wavelengths.

   However, MLN/MRN assumes no policy boundary between customer and
   provider domains.  Thus, the level of information exchanged is not
   restricted, and full interoperability of both the signaling and
   routing protocols is required.

Gonzalez de Dios, et al. Expires August 18, 2014                [Page 9]
Internet-Draft Control Models for customer-provider netwks February 2014

3.3.2.  Management Model

   In this particular case, the role of the control plane is limited to
   operate independently in each of the domains.  [Editor's note: Common
   Control... WG => do we leave it?]

4.  Security Considerations

   TBD

5.  Contributing Authors

6.  Acknowledgments

   The authors would like to thank Lou Berger for pointing out the
   direction of the document and Dieter Beler for his review.  The
   authors would like to specially thank all the authors of draft-
   farrel-interconnected-te-info-exchange-02

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.

   [RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in
              BGP-4", RFC 3107, May 2001.

   [RFC3717]  Rajagopalan, B., Luciani, J., and D. Awduche, "IP over
              Optical Networks: A Framework", RFC 3717, March 2004.

   [RFC4208]  Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
              "Generalized Multiprotocol Label Switching (GMPLS) User-
              Network Interface (UNI): Resource ReserVation Protocol-
              Traffic Engineering (RSVP-TE) Support for the Overlay
              Model", RFC 4208, October 2005.

7.2.  Informative References

   [draft-farrel-interconnected-te-info-exchange-02]
              "Farrel, A., Drake, J., Bitar, N., Swallow, G.,
              Ceccarelli, D. draft-farrel-interconnected-te-info-
              exchange-02 Problem Statement and Architecture for
              Information Exchange Between Interconnected Traffic
              Engineered Networks", 2014.

Gonzalez de Dios, et al. Expires August 18, 2014               [Page 10]
Internet-Draft Control Models for customer-provider netwks February 2014

Authors' Addresses

   Oscar Gonzalez de Dios (editor)
   Telefonica GCTO
   Don Ramon de la Cruz 82-84
   Madrid  28045
   Spain

   Phone: +34913128832
   Email: ogondio@tid.es

   Julien Meuric (editor)
   Orange
   2 avenue Pierre Marzin
   Lannion  22300
   France

   Email: julien.meuric@orange.com

   Daniele Ceccarelli
   Ericsson
   Via Calda 5
   Genova
   Italy

   Phone: +39 010 600 2512
   Email: daniele.ceccarelli@ericsson.com

Gonzalez de Dios, et al. Expires August 18, 2014               [Page 11]