CCAMP Working Group Haomian Zheng
Internet Draft Italo Busi
Intended status: Informational Huawei
Yunbin Xu
CAICT
Ricard Vilalta
CTTC
Expires: April 2018 October 30, 2017
Analysis of Transport North Bound Interface Use Case 3
draft-tnbidt-ccamp-transport-nbi-analysis-uc3-00
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 30, 2018.
Copyright Notice
Copyright (c) 2017 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
Zheng, Busi et al. Expires April 30, 2018 [Page 1]
Internet-Draft T-NBI Use Case 3 Analysis October 2017
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.
Abstract
This document analyses how YANG models being defined by IETF (TEAS
and CCAMP WG in particular) can be used to support Use Case 3 (multi-
domain with single-layer) scenarios as referenced later in this
document.
Table of Contents
1. Introduction...................................................3
1.1. Assumptions...............................................3
1.2. Feedbacks provided to the IETF Working Groups.............3
2. Conventions used in this document..............................3
3. Scenario Overview..............................................3
3.1. Topology Abstractions.....................................4
3.1.1. Single Domain Topology...............................5
3.1.2. Multi-domain Topology Stitching......................6
3.2. Multi-domain Service Configuration........................7
3.2.1. Procedure Description................................7
3.2.2. ODU Transit Service..................................9
3.2.3. EPL over ODU Service.................................9
3.2.4. Other OTN Client Services............................9
3.3. Protection Scenarios......................................9
3.3.1. Linear Protection (end-to-end).......................9
3.3.2. Segmented Protection.................................9
4. Topology Abstraction: detailed JSON examples..................10
5. Service Configuration: detailed JSON examples.................10
5.1. ODU Transit Service......................................10
6. Security Considerations.......................................10
7. IANA Considerations...........................................10
8. Conclusions...................................................10
9. References....................................................10
9.1. Normative References.....................................10
9.2. Informative References...................................11
10. Acknowledgments..............................................11
Zheng, Busi et al. Expires April 30, 2018 [Page 2]
Internet-Draft T-NBI Use Case 3 Analysis October 2017
1. Introduction
This document analyses how YANG models developed by IETF (TEAS and
CCAMP WG) can be used to support Use Case 3 (multi-domain with
single-layer) scenarios as described in [TNBI-UseCases].
1.1. Assumptions
This document is using the ACTN [ACTN-Fwk] as an architecture that
deploys the IETF models. The motivation of this draft is to analyze
how existing IETF models can be used on the MPI between the PNC and
the MDSC to support the use case 3 scenarios as defined in section 6
of [TNBI-UseCases].
This document assumes the applicability of the YANG models to the
ACTN interfaces as defined in [ACTN-YANG] and therefore considers the
TE Topology YANG model defined in [TE-TOPO], with the OTN Topology
augmentation defined in [OTN-TOPO] and the TE Tunnel YANG model
defined in [TE-TUNNEL], with the OTN Tunnel augmentation defined in
[OTN-TUNNEL].
In this document, the assumptions made in section 1 of [TNBI-UseCase-
1] still apply. In summary, it is assumed that 1) MDSC uses the
explicit-route-object list on MPI to specify the ingress/egress links
for a tunnel segment request, and 2) label and TS availability
information are reported from PNC to MDSC.
1.2. Feedbacks provided to the IETF Working Groups
The analysis done in this version of this document has triggered the
following feedbacks to TEAS WG:
o Updates to the plug-id definition in [TE-TOPO] to support plug-id
also when auto-discovery (e.g., LMP based) mechanisms are used on
inter-domain links
2. Conventions used in this document
The conventions defined in section 2 of [TNBI-UseCase-1] still apply
in this document.
3. Scenario Overview
Use Case 3 is described in [TNBI-Use Cases] as a multi-domain with
single layer network scenario supporting different types of services.
This section provides a high-level overview of how IETF YANG models
Zheng, Busi et al. Expires April 30, 2018 [Page 3]
Internet-Draft T-NBI Use Case 3 Analysis October 2017
can be used to support these uses cases at the MPI between the
Transport PNC and the MDSC.
Section 3.1 describes the different topology abstractions provided to
the MDSC by each PNC via its own MPI. The reference network and
controlling hierarchy is defined in section 6.1 of [TNBI-Use Cases].
Section 3.2 describes how the difference services, defined in section
6.3 of [TNBI-UseCases], can be setup by the MDSC by coordinating
requests to each PNC via their own MPIs.
Section 3.3 describes how the protection scenarios can be deployed,
including end-to-end protection and segment protection, for both
intra-domain and inter-domain scenario.
3.1. Topology Abstractions
The reference network is shown in Figure 1, which is the same as
Figure 3 of [TNBI-UseCases]:
Zheng, Busi et al. Expires April 30, 2018 [Page 4]
Internet-Draft T-NBI Use Case 3 Analysis October 2017
........................
.......... : :
: : : Network domain 1 : .............
:Customer: : : : :
:domain 1: : S1 -------+ : : Network :
: : : / \ : : domain 3 : ..........
: C-R1 ------- S3 ----- S4 \ : : : : :
: : : \ \ S2 --------+ : :Customer:
: : : \ \ | : : \ : :domain 3:
: : : S5 \ | : : \ : : :
: C-R2 ------+ / \ \ | : : S31 --------- C-R7 :
: : : \ / \ \ | : : / \ : : :
: : : S6 ---- S7 ---- S8 ------ S32 S33 ------ C-R8 :
: : : / | | : : / \ / : :........:
: C-R3 ------+ | | : :/ S34 :
: : :..........|.......|...: / / :
:........: | | /:.../.......:
| | / /
...........|.......|..../..../...
: | | / / : ..........
: Network | | / / : : :
: domain 2 | | / / : :Customer:
: S11 ---- S12 / : :domain 2:
: / | \ / : : :
: S13 S14 | S15 ------------- C-R4 :
: | \ / \ | \ : : :
: | S16 \ | \ : : :
: | / S17 -- S18 --------- C-R5 :
: | / \ / : : :
: S19 ---- S20 ---- S21 ------------ C-R6 :
: : : :
:...............................: :........:
Figure 1 Reference Topology
The network is portioned in three domains with inter-domain links
connecting the domains with each other. The controlling hierarchy is
shown in Figure 3 of [TNBI-UseCases]: the three PNCs are responsible
for the topology abstraction and device configuration for their
respective domains, and the MDSC is used to coordinate the 3 domains.
3.1.1. Single Domain Topology
Each PNC reports its respective topology to the MDSC with different
abstraction method, as described in section 6.2 of [TNBI-UseCases].
Zheng, Busi et al. Expires April 30, 2018 [Page 5]
Internet-Draft T-NBI Use Case 3 Analysis October 2017
The physical topology of domain 1 and the topology abstraction (i.e.,
white topology abstraction) provided by PNC1 are the same as those
described in section 3.1.1 of [TNBI-UseCase-1] for the single domain
topology abstraction use case.
PNC2 provides a "type A grey topology abstraction": only one abstract
node (i.e., AN2), with only inter-domain and access links, is
reported at the MPI2.
PNC3 provides a "type B grey topology abstraction": two abstract
nodes (i.e., AN31 and AN32), with internal links, inter-domain links
and access links, are reported at the MPI3.
3.1.2. Multi-domain Topology Stitching
As assumed in the beginning of this section, MDSC does not have any
knowledge of the topologies of each domain until each PNC reports its
own abstraction topology, so the MDSC needs to merge together the
abstract topologies provided by different PNCs, at the MPIs, to build
its own topology view, as described in section 4.3 of [TE-TOPO].
Given the topologies reported from multiple PNCs, the MDSC need to
stitch the multi-domain topology and obtain the full map of topology.
The topology of each domain main be in an abstracted shape (refer to
section 5.2 of [ACTN-Fwk]for different level of abstraction), while
the inter-domain link information MUST be complete and fully
configured by the MDSC.
The inter-domain link information is reported to the MDSC by the two
PNCs, controlling the two ends of the inter-domain link.
The MDSC needs to understand how to "stitch" together these inter-
domain links.
One possibility is to use the plug-id information, defined in [TE-
TOPO]: two inter-domain links reporting the same plug-id value can be
merged as a single intra-domain link within any MDSC native topology.
The value of the reported plug-id information can be either assigned
by a central network authority, and configured within the two PNC
domains, or it can be discovered using automatic discovery mechanisms
(e.g., LMP-based, as defined in [RFC6898]).
In case the plug-id values are assigned by a central authority, it is
under the central authority responsibility to assign unique values.
In case the plug-id values are automatically discovered, the
information discovered by the automatic discovery mechanisms needs to
Zheng, Busi et al. Expires April 30, 2018 [Page 6]
Internet-Draft T-NBI Use Case 3 Analysis October 2017
be encoded as a bit string within the plug-id value. This encoding is
implementation specific but the encoding rules need to be consistent
across all the PNCs.
In case of co-existence within the same network of multiple sources
for the plug-id (e.g., central authority and automatic discovery or
even different automatic discovery mechanisms), it is RECOMMENDED
that the plug-id namespace is partitioned to avoid that different
sources assign the same plug-id value to different inter-domain link.
The encoding of the plug-id namespace within the plug-id value is
implementation specific but needs to be consistent across all the
PNCs.
Another possibility is to pre-configure, either in the adjacent PNCs
or in the MDSC, the association between the inter-domain link
identifiers (topology-id, node-id and tp-id) assigned by the two
adjacent PNCs to the same inter-domain link.
This option requires further investigation.
3.2. Multi-domain Service Configuration
Multi-domain service configuration can be found in section 6.3 of
[TNBI-Usecases].
As an example, the objective in this section is to configure a
transport service between C-R1 and C-R5. The cross-domain routing is
assumed to be C-R1 <-> S3 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <->
S18 <-> C-R5.
According to the different client signal type, there is different
adaptation required. In this document, we are trying our best to
reuse what has been defined in [TNBI-UseCase-1], which is the single
domain case.
3.2.1. Procedure Description
The service configuration procedure is assumed to be initiated (step
1 in Figure 2) at the CMI from CNC to MDSC, using XXX(LxSM,
transport-service, VN, TBD) service models. The MDSC will understand
this configure as as a request to setup a service from node A to node
Z. Analysis of the CMI models is for further study.
Zheng, Busi et al. Expires April 30, 2018 [Page 7]
Internet-Draft T-NBI Use Case 3 Analysis October 2017
|
| {1}
V
----------------
| {2} |
| {3} MDSC |
| |
----------------
^ ^ ^
{3.1} | | |
+---------+ |{3.2} |
| | +----------+
| V |
| ---------- |{3.3}
| | PNC2 | |
| ---------- |
| ^ |
V | {4.2} |
---------- V |
| PNC1 | ----- V
---------- (Network) ----------
^ ( Domain 2) | PNC3 |
| {4.1} ( _) ----------
V ( ) ^
----- C==========D | {4.3}
(Network) / ( ) \ V
( Domain 1) / ----- \ -----
( )/ \ (Network)
A===========B \ ( Domain 3)
/ ( ) \( )
AP-1 ( ) X===========Z
----- ( ) \
( ) AP-2
-----
Figure 2 Multi-domain Service Setup
After receiving such request, MDSC determines the domain sequence,
i.e., domain 1 <-> domain 2 <-> domain 3, with corresponding PNCs and
inter-domain links (step 1 in Figure 2).
As described in [PATH-COMPUTE], the domain sequence can be determined
by running the MDSC own path computation on the MDSC internal
topology, defined in section 3.1.2, if and only if the MDSC has
enough topology information. Otherwise the MDSC can send path
computation requests to the different PNCs (steps 2.1, 2.2 and 2.3 in
Zheng, Busi et al. Expires April 30, 2018 [Page 8]
Internet-Draft T-NBI Use Case 3 Analysis October 2017
Figure 2) and use this information to determine the optimal path on
its internal topology and therefore the domain sequence.
The MDSC will then decompose the tunnel request into a few tunnel
segments via tunnel model (including both TE tunnel model and OTN
tunnel model), and request different PNCs to setup each intra-domain
tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 2).
Assume that each intra-domain tunnel segment can be set up
successfully, and each PNC response to the MDSC respectively. Based
on each segment, MDSC will take care of the configuration of both the
intra-domain tunnel segment and inter-domain tunnel via corresponding
MPI (via TE tunnel model and OTN tunnel model). More specifically,
for the inter-domain configuration, the ts bitmap and tpn information
need to be configured via OTN tunnel model. . Then the end-to-end OTN
tunnel will be ready.
In any case, the access link configuration is done only on the PNCs
that control the access links (e.g., PNC-1 and PNC-3 in our example)
and not on the PNCs of transit domain (e.g., PNC-2 in our example).
Access link will be configured by MDSC after the OTN tunnel is set
up. Access configuration is different and dependent on the different
type of service. More details can be found in the following sections.
3.2.2. ODU Transit Service
To be added
3.2.3. EPL over ODU Service
To be added
3.2.4. Other OTN Client Services
To be added
3.3. Protection Scenarios
3.3.1. Linear Protection (end-to-end)
To be added
3.3.2. Segmented Protection
To be added
Zheng, Busi et al. Expires April 30, 2018 [Page 9]
Internet-Draft T-NBI Use Case 3 Analysis October 2017
4. Topology Abstraction: detailed JSON examples
To be added
5. Service Configuration: detailed JSON examples
5.1. ODU Transit Service
To be added
6. Security Considerations
This section is for further study
7. IANA Considerations
This document requires no IANA actions.
8. Conclusions
This section is for further study
9. References
9.1. Normative References
[ACTN-Fwk] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction
and Control of Transport Networks", draft-ietf-teas-actn-
framework, work in progress.
[TNBI-UseCases] Busi, I., King, D. et al, "Transport Northbound
Interface Use Cases", draft-ietf-ccamp-transport-nbi-use-
cases, work in progress.
[TNBI-UseCase-1] Busi, I., King, D. et al, "Analysis of Transport
North Bound Interface Use Case 1", draft-tnbidt-ccamp-
transport-nbi-analysis-uc1, work in progress.
[TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", draft-
ietf-teas-yang-te-topo, work in progress.
[OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical Transport
Network Topology", draft-ietf-ccamp-otn-topo-yang, work in
progress.
Zheng, Busi et al. Expires April 30, 2018 [Page 10]
Internet-Draft T-NBI Use Case 3 Analysis October 2017
[TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
te, work in progress.
[PATH-COMPUTE] Busi, I., Belotti, S. et al, "Yang model for
requesting Path Computation", draft-busibel-teas-yang-path-
computation, work in progress.
[OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft-
sharma-ccamp-otn-tunnel-model, work in progress.
9.2. Informative References
[RFC6898] Li, D. et al., "Link Management Protocol Behavior
Negotiation and Configuration Modifications", RFC 6898,
March 2013.
[ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for
Abstraction and Control of Traffic Engineered Networks",
draft-zhang-teas-actn-yang, work in progress.
[I2RS-TOPO] Clemm, A. et al., "A Data Model for Network Topologies",
draft-ietf-i2rs-yang-network-topo, work in progress.
10. Acknowledgments
The authors would like to thank all members of the Transport NBI
Design Team involved in the definition of use cases, gap analysis and
guidelines for using the IETF YANG models at the Northbound Interface
(NBI) of a Transport SDN Controller.
The authors would like to thank Xian Zhang, Anurag Sharma, Sergio
Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar
Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated
the work on gap analysis for transport NBI and having provided
foundations work for the development of this document.
The authors would like to thank the authors of the TE Topology and
Tunnel YANG models [TE-TOPO] and [TE-TUNNEL], in particular Igor
Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their
support in addressing any gap identified during the analysis work.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Zheng, Busi et al. Expires April 30, 2018 [Page 11]
Internet-Draft T-NBI Use Case 3 Analysis October 2017
Haomian Zheng (Editor)
Huawei
Email: zhenghaomian@huawei.com
Italo Busi
Huawei
Email: italo.busi@huawei.com
Yunbin Xu (Editor)
CAICT
Email: xuyunbin@ritt.cn mailto:d.king@lancaster.ac.uk
Ricard Vilalta
CTTC
Email: ricard.vilalta@cttc.es
Carlo Perocchio
Ericsson
Email: carlo.perocchio@ericsson.com
Gianmarco Bruno
Ericsson
Email: gianmarco.bruno@ericsson.com
Zheng, Busi et al. Expires April 30, 2018 [Page 12]