ACTN BOF D. Dhody
Internet-Draft X. Zhang
Intended status: Informational Huawei Technologies
Expires: August 18, 2014 O. Gonzalez de Dios
Telefonica
D. Ceccarelli
Ericsson
February 14, 2014
Packet Optical Integration (POI) Use Cases for Abstraction and Control
of Transport Networks (ACTN)
draft-dhody-actn-poi-use-case-01
Abstract
This document describes the Abstraction and Control of Transport
Networks (ACTN) use cases related to Packet and Optical Integration
(POI), that may be potentially deployed in various transport networks
and apply to different applications.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Dhody, et al. Expires August 18, 2014 [Page 1]
Internet-Draft ACTN-POI-USECASE February 2014
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet Optical Integration . . . . . . . . . . . . . . . . . 3
3.1. Traffic Planning, Monitoring and Automatic Network
Adjustments . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Automated Congestion Management . . . . . . . . . . . 4
3.2. Protection and Restoration Synergy . . . . . . . . . . . 5
3.3. Service Awareness . . . . . . . . . . . . . . . . . . . . 5
3.4. Coordination between Multiple Network Domains . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 8
1. Introduction
The transport networks are in an unique position to embrace the
concepts of software defined networking (SDN) because of the existing
separation in control and forwarding plane via GMPLS/ASON. The path
computation element (PCE) [RFC4655] and its stateful extension
[STATEFUL-PCE] can further provide a central control over the
resources. Abstraction and Control of Transport Network (ACTN) is
focused on building over the existing blocks by adding
programmability, access and control over abstract virtual topologies.
[ACTN-PROBLEM] and [ACTN-FWK] provides detailed information regarding
this work. Further [ACTN-USECASE] describe the overall use-cases for
ACTN. This document focuses on the Packet and Optical Integration
(POI) use cases of ACTN.
It is preferable to coordinate network resource control and
utilization rather than controlling and optimizing resources at each
network layer (packet and optical transport network) independently.
This facilitates network efficiency and network automation.
In a multi-layer network via client and server networking roles,
Label Switched Paths (LSPs) in a server (lower) layer are used to
carry client (higher) layer LSPs across the server (lower) layer
Dhody, et al. Expires August 18, 2014 [Page 2]
Internet-Draft ACTN-POI-USECASE February 2014
network. Basic Packet and Optical Integration (POI) may be achieved
by some of the existing mechanism as specified in [RFC4208] and
[RFC5623]. This document explores the POI use cases of ACTN to help
provide programmable network services like orchestration, access to
abstract topology and control over the resources.
Increasingly there is a need for packet and optical transport
networks to work together to provide accelerated services. Transport
networks can provide useful information to the packet network
allowing it to make intelligent decisions and control its allocated
resources. In this POI use-case, we regard packet networks as a
customer to transport networks. It is interesting to note that the
Packet networks themselves may have their ultimate clients to
support. The use case described in this document are primarily
concerned with 'packet network as a customer' in a single trusted
domain.
1.1. Requirements Language
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 [RFC2119].
2. Terminology
The following terminology is used in this document.
ACTN: Abstraction and Control of Transport Networks.
PCE: Path Computation Element. An entity (component, application,
or network node) that is capable of computing a network path or
route based on a network graph and applying computational
constraints.
POI: Packet and Optical Integration
VNTM: Virtual Network Topology Manager
3. Packet Optical Integration
Connections (or tunnels) formed across the optical transport network,
can be used as virtual TE links in the packet network. The
relationship is reduced to determining which tunnels to set up, how
to trigger them, how to route them, and what capacity to assign them.
As the demands in the packet network vary, these tunnels may need to
be modified.
Dhody, et al. Expires August 18, 2014 [Page 3]
Internet-Draft ACTN-POI-USECASE February 2014
An entity in packet network - (maybe a Path Computation Element
(PCE), Virtual Network Topology Manager (VNTM) [RFC5623], Controller
etc..) should be aware of the abstract topology of the transport
network. This entity is the customer controller as per [ACTN-FWK]
which interacts with Virtual Network Controller (VNC). The abstract
topology may consist of established tunnels in optical transport
network or ones that can be created on demand. The level of
abstraction is dependent on various management, security and policy
considerations. This abstract topology information in the packet
network can be utilized in various cases, as detailed in the
following sections.
3.1. Traffic Planning, Monitoring and Automatic Network Adjustments
Currently there is a schism between network planning for packet and
optical transport networks. Sometimes these networks are
administered, operated and planned independently even when they are a
part of a single trusted domain. Any change in traffic requirements
requires long business process to make changes in the network. In
dynamic networks this is no longer acceptable.
A unified Packet+Optical traffic planning tool can be developed which
uses the traffic demand matrix to plan the optical transport network.
Further based on traffic demand changes, historical data, traffic
prediction and monitoring, changes should be made to the optical
transport network. An access to abstract topology of the optical
transport network based on established and potential (on-demand)
tunnels in transport network can provide mechanism to handle this.
Further optical bypass may be established automatically to offload
the continuous changing traffic to transport network allowing
streamlined business process between packet and optical transport
networks.
3.1.1. Automated Congestion Management
Congestion management and synergized network optimization for packet
and transport networks can eliminate the need for overbooking of
transport networks as dumb pipes. Application could be written that
provide automated congestion management and network optimization.
Automated congestion management recognizes prolonged congestion in
the network and works with the controllers to add bandwidth at a
transport layer, to alleviate the congestion, or make changes in the
packet layer to reroute traffic around the congestion.
For such applications there is a clear need for an abstract network
topology of optical transport layer, further there is also a need for
a synergy of cost and SLA across optical and packet networks.
Dhody, et al. Expires August 18, 2014 [Page 4]
Internet-Draft ACTN-POI-USECASE February 2014
3.2. Protection and Restoration Synergy
The protection and restoration are usually handled individually in
Packet and optical layer. There is a need for synergy and optimized
handling of protection of resources across layers. A lot more
resources in the optical transport network are booked for backup then
actually required since there is a lack of coordination between
packet and optical layers. The access to abstract graph of transport
network with information pertaining to backup path information can
help the packet network to handle protection, shared risk, fault
restoration in an optimized way. Informing the packet network about
both working and protection path which are either already
established, or potential path can be useful.
A significant improvements in overall network availability that can
be achieved by using optical transport shared-risk link group (SRLG)
information to guide packet network decisions; for example, to avoid
or minimize common SRLGs for the main (working) path and the loop
free alternative or traffic engineered fast reroute (LFA/TE FRR)
back-up path. Shared risk information need to be synergized between
the packet and optical. A mechanism to provide abstracted SRLG
information can help the packet network consider this information
while handling protection and restoration.
3.3. Service Awareness
In certain networks like financial information network (stock/
commodity trading) and enterprises using cloud based applications,
Latency (delay), Latency-Variation (jitter), Packet Loss and
Bandwidth Utilization are associated with the SLA. These SLAs must
be synergized across packet and optical transport networks. Network
optimization evaluates network resource usage at all layers and
recommends or executes service path changes while ensuring SLA
compliance. It thus makes more effective use of the network, and
relieves current or potential congestion.
The main economic benefits of ACTN arise from its ability to maintain
the SLA of the services at reduced overall network cost considering
both packet and optical transport network. Operational benefits of
the ACTN also stem from greater flexibility in handling dynamic
traffic such as demand uncertainty or variations over time, or
optimization based on cost or latency, or improved handling of
catastrophic failures.
Dhody, et al. Expires August 18, 2014 [Page 5]
Internet-Draft ACTN-POI-USECASE February 2014
3.4. Coordination between Multiple Network Domains
In some deployments, optical transport network may further be divided
into multiple domains, an abstracted topology comprising of multiple
optical domains MAY be provided to the packet network. A Seamless
aggregation and orchestration across multiple optical transport
domains is achieved via the VNC, a great help in such deployments.
Another interesting deployment involves multiple packet network
domains. There exist scenarios where the topology provided to the
packet network domains may be different based on the initial demand
matrix as well as, management, security and policy considerations.
The ACTN framework as described in [ACTN-FWK] should support the
aggregation and orchestration across network domains and layers.
4. Security Considerations
TBD.
5. IANA Considerations
None, this is an informational document.
6. Acknowledgments
TBD.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
Dhody, et al. Expires August 18, 2014 [Page 6]
Internet-Draft ACTN-POI-USECASE February 2014
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
"Framework for PCE-Based Inter-Layer MPLS and GMPLS
Traffic Engineering", RFC 5623, September 2009.
[STATEFUL-PCE]
Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
Extensions for Stateful PCE [draft-ietf-pce-stateful-
pce]", October 2013.
[ACTN-FWK]
Ceccarelli, D., Fang, L., Lee, Y., and D. Lopez,
"Framework for Abstraction and Control of Transport
Networks (draft-ceccarelli-actn-framework)", January 2014.
[ACTN-PROBLEM]
Lee, Y. and D. King, "Problem Statement for Abstraction
and Control of Transport Networks (draft-leeking-actn-
problem-statement)", February 2014.
[ACTN-USECASE]
Dhody, D., Zhang, X., and O. Gonzalez de Dios, "Use Cases
for Abstraction and Control of Transport Networks (ACTN)
(draft-dhodyzhang-actn-use-case-00)", February 2014.
Dhody, et al. Expires August 18, 2014 [Page 7]
Internet-Draft ACTN-POI-USECASE February 2014
Appendix A. Contributor Addresses
Bin-Yeong Yoon
ETRI
SOUTH KOREA
EMail: byyun@etri.re.kr
Udayasree Palle
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: udayasree.palle@huawei.com
Authors' Addresses
Dhruv Dhody
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: dhruv.ietf@gmail.com
Xian Zhang
Huawei Technologies
Bantian, Longgang District
Shenzhen, Guangdong 518129
P.R.China
EMail: zhang.xian@huawei.com
Oscar Gonzalez de Dios
Telefonica
SPAIN
EMail: ogondio@tid.es
Dhody, et al. Expires August 18, 2014 [Page 8]
Internet-Draft ACTN-POI-USECASE February 2014
Daniele Ceccarelli
Ericsson
Via E. Melen 77, Genova - Erzelli
Italy
EMail: daniele.ceccarelli@ericsson.com
Dhody, et al. Expires August 18, 2014 [Page 9]