One document matched: draft-dios-ccamp-control-models-customer-provider-00.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<!--
vim: set softtabstop=2 shiftwidth=2 expandtab
RCAS: uploaded version
version=201302121230
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4208 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4208.xml">
<!ENTITY RFC3107 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3107.xml">
<!ENTITY RFC3717 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3717.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="info" docName="draft-dios-ccamp-control-models-customer-provider-00" ipr="trust200902" >
<front>
<title abbrev="Control Models for customer-provider netwks">Terminology and Models for Control of Traffic Engineered Networks with Provider-Customer Relationship</title>
<author fullname="Oscar Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios">
<organization>Telefonica GCTO</organization>
<address>
<postal>
<street>Don Ramon de la Cruz 82-84</street>
<city>Madrid</city>
<region></region>
<code>28045</code>
<country>Spain</country>
</postal>
<phone>+34913128832</phone>
<email>ogondio@tid.es</email>
</address>
</author>
<author fullname="Julien Meuric" initials="J." role="editor" surname="Meuric">
<organization>Orange</organization>
<address>
<postal>
<street>2 avenue Pierre Marzin</street>
<city>Lannion</city>
<region></region>
<code>22300</code>
<country>France</country>
</postal>
<phone></phone>
<email>julien.meuric@orange.com</email>
</address>
</author>
<author fullname="Daniele Ceccarelli" initials="D." surname="Ceccarelli">
<organization>Ericsson</organization>
<address>
<postal>
<street>Via Calda 5</street>
<city>Genova</city>
<region></region>
<code></code>
<country>Italy</country>
</postal>
<phone>+39 010 600 2512</phone>
<email>daniele.ceccarelli@ericsson.com</email>
</address>
</author>
<date year="2014" />
<area>Routing</area>
<workgroup>Network Working Group</workgroup>
<keyword>UNI</keyword>
<abstract>
<t>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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<!-- ===================================================================
Introduction
=================================================================== -->
<section title="Introduction">
<t>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.</t>
<t>The interface between the customer and the provider domain is typically called "User-to-Network Interface" (UNI), and regarded as signaling-only <xref target="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.</t>
<t>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. </t>
<section title="Examples of Customer-Provider TE Network Domain Scenarios">
<t>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.</t>
<t>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 optical network that provides the switching for the wavelenghts as well as restoration capabilities of the optical channels.</t>
<t>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.</t>
<t>Summing up, there number of applicable scenarios is wide.</t>
</section>
</section>
<!-- ===================================================================
Terminology
=================================================================== -->
<section title="Terminology">
<section title="Customer Domain - Provider Domain Interface">
<t> 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.</t>
<section title="UNI in IP over Optical Networks">
<t><xref target="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."</t>
<t>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.</t>
</section>
<section title="ITU-T Definition of UNI">
<t>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."</t>
<t>The terms "requester/provider" are used to refer to the relationship.</t>
</section>
<section title="OIF Definition of UNI">
<t>UNI: "The service control interface between a client device and the transport network."</t>
<t>UNI-C: "The logical entity that terminates UNI signalling on the client device side."</t>
<t>UNI-N: "The logical entity that terminates UNI signalling on the transport network side."</t>
<t>The terms "client/transport" and "client/network" are used to refer to the relationship.</t>
</section>
<section title="Proposed Vocabulary">
<t>As listed above, the existing terminology is far from unique. To avoid overloaded concepts, this document proposes to use the "customer/provider" terms.</t>
<t>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.</t>
<section title="Customer network">
<t>A Customer network is defined as a network domain able to request a connectivity service to a provider network domain across an administrative boundary.</t>
</section>
<section title="Provider network">
<t>A Provider network is defined as a network domain able to deliver connectivity services to a customer network domain across an administrative boundary.</t>
</section>
<section title="Customer-Provider Control Plane Interface">
<t>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.</t>
</section>
</section>
</section>
<section title="Reachability">
<t>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.</t>
<t>The document <xref target="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] </t>
<t>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.</t>
<t>In the context of Traffic Engineered networks with customer and provider relationships, we can define several types of reachabiity: <xref target="draft-farrel-interconnected-te-info-exchange-02"/> </t>
<section title="Unqualified Reachability">
<t>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.</t>
<t>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.</t>
</section>
<section title="Qualified Reachability">
<t>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.</t>
</section>
<section title="Qualified Reachability with associated potential TE path">
<t>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.</t>
</section>
</section>
</section>
<section title="Control Models">
<t>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.</t>
<t>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.</t>
<section title="Signaling Only">
<t>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.</t>
<t>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.</t>
<t>The most basic case relies on sending a loose ERO from the customer, specifying the edges of the connection.</t>
<t>In a trusted interconnection mode, the signalling allows the customer domain to provide a full ERO, given to client network by external tools.</t>
<section title="Signaling with Requirements">
<t>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.</t>
</section>
<section title="Signaling with Collection">
<t>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.</t>
</section>
</section>
<section title="Signaling and Reachability Model">
<t> This second model considers that, in addition to signaling, the customer domain receives some reachability information through a control plane mechanism.</t>
<section title="Signalling + Basic Reachability">
<t>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.</t>
</section>
<section title="Signalling + Qualified Reachability">
<t> 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).
</t>
</section>
<section title="Signalling + Qualified Reachability + Potential Services">
<t>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.</t>
</section>
</section>
<section title="Other Models">
<section title="Multi-Layer Networks / Multi-Region Networks">
<t>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.</t>
<t>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.</t>
</section>
<section title="Management Model">
<t>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?]</t>
</section >
</section>
</section>
<!-- ===================================================================
SECURITY CONSIDERATIONS
=================================================================== -->
<section title="Security Considerations">
<t>TBD</t>
</section>
<!-- ===================================================================
CONTRIBUTING AUTHORS
=================================================================== -->
<section title="Contributing Authors">
<t>
</t>
</section>
<!-- ===================================================================
ACKNOWLEDGEMENTS
=================================================================== -->
<section title="Acknowledgments">
<t>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</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC4208;
&RFC3107;
&RFC3717;
&RFC2119;
</references>
<references title="Informative References">
<reference anchor="draft-farrel-interconnected-te-info-exchange-02">
<front>
<title>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</title>
<author></author>
<date year="2014"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:06:58 |