Analysis of Transport North Bound Interface Use Case 1
draft-tnbidt-ccamp-transport-nbi-analysis-uc1-00
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 | Italo Busi , Daniel King | ||
| Last updated | 2017-07-03 | ||
| 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-tnbidt-ccamp-transport-nbi-analysis-uc1-00
CCAMP Working Group I. Busi (Ed.)
Internet Draft Huawei
Intended status: Informational D. King (Ed.)
Lancaster University
Expires: January 2018 July 3, 2017
Analysis of Transport North Bound Interface Use Case 1
draft-tnbidt-ccamp-transport-nbi-analysis-uc1-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 December 3, 2017.
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
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
Busi, King et al. Expires January 3, 2018 [Page 1]
Internet-Draft T-NBI Use Case 1 Analysis July 2017
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 1
(single-domain with single-layer) scenarios as referenced later in
this document.
Table of Contents
1. Introduction...................................................2
1.1. Assumptions...............................................3
1.2. Feedbacks provided to the IETF Working Groups.............3
2. Conventions used in this document..............................4
3. High-level Overview............................................5
3.1. Topology Abstraction......................................5
3.1.1. ODU White Topology Abstraction.......................5
3.2. Service Configuration.....................................7
3.2.1. ODU Transit Service..................................7
3.2.2. OTN Client Private Line Service......................9
3.2.3. EPL over ODU Service.................................9
4. Topology Abstraction: detailed JSON examples..................10
4.1. ODU White Topology Abstraction...........................10
5. Service Configuration: detailed JSON examples.................10
5.1. ODU Transit Service......................................10
6. Security Considerations.......................................10
7. IANA Considerations...........................................10
8. Conclusions...................................................11
9. References....................................................11
9.1. Normative References.....................................11
9.2. Informative References...................................11
10. Acknowledgments..............................................11
Appendix A. Validating a JSON fragment against a YANG Model......13
A.1. DSDL-based approach......................................13
A.2. Why not using a XSD-based approach.......................13
A.3. JSON Code: use-case-1-topology-01.json...................14
A.4. JSON Code: use-case-1-odu2-service-01.json...............14
1. Introduction
This document analyses how YANG models being developed by IETF (TEAS
and CCAMP WG) can be used to support Use Case 1 (single-domain with
single-layer) scenarios as described in [TNBI- UseCases].
Busi, King et al. Expires January 3, 2018 [Page 2]
Internet-Draft T-NBI Use Case 1 Analysis July 2017
1.1. Assumptions
This document is analyzing how existing models developed by the IETF
can be used at the MPI between the Transport PNC and the MDSC to
support the use case 1 scenarios as defined in section 3 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].
The analysis of how to use the attributes in the I2RS Topology YANG
model, defined in [I2RS-TOPO], is for further study.
Moreover this document is making the following assumptions, still to
be validated with TEAS WG:
1. The MDSC can request, at the MPI, the Transport PNC to setup a
Transit Tunnel Segment using the TE Tunnel YANG model: in this
case, since the endpoints of the E2E Tunnel are outside the domain
controlled by the Transport PNC, the MDSC would not specify any
source or destination TTP (i.e., it would leave the source,
destination, src-tp-id and dst-tp-id attributes empty) and it
would use the explicit-route-object list to specify the ingress
and egress links of the Transit Tunnel Segment.
2. The Transport PNC provides to the MDSC, at the MPI, the list of
available timeslots on the access links using the TE Topology YANG
model and OTN Topology augmentation. The TE Topology YANG model in
[TE-TOPO] is being updated to report the label set information.
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 On-going discussion about how to use the TE Tunnel YANG model in
[TE-TUNNEL] to support tunnel segments.
o Need to change TE Tunnel YANG model in [TE-TUNNEL] to clarify that
the router-id and interface-id attributes in the unnumbered
explicit-route-object corresponds to the te-node-id and te-tp-id
attributes identifying an LTP in the TE Topology YANG model.
Busi, King et al. Expires January 3, 2018 [Page 3]
Internet-Draft T-NBI Use Case 1 Analysis July 2017
o Need to add information about the label set (e.g., list of
available timeslots) in the TE Topology and TE Tunnel YANG models.
o Some detailed fixes to the TE Tunnel YANG model in [TE-TUNNEL]
have also been identified during the validation of the JSON
examples against the TE Tunnel YANG model.
2. Conventions used in this document
This document provides some detailed JSON code examples to describe
how the YANG models being developed by IETF (TEAS and CCAMP WG in
particular) can be used.
The examples are provided using JSON because JSON code is easier for
humans to read and write.
Different objects need to have an identifier. The convention used to
create mnemonic identifiers is to use the object name (e.g., S3 for
node S3), followed by its type (e.g., NODE), separated by an "-",
followed by "-ID". For example the mnemonic identifier for node S3
would be S3-NODE-ID.
JSON language does not support the insertion of comments that have
been instead found to be useful when writing the examples. This
document inserts comments into the JSON code as JSON name/value pair
with the JSON name string starting with the "//" characters. For
example, when describing the example of a TE Topology instance
representing the ODU Abstract Topology exposed by the Transport PNC,
the following comment has been added to the JSON code:
"// comment": "ODU Abstract Topology @ MPI",
The JSON code examples provided in this document have been validated
against the YANG models following the validation process described in
Appendix A, which would not consider the comments.
In order to have successful validation of the examples, some
numbering scheme has been defined to assign identifiers to the
different entities which would pass the syntax checks. In that case,
to simplify the reading, another JSON name/value pair, formatted as a
comment and using the mnemonic identifiers is also provided. For
example, the identifier of node S3 (S3-NODE-ID) has been assumed to
be "10.0.0.3" and would be shown in the JSON code example using the
two JSON name/value pair:
"// te-node-id": "S3-NODE-ID",
Busi, King et al. Expires January 3, 2018 [Page 4]
Internet-Draft T-NBI Use Case 1 Analysis July 2017
"te-node-id": "10.0.0.3",
The first JSON name/value pair will be automatically removed in the
first step of the validation process while the second JSON name/value
pair will be validate against the YANG model definitions.
3. High-level Overview
Use Case 1 is described in [TNBI-UseCases] as a single-domain with
single layer network scenario supporting different types of services.
This section provides an high-level overview of how IETF YANG models
can be used to support these uses cases at the MPI between the
Transport PNC and the MDSC.
Section 3.1 describes the topology abstraction provided to the MDSC
by the Transport PNC at the MPI.
Section 3.2 describes how the difference services, defined in section
3.3 of [TNBI-UseCases], can be requested to the Transport PNC by the
MDSC at the MPI.
3.1. Topology Abstraction
3.1.1. ODU White Topology Abstraction
In case the Transport PNC exports to the MDSC a white topology, at
the MPI there will be one TE Topology instance for the ODU layer
(called "ODU Topology") containing one TE Node (called "ODU Node")
for each physical node, as shown in Figure 1 below.
Busi, King et al. Expires January 3, 2018 [Page 5]
Internet-Draft T-NBI Use Case 1 Analysis July 2017
..................................
: :
: ODU Abstract Topology @ MPI :
: :
: +----+ +----+ :
: | | | | :
: | S1 |--------| S2 |- - - - -(C-R4)
: +----+ +----+ :
: / | :
: / | :
: +----+ +----+ | :
: | | | | | :
(C-R1)- - - - -| S3 |---| S4 | | :
:S3-1+----+ +----+ | :
: \ \ | :
: \ \ | :
: +----+ \ | :
: | | \ | :
: | S5 | \ | :
: +----+ \ | :
(C-R2)- - - - - / \ \ | :
:S6-1 \ / \ \ | :
: +----+ +----+ +----+ :
: | | | | | | :
: | S6 |---| S7 |---| S8 |- - - - -(C-R5)
: +----+ +----+ +----+ :
: / :
(C-R3)- - - - - :
:S6-2 :
:................................:
Figure 1 White Topology Abstraction (ODU Topology)
The ODU Nodes in Figure 1 are using with the same names as the
physical nodes to simplify the description of the mapping between the
ODU Nodes exposed by the Transport PNCs at the MPI and the physical
nodes in the data plane.
As described in section 3.2 of [TNBI-UseCases], it is assumed that
the physical links between the physical nodes are pre-configured up
to the OTU4 trail using mechanisms which are outside the scope of
this document. The Transport PNC exports to the MDSC via the MPI, one
TE Link (called "ODU Link") for each of these physical links.
Access links in Figure 1 are shown as ODU Links: the modeling of the
access links for other access technologies is currently an open
issue.
Busi, King et al. Expires January 3, 2018 [Page 6]
Internet-Draft T-NBI Use Case 1 Analysis July 2017
The "external-domain" container allows the MDSC to glue together the
ODU Topology provided by the Transport PNC with the information
provided by the IP PNC to know which access link is connected with
each link/router in the IP domain (e.g., that C-R1 is connected with
the access link terminating on S3-1 LTP in the ODU Topology).
3.2. Service Configuration
3.2.1. ODU Transit Service
In this case, the access links are configured as ODU Link, as
described in section 3.1.1 above.
As described in section 3.3.1 of [TNBI-UseCases], the MDSC needs to
setup an ODU2 trail, supporting an IP link, between C-R1 and C-R3.
From the topology information described in section 3.1.1 above, the
MDSC can know that C-R1 is attached to the access link terminating on
S3-1 LTP in the ODU Topology and that C-R3 is attached to the access
link terminating on S6-2 LTP in the ODU Topology.
Based on the assumption 1) in section Error! Reference source not
found., MDSC would then request Transport PNC to setup an ODU2
(Transit Segment) Tunnel between S3-1 and S6-2 LTPs:
o Source and Destination TTP are not specified (since it is a
Transit Tunnel)
o Ingress and egress points are indicated in the explicit-route-
objects of the primary path:
o The first element of the explicit-route-objects references the
access link terminating on S3-1 LTP
o Last element of the explicit-route-objects references the
access link terminating on S6-2 LTP
The configuration of the timeslots used by the ODU2 connection within
the transport network domain (i.e., on the internal links) is a
matter of the Transport PNC and its interactions with the physical
network elements and therefore is outside the scope of this document.
However, the configuration of the timeslots used by the ODU2
connection at the edge of the transport network domain (i.e., on the
access links) needs to take into account not only the timeslots
available on the physical nodes at the edge of the transport network
domain (e.g., S3 and S6) but also on the devices, outside of the
Busi, King et al. Expires January 3, 2018 [Page 7]
Internet-Draft T-NBI Use Case 1 Analysis July 2017
transport network domain, connected through these access links (e.g.,
C-R1 and C-R3).
Based on the assumption 2) in section Error! Reference source not
found., MDSC, when requesting the Transport PNC to setup the (Transit
Segment) ODU2 Tunnel, it would also configure the timeslots to be
used on the access links. The MDSC can known the timeslots which are
available on the edge OTN Node (e.g., S3 and S6) from the OTN
Topology information exposed by the Transport PNC at the MPI as well
as the timeslots which are available on the devices, outside of the
transport network domain, connected through these access links (e.g.,
C-R1 and C-R3) by means which are outside the scope of this document.
The Transport PNC performs path computation and sets up the ODU2
cross-connections within the physical nodes S3, S5 and S6, as shown
in section 4.3.1 of [TNBI-UseCases].
The Transport PNC reports the status of the created ODU2 (Transit
Segment) Tunnel and its path within the ODU Topology as shown in
Figure 2 below:
Busi, King et al. Expires January 3, 2018 [Page 8]
Internet-Draft T-NBI Use Case 1 Analysis July 2017
..................................
: :
: ODU Abstract Topology @ MPI :
: :
: +----+ +----+ :
: | | | | :
: | S1 |--------| S2 |- - - - -(C-R4)
: +----+ +----+ :
: / | :
: / | :
: +----+ +----+ | :
: | | | | | :
(C-R1)- - - - - S3 |---| S4 | | :
:S3-1 <<== + +----+ | :
: = \ | :
: = \ \ | :
: == ---+ \ | :
: = | \ | :
: = S5 | \ | :
: == --+ \ | :
(C-R2)- - - - - = \ \ | :
:S6-1 \ / = \ \ | :
: +--- = +----+ +----+ :
: | = | | | | :
: | S6 = --| S7 |---| S8 |- - - - -(C-R5)
: +--- = +----+ +----+ :
: / = :
(C-R3)- - - - - <<=== :
:S6-2 :
:................................:
Figure 2 ODU2 Transit Tunnel
3.2.2. OTN Client Private Line Service
To be added
3.2.3. EPL over ODU Service
To be added
Busi, King et al. Expires January 3, 2018 [Page 9]
Internet-Draft T-NBI Use Case 1 Analysis July 2017
4. Topology Abstraction: detailed JSON examples
4.1. ODU White Topology Abstraction
Section 3.1.1 describes how the Transport PNC can provide a white
topology abstraction to the MDSC via the MPI. Figure 1 is an example
of such ODU Topology.
This section provides the detailed JSON code describing this ODU
Topology, using the [TE-TOPO] and [OTN-TOPO] YANG models.
Note that this example is based on -09 version of [TE-TOPO] and on
the -00 version of [OTN-TOPO]. Further changes to align with latest
updates of these YANG models will be provided in the future version
of this document.
JSON code "use-case-1-topology-01.json" has been provided at in the
appendix of this document.
5. Service Configuration: detailed JSON examples
5.1. ODU Transit Service
Section 3.2.1 describes how the MDSC can request a Transport PNC, via
the MPI, to setup an ODU2 transit service over an ODU Topology
described in section 3.1.1.
This section provides the detailed JSON code describing this ODU
Topology, using the [TE-TUNNEL] and [OTN-TUNNEL] YANG models.
Note that this example is based on -06 version of [TE-TUNNEL] and on
the -02 version of [OTN-TUNNEL]. Further changes to align with latest
updates of these YANG models will be provided in the future version
of this document.
JSON code "use-case-1-odu2-service-01.json" has been provided at in
the appendix of this document.
6. Security Considerations
This section is for further study
7. IANA Considerations
This document requires no IANA actions.
Busi, King et al. Expires January 3, 2018 [Page 10]
Internet-Draft T-NBI Use Case 1 Analysis July 2017
8. Conclusions
This section is for further study
9. References
9.1. Normative References
[TNBI-UseCases] Busi, I., King, D. et al, "Transport Northbound
Interface Use Cases", draft-tnbidt-ccamp-transport-nbi-use-
cases, 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.
[TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
te, 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
[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
Busi, King et al. Expires January 3, 2018 [Page 11]
Internet-Draft T-NBI Use Case 1 Analysis July 2017
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.
Busi, King et al. Expires January 3, 2018 [Page 12]
Internet-Draft T-NBI Use Case 1 Analysis July 2017
Appendix A. Validating a JSON fragment against a YANG Model
The objective is to have a tool that allows validating whether a
piece of JSON code is compliant with a YANG model without using a
client/server.
A.1. DSDL-based approach
The idea is to generate a JSON driver file (JTOX) from YANG, then use
it to translate JSON to XML and validate it against the DSDL schemas,
as shown in Figure 3.
Useful link: https://github.com/mbj4668/pyang/wiki/XmlJson
(2)
YANG-module ---> DSDL-schemas (RNG,SCH,DSRL)
| |
| (1) |
| |
Config/state JTOX-file | (4)
\ | |
\ | |
\ V V
JSON-file------------> XML-file ----------------> Output
(3)
Figure 3 - DSDL-based approach for JSON code validation
In order to allow the use of comments following the convention
defined in section 0 without impacting the validation process, these
comments will be automatically removed from the JSON-file that will
be validate.
A.2. Why not using a XSD-based approach
This approach has been analyzed and discarded because no longer
supported by pyang.
The idea is to convert YANG to XSD, JSON to XML and validate it
against the XSD, as shown in Figure 4:
Busi, King et al. Expires January 3, 2018 [Page 13]
Internet-Draft T-NBI Use Case 1 Analysis July 2017
(1)
YANG-module ---> XSD-schema - \ (3)
+--> Validation
JSON-file------> XML-file ----/
(2)
Figure 4 - XSD-based approach for JSON code validation
The pyang support for the XSD output format was deprecated in 1.5 and
removed in 1.7.1. However pyang 1.7.1 is necessary to work with YANG
1.1 so the process shown in Figure 4 will stop just at step (1).
A.3. JSON Code: use-case-1-topology-01.json
The JSON code for this use case is currently located on GitHub at:
https://github.com/danielkinguk/transport-nbi/blob/master/Internet
-Drafts/Use-Case-1-Analysis/use-case-1-topology-01.json
A.4. JSON Code: use-case-1-odu2-service-01.json
The JSON code for this use case is currently located on GitHub at:
https://github.com/danielkinguk/transport-nbi/blob/master/Internet
-Drafts/Use-Case-1-Analysis/use-case-1-odu2-service-01.json
Busi, King et al. Expires January 3, 2018 [Page 14]
Internet-Draft T-NBI Use Case 1 Analysis July 2017
Authors' Addresses
Italo Busi (Editor)
Huawei
Email: italo.busi@huawei.com
Daniel King (Editor)
Lancaster University
Email: d.king@lancaster.ac.uk
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Gianmarco Bruno
Ericsson
Email: gianmarco.bruno@ericsson.com
Carlo Perocchio
Ericsson
Email: carlo.perocchio@ericsson.com
Busi, King et al. Expires January 3, 2018 [Page 15]