< draft-mm-sdn-vc-vn-on-demand-use-case-00.txt   draft-mm-sdn-vc-vn-on-demand-use-case-01.txt >
Network Working Group M. Chen Network Working Group M. Chen
Internet-Draft M. McBride Internet-Draft M. McBride
Intended status: Informational Huawei Technologies Co., Ltd Intended status: Informational Huawei Technologies Co., Ltd
Expires: January 10, 2013 July 09, 2012 Expires: January 17, 2013 L. Ou
China Telecom
July 16, 2012
Software Defined Networks Use Case for Virtual Connection and Network on Software Defined Networks Use Case for Virtual Connection and Network on
Demand Demand
draft-mm-sdn-vc-vn-on-demand-use-case-00 draft-mm-sdn-vc-vn-on-demand-use-case-01
Abstract Abstract
Software Defined Networks (SDN) provide a way to virtualize and Software Defined Networks (SDN) provide a way to virtualize and
abstract the network and presents the virtual/abstract resources to abstract the network and presents the virtual/abstract resources to
the third-party applications/software. The applications/software the third-party applications/software. The applications/software
can, by the programmable interface or Northbound API, request, can, by the programmable interface or Northbound API, request,
manipulate and monitor the services that the network provided. With manipulate and monitor the services that the network provided. With
this SDN capability, more innovative services can be introduced and this SDN capability, more innovative services can be introduced and
rapidly deployed. Additionally, existing services can be deployed rapidly deployed. Additionally, existing services can be deployed
skipping to change at page 1, line 48 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 17, 2013.
This Internet-Draft will expire on January 10, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Reference Architecture . . . . . . . . . . . . . . . . . . 4 2.1. Reference Architecture . . . . . . . . . . . . . . . . . . 5
2.2. VC on Demand . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. VC on Demand . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. VN on Demand . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. VN on Demand . . . . . . . . . . . . . . . . . . . . . . . 7
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 6. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
At present, applications and networks are independent of each other, At present, applications and networks are independent of each other,
and there is almost no interaction between the two layers. The and there is almost no interaction between the two layers. The
applications normally have no idea about how the application data be applications normally have no idea about how the application data be
transmitted over the network nor the status of the network. The transmitted over the network nor the status of the network. The
application requirements and constraints to the network are passed to application requirements and constraints to the network are passed to
service providers by some bill forms or contracts, and then the service providers by some bill forms or contracts, and then the
network operators set up the network according to the bill forms or network operators set up the network according to the bill forms or
skipping to change at page 6, line 7 skipping to change at page 7, line 7
2. VC Request/Response 2. VC Request/Response
When the controller is determined, the application sends a VC request When the controller is determined, the application sends a VC request
to the VC Controller to Create/Delete/Modify/Query a VC (e.g., to the VC Controller to Create/Delete/Modify/Query a VC (e.g.,
request a new VC from VDE1 to VDE2). The VC controller could choose request a new VC from VDE1 to VDE2). The VC controller could choose
to respond to the application immediately, or wait for the VC to be to respond to the application immediately, or wait for the VC to be
successfully constructed and then respond to the application. successfully constructed and then respond to the application.
3. VC Path Compute 3. VC Path Compute
According to the requirements and constraints from the App, the VC According to the requirements and constraints (e.g., bandwidth,
controller needs to determine a specific network service to serve the delay, loss etc.) from the App, the VC controller needs to determine
VC request, map the VC to a specific network path (e.g., mapping the a specific network service to serve the VC request, map the VC to a
VC to an openflow-based flow/an E-line/an E-tree/a PW/a TE LSP... ) specific network path (e.g., mapping the VC to an openflow-based
and then compute/find the path. VC controller could finish the path flow/an E-line/an E-tree/a PW/a TE LSP... ) and then compute/find the
computation by itself (for example, the controller has an embedded path. VC controller could finish the path computation by itself (for
path computation engine), or it may send a path compute request to example, the controller has an embedded path computation engine), or
another entity(e.g., Path Computation Element (PCE)) to finish the it may send a path compute request to another entity(e.g., Path
path computation. Computation Element (PCE)) to finish the path computation.
4. VC Provisioning 4. VC Provisioning
When the VC path is determined, the VC controller will then send VC When the VC path is determined, the VC controller will then send VC
provisioning request to the related network devices to provision the provisioning request to the related network devices to provision the
path. For example, the request could be to install an entry in the path. For example, the request could be to install an entry in the
openflow table, or trigger the ingress PE to signal a TE LSP or PW, openflow table, or trigger the ingress PE to signal a TE LSP or PW,
etc. The communication channel between VC controller and the network etc. The communication channel between VC controller and the network
devices could be either the existing protocols (e.g., Openflow, devices could be either the existing protocols (e.g., Openflow,
Netconf, Comand Line Interface(CLI), etc.) or new APIs defined in the Netconf, Command Line Interface(CLI), etc.) or new APIs defined in
future. the future.
5. VC Monitoring 5. VC Monitoring
Once a VC is established, the application may require the ability to Once a VC is established, the application may require the ability to
monitor the status of the VC. The application data could be monitor the status of the VC. The application data could be
directed, according to the VC status, to switchover the data to a directed, according to the VC status, to switchover the data to a
backup path when the master path is broken, or to switchover the data backup path when the master path is broken, or to switchover the data
to a more cost-effective path, etc. to a more cost-effective path, etc.
6. VC Policy 6. VC Policy
skipping to change at line 353 skipping to change at page 10, line 11
China China
Email: mach@huawei.com Email: mach@huawei.com
Mike McBride Mike McBride
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: michael.mcbride@huawei.com Email: michael.mcbride@huawei.com
Liang Ou
China Telecom
Email: oul@gsta.com
 End of changes. 7 change blocks. 
25 lines changed or deleted 26 lines changed or added

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