< draft-lachosrothenberg-alto-brokermdo-01.txt   draft-lachosrothenberg-alto-brokermdo-02.txt >
ALTO WG D. Lachos ALTO WG D. Lachos
Internet-Draft C. Rothenberg Internet-Draft C. Rothenberg
Intended status: Informational Unicamp Intended status: Informational Unicamp
Expires: January 3, 2019 July 2, 2018 Expires: September 12, 2019 March 11, 2019
ALTO-based Broker-assisted Multi-domain Orchestration ALTO-based Broker-assisted Multi-domain Orchestration
draft-lachosrothenberg-alto-brokermdo-01 draft-lachosrothenberg-alto-brokermdo-02
Abstract Abstract
Evolving networking scenarios (e.g., 5G) demand new multiple Evolving networking scenarios (e.g., 5G) demand new multiple
administrative domain (aka multi-domain) orchestration models. This administrative domain (aka multi-domain) orchestration models. This
document proposes the use of Application-Layer Traffic Optimization document proposes a new broker-plane approach working on top of per-
(ALTO) services to offer topology and resources addressing network domain management and orchestration functions to coordinate the
service discovery and provisioning by multi-domain orchestrators. delivery of a multi-operator End-to-End Network Service (E2ENS).
The ALTO services with the proposed protocol extension offer This proposed design resorts to the Application-Layer Traffic
aggregated views on various types of resources contributing to a more Optimization (ALTO) protocol to offer topology and resource
simple and scalable solution for resource and service discovery in information from different administrative domains. The ALTO services
multi-domain, multi-technology environments. with the proposed protocol extension offer aggregated views on
various types of resources contributing to a more simple and scalable
Requirements Language solution.
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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Changes Since Version -00 . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Problem Statement and Challenges . . . . . . . . . . . . . . 5
5. Problem Statement and Challenges . . . . . . . . . . . . . . 5 5. Proposed Approach . . . . . . . . . . . . . . . . . . . . . . 6
6. Proposed Approach . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Inter-domain Resource (IdR) Component . . . . . . . . . . 7
6.1. Inter-domain Resource (IdR) Component . . . . . . . . . . 7 5.2. Inter-domain Topology (IdT) Component . . . . . . . . . . 7
6.2. Inter-domain Topology (IdT) Component . . . . . . . . . . 8 5.3. ALTO Server Functionalities . . . . . . . . . . . . . . . 7
6.3. ALTO Server Functionalities . . . . . . . . . . . . . . . 8 5.4. Filtered Cost Map Extension . . . . . . . . . . . . . . . 8
6.4. Filtered Cost Map Extension . . . . . . . . . . . . . . . 8 5.4.1. Accept Input Parameters . . . . . . . . . . . . . . . 8
6.4.1. Accept Input Parameters . . . . . . . . . . . . . . . 9 5.4.2. Response . . . . . . . . . . . . . . . . . . . . . . 9
6.4.2. Response . . . . . . . . . . . . . . . . . . . . . . 9 5.5. Examples of Message Exchange . . . . . . . . . . . . . . 9
6.5. Examples of Message Exchange . . . . . . . . . . . . . . 10 5.5.1. Property Map Service . . . . . . . . . . . . . . . . 9
6.5.1. Property Map Service . . . . . . . . . . . . . . . . 10 5.5.2. Filtered Cost Map Service . . . . . . . . . . . . . . 10
6.5.2. Filtered Cost Map Service . . . . . . . . . . . . . . 11 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 16 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Proof of Concept Use Case Implementation . . . . . . 18 Appendix A. Proof of Concept Use Case Implementation . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Envisioned 5G network architectures and related service models Envisioned 5G network architectures and related service models
consider broader cooperation between stakeholders in order to provide consider broader cooperation between stakeholders in order to provide
flexible multi-operator multi-domain services. These multi-provider flexible multi-operator multi-domain services. These multi-provider
orchestration operations will require the information exchange across orchestration operations will require the information exchange across
Multi-domain Orchestrators (MdOs). The key information to be Multi-domain Orchestrators (MdOs). The key information to be
exchanged between MdOs includes the abstract network topology, exchanged between MdOs includes the abstract network topology,
resource availability (e.g., CPUs, Memory, and Storage) and resource availability (e.g., CPUs, Memory, and Storage) and
capability (e.g., supported network functions). capability (e.g., supported network functions).
This document presents a federation networking paradigm where a This document presents a federation networking paradigm where a
broker-plane works on top of the management and orchestration plane broker-plane works on top of the management and orchestration plane
to assist and coordinate the creation of an End-to-End Network to assist and coordinate the creation of an End-to-End Network
Service (E2ENS) spanning over multi-operator multi-domain networks. Service (E2ENS) spanning over multi-operator multi-domain networks.
Our design resorts to the Application-Layer Traffic Optimization Our design resorts to the Application-Layer Traffic Optimization
(ALTO) protocol [RFC7285] to address the lack of abstractions to (ALTO) protocol [RFC7285] to address the lack of abstractions to
discover and adequately represent in confidentiality-preserving discover and adequately represent in confidentiality-preserving
fashion the resource and topology information from different fashion the resource and topology information from different
administrative domains. Moreover, this draft introduces an extension administrative domains. Moreover, this draft introduces an extension
to the ALTO base protocol for inter-domain connectivity information to the ALTO base protocol for inter-domain connectivity information
discovery. discovery.
2. Changes Since Version -00 2. Terminology
o Many minor style and grammar edits.
o Updated Problem Statement and Challenges section.
o Removed Property Map Extension section. The current Property Map
draft [DRAFT-PM] already supports property values encoded as
JSONArray.
o Added section on benefits and open questions in our proposed
architecture.
3. Terminology
We use the following definitions, as established in [ETSI-NFV-DEF]: We use the following definitions, as established in [ETSI-NFV-DEF]:
Administrative Domain: Collection of systems and networks operated Administrative Domain: Collection of systems and networks operated
by a single organization or administrative authority. by a single organization or administrative authority.
Network Function (NF): Functional block within a network Network Function (NF): Functional block within a network
infrastructure that has well-defined external interfaces and well- infrastructure that has well-defined external interfaces and well-
defined functional behaviour. defined functional behaviour.
skipping to change at page 4, line 40 skipping to change at page 4, line 15
Resource Topology (RT): Functional module that is responsible for Resource Topology (RT): Functional module that is responsible for
keeping an updated global view of the underlying infrastructure keeping an updated global view of the underlying infrastructure
topology exposed by DOs. topology exposed by DOs.
Service Graph (SG): A high-level data model for defining flexible Service Graph (SG): A high-level data model for defining flexible
network services (including traffic steering primitives). network services (including traffic steering primitives).
Service Access Point (SAP): A named/tagged port supporting stitching Service Access Point (SAP): A named/tagged port supporting stitching
(service to service, domain to domain, etc.) (service to service, domain to domain, etc.)
4. Scope 3. Scope
Existing proposals for the network service orchestration are
intrinsically conceived for single administrative domain scenarios.
For example, in the standard service orchestration model described in
ETSI NFV MANO framework [ETSI-NFV-MANO], one orchestrator is supposed
to work within one administrative domain. The analysis of
orchestration and management of network Services over multiple
administrative domains have begun to be addressed by ETSI
in [ETSI-NFV-MANO-MDO].
Envisioned 5G scenarios are expected to work not only with Envisioned 5G scenarios are expected to work not only with
heterogeneous technologies but also across different network heterogeneous technologies but also across different network
operators. Many ongoing initiatives and projects related are operators. Many ongoing standardization activities and research
addressing the multi-provider multi-domain orchestration challenges projects are addressing the multi-provider multi-domain orchestration
under different approaches. For example, [H2020.5GEX] seeks to challenges under different approaches.
integrate multiple administrations and technologies through the
collaboration between operations. Other studies are envisioned to For example, within the IETF, [RFC8459] proposes a hierarchical
use a centralized approach, where each domain advertises its Service Function Chaining (SFC) for multiple domains under the same
administrative entity, and the document "Hybrid Hierarchical Multi-
Domain SFC [DRAFT-HHSFC] describes SFC crossing different domains
owned by various organizations or by a single organization with
administration partitions. In the NFVRG, the draft "Multi-domain
Network Virtualization" [DRAFT-MD-VIRT] envisions a complete E2E
logical network as stitching services offered by multiple domains
from multiple providers. Another initiative is the ETSI Industry
Specification Group for Network Functions Virtualization (ETSI NFV
ISG), the document [ETSI-NFV-IFA028] reports different NFV MANO
architectural approaches with use cases related to network services
provided using multiple administrative domains.
In case of research projects, [H2020.5GEX] [H2020-5G-TRANSFORMER]
seek to integrate multiple administrations and technologies through
the collaboration between operations. Other studies are envisioned
to use a centralized approach, where each domain advertises its
capabilities to a federation layer which will act as a capabilities to a federation layer which will act as a
broker [VITAL][T-NOVA]. The proposed architecture in [ICAF] allows broker [VITAL][T-NOVA]. The proposed architecture in [ICAF] allows
the creation of cloud services from different administrative domains, the creation of cloud services from different administrative domains,
however, it is not related to the provisioning of NFV-based cross- however, it is not related to the provisioning of NFV-based cross-
domain network services. domain network services.
All such proposals described above envision the potential All such proposals described above envision the potential
introduction of new business model approaches, including federation introduction of new business model approaches, including federation
models [PPP-5:2013] among administrative domains. In this context, models [PPP-5:2013] among administrative domains. In this context,
this document considers each network operator involved in the this document considers each network operator involved in the
community advertises its abstracted capabilities (e.g., software/ community advertises its abstracted capabilities (e.g., software/
hardware resources, physical/virtual network functions, etc.) to a hardware resources, physical/virtual network functions, etc.) to a
broker (i.e., 3rd party). This latter, in its turn, provides or broker (i.e., 3rd party). This broker, in its turn, provides or
assists coordinate E2E network services spanning multi-domain assists coordinate E2E network services spanning multi-domain
networks. networks.
5. Problem Statement and Challenges 4. Problem Statement and Challenges
The provision of a complete E2E network service requires chaining The provision of a complete E2E network service requires chaining
services provided by multiple network operator with multiple services provided by multiple network operators with multiple
technologies. In this multi-domain environment, the orchestration technologies. In this multi-domain environment, the orchestration
process will require an advertise mechanism through which single process will require an advertisement mechanism through which
domains can describe their capabilities, resources, and VNFs in an individual domains can describe their capabilities, resources, and
interoperable manner. Moreover, a discovery mechanism is also VNFs in an interoperable manner. Moreover, a discovery mechanism is
necessary so that source domains can obtain candidate domains (with also necessary so that source domains can obtain candidate domains
the corresponding connectivity information) which can provide a part (with the corresponding connectivity information) which can provide a
of the service and/or slide in an E2ENS requirement. part of the service and/or slice in an E2ENS requirement.
In order to the advertising and discovery process works in a proper In order that the advertising and discovery process works in a proper
way, a number of challenges can be identified: way, a number of challenges can be identified:
Lack of Abstractions: Multiple vendors with heterogeneous Lack of Abstractions: Multiple vendors with heterogeneous
technologies need an information model to adequately represent technologies need an information model to adequately represent
in confidentiality-preserving fashion the resource and topology in confidentiality-preserving fashion the resource and topology
information. information.
Scalability: Involves the distribution of topology and resource Scalability: Involves the distribution of topology and resource
information in a peer-to-peer fashion (MdO-to-MdO). Multi- information in a peer-to-peer fashion (MdO-to-MdO). Multi-
operator multi-domain environments where the information operator multi-domain environments where the information
skipping to change at page 6, line 18 skipping to change at page 6, line 5
resources. Such procedures consist in deploying and configuring resources. Such procedures consist in deploying and configuring
physical peering points for these domains. physical peering points for these domains.
Complexity: Refers to the discovery mechanism to pre-select Complexity: Refers to the discovery mechanism to pre-select
candidate domains, accounting for resources and capabilities, candidate domains, accounting for resources and capabilities,
necessary for an E2E network service deployment. An intrinsic necessary for an E2E network service deployment. An intrinsic
complexity exists in the process of assembling, logically complexity exists in the process of assembling, logically
organizing, and enabling abstraction views of different organizing, and enabling abstraction views of different
resources and capabilities in multi-domain scenarios. resources and capabilities in multi-domain scenarios.
6. Proposed Approach 5. Proposed Approach
The primary design goal for ALTO-based Broker-assisted Multi-domain The primary design goal for ALTO-based Broker-assisted Multi-domain
Orchestration is to discover resource and topology information from Orchestration is to discover resource and topology information from
different administrative domains involved in the federation, while different administrative domains involved in the federation, while
also safeguarding the privacy and autonomy of every domain. also safeguarding the privacy and autonomy of every domain.
In the architectural proposal shown in Figure 1, a broker component In the architectural proposal shown in Figure 1, a broker component
is conceived to be working as coordinator of a set of MdOs, whose key is conceived to be working as coordinator of a set of MdOs. In
components are: the Inter-domain Resource (IdR), the Inter-domain particular, the broker-assisted design consists of the following key
Topology (IdT) and the ALTO Server. components: (i) Inter-domain Resource (IdR), (ii) Inter-domain
Topology (IdT), and (iii) ALTO Server.
BROKER COMPONENT BROKER COMPONENT
+--------------------------------------------+ +--------------------------------------------+
| | | |
| +-----------------+ | | +-----------------+ |
| | | | | | | |
XXXXXXXXXXXXXXXXXXX ALTO SERVER(s) | | XXXXXXXXXXXXXXXXXXX ALTO SERVER(s) | |
X | | + | X | | + |
X | +----------------+\ | X | +----------------+\ |
X | / \ | X | / \ |
X | / \ | X | / \ |
X | +------+/+-------+ +---------------+ | X | +------+/+-------+ +---------------+ |
X | | Inter-domain | | Inter-domain | | X | | Inter-domain | | Inter-domain | |
X | | Topology (IdT) | | Resource (IdR)| | X | | Topology (IdT) | | Resource (IdR)| |
X | +-^------^-------+ +---^-------^---+ | X | +-^------^-------+ +---^-------^---+ |
X | | | | | | X | . . * * |
X +--------------------------------------------+ X +----.------.-----------------*-------*------+
X | | | | X . . * *
X | | | | X . . * *
+--X--------+---+--------------------+ | +--X--------.---+********************* *
| | | | | | . *
| | +------------+------------+---+ | | .............+------------*---+
| MdO1 | | | | MdO1 | | |
| +<------------->+ +---+ | +<------------->+ +---+
+---------------+ | MdO2 | | +---------------+ | MdO2 | |
| | | | | |
+-+--------------+ | Legend: +-+--------------+ |
| | XXX ALTO Protocol | |
Legend: | MdO(n) | ... BGP/BGP-LS/REST | MdO(n) |
XXX ALTO Protocol +------------------+ *** UNIFY/TOSCA/ETSI-NFV +------------------+
Figure 1: Broker-assisted Multi-operator Network Architecture Figure 1: Broker-assisted Multi-operator Network Architecture
6.1. Inter-domain Resource (IdR) Component 5.1. Inter-domain Resource (IdR) Component
It creates a hierarchical database that contains inter-domain It creates a hierarchical database that contains inter-domain
resource information such as resource availability (i.e., CPU, resource information such as resource availability (i.e., CPU,
memory, and storage), Virtual Network Functions (VNFs) and Physical memory, and storage), Virtual Network Functions (VNFs) and Physical
Network Functions (PNFs) supported and Service Access Points (SAPs) Network Functions (PNFs) supported and Service Access Points (SAPs)
to access those resources. UNIFY [UNIFY.NFFG], TOSCA [TOSCA], ETSI- to access those resources. UNIFY [UNIFY.NFFG], TOSCA [TOSCA], ETSI-
NFV [ETSI-NFV-MANO], among other data models can be used to create NFV [ETSI-NFV-MANO], among other data models can be used to create
the interface between IdR and MdOs. the interface between IdR and MdOs.
6.2. Inter-domain Topology (IdT) Component 5.2. Inter-domain Topology (IdT) Component
A hierarchical TED (Traffic Engineering Database) that contains A hierarchical TED (Traffic Engineering Database) that contains
inter-domain network topology information including additional key inter-domain network topology information including additional key
parameters (e.g., throughput and latency of links). This information parameters (e.g., throughput and latency of links). This information
can be retrieved from each MdO through BGP-LS or REST interfaces. can be retrieved from each MdO through BGP-LS or REST interfaces.
6.3. ALTO Server Functionalities 5.3. ALTO Server Functionalities
The ALTO server component is the core of the broker layer. Multiple The ALTO server component is the core of the broker layer. Multiple
logically centralized ALTO servers use the information collected from logically centralized ALTO servers use the information collected from
IdR and IdT modules to create and provide abstract maps with a IdR and IdT components to create and provide abstract maps with a
simplified view, yet enough information about MdOs involved in the simplified view, yet enough information about MdOs involved in the
federation. This information includes domain-level topology, storage federation. This information includes domain-level topology,
resources, computation resources, networking resources and PNF/VNF resource availability (i.e., CPU, memory, and storage), PNF/VNF
capabilities. capabilities, and SAPs.
As an ALTO client, each MdO sends ALTO service queries to the ALTO As an ALTO client, each MdO sends ALTO service queries to the ALTO
server. This server provides aggregated inter-domain information server. This server provides aggregated inter-domain information
exposed as set ALTO base services defined in [RFC7285], e.g., Network exposed as set ALTO base services defined in [RFC7285], e.g., Network
Map, Cost Map and ALTO extension services, e.g., Property Map, Cost Map and ALTO extension services, e.g., Property
Map [DRAFT-PM], Multi-Cost Map [RFC8189], Path Vector [DRAFT-PV]. Map [DRAFT-PM], Multi-Cost Map [RFC8189], Path Vector [DRAFT-PV].
For example, when a source MdO receives a customer service request, For example, when a source MdO receives a customer service request,
it checks whether or not it can deliver the full service. If it is it checks whether or not it can deliver the full service. If it is
unable to do so, the MdO consumes from the ALTO Server the Property unable to do so, the MdO consumes from the ALTO Server the Property
Map service to have a clear global view of the resource information Map service to have a clear global view of the resource information
offered by other MdOs. This information allows discovering which offered by other MdOs. This information allows discovering which
candidate MdOs may be contacted to deliver the remaining requirements candidate MdOs may be contacted to deliver the remaining requirements
of a requested end-to-end service deployment. The connectivity of a requested end-to-end service deployment. The connectivity
information among discovered MdOs can be retrieved by a Cost Map information among discovered MdOs can be retrieved by a Cost Map
service, responding, for instance, a path vector with the AS-level service, responding, for instance, a path vector with the AS-level
topology distance between the source MdO and candidate MdOs. topology distance between the source MdO and candidate MdOs.
6.4. Filtered Cost Map Extension 5.4. Filtered Cost Map Extension
The ALTO server MUST provide connectivity information for every SG The ALTO server MUST provide connectivity information for every SG
link in the SG path for an E2E requirement. This information is the link in the SG path for an E2E requirement. This information is the
AS-level topology distance in the form of path vector, and it AS-level topology distance in the form of path vector, and it
includes all possible ways for each (source node, destination node) includes all possible ways for each (source node, destination node)
pair in the SG link. pair in the SG link.
In this section, we introduce a non-normative overview of the In this section, we introduce a non-normative overview of the
Filtered Cost Map defined in Section 6.1 of [DRAFT-PV] [1]. Filtered Cost Map defined in Section 6.1 of [DRAFT-PV] [1].
The specifications for the "Media Types", "HTTP method", The specifications for the "Media Types", "HTTP method",
"Capabilities" and "Uses" (described in Section 6.1 of [DRAFT-PV] "Capabilities" and "Uses" (described in Section 6.1 of [DRAFT-PV]
[2]) are unchanged. [2]) are unchanged.
6.4.1. Accept Input Parameters 5.4.1. Accept Input Parameters
The ReqFilteredCostMap object in Section 6.1.2 of [DRAFT-PV] [3] is The ReqFilteredCostMap object in Section 6.1.2 of [DRAFT-PV] [3] is
extended as follow: extended as follow:
object { object {
[NFFG sg;] NFFG sg;
} ReqFilteredCostMap; } ReqFilteredCostMap;
object { object {
JSONString nfs<1..*>; JSONString nfs<1..*>;
JSONString saps<1..*>; JSONString saps<1..*>;
NextHops sg_links<1..*>; NextHops sg_links<1..*>;
REQs reqs<1..*>; REQs reqs<1..*>;
} NFFG; } NFFG;
object { object {
skipping to change at page 9, line 44 skipping to change at page 9, line 15
sg: If present, the ALTO Server MUST allow the request input to sg: If present, the ALTO Server MUST allow the request input to
include an SG with a formatted body as an NFFG object. An NFFG include an SG with a formatted body as an NFFG object. An NFFG
object contains NFs, SAPs, SG links representing logical object contains NFs, SAPs, SG links representing logical
connections between NFs, SAPs or both and E2E requirements as a connections between NFs, SAPs or both and E2E requirements as a
list of ids of SG links. list of ids of SG links.
It is worth noting that further versions of this draft will define a It is worth noting that further versions of this draft will define a
more elaborated NFFG object to support extended parameters such as more elaborated NFFG object to support extended parameters such as
monitoring parameters, resource requirements, etc. monitoring parameters, resource requirements, etc.
6.4.2. Response 5.4.2. Response
If the ALTO client includes the path vector cost mode in the "cost- If the ALTO client includes the path vector cost mode in the "cost-
type" or "multi-cost-types" field of the input parameter, the type" or "multi-cost-types" field of the input parameter, the
response for each SG link in each E2E requirement MUST be encoded as response for each SG link in each E2E requirement MUST be encoded as
a JSONArray of JSONArrays of JSONStrings. Anyone of the sub-arrays a JSONArray of JSONArrays of JSONStrings. Anyone of the sub-arrays
indicates a potential candidate path calculated as the per-domain indicates a potential candidate path calculated as the per-domain
topological distance corresponding to the amount of traversing topological distance corresponding to the amount of traversing
domains. domains.
Moreover, as defined in Section 6.3.6 of [DRAFT-PV] [4], If an ALTO Moreover, as defined in Section 6.3.6 of [DRAFT-PV] [4], If an ALTO
client sends a request of the media type "application/alto- client sends a request of the media type "application/alto-
costmapfilter+json" and accepts "multipart/related", the ALTO server costmapfilter+json" and accepts "multipart/related", the ALTO server
MUST provide path vector information along with the associated MUST provide path vector information along with the associated
Property Map information (e.g., entry points of the corresponding Property Map information (e.g., entry points of the corresponding
foreign domains), in the same body of the response. foreign domains), in the same body of the response.
Section 6.5.2 gives an example of the Filtered Cost Map query and the Section 5.5.2 gives an example of the Filtered Cost Map query and the
corresponding responses. corresponding responses.
6.5. Examples of Message Exchange 5.5. Examples of Message Exchange
This section list a couple of examples of the Property Map and This section list a couple of examples of the Property Map and
Filtered Cost Map queries and the corresponding responses. These Filtered Cost Map queries and the corresponding responses. These
responses are based on the information in Table 1 and Table 2 of a responses are based on the information in Table 1 and Table 2 of a
use case implementation described in Appendix A. use case implementation described in Appendix A.
6.5.1. Property Map Service 5.5.1. Property Map Service
In this example, the ALTO client wants to retrieve the entire In this example, the ALTO client wants to retrieve the entire
Property Map for PID entities with the "entry-point", "cpu", "mem", Property Map for PID entities with the "entry-point", "cpu", "mem",
"storage", "port" and "nf" properties. "storage", "port" and "nf" properties.
o HTTP Request:
GET /propmap/full/inet-ucmspn HTTP/1.1 GET /propmap/full/inet-ucmspn HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json Accept: application/alto-propmap+json,application/alto-error+json
o HTTP Response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: ### Content-Length: ###
Content-Type: application/alto-propmap+json Content-Type: application/alto-propmap+json
{ {
"property-map": { "property-map": {
"pid:AS1": { "pid:AS1": {
"entry-point": [ "http://172.25.0.10:8888/escape" ], "entry-point": [ "http://172.25.0.10:8888/escape" ],
"cpu": [ "50.0" ], "cpu": [ "50.0" ],
"mem": [ "60.0" ], "mem": [ "60.0" ],
"storage": [ "70.0" ], "storage": [ "70.0" ],
skipping to change at page 11, line 40 skipping to change at page 10, line 42
"entry-point": [ "http://172.27.0.10:8888/escape" ], "entry-point": [ "http://172.27.0.10:8888/escape" ],
"cpu": [ "80.0" ], "cpu": [ "80.0" ],
"mem": [ "90.0" ], "mem": [ "90.0" ],
"storage": [ "100.0" ], "storage": [ "100.0" ],
"port": [ "SAP2" ], "port": [ "SAP2" ],
"nf": [ "NF1", "NF3" ] "nf": [ "NF1", "NF3" ]
} }
} }
} }
6.5.2. Filtered Cost Map Service 5.5.2. Filtered Cost Map Service
The following example uses the Filtered Cost Map service to request The following example uses the Filtered Cost Map service to request
the path vector for a given E2E requirement. The SG request the path vector for a given E2E requirement. The SG request
information in Table 2 is used to describe the service, and it is information in Table 2 is used to describe the service, and it is
composed of three NFs (NF1, NF2, and NF3) and two SAPs (SAP1 and composed of three NFs (NF1, NF2, and NF3) and two SAPs (SAP1 and
SAP2). Links connecting the NFs and SAPs ("sg_links" tag) are also SAP2). Links connecting the NFs and SAPs ("sg_links" tag) are also
included, followed by an E2E requirement ("reqs" tag) with included, followed by an E2E requirement ("reqs" tag) with
information about the order in which NFs are traversed from SAP1 to information about the order in which NFs are traversed from SAP1 to
SAP2. SAP2.
Note that the request accepts "multipart/related" media type. This Note that the request accepts "multipart/related" media type. This
means the ALTO server will include associated property information in means the ALTO server will include associated property information in
the same response. the same response.
o HTTP Request:
POST /costmap/pv HTTP/1.1 POST /costmap/pv HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: multipart/related, application/alto-costmap+json, Accept: multipart/related, application/alto-costmap+json,
application/alto-propmap+json, application/alto-error+json application/alto-propmap+json, application/alto-error+json
Content-Length: [TBD] Content-Length: [TBD]
Content-Type: application/alto-costmapfilter+json Content-Type: application/alto-costmapfilter+json
{ {
"cost-type": { "cost-type": {
"cost-mode": "array", "cost-mode": "array",
skipping to change at page 13, line 10 skipping to change at page 12, line 17
{ {
"id": 1, "id": 1,
"src-node": "SAP1", "src-node": "SAP1",
"dst-node": "SAP2", "dst-node": "SAP2",
"sg-path": [ 1, 2, 3, 4 ] "sg-path": [ 1, 2, 3, 4 ]
} }
] ]
} }
} }
The ALTO server returns connectivity information for the E2E o HTTP Response: The ALTO server returns connectivity information
requirement provided by the ALTO Client request of the above example. for the E2E requirement provided by the ALTO Client request of the
Also, the response includes Property Map information for each element above example.
in the path vector. In this case, it is retrieved a Property Map
with the "entry-point" property, i.e., the URL of the MdO entry point For each SG link in the E2E requirement (SAP1->NF1, NF1->NF2,
for the corresponding network. NF2->NF3, NF3->SAP2), the ALTO server returns sub-arrays
indicating potential candidate paths calculated as the AS-level
topological distance corresponding to the amount of traversing
domains.
Also, the response includes Property Map information for each
element in the path vector. In this case, it is retrieved a
Property Map with the "entry-point" property, i.e., the URL of the
MdO entry point for the corresponding network.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: [TBD] Content-Length: [TBD]
Content-Type: multipart/related; boundary=example Content-Type: multipart/related; boundary=example
--example --example
Content-Type: application/alto-endpointcost+json Content-Type: application/alto-endpointcost+json
{ {
"meta": { "meta": {
skipping to change at page 14, line 29 skipping to change at page 13, line 42
{ {
"property-map": { "property-map": {
"pid:AS1": { "entry-point": "http://172.25.0.10:8888/escape" }, "pid:AS1": { "entry-point": "http://172.25.0.10:8888/escape" },
"pid:AS2": { "entry-point": "http://172.26.0.10:8888/escape" }, "pid:AS2": { "entry-point": "http://172.26.0.10:8888/escape" },
"pid:AS3": { "entry-point": "http://172.27.0.10:8888/escape" } "pid:AS3": { "entry-point": "http://172.27.0.10:8888/escape" }
} }
} }
--example-- --example--
7. Discussion 6. Discussion
In this section we analyze the benefits and open issues in our In this section, we analyze the benefits and open issues in our
broker-assisted architecture. broker-assisted architecture.
7.1. Benefits 6.1. Benefits
The broker-assisted orchestration has numerous benefits, such as: The broker-assisted orchestration has numerous benefits, such as:
o Avoid the distribution of topology and resource information in a o Avoid the distribution of topology and resource information in a
peer-to-peer fashion (MdO-to-MdO) peer-to-peer fashion (MdO-to-MdO)
o The (abstracted) information and offered resources, services are o The (abstracted) information and offered resources, services are
maintained in each local MdO. maintained in each local MdO.
o Allow domains without physical infrastructure (hence without BGP o Allow domains without physical infrastructure (hence without BGP
or BGP-LS) to advertise their capabilities. or BGP-LS) to advertise their capabilities.
o An ALTO-based privacy-preserving information model to provide o An ALTO-based privacy-preserving information model to provide
computing, storage and networking resource info. computing, storage, and networking resource info.
o An MdO discovery method to determine the underlying network graph o An MdO discovery method to determine the underlying network graph
and a potential set of paths before bilateral negotiation between and a potential set of paths before bilateral negotiation between
MdOs is started. MdOs is started.
7.2. Open Issues 6.2. Open Issues
Although the broker-assisted information exchange has several Although the broker-assisted information exchange has several
advantages, it also raises some questions which we try to answer from advantages, it also raises some questions which we try to answer from
our lessons learned. our lessons learned.
o What kind of organization will manage and support the operation of o What kind of organization will manage and support the operation of
a broker entity? If a broker is used to exchange information, a broker entity? If a broker is used to exchange information,
then how does one ensure that the data delivered amongst the then how does one ensure that the data delivered amongst the
operators by this 3rd party has not been changed? operators by this 3rd party has not been changed?
skipping to change at page 15, line 47 skipping to change at page 15, line 16
have a preference to share a different view about its compute and have a preference to share a different view about its compute and
network resources towards different operators. For example, a network resources towards different operators. For example, a
detailed view for the operators that are belonging to same detailed view for the operators that are belonging to same
operator group and a high-level information towards the other operator group and a high-level information towards the other
operators. How is the fine-grained/coarse-grained information operators. How is the fine-grained/coarse-grained information
exchange handled?. exchange handled?.
* It requires much more complex database handling and information * It requires much more complex database handling and information
exchange with the MdOs depending on the policies. exchange with the MdOs depending on the policies.
8. IANA Considerations 7. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
9. Security Considerations 8. Security Considerations
TBD. TBD.
10. Acknowledgments 9. Acknowledgments
This work is supported by the Innovation Center of Ericsson S.A., This work is supported by the Innovation Center of Ericsson S.A.,
Brazil (grant agreement UNI.64). Brazil (grant agreement UNI.64).
Thank you to Robert Szabo (Ericsson Research, Hungary) for the Thank you to Robert Szabo (Ericsson Research, Hungary) for the
contribution and substantial feedback and suggestions in this contribution and substantial feedback and suggestions in this
document. document.
Many thanks to Richard Yang, Dawn Chan, Jensen Zhang, Shawn Lin, Qiao Many thanks to Richard Yang, Dawn Chan, Jensen Zhang, Shawn Lin, Qiao
Xiang, Sabine Randriamasy for their feedback on this draft. Xiang, Sabine Randriamasy for their feedback on this draft.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997, Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://xml.resource.org/public/rfc/html/rfc2119.html>. <http://xml.resource.org/public/rfc/html/rfc2119.html>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy, Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol", "Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014, RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>. <https://www.rfc-editor.org/info/rfc7285>.
[RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost
Application-Layer Traffic Optimization (ALTO)", RFC 8189, Application-Layer Traffic Optimization (ALTO)", RFC 8189,
DOI 10.17487/RFC8189, October 2017, DOI 10.17487/RFC8189, October 2017,
<https://www.rfc-editor.org/info/rfc8189>. <https://www.rfc-editor.org/info/rfc8189>.
11.2. Informative References [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
"Hierarchical Service Function Chaining (hSFC)", RFC 8459,
DOI 10.17487/RFC8459, September 2018,
<https://www.rfc-editor.org/info/rfc8459>.
10.2. Informative References
[DRAFT-HHSFC] [DRAFT-HHSFC]
Li, G., Li, G., Li, T., Xu, Q., and H. Zhou, "Hybrid Li, G., Li, G., Li, T., Xu, Q., and H. Zhou, "Hybrid
Hierarchical Multi-Domain Service Function chaining", Hierarchical Multi-Domain Service Function chaining",
draft-li-sfc-hhsfc-04 (work in progress), April 2018. draft-li-sfc-hhsfc-05 (work in progress), September 2018.
[DRAFT-MD-VIRT]
Bernardos, C., Contreras, L., Vaishnavi, I., Szabo, R.,
Li, X., Paolucci, F., Sgambelluri, A., Martini, B.,
Valcarenghi, L., Landi, G., Andrushko, D., and A. Mourad,
"Multi-domain Network Virtualization", draft-bernardos-
nfvrg-multidomain-05 (work in progress), September 2018.
[DRAFT-PM] [DRAFT-PM]
Roome, W., Chen, S., Randriamasy, S., Yang, Y., and J. Roome, W., Chen, S., Randriamasy, S., Yang, Y., and J.
Zhang, "Unified Properties for the ALTO Protocol", draft- Zhang, "Unified Properties for the ALTO Protocol", draft-
ietf-alto-unified-props-new-03 (work in progress), March ietf-alto-unified-props-new-03 (work in progress), March
2018. 2018.
[DRAFT-PV] [DRAFT-PV]
Bernstein, G., Chen, S., Gao, K., Lee, Y., Roome, W., Bernstein, G., Chen, S., Gao, K., Lee, Y., Roome, W.,
Scharf, M., Yang, Y., and J. Zhang, "ALTO Extension: Path Scharf, M., Yang, Y., and J. Zhang, "ALTO Extension: Path
Vector Cost Type", draft-ietf-alto-path-vector-03 (work in Vector Cost Type", draft-ietf-alto-path-vector-03 (work in
progress), March 2018. progress), March 2018.
[ETSI-NFV-DEF] [ETSI-NFV-DEF]
ETSI, "Network Functions Virtualisation (NFV); Terminology ETSI, "Network Functions Virtualisation (NFV); Terminology
for Main Concepts in NFV V1.3.1", Jan 2018, for Main Concepts in NFV V1.3.1", Jan 2018,
<https://docbox.etsi.org/isg/nfv/open/Publications_pdf/ <https://docbox.etsi.org/isg/nfv/open/Publications_pdf/
Specs-Reports/NFV%20003v1.3.1%20-%20GR%20-%20Terminology%2 Specs-Reports/NFV%20003v1.3.1%20-%20GR%20-%20Terminology%2
0for%20Main%20Concepts%20in%20NFV.pdf>. 0for%20Main%20Concepts%20in%20NFV.pdf>.
[ETSI-NFV-IFA028]
ETSI, "Report on architecture options to support multiple
administrative domains V3.1.1", Jan 2018,
<http://www.etsi.org/deliver/etsi_gr/NFV-
IFA/001_099/028/03.01.01_60/gr_NFV-IFA028v030101p.pdf>.
[ETSI-NFV-MANO] [ETSI-NFV-MANO]
ETSI, "Network Functions Virtualisation (NFV) Management ETSI, "Network Functions Virtualisation (NFV) Management
and Orchestration V1.1.1", Dec 2014, and Orchestration V1.1.1", Dec 2014,
<http://www.etsi.org/deliver/etsi_gs/NFV- <http://www.etsi.org/deliver/etsi_gs/NFV-
MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf>. MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf>.
[ETSI-NFV-MANO-MDO] [H2020-5G-TRANSFORMER]
ETSI, "Network Functions Virtualisation (NFV) Release 3; H2020, "5G-Transformer -- 5G Mobile Transport Platform for
Management and Orchestration; Report on architecture Vertical", 2017, <http://5g-transformer.eu/>.
options to support multiple administrative domains
V3.1.1", Jan 2018, <http://www.etsi.org/deliver/etsi_gr/
NFV-IFA/001_099/028/03.01.01_60/
gr_NFV-IFA028v030101p.pdf>.
[H2020.5GEX] [H2020.5GEX]
Bernardos, C., Dugeon, O., Galis, A., Morris, D., Simon, Bernardos, C., Dugeon, O., Galis, A., Morris, D., Simon,
C., and R. Szabo, "5G Exchange (5GEx)--Multi-domain C., and R. Szabo, "5G Exchange (5GEx)--Multi-domain
Orchestration for Software Defined Infrastructures", Orchestration for Software Defined Infrastructures",
focus vol. 4, no.5, p.2, 2015. focus vol. 4, no.5, p.2, 2015.
[H2020.5GEX.ESCAPE] [H2020.5GEX.ESCAPE]
5GEx Project, "ESCAPE: Extensible Service ChAin 5GEx Project, "ESCAPE: Extensible Service ChAin
Prototyping Environment", 2015, Prototyping Environment", 2015,
skipping to change at page 18, line 33 skipping to change at page 18, line 15
[UNIFY.NFFG] [UNIFY.NFFG]
UNIFY Deliverable D3.2a, "Network Function Forwarding UNIFY Deliverable D3.2a, "Network Function Forwarding
Graph specification", 2015, <http://www.fp7- Graph specification", 2015, <http://www.fp7-
unify.eu/files/fp7-unify-eu-docs/Results/Deliverables/ unify.eu/files/fp7-unify-eu-docs/Results/Deliverables/
UNIGY_D3.2a_NFFG%20Specification.pdf>. UNIGY_D3.2a_NFFG%20Specification.pdf>.
[VITAL] VITAL PROJECT H2020, "VITAL -- VIrtualized hybrid [VITAL] VITAL PROJECT H2020, "VITAL -- VIrtualized hybrid
satellite-TerrestriAl systems for resilient and fLexible satellite-TerrestriAl systems for resilient and fLexible
future networks", 2015, <http://www.ict-vital.eu/>. future networks", 2015, <http://www.ict-vital.eu/>.
11.3. URIs 10.3. URIs
[1] https://tools.ietf.org/html/draft-ietf-alto-path-vector- [1] https://tools.ietf.org/html/draft-ietf-alto-path-vector-
02#section-6.1 02#section-6.1
[2] https://tools.ietf.org/html/draft-ietf-alto-path-vector- [2] https://tools.ietf.org/html/draft-ietf-alto-path-vector-
02#section-6.1 02#section-6.1
[3] https://tools.ietf.org/html/draft-ietf-alto-path-vector- [3] https://tools.ietf.org/html/draft-ietf-alto-path-vector-
02#section-6.1.2 02#section-6.1.2
 End of changes. 51 change blocks. 
139 lines changed or deleted 157 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/