A YANG Model for IP Link and Transport Service Mapping
draft-fu-pce-ip-link-transport-service-mapping-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Pengcheng FU , Jianzhong FU , Ruiquan Jing | ||
| Last updated | 2016-10-28 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-fu-pce-ip-link-transport-service-mapping-00
Network Working Group PC. Fu
Internet-Draft JZ. FU
Intended status: Standards Track Huawei Technologies
Expires: May 1, 2017 AJ. Wang
RQ. Jing
China Telecom
October 28, 2016
A YANG Model for IP Link and Transport Service Mapping
draft-fu-pce-ip-link-transport-service-mapping-00
Abstract
IP+optical is a cross-layer collaboration technology for unified
management of IP and optical networks. Based on framework proposed
in [ACTN-FWK][I-D.ietf-teas-actn-framework], this draft presents
specific information about the IP+optical solution: hierarchical
controllers + disabled GMPLS UNIs. This solution does not involve
UNI tunnel objects. Therefore, the mapping between IP links and
transport services is key point of this solution. This draft
provides a YANG model for the RESTCONF/NETCONF protocol. This YANG
module defines NBIs for the IP+optical super controller.
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 May 1, 2017.
Fu, et al. Expires May 1, 2017 [Page 1]
Internet-Draft October 2016
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
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
1.1. IP+optical solution . . . . . . . . . . . . . . . . . . . 2
1.2. Unified cross-layer algorithm . . . . . . . . . . . . . . 6
1.3. IP+VNT algorithm . . . . . . . . . . . . . . . . . . . . 7
1.4. IP Link and Transport Service Mapping . . . . . . . . . . 8
2. IP Link and Transport Service Mapping Model - YANG Tree . . . 10
3. IP Link and Transport Service Mapping Model - YANG Code . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
7. Normative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
1.1. IP+optical solution
IP+optical is a cross-layer collaboration technology for unified
management of IP and optical networks. IP+optical adopts the C/S
architecture, where the IP network is the client-layer network and
the optical network is the server-layer network. The mapping between
IP-layer IP links and transport services is the key ability of an
IP+optical network. Through the mapping, the services of IP layers
and those of transport layers can be associated to implement use
cases of IP+optical scenarios.
IP+optical use cases include multi-layer topology visualization,
automated network deployment, multi-layer automated service
deployment, multi-layer protection and restoration, multi-layer
optimization, and multi-layer maintenance window.
Fu, et al. Expires May 1, 2017 [Page 2]
Internet-Draft October 2016
Based on framework proposed in [ACTN-
FWK][I-D.ietf-teas-actn-framework], this draft presents specific
information about the IP+optical solution: hierarchical controllers +
disabled GMPLS UNIs. This solution does not involve UNI tunnel
objects. Therefore, the mapping between IP links and transport
services is key point of this solution.
+----------+
|IP+Optical|
| Super |
|Controller|
+-/------\-+
/ \
+---------/--+ +--\--------+
| IP | | Optical |
| Controller | |Controller |
+----+-------+ +---+-------+
| |
+----+----------------+-------------+
/R | R |R R /
/ R R | /
IP / R . R . | R R /
Layer +-------------------------+---------+
. . . . | . .
. . . . | . .
. . . . | . .
. . . . | . .
. . . . | . .
+---------------------+-------------+
/ O . O . O . | O O /
/ O . O O /
Optical / O O O O O /
Layer +-----------------------------------+
In real-world situations, IP+optical super controllers can be
separately deployed or combined with other controllers. For example,
in IP+optical single-domain scenarios, an IP+optical super controller
can be combined with an IP domain controller. In IP multi-domain and
optical multi-domain scenarios, you can deploy one separate IP super
controller and one separate optical super controller. The two super
controllers communicate through RESTConf interfaces and use the
IP+VNT algorithm to complete E2E cross-layer path calculation. In
such multi-domain scenarios, you can also deploy only one IP+optical
super controller and use a unified cross-layer algorithm in the
controller to complete E2E cross-layer path calculation.
Fu, et al. Expires May 1, 2017 [Page 3]
Internet-Draft October 2016
+----------+
|IP+Optical|
| Super |
|Controller|
+--/-----\-+
/ \
/ +--\--------+
/ | Optical |
/ |Controller |
/ +---+-------+
/ |
+-----/---------------+-------------+
/R / R |R R /
/ R R | /
IP / R . R . | R R /
Layer +-------------------------+---------+
. . . . | . .
. . . . | . .
. . . . | . .
. . . . | . .
. . . . | . .
+---------------------+-------------+
/ O . O . O . | O O /
/ O . O O /
Optical / O O O O O /
Layer +-----------------------------------+
Fu, et al. Expires May 1, 2017 [Page 4]
Internet-Draft October 2016
+--------------------+
| IP+Optical |
| Super |
| Controller |
+/--------+---------\+
/ | \
+-----------/+ +-----+-----+ +-\---------+
| IP | | Optical | | Optical |
| Controller | |Controller | |Controller |
+--------+---+ +-+---------+ +-------+---+
| | |
+-+---------+---------------------+-------+
/R | R | R R | R /
/ . | . | R . R . | /
IP / . R . R | . . R . . R | R /
Layer +---.--.-.------+----.----------.-----+---+
. . . . | . . . . . . | .
. . . . | . . . . . . | .
. . . . | . . . . . . | .
. . . . | . . . . . . | .
. . . . | . . . . . . | .
+--.-.------+----.----+ +---.-----+-------+
/O . O O | . O . / /. . O | O /
/ O O/ / O O | /
Optical / O O / / O O /
Layer +---------------------+ +-----------------+
Fu, et al. Expires May 1, 2017 [Page 5]
Internet-Draft October 2016
+------------+ +--------------------+
| IP | | IP+Optical |
| Controller +------+ Controller |
+-------+----+ +---+-------------+--+
| | |
| | |
| +--------+--+ +-----+-----+
| | Optical | | Optical |
| |Controller | |Controller |
| +--+--------+ +-------+---+
| | |
+-+---------+---------------------+-------+
/R | R | R R | R /
/ . | . | R . R . | /
IP / . R . R | . . R . . R | R /
Layer +---.--.-.------+----.----------.-----+---+
. . . . | . . . . . . | .
. . . . | . . . . . . | .
. . . . | . . . . . . | .
. . . . | . . . . . . | .
. . . . | . . . . . . | .
+--.-.------+----.----+ +---.-----+-------+
/O . O O | . O . / /. . O | O /
/ O O/ / O O | /
Optical / O O / / O O /
Layer +---------------------+ +-----------------+
1.2. Unified cross-layer algorithm
In this model, inter-layer path computation is performed by a single
PCE that has topology visibility into all layers. Such a PCE is
called a multi-layer PCE. In Figure 2, the network is comprised of
two layers. LSRs H1, H2,H3, and H4 belong to the higher layer, and
LSRs H2, H3, L1, and L2 belong to the lower layer. The PCE is a
multi-layer PCE that has visibility into both layers. It can perform
end-to-end path computation across layers (single PCE path
computation). For instance, it can compute an optimal path
H1-H2-L1-L2-H3-H4 for a higher-layer LSP from H1 to H4. This path
includes the path of a lower-layer LSP from H2 to H3 that is already
in existence or not yet established. return it to H1.Of course, more
complex cooperation may be required if an optimal end-to-end path is
desired.
Fu, et al. Expires May 1, 2017 [Page 6]
Internet-Draft October 2016
Controller
+-----------------------------------+
| +--------------+ |
| |Multilayer-PCE| |
| +--------------+ |
| +--------++-----------++--------+ |
| |IP ||Cross-Layer||Optical | |
| |Topology||Topology ||Topology| |
| +--------++-----------++--------+ |
+----------------+------------------+
|
|
|
----- ----- | ----- -----
| R |--| R |........|.......| R |--| R |
| H1 | | H2 | | H3 | | H4 |
----- -----\ /----- -----
\----- -----/
| O |--| O |
| L1 | | L2 |
----- -----
1.3. IP+VNT algorithm
In this model, there is at least one PCE per layer, and each PCE has
topology visibility restricted to its own layer. Some providers may
want to keep the layer boundaries due to factors such as
organizational and/or service management issues. The choice for
multiple PCE computation instead of single PCE computation may also
be driven by scalability considerations, as in this mode a PCE only
needs to maintain topology information for one layer (resulting in a
size reduction for the Traffic Engineering Database (TED)).These PCEs
are called mono-layer PCEs. Mono-layer PCEs collaborate to compute
an end-to-end optimal path across layers. Figure 3 shows multiple
PCE inter-layer computation with inter-PCE communication. There is
one PCE in each layer. The PCEs from each layer collaborate to
compute an end-to-end path across layers. PCE Hi is responsible for
computations in the higher layer and may "consult" with PCE Lo to
compute paths across the lower layer. PCE Lo is responsible for path
computation in the lower layer. A simple example of cooperation
between the PCEs could be as follows:
o LSR H1 sends a request to PCE Hi for a path H1-H4.
o PCE Hi selects H2 as the entry point to the lower layer and H3 as
the exit point.
o PCE Hi requests a path H2-H3 from PCE Lo.
Fu, et al. Expires May 1, 2017 [Page 7]
Internet-Draft October 2016
o PCE Lo returns H2-L1-L2-H3 to PCE Hi.
o PCE Hi is now able to compute the full path (H1-H2-L1-L2-H3-H4)
IP Controller Optical Controller
+-----------------------+ +-----------------------------------+
| +------+ | | +-----------+ |
| |IP-PCE| | | |Optical-PCE| |
| +------+ | | +-----------+ |
|+--------++-----------+| | +--------++-----------++--------+ |
||IP ||VNT || | |VNT ||Cross-Layer||Optical | |
||Topology||Topology || | |Topology||Topology ||Topology| |
|+--------++-----------+| | +--------++-----------++--------+ |
+-----------+---+-------+ +----------+-----+------------------+
| |
| |
| |
| |
| |
----- ----- | ----- -----
| R |-+| R |......................|.| R |--| R |
| H1 | | H2 | | | H3 | | H4 |
----- -----\ | /----- -----
\ /
\ /
\ /
\ /
\----- -----/
| O |--| O |
| L1 | | L2 |
----- -----
1.4. IP Link and Transport Service Mapping
The mapping varies with IP link interfaces and changes with system
creation, dismantlement, and scheduling changes.
Fu, et al. Expires May 1, 2017 [Page 8]
Internet-Draft October 2016
+-----+ +-----+
| R | IP Link | R |
| H1 | | H2 |
| @############################@ |
| |\ /| |
+---- + \ / + ----+
\ /
\ Transport Service /
\ +-----+ +-----+ /
\| |--| |/
@**************@
| O | | O |
| L1 | | L2 |
| | | |
+-----+ +-----+
IP Link
+-----+ +-----+
| R O|^^^^^^^^^^^^^^^^^^^^^^^^^^^^|O R |
| H1 O|^^^^^^^^^^^^^^^^^^^^^^^^^^^^|O H2 |
| O@^^^^^^^^^^^^^^^^^^^^^^^^^^^^@O |
| |\ /| |
+---- + \ / + ----+
\ /
\ Transport Service /
\ +-----+ +-----+ /
\| |--| |/
@**************@
| O | | O |
| L1 | | L2 |
| | | |
+-----+ +-----+
+-----+ +-----+
| R | IP Link | R |
| H1 @ @ H2 |
| E^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^E |
| @ \ / @ |
+---- +\ \ / /+ ----+
\ \ / /
\ \ Transport Service/ /
\ \+-----+ +-----+/ /
\ @**************@ /
\| |/
@**************@
| O | | O |
| L1 | | L2 |
+-----+ +-----+
Fu, et al. Expires May 1, 2017 [Page 9]
Internet-Draft October 2016
2. IP Link and Transport Service Mapping Model - YANG Tree
(preamble)
module: ietf-Mapping-IP_Link-Transport_Service
+--rw Mapping-IP_Link-Transport_Service
+--rw Mapping* [Mapping-id]
+--rw Mapping-id
+--rw config
| +--rw Mapping-id uint32
| +--rw Mapping-name string
| +--rw IP-Link* [node-id If-id]
| | +--rw IP_Link-name string
| | +--rw IP_Link-base[physical/VLAN if/Eth-Trunk]
| | +--rw source-node-id union
| | +--rw source-if-id uint32
| | +--rw sink-node-id union
| | +--rw sink-if-id uint32
| | +--rw bandwidth decimal64
| | +--rw delay decimal64
| | +--rw srlg[] decimal64
| | +--rw IP+Optial protection-type identityref
| +--rw transport-service
| | +--rw transport-service-id uint32
| | +--rw bandwidth? decimal64
| | +--rw delay-limit? decimal64
| | +--rw delayvariation-limit? decimal64
| | +--rw srlg[]? decimal64
| | +--rw protection-type? Identityref
| | +--rw supporting-tunnel
| | +--rw tunnel-name? string
+--ro state
| +--ro Mapping-id uint32
| +--ro Mapping-name string
| +--ro IP-Link* [node-id If-id]
| | +--ro IP_Link-name string
| | +--ro IP_Link-base[physical/VLAN if/Eth-Trunk]
| | +--ro source-node-id union
| | +--ro source-if-id uint32
| | +--ro sink-node-id union
| | +--ro sink-if-id uint32
| | +--ro bandwidth decimal64
| | +--ro delay decimal64
| | +--ro srlg[] decimal64
| | +--ro IP+Optial protection-type identityref
| +--ro transport-service
| | +--ro transport-service-id uint32
| | +--ro bandwidth? decimal64
Fu, et al. Expires May 1, 2017 [Page 10]
Internet-Draft October 2016
| | +--ro delay-limit? decimal64
| | +--ro delayvariation-limit? decimal64
| | +--ro srlg[]? decimal64
| | +--ro protection-type? Identityref
| | +--rw supporting-tunnel
| | +--rw tunnel-name? string
(postamble)
3. IP Link and Transport Service Mapping Model - YANG Code
(preamble)
<CODE BEGINS> file "ietf-mapping-ip_link-transport_service@2016-10-28.yang"
module ietf-mapping-ip_link-transport {
namespace "urn:ietf:params:xml:ns:yang:ietf-mapping-ip_link-transport";
prefix "ip-trans-map";
import ietf-inet-types {
prefix inet;
}
import ietf-yang-types {
prefix yang;
}
organization
"Huawei Technologies";
contact
"fupengcheng@huawei.com";
description
"The YANG module defines a mapping between ip link
and transport.";
revision 2016-10-28 {
description "Initial revision.";
}
/* Features */
feature ip-link {
description "ip-link paras";
}
feature transport {
description "transport paras";
}
Fu, et al. Expires May 1, 2017 [Page 11]
Internet-Draft October 2016
/* Typedefs */
typedef protection-type {
type string;
description
"ip or optical protection type.";
}
/* Groupings */
grouping ip-link-paras {
container ip-links {
list ip-link {
key ip-link-name;
leaf ip-link-name {
type string;
description
"name of an ip link.";
}
leaf ip-link-base {
type enumeration {
enum "physical" {
description
"physical link.";
}
enum "vlan-if" {
description
"vlan if";
}
enum "eth-trunk" {
description
"eth-trunk";
}
}
}
leaf source-node-id {
type string;
description
"source node id.";
}
leaf source-if-id {
type uint32;
description
"source if id.";
}
leaf sink-node-id {
type string;
description
"sink node id.";
Fu, et al. Expires May 1, 2017 [Page 12]
Internet-Draft October 2016
}
leaf sink-if-id {
type uint32;
description
"sink if id.";
}
leaf bandwidth {
type decimal64;
description
"bandwidth.";
}
leaf delay {
type decimal64;
description
"delay.";
}
leaf srlg {
type decimal64;
description
"srlg.";
}
leaf ip-optical {
type protection-type;
description
"IP_Optial.";
}
description
"List of ip links";
}
description
"Container of ip links";
}
description
"This grouping defines ip link parameters";
}
grouping transport-service-paras {
container transport-service {
leaf transport-service-id {
type uint32;
description
"transport service id.";
}
leaf bandwidth {
type decimal64;
description
"bandwidth.";
Fu, et al. Expires May 1, 2017 [Page 13]
Internet-Draft October 2016
}
leaf delay-limit {
type decimal64;
description
"delay limit.";
}
leaf delayvariation-limit {
type decimal64;
description
"delayvariation limit.";
}
leaf srlg {
type decimal64;
description
"srlg.";
}
leaf ip-optical {
type protection-type;
description
"IP_Optial.";
}
leaf supporting-tunnel-name {
type string;
description
" supporting tunnel name."
}
}
description
"This grouping defines transport service parameters";
}
/* Main blocks */
container mapping-ip-link-transport-service {
list mappings {
key mapping-id;
leaf mapping-id {
type string;
description
"key of a mapping.";
}
leaf mapping-name {
type string;
description
"name of a mapping";
}
uses ip-link-paras;
Fu, et al. Expires May 1, 2017 [Page 14]
Internet-Draft October 2016
uses transport-service-paras;
}
}
}
(postamble)
4. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
6. Acknowledgements
7. Normative References
[I-D.ietf-teas-actn-framework]
Ceccarelli, D. and Y. Lee, "Framework for Abstraction and
Control of Traffic Engineered Networks", draft-ietf-teas-
actn-framework-01 (work in progress), October 2016.
[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>.
Authors' Addresses
Pengcheng FU
Huawei Technologies
Email: fupengcheng@huawei.com
Jianzhong FU
Huawei Technologies
Email: fujianzhong@huawei.com
Aijun.Wang
China Telecom
Email: wangaj@ctbri.com.cn
Fu, et al. Expires May 1, 2017 [Page 15]
Internet-Draft October 2016
Ruiquan Jing
China Telecom
Email: jingrq@ctbri.com.cn
Fu, et al. Expires May 1, 2017 [Page 16]