draft-ietf-teas-actn-framework-06.txt   draft-ietf-teas-actn-framework-07.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: December 2017 Huawei Expires: January 19, 2018 Huawei
June 13, 2017 July 20, 2017
Framework for Abstraction and Control of Traffic Engineered Networks Framework for Abstraction and Control of Traffic Engineered Networks
draft-ietf-teas-actn-framework-06 draft-ietf-teas-actn-framework-07
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 December 13, 2017. This Internet-Draft will expire on January 19, 2018.
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 2, line 29 skipping to change at page 2, line 29
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Terminology...............................................5 1.1. Terminology...............................................5
2. Business Model of ACTN.........................................9 2. Business Model of ACTN.........................................9
2.1. Customers.................................................9 2.1. Customers................................................10
2.2. Service Providers........................................10 2.2. Service Providers........................................10
2.3. Network Providers........................................12 2.3. Network Providers........................................12
3. Virtual Network Service.......................................12 3. Virtual Network Service.......................................12
4. ACTN Base Architecture........................................13 4. ACTN Base Architecture........................................13
4.1. Customer Network Controller..............................15 4.1. Customer Network Controller..............................15
4.2. Multi Domain Service Coordinator.........................16 4.2. Multi Domain Service Coordinator.........................16
4.3. Physical Network Controller..............................17 4.3. Physical Network Controller..............................17
4.4. ACTN Interfaces..........................................17 4.4. ACTN Interfaces..........................................17
5. Advanced ACTN architectures...................................18 5. Advanced ACTN architectures...................................18
5.1. MDSC Hierarchy for scalability...........................18 5.1. MDSC Hierarchy for scalability...........................18
5.2. Functional Split of MDSC Functions in Orchestrators......19 5.2. Functional Split of MDSC Functions in Orchestrators......19
6. Topology Abstraction Method...................................21 6. Topology Abstraction Method...................................21
6.1. No abstraction (native/white topology)...................22 6.1. Abstraction Factors......................................22
6.2. One Virtual Node (black topology)........................23 6.2. Abstraction Types........................................23
6.3. Abstraction of TE tunnels for all pairs of border nodes 6.2.1. Native/White Topology...............................23
(grey topology)...............................................24 6.2.2. Black Topology......................................24
6.3.1. Grey topology type A: border nodes with a TE links 6.2.3. Grey Topology.......................................25
between them in a full mesh fashion........................25
6.3.2. Grey topology Type B................................25 6.3. Building Methods of Grey Topology........................27
6.4. Topology Abstraction Granularity Level example...........25 6.3.1. Automatic generation of abstract topology by
7. Access Points and Virtual Network Access Points...............27 configuration..............................................27
7.1. Dual homing scenario.....................................29 6.3.2. On-demand generation of supplementary topology via path
8. Advanced ACTN Application: Multi-Destination Service..........30 compute request/reply......................................28
8.1. Pre-Planned End Point Migration..........................31 6.4. Abstraction Configuration Consideration..................29
8.2. On the Fly End Point Migration...........................32 6.4.1. Packet Networks.....................................29
9. Advanced Topic................................................32 6.4.2. OTN Networks........................................29
10. Manageability Considerations.................................32 6.4.3. WSON Networks.......................................30
10.1. Policy..................................................33 6.5. Topology Abstraction Granularity Level example...........30
10.2. Policy applied to the Customer Network Controller.......34 7. Access Points and Virtual Network Access Points...............32
10.3. Policy applied to the Multi Domain Service Coordinator..34 7.1. Dual homing scenario.....................................34
10.4. Policy applied to the Physical Network Controller.......34 8. Advanced ACTN Application: Multi-Destination Service..........35
11. Security Considerations......................................35 8.1. Pre-Planned End Point Migration..........................36
8.2. On the Fly End Point Migration...........................37
9. Advanced Topic................................................37
10. Manageability Considerations.................................37
10.1. Policy..................................................38
10.2. Policy applied to the Customer Network Controller.......39
10.3. Policy applied to the Multi Domain Service Coordinator..39
10.4. Policy applied to the Physical Network Controller.......39
11. Security Considerations......................................40
11.1. Interface between the Customer Network Controller and Multi 11.1. Interface between the Customer Network Controller and Multi
Domain Service Coordinator (MDSC), CNC-MDSC Interface (CMI)...36 Domain Service Coordinator (MDSC), CNC-MDSC Interface (CMI)...41
11.2. Interface between the Multi Domain Service Coordinator and 11.2. Interface between the Multi Domain Service Coordinator and
Physical Network Controller (PNC), MDSC-PNC Interface (MPI)...36 Physical Network Controller (PNC), MDSC-PNC Interface (MPI)...41
12. References...................................................37 12. References...................................................42
12.1. Informative References..................................37 12.1. Informative References..................................42
13. Contributors.................................................38 13. Contributors.................................................43
Authors' Addresses...............................................39 Authors' Addresses...............................................44
APPENDIX A - Example of MDSC and PNC functions integrated in APPENDIX A - Example of MDSC and PNC functions integrated in
Service/Network Orchestrator.....................................40 Service/Network Orchestrator.....................................45
APPENDIX B - Example of IP + Optical network with L3VPN service..40 APPENDIX B - Example of IP + Optical network with L3VPN service..45
APPENDIX C - Example of ODU service connectivity................41
1. Introduction 1. Introduction
Traffic Engineered networks have a variety of mechanisms to Traffic Engineered networks have a variety of mechanisms to
facilitate separation of data plane and control plane including facilitate separation of data plane and control plane including
distributed signaling for path setup and protection, centralized distributed signaling for path setup and protection, centralized
path computation for planning and traffic engineering, and a range path computation for planning and traffic engineering, and a range
of management and provisioning protocols to configure and activate of management and provisioning protocols to configure and activate
network resources. These mechanisms represent key technologies for network resources. These mechanisms represent key technologies for
enabling flexible and dynamic networking. enabling flexible and dynamic networking.
skipping to change at page 15, line 14 skipping to change at page 15, line 14
+--------------+ +---------------+ +--------------+ +--------------+ +---------------+ +--------------+
| CNC-A | | CNC-B | | CNC-C | | CNC-A | | CNC-B | | CNC-C |
|(DC provider) | | (ISP) | | (MVNO) | |(DC provider) | | (ISP) | | (MVNO) |
+--------------+ +---------------+ +--------------+ +--------------+ +---------------+ +--------------+
\ | / \ | /
Business \ | / Business \ | /
Boundary =======\========================|=========================/======= Boundary =======\========================|=========================/=======
Between \ | CMI / Between \ | CMI /
Customer & ----------- | -------------- Customer & ----------- | --------------
Network Provider \ | / Network Provider \ | /
+-----------------------+ +-----------------------+
| MDSC | | MDSC |
+-----------------------+ +-----------------------+
/ | \ / | \
------------ |MPI ---------------- ------------ |MPI ----------------
/ | \ / | \
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| PNC | | PNC | | PNC | | PNC | | PNC | | PNC |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| GMPLS / | / \ | GMPLS / | / \
| trigger / |SBI / \ | trigger / |SBI / \
-------- ----- | / \ -------- ----- | / \
( ) ( ) | / \ ( ) ( ) | / \
- - ( Phys. ) | / ----- - - ( Phys. ) | / -----
skipping to change at page 21, line 48 skipping to change at page 21, line 43
in [Service-YANG]. The MPI is a subset of network configuration in [Service-YANG]. The MPI is a subset of network configuration
model to support TE configuration. This model encompasses the MPI model to support TE configuration. This model encompasses the MPI
model plus other non-TE/non-ACTN models to control non-ACTN model plus other non-TE/non-ACTN models to control non-ACTN
functions of the domain controller (e.g., L3VPN). functions of the domain controller (e.g., L3VPN).
Device configuration model is used by a controller to configure Device configuration model is used by a controller to configure
physical network elements. physical network elements.
6. Topology Abstraction Method 6. Topology Abstraction Method
This section discusses topology abstraction types and their context This section discusses topology abstraction factors, types and their
in ACTN architecture. Topology abstraction is useful in ACTN context in ACTN architecture. Topology abstraction is useful in ACTN
architecture as a way to scale multi-domain network operation. As architecture as a way to scale multi-domain network operation. Note
the MDSC needs to coordinate with the PNCs in multi-domain networks
for determining a feasible domain sequence and provisioning the end-
to-end tunnel based on the determined domain sequence, topology
abstraction provides an efficient network scaling mechanism. Note
that this is the abstraction performed by the PNC to the MDSC or by that this is the abstraction performed by the PNC to the MDSC or by
the MDSC-L to the MDSC-H, and that this is different from the VN the MDSC-L to the MDSC-H, and that this is different from the VN
Type 2 topology (that is created and negotiated between the CNC and Type 2 topology (that is created and negotiated between the CNC and
the MDSC as part of the VNS). The purpose of topology abstraction the MDSC as part of the VNS). The purpose of topology abstraction
discussed in this section is for an efficient internal network discussed in this section is for an efficient internal network
operation based on abstraction principle. operation based on abstraction principle.
Refer to [ACTN-Abstraction] for detailed discussions on factors that 6.1. Abstraction Factors
affect topology abstraction, how to build topology abstraction,
various considerations and which method to pick based on abstraction
types and the nature of underlying transport technology (e.g., MPLS,
OTN, WSON, etc.).
6.1. No abstraction (native/white topology) This section provides abstraction factors in the ACTN architecture.
The MDSC oversees the specific aspects of the different domains and
builds a single abstracted end-to-end network topology in order to
coordinate end-to-end path computation and path/service
provisioning. In order for the MDSC to perform its coordination
function, it depends on the coordination with the PNCs which are the
domain-level controllers especially as to what level of domain
network resource abstraction is agreed upon between the MDSC and the
PNCs.
As discussed in [RFC7926], abstraction is tied with policy of the
networks. For instance, per an operational policy, the PNC would not
be allowed to provide any technology specific details (e.g., optical
parameters for WSON) in its update. In such case, the abstraction
level of the update will be in a generic nature. In order for the
MDSC to get technology specific topology information from the PNC, a
request/reply mechanism may be employed.
In some cases, abstraction is also tied with the controller's
capability of abstraction as it involves some rules and algorithms
to be applied to the actual network resource information (which is
also known as network topology).
[TE-Topology] describes YANG models for TE-network abstraction.
[PCEP-LS] describes PCEP Link-state mechanism that also allows for
transport of abstract topology in the context of Hierarchical PCE.
There are factors that may impact the choice of abstraction. Here
are the most relevant:
- The nature of underlying domain networks: Abstraction depends on
the nature of the underlying domain networks. For instance, packet
networks may have different level of abstraction requirements from
that of optical networks. Within optical networks, WSON may have
different level of abstraction requirements than the OTN networks.
- The capability of the PNC: Abstraction depends on the capability
of the PNCs. As abstraction requires hiding details of the
underlying resource network resource information, the PNC
capability to run some internal optimization algorithm impacts the
feasibility of abstraction. Some PNC may not have the ability to
abstract native topology while other PNCs may have such an ability
to abstract actual topology by using sophisticated algorithms.
- Scalability factor: Abstraction is a function of scalability. If
the actual network resource information is of small size, then the
need for abstraction would be less than the case where the native
network resource information is of large size. In some cases,
abstraction may not be needed at all.
- The frequency of topology updates: The proper abstraction level
may depend on the frequency of topology updates and vice versa.
- The capability/nature of the MDSC: The nature of the MDSC impacts
the degree/level of abstraction. If the MDSC is not capable of
handling optical parameters such as those specific to OTN/WSON,
then white topology abstraction may not work well.
- The confidentiality: In some cases where the PNC would like to
hide key internal topological data from the MDSC, the abstraction
method should consider this aspect.
- The scope of abstraction: All of the aforementioned factors are
equally applicable to both the MPI (MDSC-PNC Interface) and the
CMI (CNC-MDSC Interface).
6.2. Abstraction Types
This section defines the following three types of topology
abstraction:
. Native/White Topology (Section 6.2.1)
. Black Topology (Section 6.2.2)
. Grey Topology (Section 6.2.3)
6.2.1. Native/White Topology
This is a case where the PNC provides the actual network topology to This is a case where the PNC provides the actual network topology to
the MDSC without any hiding or filtering of information as shown in the MDSC without any hiding or filtering of information as shown in
Figure 6. In this case, the MDSC has the full knowledge of the Figure 6a. In this case, the MDSC has the full knowledge of the
underlying network topology and as such there is no need for the underlying network topology and as such there is no need for the
MDSC to send a path computation request to the PNC. The computation MDSC to send a path computation request to the PNC. The computation
burden will fall on the MDSC to find an optimal end-to-end path and burden will fall on the MDSC to find an optimal end-to-end path and
optimal per domain paths. optimal per domain paths.
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
+-+ +-----+ +-----+ +-----+ +-+ +-+ +-----+ +-----+ +-----+ +-+
++-+ ++-+ +-++ +-++ ++-+ ++-+ +-++ +-++
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
++-+ ++-+ +-++ +-++ ++-+ ++-+ +-++ +-++
+-+ +-----+ +-----+ +-----+ +-+ +-+ +-----+ +-----+ +-----+ +-+
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
Figure 6a: The native/white topology Figure 6a: The native/white topology
6.2. One Virtual Node (black topology) 6.2.2. Black Topology
The entire domain network is abstracted as a single virtual node The entire domain network is abstracted as a single virtual node
(see the definition of virtual node in [RFC7926]) with the (see the definition of virtual node in [RFC7926]) with the
access/egress links without disclosing any node internal access/egress links without disclosing any node internal
connectivity information. connectivity information.
Figure 6b depicts a native topology with the corresponding black Figure 6b depicts a native topology with the corresponding black
topology with one virtual node and inter-domain links. In this case, topology with one virtual node and inter-domain links. In this case,
the MDSC has to make path computation requests to the PNCs before it the MDSC has to make path computation requests to the PNCs before it
can determine an end-to-end path. If there are a large number of can determine an end-to-end path. If there are a large number of
inter-connected domains, this abstraction method may impose a heavy inter-connected domains, this abstraction method may impose a heavy
skipping to change at page 24, line 5 skipping to change at page 25, line 30
| | | |
| | | |
| | | |
| | | |
+--+ +--+ +--+ +--+
+--------+ +--------+
Figure 6b: The native topology and the corresponding black topology Figure 6b: The native topology and the corresponding black topology
with one virtual node and inter-domain links with one virtual node and inter-domain links
6.3. Abstraction of TE tunnels for all pairs of border nodes (grey 6.2.3. Grey Topology
topology)
This abstraction level, referred to a grey topology is between black This abstraction level, referred to a grey topology, represents a
topology and white topology from a granularity point of view. As compromise between black and white topology from a granularity point
shown in Figures 7a and 7b, we may further differentiate from a of view. As shown in Figures 7a and 7b, we may further differentiate
perspective of how to abstract internal TE resources between the from a perspective of how to abstract internal TE resources between
pairs of border nodes: the pairs of border nodes:
. Grey topology type A: border nodes with a TE links between them . Grey topology type A: border nodes with a TE links between them
in a full mesh fashion (See Figure 7a) in a full mesh fashion (See Figure 7a).
. Grey topology type B: border nodes with some internal
abstracted nodes and abstracted links (See Figure 7b)
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
+-+ +-----+ +-----+ +-----+ +-+ +-+ +-----+ +-----+ +-----+ +-+
++-+ ++-+ +-++ +-++ ++-+ ++-+ +-++ +-++
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
++-+ ++-+ +-++ +-++ ++-+ ++-+ +-++ +-++
+-+ +-----+ +-----+ +-----+ +-+ +-+ +-----+ +-----+ +-----+ +-+
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
+--+ +--+ +--+ +--+
+-+ +----+ +-+ +-+ +----+ +-+
++-+ +-++ ++-+ +-++
| \ / | | \ / |
| \/ | | \/ |
| /\ | | /\ |
| / \ | | / \ |
++-+ +-++ ++-+ +-++
+-+ +----+ +-+ +-+ +----+ +-+
+--+ +--+ +--+ +--+
Figure 7a: The native topology and the corresponding grey topology Figure 7a: The native topology and the corresponding grey topology
type A with TE links between border nodes type A with TE links between border nodes
For each pair of ingress and egress nodes (i.e., border nodes
to/from the domain), TE link metric is provided with TE attributes
such as max bandwidth available, link delay, etc. This abstraction
depends on the underlying TE networks.
Note that this grey topology can also be represented as a single
abstract node with the connectivity matrix defined in [TE-Topology],
abstracting the internal connectivity information. The only thing
might be different is some additional information about the end
points of the links of the border nodes (i.e., links outward
customer-facing) as they cannot be included in the connectivity
matrix's termination points.
. Grey topology type B: border nodes with some internal
abstracted nodes and abstracted links (See Figure 7b)
+--+ +--+ +--+ +--+ +--+ +--+
+-+ +-----+ +-----+ +-+ +-+ +-----+ +-----+ +-+
++-+ ++-+ +-++ ++-+ ++-+ +-++
| | | |
| | | |
| | | |
| | | |
++-+ ++-+ +-++ ++-+ ++-+ +-++
+-+ +-----+ +-----+ +-+ +-+ +-----+ +-----+ +-+
+--+ +--+ +--+ +--+ +--+ +--+
Figure 7b: The grey topology type B with abstract nodes/links Figure 7b: The grey topology type B with abstract nodes/links
between border nodes between border nodes
6.3.1. Grey topology type A: border nodes with a TE links
between them in a full mesh fashion
For each pair of ingress and egress nodes (i.e., border nodes
to/from the domain), TE link metric is provided with TE attributes
such as max bandwidth available, link delay, etc. This abstraction
depends on the underlying TE networks.
Note that this grey topology can also be represented as a single
abstract node with the connectivity matrix defined in [TE-Topology],
abstracting the internal connectivity information. The only thing
might be different is some additional information about the end
points of the links of the border nodes (i.e., links outward
customer-facing) as they cannot be included in the connectivity
matrix's termination points.
6.3.2. Grey topology Type B
The grey abstraction type B would allow the MDSC to have more The grey abstraction type B would allow the MDSC to have more
information about the internals of the domain networks by the PNCs information about the internals of the domain networks by the PNCs
so that the MDSC can flexibly determine optimal paths. The MDSC may so that the MDSC can flexibly determine optimal paths. The MDSC may
configure some of the internal virtual nodes (e.g., cross-connect) configure some of the internal virtual nodes (e.g., cross-connect)
to redirect its traffic as it sees changes from the domain networks. to redirect its traffic as it sees changes from the domain networks.
6.4. Topology Abstraction Granularity Level example 6.3. Building Methods of Grey Topology
This section discusses two different methods of building a grey
topology:
. Automatic generation of abstract topology by configuration
(Section 6.3.1)
. On-demand generation of supplementary topology via path
computation request/reply (Section 6.3.2)
6.3.1. Automatic generation of abstract topology by configuration
The "Automatic generation" method is based on the
abstraction/summarization of the whole domain by the PNC and its
advertisement on MPI interface once the abstraction level is
configured. The level of abstraction advertisement can be decided
based on some PNC configuration parameters (e.g. provide the
potential connectivity between any PE and any ASBR in an MPLS-TE
network.
Note that the configuration parameters for this potential topology
can include available B/W, latency, or any combination of defined
parameters. How to generate such tunnel information is beyond the
scope of this document.
Such potential topology needs to be periodically or
incrementally/asynchronously updated every time that a failure, a
recovery or the setup of new VNs causes a change in the
characteristics of the advertised grey topology (e.g. in our
previous case if due to changes in the network is it now possible to
provide connectivity between a given PE and a given ASBR with a
higher delay in the update).
6.3.2. On-demand generation of supplementary topology via path compute
request/reply
The "on-demand generation" of supplementary topology is to be
distinguished from automatic generation of abstract topology. While
abstract topology is generated and updated automatically by
configuration as explained in Section 6.3.1, additional
supplementary topology may be obtained by the MDSC via path compute
request/reply mechanism. Starting with a black topology
advertisement from the PNCs, the MDSC may need additional
information beyond the level of black topology from the PNCs.
It is assumed that the black topology advertisement from PNCs would
give the MDSC each domain's the border node/link information. Under
this scenario, when the MDSC needs to allocate a new VN, the MDSC
can issue a number of Path Computation requests as described in
[ACTN-YANG] to different PNCs with constraints matching the VN
request. An example is provided in Figure 4, where the MDSC is
requesting to setup a P2P VN between AP1 and AP2. The MDSC can use
two different inter-domain links to get from Domain X to Domain Y,
namely the one between ASBRX.1 and ASBRY.1 and the one between
ASBRX.2 and ASBRY.2, but in order to choose the best end to end path
it needs to know what domain X and Y can offer in term of
connectivity and constraints between the PE nodes and the ASBR
nodes.
------- -------
( ) ( )
- ASBRX.1------- ASBRY.1 -
(+---+ ) ( +---+)
-+---( |PE1| Dom.X ) ( Dom.Y |PE2| )---+-
| (+---+ ) ( +---+) |
AP1 - ASBRX.2------- ASBRY.2 - AP2
( ) ( )
------- -------
Figure 4: A multi-domain networks example
A path computation request will be issued to PNC.X asking for
potential connectivity between PE1 and ASBRX.1 and between PE1 and
ASBRX.2 with related objective functions and TE metric constraints.
A similar request will be issued to PNC.Y and the results merged
together at the MDSC to be able to compute the optimal end-to-end
path including the inter domain links.
The info related to the potential connectivity may be cached by the
MDSC for subsequent path computation processes or discarded, but in
this case the PNCs are not requested to keep the grey topology
updated.
6.4. Abstraction Configuration Consideration
This section provides a set of abstraction configuration
considerations.
It is expected that the abstraction level be configured between the
CNC and the MDSC (i.e., the CMI) depending on the capability of the
CNC. This negotiated level of abstraction on the CMI may also impact
the way the MDSC and the PNCs configure and encode the abstracted
topology. For example, if the CNC is capable of sophisticated
technology specific operation, then this would impact the level of
abstraction at the MDSC with the PNCs. On the other hand, if the CNC
asks for a generic topology abstraction, then the level of
abstraction at the MDSC with the PNCs can be less technology
specific than the former case.
The subsequent sections provide a list of possible abstraction
levels for various technology domain networks.
6.4.1. Packet Networks
- For grey abstraction, the type of abstraction and its parameters
can be defined and configured.
o Abstraction Level 1: TE-tunnel abstraction for all (S-D)
border pairs with:
. Maximum B/W available per Priority Level
. Minimum Latency
6.4.2. OTN Networks
For OTN networks, max bandwidth available may be per ODU 0/1/2/3
switching level or aggregated across all ODU switching levels (i.e.,
ODUj/k). Clearly, there is a trade-off between these two abstraction
methods. Some OTN switches can switch any level of ODUs and in such
case there is no need for ODU level abstraction.
- For grey abstraction, the type of abstraction and its parameters
can be defined and configured.
o Abstraction Level 1: Per ODU Switching level (i.e., ODU type
and number) TE-tunnel abstraction for all (S-D) border pairs
with:
. Maximum B/W available per Priority Level
. Minimum Latency
o Abstraction Level 2: Aggregated TE-tunnel abstraction for all
(S-D) border pairs with:
. Maximum B/W available per Priority Level
. Minimum Latency
6.4.3. WSON Networks
For WSON networks, max bandwidth available may be per
lambda/frequency level (OCh) or aggregated across all
lambda/frequency level. Per OCh level abstraction gives more
detailed data to the MDSC at the expense of more information
processing. Either OCh-level or aggregated level abstraction should
factor in the RWA constraint (i.e., wavelength continuity) at the
PNC level. This means the PNC should have this capability and
advertise it as such.
For grey abstraction, the type of abstraction and its parameters can
be defined and configured as follows:
o Abstraction Level 1: Per Lambda/Frequency level TE-tunnel
abstraction for all (S-D) border pairs with:
. Maximum B/W available per Priority Level
. Minimum Latency
o Abstraction Level 2: Aggregated TE-tunnel abstraction for all
(S-D) border pairs with:
. Maximum B/W available per Priority Level
6.5. Topology Abstraction Granularity Level example
This section illustrates how topology abstraction operates in This section illustrates how topology abstraction operates in
different level of granularity over a hierarchy of MDSCs which is different level of granularity over a hierarchy of MDSCs which is
shown in Figure 8 below. shown in Figure 8 below.
+-----+ +-----+
| CNC | CNC wants to create a VN | CNC | CNC wants to create a VN
+-----+ between CE A and CE B +-----+ between CE A and CE B
| |
| |
+-----------------------+ +-----------------------+
| MDSC-H | | MDSC-H |
+-----------------------+ +-----------------------+
/ \ / \
/ \ / \
+--------+ +--------+ +--------+ +--------+
| MDSC-L1| | MDSC-L2| | MDSC-L1| | MDSC-L2|
+--------+ +--------+ +--------+ +--------+
/ \ / \ / \ / \
/ \ / \ / \ / \
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
CE A o----|PNC 1| |PNC 2| |PNC 3| |PNC 4|----o CE B CE A o----|PNC 1| |PNC 2| |PNC 3| |PNC 4|----o CE B
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Topology operated by MDSC-H Topology operated by MDSC-H
skipping to change at page 27, line 18 skipping to change at page 32, line 18
provides a grey topology abstraction in which to present only border provides a grey topology abstraction in which to present only border
nodes and links within and outside the domain. The abstract topology nodes and links within and outside the domain. The abstract topology
MDSC-L1 would operate is basically a combination of the two MDSC-L1 would operate is basically a combination of the two
topologies the PNCs (PNC 1 and PNC 2) provide. Likewise, the topologies the PNCs (PNC 1 and PNC 2) provide. Likewise, the
abstract topology MDSC-L2 would operate is shown in Figure 8. Both abstract topology MDSC-L2 would operate is shown in Figure 8. Both
MDSC-L1 and MDSC-L2 provide a black topology abstraction in which MDSC-L1 and MDSC-L2 provide a black topology abstraction in which
each PNC domain is presented as one virtual node to its top level each PNC domain is presented as one virtual node to its top level
MDSC-H. Then the MDSC-H combines these two topologies updated by MDSC-H. Then the MDSC-H combines these two topologies updated by
MDSC-L1 and MDSC-L2 to create the abstraction topology to which it MDSC-L1 and MDSC-L2 to create the abstraction topology to which it
operates. MDSC-H sees the whole four domain networks as four virtual operates. MDSC-H sees the whole four domain networks as four virtual
nodes connected via virtual links. This illustrates the point nodes connected via virtual links. The top level MDSC may operate on
discussed in Section 5.1: The top level MDSC may operate on a higher a higher level of abstraction (i.e., less granular level) than the
level of abstraction (i.e., less granular level) than the lower lower level MSDCs.
level MSDCs.
7. Access Points and Virtual Network Access Points 7. Access Points and Virtual Network Access Points
In order not to share unwanted topological information between the In order not to share unwanted topological information between the
customer domain and provider domain, a new entity is defined which customer domain and provider domain, a new entity is defined which
is referred to as the Access Point (AP). See the definition of AP in is referred to as the Access Point (AP). See the definition of AP in
Section 1.1. Section 1.1.
A customer node will use APs as the end points for the request of A customer node will use APs as the end points for the request of
VNS as shown in Figure 9. VNS as shown in Figure 9.
skipping to change at page 29, line 39 skipping to change at page 34, line 36
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.
skipping to change at page 34, line 22 skipping to change at page 39, line 22
and survivability. Furthermore, application access and type of and survivability. Furthermore, application access and type of
virtual network service requested by the CNC, will be need adhere to virtual network service requested by the CNC, will be need adhere to
specific access control policies. specific access control policies.
10.3. Policy applied to the Multi Domain Service Coordinator 10.3. Policy applied to the Multi Domain Service Coordinator
A key objective of the MDSC is to help the customer express the A key objective of the MDSC is to help the customer express the
application connectivity request via its CNC as set of desired application connectivity request via its CNC as set of desired
business needs, therefore policy will play an important role. business needs, therefore policy will play an important role.
Once authorised, the virtual network service will be instantiated Once authorized, the virtual network service will be instantiated
via the CNC-MDSC Interface (CMI), it will reflect the customer via the CNC-MDSC Interface (CMI), it will reflect the customer
application and connectivity requirements, and specific service application and connectivity requirements, and specific service
transport needs. The CNC and the MDSC components will have agreed transport needs. The CNC and the MDSC components will have agreed
connectivity end-points, use of these end-points should be defined connectivity end-points, use of these end-points should be defined
as a policy expression when setting up or augmenting virtual network as a policy expression when setting up or augmenting virtual network
services. Ensuring that permissible end-points are defined for CNCs services. Ensuring that permissible end-points are defined for CNCs
and applications will require the MDSC to maintain a registry of and applications will require the MDSC to maintain a registry of
permissible connection points for CNCs and application types. permissible connection points for CNCs and application types.
It may also be necessary for the MDSC to resolve policy conflicts, It may also be necessary for the MDSC to resolve policy conflicts,
 End of changes. 32 change blocks. 
122 lines changed or deleted 346 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/