One document matched: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt
Differences from draft-deng-opsawg-composed-vpn-sm-requirements-00.txt
OPSA Working Group H. Deng
Internet-Draft China Mobile
Intended status: Informational
Expires: January 19, 2017 July 18, 2016
Requirements of Composed VPN Service Model
draft-deng-opsawg-composed-vpn-sm-requirements-01
Abstract
The operator facing data model is valuable to reduce the operation
and management. This document describes requirements of the composed
VPN service model for operators to deploy end to end PE-based VPN
services across multiple autonomous systems.
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 RFC 2119 [RFC2119].
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 January 19, 2017.
Copyright Notice
Copyright (c) 2016 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
Deng Expires January 19, 2017 [Page 1]
Internet-Draft Composed VPN Service Model July 2016
carefully, as they describe your rights and restrictions with respect
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
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases and Usage . . . . . . . . . . . . . . . . . . . . . 3
4. Design Requirements . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Internet Service Providers (ISPs) have significant interest on
providing Provider Edge (PE) based virtual private network (VPN)
services, in which the tunnel endpoints are the PE devices. In this
case, the Customer Edge (CE) devices do not need to have any special
VPN capabilities. Customers can reduce support costs by outsourcing
VPN operations to ISPs and using the obtained connectivity.
Typically, customers require either layer 2 or layer 3 connectivity
services to exchange traffic among a collection of sites. The ISP
gets the requirement and deploys the end to end VPN across multiple
autonomous systems (AS) with an orchestrator.
The model described in [I-D.ietf-l3sm-l3vpn-service-model] is used
for communication between customers and network operators. It
facilitates customers to request the layer 3 VPN service while
concealing many provider parameters they do not know.
However, the network operators have a different view of the managed
network. An operator facing model is required to reduce the
operation and management while still having reasonable control on the
network. So that the operators can verify and optimize the VPN
deployment based on the existing network.
This document describes requirements of the generic VPN model from
the operators' view for the PE-based VPN service configuration. It
aims at providing a simplified configuration on how the requested VPN
Deng Expires January 19, 2017 [Page 2]
Internet-Draft Composed VPN Service Model July 2016
service is to be deployed over the shared network infrastructure.
This model is limited to PE-Based VPNs as described in RFC 4110
[RFC4110] with the combination of layer 2 and layer 3 VPN services in
multiple ASes.
2. Definitions
o Segment VPN service: The VPN service deployed for one segment
which is usually an AS.
o Composed VPN service: The VPN service deployed within the ISP
administrative domain across one or more segments. It could be a
combination of layer 2 and layer 3 VPN services for each segment.
3. Use Cases and Usage
In practice, ISP may have various scenarios for the end to end VPN
service deployment depending on the network infrastructure and the
customer sites connectivity requirements. It will consequently
generate requirements of the generic composed VPN service model
design. The composed VPN service data model described in this
document covers the following scenarios:
o Multi-AS VPN Service: Customer sites are located in different
autonomous systems(AS). ISP need to deploy the VPN service across
multiple ASes.
o Composed L2 and L3 VPN Service: Although the customer may request
either layer 2 or layer 3 VPN service, the network infrastructure
among customer sites may require different VPN service in the
corresponding AS. So, an end to end VPN service within the ISP
domain may be a composition of multiple segmental layer 2 and
layer 3 VPN services.
o Dynamic Site Insertion: The customer site that is not in the
previously provisioned VPN can be quickly included.
A typical usage of this operator facing model is as an input for an
orchestration layer which will be responsible to translate it to
segment VPN information for the configutation of domain controllers.
As shown in the following figure, while, for example, users may send
highly abstracted layer 3 VPN service requests to the application
(e.g. BSS), it's not enough for operators to deploy an end to end
VPN service. The operator facing interface enables configuration of
VPN deployment by introducing more network knowlegde and garvenance
policies. For example :
Deng Expires January 19, 2017 [Page 3]
Internet-Draft Composed VPN Service Model July 2016
o Optimize the VPN deployment of the customer's requests based on
the exiting networking, e.g. deploy the L3VPN request from the
customer to multiple VPN segments (IPRAN, PTN, IPCore) in the end
to end environment.
o Add the operation requirements, e.g. operation visualization,
monitoring, diagnosis.
o Manage various policies for different customers.
+
Customer Facing Interface |
+------v-------+
| Application |
+------+-------+
Operator Facing Interface |
+------v-------+
| Orchestrator |
+----+---+-----+
| |
+---------+ +-----------+
| |
+------+------+ +------+------+
| Controller1 | | Controller2 |
+------+------+ +------+------+
| |
+---------+-----------+ +----------+----------+
| AS1 L2VPN | | AS2 L3VPN |
+-------+ | +------+ +------+ | | +------+ +------+ | +-------+
| Site1 +----+ PE11 +---+ PE12 +------+ PE21 +---+ PE22 +----+ Site2 |
+-------+ | +------+ +------+ | | +------+ +------+ | +-------+
+---------------------+ +---------------------+
4. Design Requirements
The PE-based VPN service is modeled with a recursive pattern as shown
in the following figure. The VPN service deployed within each AS is
modeled as a Segment VPN object including the VPN description
information within this AS and the Access Points (AP) that are used
to connect to the peered device or AS. As an end to end VPN service
within the ISP domain, it's then modeled as a Composed VPN object
with the overall VPN information and the APs that are used to connect
to the peered customer sites.
Deng Expires January 19, 2017 [Page 4]
Internet-Draft Composed VPN Service Model July 2016
AP1 +---------------+ AP4
+-------+ ComposedVPN +-------+
+----+-----+----+
| |
+---------+ +---------+
| |
AP1 +-----v-----+ AP2 AP3 +-----v-----+ AP4
+------+ SegVPN1 +-------------+ SegVPN2 +------+
+-----------+ +-----------+
+--------------------------------------------------------------------+
+---------------------+ +---------------------+
| AS1 | | AS2 |
+-------+ | +------+ +------+ | | +------+ +------+ | +-------+
| Site1 +----+ PE11 +---+ PE12 +------+ PE21 +---+ PE22 +----+ Site2 |
+-------+ | +------+ +------+ | | +------+ +------+ | +-------+
+---------------------+ +---------------------+
Generic PE-based VPN Modeling
The composed VPN model can be structured as in the following figure.
The Composed VPN top container contains VPN basic information, a list
of segment VPN information, and a list of access point information.
The Basic Information here includes overall description for this
composed VPN service. I.e., all the properties (e.g., topology,
service type) in this object describe the overview that the customer
want, no matter with any segment VPN information.
The Access Point List in the Composed VPN container describes a list
of APs that are used to connect to the peered customer sites.
However, the AP is modeled with generic Access Point Information
provided by the PE either in the composed VPN view or in the segment
VPN view. The AP contains:
o the basic information that is relatively static, no matter which
exact peer AP is going to connect.
o the information about the routing protocol that is used to
exchange the routing information with the remote peer. This
object is extensible with any posible routing protocols. The BGP
and static routing listed are examples to show how these two
widely used solutions are described.
o the QoS description. There can be two kinds of QoS configuration.
The AP based QoS: describes the QoS requirements on the access
point. For example, the CAR (committed access rate) definition on
the inbound or outbound ports. The flow based QoS: describes the
Deng Expires January 19, 2017 [Page 5]
Internet-Draft Composed VPN Service Model July 2016
QoS requirements on a flow. This enables the fine grained QoS
control with the capability of identifying the flow.
A composed VPN includes one or more segment VPN desribed by the
Segment VPN List. Each Segment VPN Information is only described
from the segment point of view. I.e., the description here takes
care about how the segment VPN looks like and how it can communicate
with peered devices outside this segment VPN. The segment
information is composed of the basic information and a list of APs.
The set of APs in the description are interfaces that customer sites
or other segment VPNs can attach. In different scenarios, each
segment VPN could be a layer 2 VPN, or layer 3 VPN.
+--------------+
| Composed VPN |
+---+----------+
|
| +-------------------+
+--+ Basic Information |
| +-------------------+
| +--Topology
| +--Service Type
| +--...
|
| +-------------------+
+--+ Access Point List |
| +-------------------+
| +--Basic Information
| +--QoS
| +--Routing Protocol
| +--...
|
| +------------------+
+--+ Segment VPN List |
+------------------+
+--Basic Information
+--Access Point List
+--...
Composed VPN Model Structure
5. IANA Considerations
TBD
Deng Expires January 19, 2017 [Page 6]
Internet-Draft Composed VPN Service Model July 2016
6. Security Considerations
TBD
7. Acknowledgements
TBD
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4110, DOI 10.17487/RFC4110, July 2005,
<http://www.rfc-editor.org/info/rfc4110>.
8.2. Informative References
[I-D.ietf-l3sm-l3vpn-service-model]
Litkowski, S., Shakir, R., Tomotaki, L., Ogaki, K., and K.
D'Souza, "YANG Data Model for L3VPN service delivery",
draft-ietf-l3sm-l3vpn-service-model-12 (work in progress),
July 2016.
Authors' Addresses
Hui Deng
China Mobile
No.32 Xuanwumen West Street
Beijing 100053
China
Email: denghui02@hotmail.com
Deng Expires January 19, 2017 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 03:04:45 |