draft-ietf-teas-actn-framework-05.txt   draft-ietf-teas-actn-framework-06.txt 
TEAS Working Group Daniele Ceccarelli (Ed) TEAS Working Group Daniele Ceccarelli (Ed)
Internet Draft Ericsson Internet Draft Ericsson
Intended status: Informational Young Lee (Ed) Intended status: Informational Young Lee (Ed)
Expires: August 2017 Huawei Expires: December 2017 Huawei
May 5, 2017 June 13, 2017
Framework for Abstraction and Control of Traffic Engineered Networks Framework for Abstraction and Control of Traffic Engineered Networks
draft-ietf-teas-actn-framework-05 draft-ietf-teas-actn-framework-06
Abstract Abstract
Traffic Engineered networks have a variety of mechanisms to Traffic Engineered networks have a variety of mechanisms to
facilitate the separation of the data plane and control plane. They facilitate the separation of the data plane and control plane. They
also have a range of management and provisioning protocols to also have a range of management and provisioning protocols to
configure and activate network resources. These mechanisms configure and activate network resources. These mechanisms
represent key technologies for enabling flexible and dynamic represent key technologies for enabling flexible and dynamic
networking. networking.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 5, 2017. This Internet-Draft will expire on December 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 5, line 39 skipping to change at page 5, line 39
view and control multi-domain networks as a single virtualized view and control multi-domain networks as a single virtualized
network. network.
. The presentation to customers of networks as a virtual network . The presentation to customers of networks as a virtual network
via open and programmable interfaces. via open and programmable interfaces.
1.1. Terminology 1.1. Terminology
The following terms are used in this document. Some of them are The following terms are used in this document. Some of them are
newly defined, some others reference existing definition: newly defined, some others reference existing definition:
. Network Slicing: Network slicing is a collection of resources
that are used to establish logically dedicated virtual networks . Network Slicing: In the context of ACTN, network slicing is a
over TE networks. It allows a network provider to provide collection of resources that are used to establish logically
dedicated virtual networks for application/customer over a dedicated virtual networks over TE networks. It allows a
common network infrastructure. The logically dedicated network provider to provide dedicated virtual networks for
resources are a part of the larger common network application/customer over a common network infrastructure. The
infrastructures that are shared among various network slice logically dedicated resources are a part of the larger common
instances which are the end-to-end realization of network network infrastructures that are shared among various network
slice instances which are the end-to-end realization of network
slicing, consisting of the combination of physically or slicing, consisting of the combination of physically or
logically dedicated resources. logically dedicated resources.
. Node: A node is a vertex on the graph representation of a TE . Node: A node is a vertex on the graph representation of a TE
topology. In a physical network topology, a node corresponds to topology. In a physical network topology, a node corresponds to
a physical network element (NE). In an abstract network a physical network element (NE). In an abstract network
topology, a node (sometimes called an abstract node) is a topology, a node (sometimes called an abstract node) is a
representation as a single vertex of one or more physical NEs representation as a single vertex of one or more physical NEs
and their connecting physical connections. The concept of a and their connecting physical connections. The concept of a
node represents the ability to connect from any access to the node represents the ability to connect from any access to the
skipping to change at page 26, line 40 skipping to change at page 26, line 40
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
--(o---o)==(o---o)== ==(o---o)==(o---o)-- --(o---o)==(o---o)== ==(o---o)==(o---o)--
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
(_) (_) (_) (_) (_) (_) (_) (_)
Actual Topology Actual Topology
___ ___ ___ ___ ___ ___ ___ ___
( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )
( o ) ( o ) ( o--o) ( o ) ( o ) ( o ) ( o--o) ( o )
( / \ ) ( |\ ) ( | | ) ( / \ ) ( / \ ) ( |\ ) ( | | ) ( / \ )
----(o-o---o-o)==(o-o-o-o-o)==(o--o--o-o)==(o-o-o-o-o)---- ----(o-o---o-o)==(o-o-o-o-o)==(o--o--o-o)==(o-o-o-o-o)----
( \ / ) ( | |/ ) ( | | ) ( \ / ) ( \ / ) ( | |/ ) ( | | ) ( \ / )
( o ) (o-o ) ( o--o) ( o ) ( o ) (o-o ) ( o--o) ( o )
(___) (___) (___) (___) (___) (___) (___) (___)
Domain 1 Domain 2 Domain 3 Domain 4 Domain 1 Domain 2 Domain 3 Domain 4
Where o is a node and -- is a link and === a border link Where o is a node and -- is a link and === a border link
Figure 8: Illustration of topology abstraction granularity levels Figure 8: Illustration of topology abstraction granularity levels
In the example depicted in Figure 8, there are four domains under In the example depicted in Figure 8, there are four domains under
control of the respective PNCs, namely, PNC 1, PNC 2, PNC3 and PNC4. control of the respective PNCs, namely, PNC 1, PNC 2, PNC3 and PNC4.
skipping to change at page 29, line 39 skipping to change at page 29, line 39
Table 3: AP and VNAP - provider view after VNS creation Table 3: AP and VNAP - provider view after VNS creation
7.1. Dual homing scenario 7.1. Dual homing scenario
Often there is a dual homing relationship between a CE and a pair of Often there is a dual homing relationship between a CE and a pair of
PEs. This case needs to be supported by the definition of VN, APs PEs. This case needs to be supported by the definition of VN, APs
and VNAPs. Suppose CE1 connected to two different PEs in the and VNAPs. Suppose CE1 connected to two different PEs in the
operator domain via AP1 and AP2 and that the customer needs 5Gbps of operator domain via AP1 and AP2 and that the customer needs 5Gbps of
bandwidth between CE1 and CE2. This is shown in Figure 11. bandwidth between CE1 and CE2. This is shown in Figure 11.
____________ ____________
AP1 ( ) AP3 AP1 ( ) AP3
-------(PE1) (PE3)------- -------(PE1) (PE3)-------
W / ( ) \X W / ( ) \X
+---+/ ( ) \+---+ +---+/ ( ) \+---+
|CE1| ( ) |CE2| |CE1| ( ) |CE2|
+---+\ ( ) /+---+ +---+\ ( ) /+---+
Y \ ( ) /Z Y \ ( ) /Z
-------(PE2) (PE4)------- -------(PE2) (PE4)-------
AP2 (____________) AP2 (____________)
Figure 11: Dual homing scenario Figure 11: Dual homing scenario
In this case, the customer will request for a VN between AP1, AP2 In this case, the customer will request for a VN between AP1, AP2
and AP3 specifying a dual homing relationship between AP1 and AP2. and AP3 specifying a dual homing relationship between AP1 and AP2.
As a consequence no traffic will flow between AP1 and AP2. The dual As a consequence no traffic will flow between AP1 and AP2. The dual
homing relationship would then be mapped against the VNAPs (since homing relationship would then be mapped against the VNAPs (since
other independent VNs might have AP1 and AP2 as end points). other independent VNs might have AP1 and AP2 as end points).
The customer view would be shown in Table 4. The customer view would be shown in Table 4.
 End of changes. 9 change blocks. 
23 lines changed or deleted 24 lines changed or added

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