draft-ietf-teas-actn-requirements-04.txt   draft-ietf-teas-actn-requirements-05.txt 
Network Working Group Young Lee (Editor) TEAS Working Group Young Lee (Editor)
Dhruv Dhody Dhruv Dhody
Internet Draft Huawei Internet Draft Huawei
Intended status: Informational Sergio Belotti Intended status: Informational Sergio Belotti
Alcatel-Lucent Nokia
Expires: July 2017 Expires: November 2017
Khuzema Pithewan Khuzema Pithewan
Infinera Infinera
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
January 3, 2017 Takuya Miyasaka
KDDI
Jong Yoon Shin
SKT
May 12, 2017
Requirements for Abstraction and Control of TE Networks Requirements for Abstraction and Control of TE Networks
draft-ietf-teas-actn-requirements-04.txt draft-ietf-teas-actn-requirements-05.txt
Abstract Abstract
This document provides a set of requirements for abstraction and This document provides a set of requirements for abstraction and
control of Traffic Engineering networks to facilitate virtual control of Traffic Engineering networks to facilitate virtual
network operation via the creation of a single virtualized network network operation via the creation of a single virtualized network
or a seamless service. This supports operators in viewing and or a seamless service. This supports operators in viewing and
controlling different domains (at any dimension: applied technology, controlling different domains (at any dimension: applied technology,
administrative zones, or vendor-specific technology islands) as a administrative zones, or vendor-specific technology islands) as a
single virtualized network. single virtualized network.
skipping to change at page 2, line 13 skipping to change at page 2, line 18
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 July 3, 2017. This Internet-Draft will expire on November 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
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
2. High-level ACTN requirements...................................4 2. High-level ACTN requirements...................................4
2.1. Service-Specific Requirements.............................4 2.1. Service-Specific Requirements.............................4
2.2. Network-Related Requirements..............................7 2.2. Network-Related Requirements..............................7
3. ACTN Interfaces Requirements...................................8 3. References.....................................................9
3.1. CMI Requirements..........................................9 3.1. Normative References......................................9
3.2. MPI Requirements.........................................11 3.2. Informative References....................................9
4. References....................................................13 4. Contributors..................................................10
4.1. Normative References.....................................13 Authors' Addresses...............................................10
4.2. Informative References...................................14
5. Contributors..................................................15
Authors' Addresses...............................................15
1. Introduction 1. Introduction
This document provides a set of requirements for Abstraction and This document provides a set of requirements for Abstraction and
Control of Traffic Engineering (TE) Networks (ACTN) identified in Control of Traffic Engineering (TE) Networks (ACTN) identified in
various use-cases. [ACTN-frame] defines the base reference various use-cases specified by the operators. [ACTN-frame] defines
architecture and terminology. the base reference architecture and terminology.
ACTN refers to the set of virtual network operations needed to ACTN refers to the set of virtual network service operations needed
orchestrate, control and manage large-scale multi-domain TE networks to orchestrate, control and manage large-scale multi-domain TE
so as to facilitate network programmability, automation, efficient networks so as to facilitate network programmability, automation,
resource sharing, and end-to-end virtual service aware connectivity efficient resource sharing, and end-to-end virtual service aware
and network function virtualization services. connectivity.
These operations are summarized as follows: These operations are summarized as follows:
- Abstraction and coordination of underlying network resources - Abstraction and coordination of underlying network resources
independent of how these resources are managed or controlled, independent of how these resources are managed or controlled,
so that higher-layer entities can dynamically control virtual so that higher-layer entities can dynamically control virtual
networks based on those resources. Control includes creating, networks based on those resources. Control includes creating,
modifying, monitoring, and deleting virtual networks. modifying, monitoring, and deleting virtual networks.
- Collation of the resources from multiple TE networks (multiple - Collation of the resources from multiple TE networks (multiple
technologies, equipment from multiple vendors, under the technologies, equipment from multiple vendors, under the
control of multiple administrations) through a process of control of multiple administrations) through a process of
hierarchical abstraction to present a customer with a single hierarchical abstraction to present a customer with a single
virtual network. This is chieved by presenting the network virtual network. This is achieved by presenting the network
domain as an abstracted topology to the customer via open and domain as an abstracted topology to the customer via open and
programmable interfaces. Hierarchical abstraction allows for programmable interfaces. Hierarchical abstraction allows for
the recursion of controllers in a customer-provider the recursion of controllers in a customer-provider
relationship. relationship.
- Orchestration of end-to-end virtual network services and - Orchestration of end-to-end virtual network services and
applications via allocation of network resources to meet applications via allocation of network resources to meet
specific service, application and customer requirements. specific service, application and customer requirements.
- Adaptation of customer requests (to control virtual resources) - Adaptation of customer requests (to control virtual resources)
skipping to change at page 4, line 12 skipping to change at page 4, line 12
- Provision via a data model of a computation scheme and virtual - Provision via a data model of a computation scheme and virtual
control capability to customers who request virtual network control capability to customers who request virtual network
services. Note that these customers could, themselves, be services. Note that these customers could, themselves, be
service providers. service providers.
ACTN solutions will build on, and extend, existing TE constructs and ACTN solutions will build on, and extend, existing TE constructs and
TE mechanisms wherever possible and appropriate. Support for TE mechanisms wherever possible and appropriate. Support for
controller-based approaches is specifically included in the possible controller-based approaches is specifically included in the possible
solution set. solution set.
Section 2 provides high-level ACTN requirements. Section 3 provides
ACTN interface requirements.
2. High-level ACTN requirements 2. High-level ACTN requirements
This section provides a summary of use-cases in terms of two This section provides a summary of use-cases in terms of two
categories: (i) service-specific requirements; (ii) network-related categories: (i) service-specific requirements; (ii) network-related
requirements. requirements. All these requirements are specified by operators that
are interested in implementing ACTN.
Service-specific requirements listed below are uniquely applied to Service-specific requirements listed below are uniquely applied to
the work scope of ACTN. Service-specific requirements are related to the work scope of ACTN. Service-specific requirements are related to
the virtual service coordination function. These requirements are the virtual service coordination function. These requirements are
related to customer's VNs in terms of service policy associated with related to customer's VNs in terms of service policy associated with
VNs such as service performance objectives, VN endpoint location VNs such as service performance objectives, VN endpoint location
information for certain required service specific functions (e.g., information for certain required service specific functions (e.g.,
security and others), VN survivability requirement, or dynamic security and others), VN survivability requirement, or dynamic
service control policy, etc. service control policy, etc.
Network-related requirements are related to the virtual network Network-related requirements are related to and necessary for
operation function. These requirements are related to multi-domain coherent/seamless for the virtual network operation function. These
and multi-layer signaling, routing, protection/restoration and requirements are related to multi-domain and multi-layer signaling,
synergy, re-optimization/re-grooming, etc. These requirements are routing, protection/restoration and synergy, re-optimization/re-
not inherently unique for the scope of ACTN but some of these grooming, etc.
requirements are in scope of ACTN, especially for coherent/seamless
operation aspect of multiple controller hierarchy.
2.1. Service-Specific Requirements 2.1. Service-Specific Requirements
1. Requirement 1: Policy Enforcement 1. Requirement 1: Virtual Network Service (VNS) creation
Ability to provide service requirement/policy (between Customer
and Network) and mechanism to enforce Service Level Agreements
(SLA).
- Endpoint selection policy, routing policy, time-related Customer MUST be able to request/instantiate the VNS to the network
policy, etc. within the confines of mutual agreement between customer and network
operator and network operator's capability. There are different
types of VNS in terms of the VN types the customer is allowed to
operate (e.g., a VN type can be simply a set of end-to-end tunnels,
or it can comprise of virtual nodes and links in mesh fashion,
etc.). The customer MUST be able to express VNS policy that captures
Service Level Agreements (SLA) associated with virtual network
service (e.g., Endpoint selection policy, routing policy, time-
related policy, etc.)
Reference: [KLEE], [LOPEZ], [SHIN], [DHODY], [FANG]. Reference: [KLEE], [LOPEZ], [SHIN], [DHODY], [FANG].
2. Requirement 2: Virtual Network (VN) Query 2. Requirement 2: Virtual Network Service Query
Ability to request/respond VN Query ("Can you give me these Customer SHOULD be able to request VNS Query ("Can you give me these
VN(s)?") VN(s)?") that include the following parameters:
Request Input: - VN type: various VN types defined by the customer (e.g.,
path, graph, etc.)
- VN end-points (Customer Edge interface information)
- VN Topology Service-specific Objective Functions (e.g.,
maximum bandwidth, minimum latency, minimum hops, etc. and
any combination of them).
- VN constraints requirement (e.g., Maximum Latency threshold,
Minimum Bandwidth, etc.)
- VN end-points (Customer Edge equipment) Reference: [KUMAKI], [FANG], [CHENG].
- VN Topology Service-specific Multi-Cost Objective Function
- VN constraints requirement
o Latency only, bandwidth guarantee, joint latency and
bandwidth guarantee
- VN Topology diversity (e.g., VN1 and VN2 must be disjoint;
Node/link disjoint from other VNs)
- VN Topology type: path, graph
Response includes VN topology: 3. Requirement 3: VNS Instantiation ("Please create a VNS for me")
- Exact Customer MUST be able to instantiate VNS that includes various VNS
- Potential related parameters:
Reference: [KUMAKI], [FANG], [CHENG]. - VN type: various VN types defined by the customer (e.g.,
path, graph, etc.)
- VN end-points (Customer Edge interface information)
- VN Topology Service-specific Objective Functions (e.g.,
maximum bandwidth, minimum latency, minimum hops, etc. and
any combination of them).
- VN constraints requirement (e.g., Maximum Latency threshold,
Minimum Bandwidth, etc.)
- VN Topology diversity when there are multiple instances of
VNS (e.g., VN1 and VN2 must be disjoint; Node/link disjoint
from other VNs)
3. Requirement 3: VN Instantiation ("Please create a VN for me") Reference: [KUMAKI], [FANG], [CHENG].
Ability to request/confirm VN Instantiation 4. Requirement 4: VNS Lifecycle Management & Operation (M&O)
Request Input: Customer MUST be able to perform the following VNS operations:
- VN instance ID - VNS Delete: Customer MUST be able to delete VNS.
- VN end-points (Customer Edge equipment) - VNS Modify: Customer MUST be able to modify VNS related
- VN Topology Service-specific Multi-Cost Objective Function parameters during the lifecycle of the instantiated VNS.
- VN constraints requirement
o Latency only, bandwidth guarantee, joint latency and
bandwidth guarantee
- VN Topology diversity (e.g., VN1 and VN2 must be disjoint;
Node/link disjoint from other VNs)
- VN Topology type: path, graph
Response includes VN topology: Reference: [FANG], [KUMAKI], [LOPEZ], [DHODY], [FANG], [KLEE].
- Exact 5. Requirement 5: VNS Isolation
- Potential
Reference: [KUMAKI], [FANG], [CHENG]. Customer's VN should be able to use arbitrary network topology,
routing, or forwarding functions as well as customized control
mechanisms independent of the underlying physical network and of
other coexisting virtual networks. Other customers' VNS operation
MUST not impact a particular customer's VNS network operation.
4. Requirement 4: VN Lifecycle Management & Operation (M&O) Reference: [KUMAKI], [FANG], [LOPEZ]
Ability to do the following VN operations: 6. Requirement 6: Multi-Destination Coordination
- Delete Customer MUST be able to define and convey service/preference
- Modify requirements for multi-destination applications (e.g., set of
- Update (VN level Operations, Administration and Management candidate sources/destinations, thresholds for load balancing,
(OAM) Monitoring) under policy agreement disaster recovery policy, etc.)
Reference: [FANG], [KUMAKI], [LOPEZ]. Reference: [FANG], [LOPEZ], [SHIN].
5. Requirement 5: VN Service Operation 7. Requirement 7: VNS Performance Monitoring
Ability to set up and manage end-to-end services on the VN The customer MUST be able to define performance monitoring
involving multi-domain and multi-layer operations of the parameters and its associated policy such as frequency of report,
underlying network while meeting constraints based on SLAs. abstraction/aggregation level of performance data (e.g., VN level,
tunnel level, virtual link/node level, etc.) with dynamic feedback
loop from the network.
Reference: [LOPEZ], [KUMAKI], [CHENG], [DHODY], [FANG], [KLEE]. Reference: [XU], [XU2], [DHODY], [CHENG]
8. Requirement 8: VNS Confidentiality and Security Requirements
6. Requirement 6: VN Confidentiality/Security The following confidentiality/security requirements MUST be
supported in all interfaces:
- A VN customer must not be able to control another customer's - Securing the request and control of resources, confidentially
virtual network of the information, and availability of function.
- A VN customer must not see any routing information (e.g. IGP - Trust domain verification (external entity versus internal
database, TE database) relating to another customer's entity)
virtual network - Encrypting data that flow between components, especially when
they are implemented at remote nodes, regardless if these are
external or internal network interfaces.
Reference: [KUMAKI], [FANG], [LOPEZ] 2.2. Network-Related Requirements
7. Requirement 7: Multi-Destination Coordination 1. Requirement 1: Virtual Network Service Coordination
Coordination of multi-destination service requirement/policy to
support dynamic applications such as VM migration, disaster
recovery, load balancing, etc.
- Service-policy primitives and their parameters Network MUST be able to support the following VNS operations:
Reference: [FANG], [LOPEZ], [SHIN]. - VNS Delete: Upon customer's VNS deletion request, network
MUST be able to delete VNS.
- VNS Modify: Upon customer's VNS modification request,
network MUST be able to modify VNS related parameters during
the lifecycle of the instantiated VNS.
- VNS Update: Upon customer's VNS performance monitoring
setup, the network MUST be able to support VNS level
Operations, Administration and Management (OAM) Monitoring
under policy agreement.
2.2. Network-Related Requirements Reference: [FANG], [KUMAKI], [LOPEZ], [DHODY], [FANG], [KLEE].
1. Requirement 1: Single Virtualized Network Topology 2. Requirement 2: Topology Abstraction Capability
Ability to build virtual network operation infrastructure based The network MUST be capable of managing its networks based on the
on multi-layer, multi-domain topology abstracted from multiple principle of topology abstraction to be able to scale multi-layer,
physical network control mechanisms (e.g., GMPLS, OpenFlow, PCE, multi-domain networks.
NMS, etc.)
Reference: [KLEE], [LOPEZ], [DHODY], [CHENG]. Reference: [KLEE], [LOPEZ], [DHODY], [CHENG].
2. Requirement 2: Multi-Domain & Multi-layer Coordination 3. Requirement 3: Multi-Domain & Multi-layer Coordination
Ability to coordinate multi-domain and multi-layer path Network coordination for multi-domain and multi-layer path
computation and path setup operation computation and path setup operation MUST be provided:
- End-to-end path computation across multi-domain networks - End-to-end path computation across multi-domain networks
(based on abstract topology from each domain) (based on abstract topology from each domain)
- Domain sequence determination - Domain sequence determination
- Request for path signaling to each domain controller - Request for path signaling to each domain controller
- Alternative path computation if any of the domain - Alternative path computation if any of the domain
controllers cannot find its domain path controllers cannot find its domain path
Reference: [CHENG], [DHODY], [KLEE], [LOPEZ], [SHIN], [SUZUKI]. Reference: [CHENG], [DHODY], [KLEE], [LOPEZ], [SHIN], [SUZUKI].
3. Requirement 3: End-to-End Path Restoration
Ability to perform end-to-end Path Restoration Operations 4. Requirement 4: End-to-End Path Restoration
- Intra-domain recovery End-to-end Path Restoration Operations MUST be provided with
- Cross-domain recovery seamless coordination between domain-level recovery schemes and
cross-domain recovery schemes.
Reference: [CHENG], [KLEE], [DHODY], [LOPEZ], [SHIN]. Reference: [CHENG], [KLEE], [DHODY], [LOPEZ], [SHIN].
4. Requirement 4: Dynamicity of network control operations 5. Requirement 5: Dynamicity of virtual network control operations
The ACTN interfaces should support dynamic network control Dynamic virtual network control operations MUST be supported. This
operations. This includes, but is not limited to, the following: includes, but is not limited to, the following:
- Real-time VN control (e.g., fast recovery/reroute upon - Real-time VNS control (e.g., fast recovery/reroute upon
network failure). network failure).
- Fast convergence of abstracted topologies upon changes due - Fast convergence of abstracted topologies upon changes due
to failure or reconfiguration across the network domain to failure or reconfiguration across the network domain
view, the multi-domain network view and the customer view. view, the multi-domain network view and the customer view.
- Large-scale VN operation (e.g., the ability to query tens of - Large-scale VNS operation (e.g., the ability to query tens
thousands of nodes, and to examine tens of thousands of of thousands of nodes, and to examine tens of thousands of
connectivity requests) for time-sensitive applications. connectivity requests) for time-sensitive applications.
Reference: [SHIN], [XU], [XU2], [KLEE], [KUMAKI], [SUZUKI]. Reference: [SHIN], [XU], [XU2], [KLEE], [KUMAKI], [SUZUKI].
5. Requirement 5: Dynamic VN Control
Dynamic/On-demand VN Modification/Confirmation with feedback loop
to the customer
- Traffic monitoring and control policies sent to the network
- Network states based traffic optimization policies
- Utilization Monitoring (including frequency of reporting)
- Abstraction of Resource Topology reflecting service-related
parameters
Reference: [XU], [XU2], [DHODY], [CHENG]
3. ACTN Interfaces Requirements
This section provides detailed ACTN interface requirements for the
two interfaces that are within the ACTN scope based on [ACTN-Frame]
and the use-cases referenced in this document.
The ACTN architecture described in [ACTN-Frame] comprises three
functional components:
- CNC: Customer Network Controller
- MDSC: Multi Domain Service Coordinator
- PNC: Physical Network Controller
The architecture gives rise to two interfaces between components:
- CMI: CNC-MDSC Interface
- MPI: MDSC-PNC Interface
3.1. CMI Requirements
1. Security/Policy Negotiation ("Who are you?") between CNC and
MDSC
- Trust domain verification (External Entity versus Internal
Service Department)
- Push/Pull support (for policy)
2. VN Topology Query ("Can you give me VN?") from CNC to MDSC
- VN end-points (CE end)
- VN Topology Service-specific Multi-Cost Objective Function
o Latency Map
o Available Bandwidth Map
o Latency Map and Available Bandwidth Map together
o Other types
- VN Topology diversity
o Node/Link disjoint from other VNs
o VN Topology level diversity (e.g., VN1 and VN2 must be
disjoint)
- VN Topology type
o Path vector (tunnel)
o Node/Links (graph)
3. VN Topology Query Response from MDSC to CNC: "Here's the VN
Topology that can be given to you if you request it"
- For VN Topology,
o This is what can be reserved for you
o This is what is available beyond what you asked for
(potential)
4. Basic VN Instantiation Request/Confirmation between CNC and
MDSC: "I need a VN for my service, please instantiate my VN"
- VN instance ID
- VN end-points
- VN service requirement
o Latency only
o B/W guarantee
o Latency and B/W guarantee together
- VN diversity
o Node/Link disjoint from other VNs
- VN level diversity (e.g., VN1 and VN2 must be disjoint)
- VN type
o Path vector (tunnel)
o Node/Links (graph)
- VN instance ID per service (unique id to identify VNs)
- If failed to instantiate the requested VN, say why
5. Dynamic/On-demand VN Instantiation/Modification and
Confirmation with feedback loop (This is to be differentiated
from Basic VN Instantiation)
- Performance/Fault Monitoring
- Utilization Monitoring (Frequency of report)
- Abstraction of Resource Topology reflecting these service-
related parameters
- Dynamic Policy enforcement
6. VN lifecycle management/operation
- Create (same as VN instantiate Request)
- Delete
- Modify
- Update (VN level OAM Monitoring) under policy agreement
7. Coordination of multi-destination service requirement/policy
to support dynamic applications such as VM migration,
disaster recovery, load balancing, etc.
- Service-policy primitives and its parameters
3.2. MPI Requirements
1. Security/Policy negotiation ("Who are you?")
- Exchange of key, etc.
- Domain preference + local policy exchange
- Push/Pull support
- Preferred peering points
- Preferred route
- Reroute policy
- End-point mobility (for multi-destination)
2. Topology Query /Response (Pull Model from MDSC to PNC: "Please
give me your domain topology")
- TED Abstraction level negotiation
- Abstract topology (per policy)
o Node/Link metrics
o Node/Link Type (Border/Gateway, etc.)
o All TE metrics (SRLG, etc.)
o Topology Metrics (latency, B/W available, etc.)
3. Topology Update (Push Model from PNC to MDSC: "The topology
has been updated")
- Under policy agreement, topology changes to be pushed to
MDSC from PNC
4. VN Path Computation Request (From MDSC to PNC: "Please give me
a path in your domain")
- VN Instance ID (Note: this is passed from CNC to MDSC)
- End-point information
- CE ends
- Border points (if applicable)
- All other PCE request info (PCEP)
5. VN Path Computation Reply ("Here's the path info per your
Request")
- Path level abstraction
- LSP DB
- LSP ID
- VN ID
6. Coordination of multi-domain Centralized Signaling Path Setup
Operation (From MDSC to PNC: "Please give me your domain path
if you can; otherwise, let me know if that is not possible."
- MSDC computes E2E path across multi-domain (based on abstract
topology from each PNC)
- MDSC determines the domain sequence
- MDSC request path signaling to each PNC (domain)
- MDSC finds alternative path if any of the PNCs cannot find
its domain path
o PNC will crankback to MDSC if it cannot find its domain
path
o PNC will confirm to MDSC if it finds its domain path
7. Path Restoration Operation after an E2E path is setup
successfully, some domain had a failure that cannot be restored
by the PNC domain (From PNC to MDSC: "My domain path failed and
I cannot restore it."; From MDSC to PNC: "OK. Please set up a
new domain path with this ingress/egress nodes."
- The problem PNC will send this notification with changed
abstract topology (computed after resource changes due to
failure/other factors)
- MDSC will find an alternate E2E path based on the changes
reported from PNC. It will need to update the E2E abstract
topology and the affected CN's VN topology in real-time (This
refers to dynamic synchronization of topology from Physical
topology to abstract topology to VN topology)
- MDSC will perform the path restoration signaling to the
affected PNCs.
8. Coordination of Multi-destination service restoration
operation: the CNC may have, for example, multiple endpoints
where the source can send its data to either one of the
endpoints. (From PNC to MDSC, "I lost my connectivity to the
endpoint. Please help to find alternative endpoint."; From MDSC
to PNC, "Please use this alternative endpoint.")
- When PNC reports domain problem that cannot be resolved at
PNC level because of there is no network restoration path to
a given destination, then MDSC has customers' profile in
which to find the customer has "multi-destination"
application.
- Under policy A, MDSC will be allowed to reroute the customer
traffic to one of the pre-negotiated destinations and
proceed with restoration of this particular customer's
traffic.
- Under policy B, CNC may reroute on its VN topology level and
push this to MDSC and MDSC maps this into its abstract
topology and proceed with restoration of this customer's
traffic.
- In either case, the MDSC will proceed its restoration
operation (as explained in Req. 7) to the corresponding
PNCs.
9. MDSC-PNC policy negotiation is also needed as to how
restoration is done across MDSC and PNCs. (From MDSC to PNC:
"Please resolve at your domain for restoration of LSP."
10. Generic Abstract Topology Update per changes due to new path
setup/connection failure/degradation/restoration (From PNC to
MDSC: "Here's an updated topology")
11. Service-specific Abstract Topology Update per changes due
to new path setup/connection failure/degradation/restoration
(From PNC to MDSC: "Here's an updated service-specific
topology")
4. References 3. References
4.1. Normative References 3.1. Normative References
[ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and [ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and
Control of Transport Networks", draft-ietf-teas-actn- Control of Transport Networks", draft-ietf-teas-actn-
framework, work in progress. framework, work in progress.
4.2. Informative References 3.2. Informative References
[CHENG] W. Cheng, et. al., "ACTN Use-cases for Packet Transport [CHENG] W. Cheng, et. al., "ACTN Use-cases for Packet Transport
Networks in Mobile Backhaul Networks", draft-cheng-actn- Networks in Mobile Backhaul Networks", draft-cheng-actn-
ptn-requirements, work in progress. ptn-requirements, work in progress.
[DHODY] D. Dhody, et. al., "Packet Optical Integration (POI) Use [DHODY] D. Dhody, et. al., "Packet Optical Integration (POI) Use
Cases for Abstraction and Control of Transport Networks Cases for Abstraction and Control of Transport Networks
(ACTN)", draft-dhody-actn-poi-use-case, work in progress. (ACTN)", draft-dhody-actn-poi-use-case, work in progress.
[FANG] L. Fang, "ACTN Use Case for Multi-domain Data Center [FANG] L. Fang, "ACTN Use Case for Multi-domain Data Center
skipping to change at page 15, line 9 skipping to change at page 10, line 18
work in progress. work in progress.
[XU2] Y. Xu, et. al., "Requirements of Abstract Alarm Report in ACTN [XU2] Y. Xu, et. al., "Requirements of Abstract Alarm Report in ACTN
architecture", draft-xu-teas-actn-abstract-alarm-report, architecture", draft-xu-teas-actn-abstract-alarm-report,
work-in-progress. work-in-progress.
[SUZUKI] T. Suzuki, et. al., "Use-case and Requirements for Multi- [SUZUKI] T. Suzuki, et. al., "Use-case and Requirements for Multi-
domain Operation Plane Change", draft-suzuki-teas-actn- domain Operation Plane Change", draft-suzuki-teas-actn-
multidomain-opc, work-in-progress. multidomain-opc, work-in-progress.
5. Contributors 4. Contributors
Kwangkook Lee Kwangkook Lee
KT KT
Email: kwangkooglee@gmail.com Email: kwangkooglee@gmail.com
Takuya Miyasaka
KDDI
Email: ta-miyasaka@kddi.com
Yunbin Xu Yunbin Xu
CATR CATR
Email: xuyunbin@mail.ritt.com.cn Email: xuyunbin@mail.ritt.com.cn
Toshiaki Suzuki Toshiaki Suzuki
Hitachi Hitachi
Email: toshiaki.suzuki.cs@hitachi.com Email: toshiaki.suzuki.cs@hitachi.com
Haomian Zheng
Huawei
Email: zhenghaomian@huawei.com
Authors' Addresses Authors' Addresses
Young Lee (Editor) Young Lee (Editor)
Huawei Technologies Huawei Technologies
5340 Legacy Drive 5340 Legacy Drive
Plano, TX 75023, USA Plano, TX 75023, USA
Phone: (469)277-5838 Phone: (469)277-5838
Email: leeyoung@huawei.com Email: leeyoung@huawei.com
Dhruv Dhody Dhruv Dhody
skipping to change at line 622 skipping to change at page 11, line 21
Khuzema Pithewan Khuzema Pithewan
Infinera Infinera
Email: kpithewan@infinera.com Email: kpithewan@infinera.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Torshamnsgatan,48 Torshamnsgatan,48
Stockholm, Sweden Stockholm, Sweden
Email: daniele.ceccarelli@ericsson.com Email: daniele.ceccarelli@ericsson.com
Takuya Miyasaka
KDDI
Email: ta-miyasaka@kddi.com
Jong Yoon Shin
SKT
Email: jongyoon.shin@sk.com
 End of changes. 64 change blocks. 
346 lines changed or deleted 149 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/