draft-ietf-ccamp-layer1-types-06.txt   draft-ietf-ccamp-layer1-types-07.txt 
CCAMP Working Group H. Zheng CCAMP Working Group H. Zheng
Internet-Draft I. Busi Internet-Draft I. Busi
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: November 14, 2020 May 13, 2020 Expires: March 25, 2021 September 21, 2020
A YANG Data Model for Layer 1 Types A YANG Data Model for Layer 1 Types
draft-ietf-ccamp-layer1-types-06 draft-ietf-ccamp-layer1-types-07
Abstract Abstract
This document defines a collection of common data types and groupings This document defines a collection of common data types and groupings
in YANG data modeling language for layer 1 networks. These derived in the YANG data modeling language for use with layer 1 networks.
common types and groupings are intended to be imported by modules These derived common types and groupings are intended to be imported
that specifies the OTN networks, including the topology, tunnel, by modules that specify OTN networks, such as topology, tunnel,
client signal adaptation and service. client signal adaptation and service.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 November 14, 2020. This Internet-Draft will expire on March 25, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . 31 10.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Examples of OTN Label Ranges . . . . . . . . . . . . 32 Appendix A. Examples of OTN Label Ranges . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This document introduces a collection of common data types which This document specifies common data types for use in YANG [RFC7950]
would be used in Layer 1 networks. The derived types and groupings data models of Layer 1 networks. The derived types and groupings are
are designed to be the common types applicable for modeling Traffic types applicable to modeling Traffic Engineering (TE) for Layer 1
Engineering (TE) features for Layer 1 networks. networks.
Typical Layer 1 network, the Optical Transport Networking, was The Optical Transport Networking, a typical Layer 1 network, is
specified in [RFC7062]. Corresponding routing and signaling protocol specified in [RFC7062]. The corresponding routing and signaling
have been specified in [RFC7138] and [RFC7139]. The types and protocol are specified in [RFC7138] and [RFC7139]. The types and
groupings defined in this document is consistent to these document, groupings defined in this document are consistent to those documents,
and will be imported in other Layer 1 data models, including but not and can be imported into other Layer 1 data models, including but not
restrictive to, [I-D.ietf-ccamp-otn-topo-yang], limited to, [I-D.ietf-ccamp-otn-topo-yang],
[I-D.ietf-ccamp-otn-tunnel-model], [I-D.ietf-ccamp-otn-tunnel-model],
[I-D.ietf-ccamp-client-signal-yang] and [I-D.ietf-ccamp-l1csm-yang]. [I-D.ietf-ccamp-client-signal-yang] and [I-D.ietf-ccamp-l1csm-yang].
The data model in this draft has only types defined including The data model in this draft only defines groupings, typedef and
groupings, typedef and identities. There is no need to include identities. There is no configuration or state data as specified in
configuration and state data according to the new Network Management the Network Management Datastore Architecture [RFC8342]. The
Datastore Architecture [RFC8342]. The content in this draft is in document is consistent with other specifications, including [MEF63]
consistent with other specifications, including [MEF63] for Layer 1 for Layer 1 service attributes, [ITU-Tg709] and [ITU-Tgsup43] for OTN
service attributes, [ITU-Tg709] and [ITU-Tgsup43] for OTN data plane data plane definitions.
definitions.
2. Terminology and Notations 2. Terminology and Notations
Refer to [RFC7062] for the key terms used in this document, and the Refer to [RFC7062] for the key terms used in this document. The
terminology for describing YANG data models can be found in terminology for describing YANG data models can be found in
[RFC7950]. [RFC7950].
3. Prefix in Data Node Names 3. Prefix in Data Node Names
In this document, names of data nodes and other data model objects In this document, names of data nodes and other data model objects
are prefixed using the standard prefix associated with the are prefixed using the standard prefix associated with the
corresponding YANG imported modules. corresponding YANG imported modules.
+-------------+---------------------------+----------------------+ +-------------+---------------------------+----------------------+
| Prefix | YANG module | Reference | | Prefix | YANG module | Reference |
+-------------+---------------------------+----------------------+ +-------------+---------------------------+----------------------+
| l1-types | ietf-layer1-types | This Document | | l1-types | ietf-layer1-types | This Document |
+-------------+---------------------------+----------------------+ +-------------+---------------------------+----------------------+
4. Layer 1 Types Overview 4. Layer 1 Types Overview
4.1. Relationship with other Modules 4.1. Relationship with other Modules
This document defines one YANG module for common Layer 1 types. The This document defines one YANG module for common Layer 1 types. The
objective is to specifies common Layer 1 TE types that can be aim is to specify common Layer 1 TE types (i.e. typedef, identity,
imported by layer 1 specific technology, for example OTN, in its grouping) that can be imported by layer 1 specific technology, for
technology-specific modules such as topology and tunnels. It is example OTN, in its technology-specific modules, such as topology and
worth noting that the generic traffic-engineering (TE) types module tunnels. It is worth noting that the generic traffic-engineering
is specified in [I-D.ietf-teas-yang-te-types] as ietf-te-types, and (TE) types module is specified in [RFC8776] as ietf-te-types, and
both the module ietf-te-types and ietf-layer1-types are needed to be both YANG modules, ietf-te-types and ietf-layer1-types, will need
imported when the OTN is configured. Generic attributes such as te- importing when the OTN is configured. Generic attributes such as te-
bandwidth and te-label, are indicated in ietf-te-types in bandwidth and te-label, are specified in ietf-te-types in [RFC8776],
[I-D.ietf-teas-yang-te-types], while the OTN-specific attributes, while the OTN-specific attributes, such as odu-type, are specified in
such as odu-type, are indicated in ietf-layer1-types in this ietf-layer1-types in this document.
document.
4.2. Content in Layer 1 Type Module 4.2. Content in Layer 1 Type Module
The module ietf-layer1-types contains the following YANG reusable The module ietf-layer1-types contains the following YANG reusable
types and groupings: types and groupings:
tributary-slot-granularity: tributary-slot-granularity:
This is to define the granularity of the server layer ODU Link (HO This specifies the granularity of the server layer ODU Link (HO ODUk
ODUk or ODUCn) supporting a client layer ODU LSP (LO ODUj or ODUk, or ODUCn) supporting a client layer ODU LSP (LO ODUj or ODUk,
respectively). Three granularities, 1.25G/2.5G/5G, have been respectively). Three granularities, 1.25G/2.5G/5G, have been
specified. specified.
odu-type: odu-type:
This is to specify the type of ODUk LSP, including the types This specifies the type of ODUk LSP, including the types specified in
specified in [RFC7139] and [RFC7963]. [RFC7139] and [RFC7963].
client-signal: client-signal:
This is to specify the client signal types of OTN networks. The This specifies the client signal types of OTN networks. The initial
initial input was the G-PID specified in [RFC7139]. Identities about input was the G-PID specified in [RFC7139]. Identities for some of
a few categories of client signal types, including ETH, STM-n, OC the categories of client signal types, including ETH, STM-n, OC
[Telcordia] and Fiber Channel have been specified. [Telcordia] and Fiber Channel, have been specified.
otn-label-range-type: otn-label-range-type:
The label range type of OTN has two different representations, The label range type of OTN is represented in one of two ways,
tributary slots (TS) and tributary port number (TPN), according to tributary slots (TS) and tributary port number (TPN), as specified in
[RFC7139]. Respective representation is specified under this same [RFC7139]. Two representations are enumerated in the otn-label-
base type. range-type.
otn-link-bandwidth: otn-link-bandwidth:
This grouping defines the link bandwidth information and could be This grouping defines the link bandwidth information and could be
used in OTN topology model for bandwidth representation. All the used in OTN topology model for link bandwidth representation. All
bandwidth related sections in generic module, the bandwidth related sections in generic module, [RFC8776], need to
[I-D.ietf-teas-yang-te-types], need to be augmented with this be augmented with this grouping for the usage of Layer 1.
grouping for the usage of Layer 1.
otn-path-bandwidth: otn-path-bandwidth:
This grouping defines the path bandwidth information and could be This grouping defines the path bandwidth information and could be
used in OTN topology model for bandwidth representation. All the used in OTN topology model for path bandwidth representation. All
bandwidth related sections in generic module, the bandwidth related sections in generic module, [RFC8776], need to
[I-D.ietf-teas-yang-te-types], need to be augmented with this be augmented with this grouping for the usage of Layer 1. This
grouping for the usage of Layer 1. This grouping is also applicable grouping is also applicable when setting up the OTN tunnel.
to set up the OTN tunnel.
otn-label-range-info and otn-label-step: otn-label-range-info and otn-label-step:
These groupings are used for the augmentation of OTN label in a These groupings are used to augment an OTN label with type,
specific way. granularity, priority and ODU types.
otn-label-start-end and otn-label-hop: otn-label-start-end and otn-label-hop:
These groupings are used for the augmentation of label for OTN link These groupings are used to augment a label for an OTN link and path
and path respectively. respectively.
optical-interface-func: optical-interface-func:
The optical interface function is specified in [MEF63]. This The optical interface function is specified in [MEF63]. This
grouping describes the functionality which encodes bits for grouping describes the functionality which encodes bits for
transmission and the corresponding decode upon reception. transmission and decodes bits upon reception.
service-performance-metric: service-performance-metric:
The service performance metric is a quantitative characterization of The service performance metric is a quantitative characterization of
Layer 1 characteristic information delivery quality experienced by the quality of the delivery of Layer 1 characteristic information as
the Layer 1 subscriber. experienced by the Layer 1 subscriber.
4.3. OTN Label and Label Range 4.3. OTN Label and Label Range
As described in [RFC7139], the OTN label usually represents the As described in [RFC7139], the OTN label usually represents the
Tributary Port Number (TPN) and the related set of Tributary Slots Tributary Port Number (TPN) and the related set of Tributary Slots
(TS) assigned to a client layer ODU LSP (LO ODUj or ODUk) on a given (TS) assigned to a client layer ODU LSP (LO ODUj or ODUk) on a given
server layer ODU (HO-ODU or ODUCn, respectively) Link (e.g., ODU2 LSP server layer ODU (HO-ODU or ODUCn, respectively) Link (e.g., ODU2 LSP
over ODU3 Link). Some special OTN label values are also defined for over ODU3 Link). Some special OTN label values are also defined for
an ODUk LSP being setup over an OTUk Link. an ODUk LSP being set up over an OTUk Link.
The same OTN label shall be assigned to the same ODUk LSP at the two The same OTN label must be assigned to the same ODUk LSP at the two
ends of an OTN Link. ends of an OTN Link.
As described in [RFC7139], TPN can be a number from 1 to 4095 and TS As described in [RFC7139], TPN can be a number from 1 to 4095 and TS
are numbered from 1 to 4095, although the actual maximum values are numbered from 1 to 4095, although the actual maximum values
depend on the type of server layer ODU. For example, a server layer depend on the type of server layer ODU. For example, a server layer
ODU4 provides 80 time slots (numbered from 1 to 80) and the TPN ODU4 provides 80 time slots (numbered from 1 to 80) and the TPN
values can be any number from 1 to 80. values can be any number from 1 to 80.
The OTN Label Range represents the values for the TPN and TS that are The OTN Label Range represents the values for the TPN and TS that are
available for ODUk LSPs to be setup over a given OTN Link. available for ODUk LSPs to be setup over a given OTN Link.
The OTN Label Range is defined by the label-restriction list, defined The OTN Label Range is defined by the label-restriction list, defined
in [I-D.ietf-teas-yang-te-types], which, for OTN, should be augmented in [RFC8776], which, for OTN, should be augmented using the otn-
using the otn-label-range-info grouping. label-range-info grouping.
Each entry in the label-restriction list represents either the range Each entry in the label-restriction list represents either the range
of the available TPN values or the range of the available TS values: of the available TPN values or the range of the available TS values:
the range-type attribute in the otn-label-range-info grouping defines the range-type attribute in the otn-label-range-info grouping defines
the type of range for each entry of the list. the type of range for each entry of the list.
Each entry of the label-restriction list, as defined in Each entry of the label-restriction list, as defined in [RFC8776],
[I-D.ietf-teas-yang-te-types], defines a label-start, a label-end, a defines a label-start, a label-end, a label-step and a range-bitmap.
label-step and a range-bitmap. The label-start and label-end The label-start and label-end definitions for OTN should be augmented
definitions for OTN should be augmented using the otn-label-start-end using the otn-label-start-end grouping. The label-step definition
grouping. The label-step definition for OTN should be augmented for OTN should be augmented using the otn-label-step grouping. It is
using the otn-label-step grouping. It is expected that the otn- expected that the otn-label-step will always be equal to its default
label-step will always be equal to its default value (i.e., 1), which value (i.e., 1), which is defined in [RFC8776].
is defined in [I-D.ietf-teas-yang-te-types].
As described in [RFC7139], in some cases, the TPN assignment rules is As described in [RFC7139], in some cases, the TPN assignment rules
flexible (e.g., ODU4 Link) while in other cases the TPN assignment are flexible (e.g., ODU4 Link) while in other cases the TPN
rules are fixed (e.g., ODU1 Link). In the former case, both TPN and assignment rules are fixed (e.g., ODU1 Link). In the former case,
TS ranges are reported, while in the latter case, the TPN range is both TPN and TS ranges are reported, while in the latter case, the
not reported to indicate that the TPN shall be set equal to the TS TPN range is not reported which indicates that the TPN shall be set
number assigned to the ODUk LSP. equal to the TS number assigned to the ODUk LSP.
As described in [RFC7139], in some cases, the TPN assignment rules As described in [RFC7139], in some cases, the TPN assignment rules
depends on the TS Granularity (e.g., ODU2 or ODU3 Links). Different depends on the TS Granularity (e.g., ODU2 or ODU3 Links). Different
entries in the label-restriction list will report different TPN entries in the label-restriction list will report different TPN
ranges for each TS granularity supported by the link, as indicated by ranges for each TS granularity supported by the link, as indicated by
the tsg attribute in the otn-label-range-info grouping. the tsg attribute in the otn-label-range-info grouping.
As described in [RFC7139], in some cases, the TPN ranges are As described in [RFC7139], in some cases the TPN ranges are different
different for different types of ODUk LSPs. For example, on an ODU2 for different types of ODUk LSPs. For example, on an ODU2 Link with
Link with 1,25G TS granularity, there is TPN range 1-4 for ODU1 and 1.25G TS granularity, the TPN range is 1-4 for ODU1 but 1-8 for ODU0
another TPN range 1-8 in common for ODU0 and ODUflex. Different and ODUflex. Different entries in the label-restriction list will
entries in the label-restriction list will report different TPN report different TPN ranges for different set of ODUk types, as
ranges for different set of ODUk types, as indicated by the odu-type- indicated by the odu-type-list in the otn-label-range-info grouping.
list in the otn-label-range-info grouping.
Appendix A provides some examples of how the TPN and TS label ranges Appendix A provides some examples of how the TPN and TS label ranges
described in Table 3 and Table 4 of [RFC7139] can be represented in described in Table 3 and Table 4 of [RFC7139] can be represented in
YANG using the groupings defined in this document. YANG using the groupings defined in this document.
4.4. ODUflex 4.4. ODUflex
ODUflex is a type of ODU which has a flexible bit rate which should ODUflex is a type of ODU which has a flexible bit rate which is
be configured when setting up an ODUflex LSP. configured when setting up an ODUflex LSP.
[ITU-Tg709], defines six types of ODUflex: ODUflex(CBR), [ITU-Tg709], defines six types of ODUflex: ODUflex(CBR),
ODUflex(GFP), ODUflex(GFP,n,k), ODUflex(IMP), ODUflex(IMP,s) and ODUflex(GFP), ODUflex(GFP,n,k), ODUflex(IMP), ODUflex(IMP,s) and
ODUflex(FlexE-aware). ODUflex(FlexE-aware).
The main difference between these types of ODUflex is the formula The main difference between these types of ODUflex is the formula
used to calculate the nominal bit rate of the ODUflex, as described used to calculate the nominal bit rate of the ODUflex, as described
in Table 7-2 of [ITU-Tg709]. A choice has been defined to describe in Table 7-2 of [ITU-Tg709]. A YANG choice has been defined to
these cases: describe these cases:
+--rw (oduflex-type)? +--rw (oduflex-type)?
+--:(generic) +--:(generic)
| +--rw nominal-bit-rate uint64 | +--rw nominal-bit-rate uint64
+--:(cbr) +--:(cbr)
| +--rw client-type identityref | +--rw client-type identityref
+--:(gfp-n-k) +--:(gfp-n-k)
| +--rw gfp-n uint8 | +--rw gfp-n uint8
| +--rw gfp-k? l1-types:gfp-k | +--rw gfp-k? l1-types:gfp-k
+--:(flexe-client) +--:(flexe-client)
| +--rw flexe-client | +--rw flexe-client
| l1-types:flexe-client-rate | l1-types:flexe-client-rate
+--:(flexe-aware) +--:(flexe-aware)
| +--rw flexe-aware-n uint16 | +--rw flexe-aware-n uint16
+--:(packet) +--:(packet)
+--rw opuflex-payload-rate uint64 +--rw opuflex-payload-rate uint64
The (generic) case has been added to allow defining the ODUflex The 'generic' case has been added to allow the ODUflex nominal bit
nominal bit rate independently from the type of ODUflex. This could rate to be defined independently from the type of ODUflex. This
be useful for forward compatibility in the transit domain/nodes where could be useful for forward compatibility in the transit domain/nodes
the setup of ODUflex LSPs does not depend from the ODUflex type. where the setup of ODUflex LSPs does not depend on the ODUflex type.
In order to simplify interoperability it is recommended to use In order to simplify interoperability the 'generic' case should be
(generic) case only when needed and to use the ODUflex specific type used only when it is needed; the ODUflex type-specific case should be
case whenever possible. used whenever possible.
The (cbr) case is used for Constant Bit Rate (CBR) client signals. The 'cbr' case is used for Constant Bit Rate (CBR) client signals.
The client-type indicates which is the CBR client signal carried by The client-type indicates which CBR client signal is carried by the
the ODUflex and, implicitly, also the client signal bit rate which is ODUflex and, implicitly, the client signal bit rate which is then
used to calculate the ODUflex(CBR) nominal bit rate as described in used to calculate the ODUflex(CBR) nominal bit rate as described in
Table 7-2 of [ITU-Tg709]. Table 7-2 of [ITU-Tg709].
The (gfp-n-k) case is used for GFP-F mapped client signals based on The 'gfp-n-k' case is used for GFP-F mapped client signals based on
ODUk.ts and n 1.25G tributary slots. The gfp-k defines the nominal ODUk.ts and 'n' 1.25G tributary slots. 'gfp-k' defines the nominal
bit-rate of the ODUk.ts which, together with the value of gfp-n, is bit-rate of the ODUk.ts which, together with the value of 'gfp-n', is
used to calculated the ODUflex(GFP,n,k) nominal bit rate as described used to calculated the ODUflex(GFP,n,k) nominal bit rate as described
in Table 7-8 and Table L-7 of [ITU-Tg709] . With few exceptions, in Table 7-8 and Table L-7 of [ITU-Tg709] . With a few exceptions,
shown in Table L-7 of [ITU-Tg709], the nominal bit-rate of the shown in Table L-7 of [ITU-Tg709], the nominal bit-rate of the
ODUk.ts could be inferred from the value of n, as shown in Table 7-8 ODUk.ts could be inferred from the value of 'n', as shown in
of [ITU-Tg709] and therefore the gfp-k is optional. Table 7-8 of [ITU-Tg709] and therefore the 'gfp-k' is optional.
The (flexe-client) case is used for IMP mapped FlexE Client signals, The 'flexe-client' case is used for Idle Mapping Procedure(IMP)
The flexe-client represents the type of FlexE Client carried by the mapped FlexE client signals, The 'flexe-client' represents the type
ODUflex which implicitly defines the value of s used to calculate the of FlexE client carried by the ODUflex which implicitly defines the
ODUflex(s) nominal bit rate as described in Table 7-2 of [ITU-Tg709]. value of 's' used to calculate the ODUflex(s) nominal bit rate as
The '10G' and '40G' enumeration values are used for 10G and 40G FlexE described in Table 7-2 of [ITU-Tg709]. The '10G' and '40G'
Clients to implicitly define the values of s=2 and s=8. For the n x enumeration values are used for 10G and 40G FlexE clients to
25G FlexE Clients the value of n is used to defines the value of s=5 implicitly define the values of s=2 and s=8. For the 'n x 25G' FlexE
x n. Clients the value of 'n' is used to defines the value of s=5 x n.
The (flexe-aware) case is used for FlexE-aware client signals. The The 'flexe-aware' case is used for FlexE-aware client signals. The
flexe-aware-n represents the value n (n = n1 + n2 + ... + np) which flexe-aware-n represents the value n (n = n1 + n2 + ... + np) which
is used to calculate the ODUflex(FlexE-aware) nominal bit rate as is used to calculate the ODUflex(FlexE-aware) nominal bit rate as
described in Table 7-2 of [ITU-Tg709]. described in Table 7-2 of [ITU-Tg709].
When (packet) case is used for both the GFP-F mapped client signals The 'packet' case is used for both the GFP-F mapped client signals
and the IMP mapped client signals. The opuflex-payload-rate is and the IMP mapped client signals. The opuflex-payload-rate is
either the GFP-F encapsulated packet client nominal bit rate or the either the GFP-F encapsulated-packet client nominal bit rate or the
64b/66b encoded packet client nominal bit rate. The calculation of 64b/66b encoded-packet client nominal bit rate. The calculation of
ODUflex(GFP) nominal bit rate is defined in section 12.2.5 of ODUflex(GFP) nominal bit rate is defined in section 12.2.5 of
[ITU-Tg709], and the calculation of ODUflex(IMP) nominal bit rate is [ITU-Tg709], and the calculation of ODUflex(IMP) nominal bit rate is
defined in section 12.2.6 of [ITU-Tg709]. The same formula is used defined in section 12.2.6 of [ITU-Tg709]. The same formula is used
in both cases. in both cases.
Section 5.1 and 5.2 of [RFC7139] defines two rules to compute the Section 5.1 and 5.2 of [RFC7139] defines two rules to compute the
number of tributary slots to be allocated to ODUflex(CBR) and number of tributary slots to be allocated to ODUflex(CBR) and
ODUflex(GFP) LSPs when carried over an HO-ODUk link. According to ODUflex(GFP) LSPs when carried over a HO-ODUk link. According to
section 19.6 of [ITU-Tg709], the rules in section 5.2 applies only to section 19.6 of [ITU-Tg709], the rules in section 5.2 apply only to
ODUflex(GFP,n,k) while the rules defined in section 5.1 applies to ODUflex(GFP,n,k) while the rules defined in section 5.1 apply to any
any other ODUflex type, including but not being limited to other ODUflex type, including, but not limited, to ODUflex(CBR).
ODUflex(CBR). Section 20.5 of [ITU-Tg709] defines the rules to Section 20.5 of [ITU-Tg709] defines the rules for computing the
compute the number of tributary slots to be allocated to ODUflex LSPs number of tributary slots to be allocated to ODUflex LSPs when
when carried over an ODUCn link. carried over an ODUCn link.
Following the [ITU-Tg709] definitions, the rules defined for Following the [ITU-Tg709] definitions, the rules defined for
ODUflex(GFP,n,k) are used only when the (gfp-n-k) case is used. In ODUflex(GFP,n,k) are used only when the 'gfp-n-k' case is used. In
all the other cases, including the (generic) case, the rules defined all the other cases, including the (generic) case, the rules defined
any other ODUflex type are used. any other ODUflex type are used.
The number of available ODUs, defined for each ODUk type, including The number of available ODUs, defined for each ODUk type, including
ODUflex, together with the number of available time-slots, reported ODUflex, together with the number of available time-slots, reported
as part of the OTN label range, provides sufficient information to as part of the OTN label range, provide sufficient information to
infer the OTN link bandwidth availability for ODUflex LSPs. This infer the OTN link bandwidth availability for ODUflex LSPs. This
information is independent from the ODUflex type. information is independent of the ODUflex type.
4.4.1. Resizable ODUflex 4.4.1. Resizable ODUflex
Resizable ODUflex is a special type of ODUflex that supports the Resizable ODUflex is a special type of ODUflex that supports the
procedures defined in [ITU-Tg7044] for hitless resizing of the procedures defined in [ITU-Tg7044] for hitless resizing of the
ODUflex nominal bit rate. ODUflex nominal bit rate.
Two odu-type identities have been defined for ODUflex: Two odu-type identities have been defined for ODUflex:
o The ODUflex identity, which is used with any type of non-resizable o The ODUflex identity, which is used with any type of non-resizable
ODUflex, as defined in Table 7-2 of [ITU-Tg709]. ODUflex, as defined in Table 7-2 of [ITU-Tg709].
o The ODUflex-resizable identity, which used only with resizable o The ODUflex-resizable identity, which is used only with resizable
ODUflex(GFP,n,k). ODUflex(GFP,n,k).
These two identities are used to identify whether an ODUflex(GFP,n,k) These two identities are used to identify whether an ODUflex(GFP,n,k)
LSP shall or not support the [ITU-Tg7044] hitless resizing procedures LSP does or does support the [ITU-Tg7044] hitless resizing
as well as whether an OTN link supports only the setup of non- procedures. They also identify whether an OTN link only supports the
resizable ODUflex LSPs or also the setup of resizable setup of non-resizable ODUflex LSPs or also supports the setup of
ODUflex(GFP,n,k) LSP but with different capabilities (e.g., a lower resizable ODUflex(GFP,n,k) LSP but with different capabilities (e.g.,
number of LSPs). a lower number of LSPs).
5. YANG Code for Layer1 Types 5. YANG Code for Layer1 Types
<CODE BEGINS>file "ietf-layer1-types@2020-05-13.yang" <CODE BEGINS>file "ietf-layer1-types@2020-09-21.yang"
module ietf-layer1-types { module ietf-layer1-types {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-layer1-types"; namespace "urn:ietf:params:xml:ns:yang:ietf-layer1-types";
prefix "l1-types"; prefix "l1-types";
organization organization
"IETF CCAMP Working Group"; "IETF CCAMP Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/ccamp/> "WG Web: <http://tools.ietf.org/wg/ccamp/>
WG List: <mailto:ccamp@ietf.org> WG List: <mailto:ccamp@ietf.org>
skipping to change at page 9, line 28 skipping to change at page 9, line 28
module ietf-layer1-types { module ietf-layer1-types {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-layer1-types"; namespace "urn:ietf:params:xml:ns:yang:ietf-layer1-types";
prefix "l1-types"; prefix "l1-types";
organization organization
"IETF CCAMP Working Group"; "IETF CCAMP Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/ccamp/> "WG Web: <http://tools.ietf.org/wg/ccamp/>
WG List: <mailto:ccamp@ietf.org> WG List: <mailto:ccamp@ietf.org>
Editor: Haomian Zheng Editor: Haomian Zheng
<mailto:zhenghaomian@huawei.com> <mailto:zhenghaomian@huawei.com>
Editor: Italo Busi Editor: Italo Busi
<mailto:Italo.Busi@huawei.com>"; <mailto:Italo.Busi@huawei.com>";
description description
"This module defines Layer 1 types. The model fully conforms "This module defines Layer 1 types (typedef, identity,
to the Network Management Datastore Architecture (NMDA). grouping). The model fully conforms to the Network Management
Datastore Architecture (NMDA).
Copyright (c) 2020 IETF Trust and the persons Copyright (c) 2020 IETF Trust and the persons
identified as authors of the code. All rights reserved. identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision "2020-05-13" { revision "2020-09-21" {
description description
"Initial Version"; "Initial Version";
reference reference
"RFC XXXX: A YANG Data Model for Layer 1 Types"; "RFC XXXX: A YANG Data Model for Layer 1 Types";
// RFC Editor: replace XXXX with actual RFC number, update date // RFC Editor: replace XXXX with actual RFC number, update date
// information and remove this note // information and remove this note
} }
typedef otn-tpn { typedef otn-tpn {
type uint16 { type uint16 {
skipping to change at page 14, line 4 skipping to change at page 13, line 49
identity ODU4 { identity ODU4 {
base odu-type; base odu-type;
description description
"ODU4 protocol (104.79Gb/s)."; "ODU4 protocol (104.79Gb/s).";
reference "RFC7139/ITU-T G.709"; reference "RFC7139/ITU-T G.709";
} }
identity ODUflex { identity ODUflex {
base odu-type; base odu-type;
description description
"ODUflex protocol (flexibile bit rate, not resizable). "ODUflex protocol (flexible bit rate, not resizable).
It could be used for any type of ODUflex, including It can be used for any type of ODUflex, including
ODUflex(CBR), ODUflex(GFP), ODUflex(GFP,n,k), ODUflex(IMP,s), ODUflex(CBR), ODUflex(GFP), ODUflex(GFP,n,k), ODUflex(IMP,s),
ODUflex(IMP) and ODUflex(FlexE-aware)."; ODUflex(IMP) and ODUflex(FlexE-aware).";
reference "RFC7139/ITU-T G.709"; reference "RFC7139/ITU-T G.709";
} }
identity ODUflex-resizable { identity ODUflex-resizable {
base odu-type; base odu-type;
description description
"ODUflex protocol (flexibile bit rate, resizable). "ODUflex protocol (flexible bit rate, resizable).
It could be used only for ODUflex(GFP,n,k)."; It can only be used for ODUflex(GFP,n,k).";
reference "RFC7139/ITU-T G.709 and ITU-T G.7044"; reference "RFC7139/ITU-T G.709 and ITU-T G.7044";
} }
identity client-signal { identity client-signal {
description description
"Base identity from which specific client signals for the "Base identity from which specific client signals for the
tunnel are derived"; tunnel are derived";
} }
identity ETH-1Gb { identity ETH-1Gb {
skipping to change at page 24, line 7 skipping to change at page 24, line 4
} }
case packet { case packet {
leaf opuflex-payload-rate { leaf opuflex-payload-rate {
type uint64; type uint64;
units "Kbps"; units "Kbps";
mandatory true; mandatory true;
description description
"Either the GFP-F encapsulated packet client nominal "Either the GFP-F encapsulated packet client nominal
bit rate for an ODUflex(GFP) or the 64b/66b encoded bit rate for an ODUflex(GFP) or the 64b/66b encoded
packet client nominal bit rate for an ODUflex(IMP)."; packet client nominal bit rate for an ODUflex(IMP).";
} }
} }
} }
} }
grouping otn-label-range-info { grouping otn-label-range-info {
description description
"label range information for OTN, is dependent on the "label range information for OTN, dependent on the
range-type, must be used together with the following range-type, must be used together with the following
groupings: otn-label-start-end and otn-label-step. "; groupings: otn-label-start-end and otn-label-step. ";
leaf range-type { leaf range-type {
type otn-label-range-type; type otn-label-range-type;
description "The type of range (e.g., TPN or TS) description "The type of range (e.g., TPN or TS)
to which the label range applies"; to which the label range applies";
} }
leaf tsg { leaf tsg {
type identityref { type identityref {
base tributary-slot-granularity; base tributary-slot-granularity;
} }
description description
"Tributary slot granularity (TSG) to which the label range "Tributary slot granularity (TSG) to which the label range
applies. applies.
This leaf shall be present when the range-type is TS; This leaf must be present when the range-type is TS;
This leaf can be omitted when mapping an ODUk over an OTUk This leaf may be omitted when mapping an ODUk over an OTUk
Link. In this case the range-type is tpn, with only one Link. In this case the range-type is tpn, with only one
entry (ODUk), and the tpn range has only one value (1)."; entry (ODUk), and the tpn range has only one value (1).";
reference reference
"G.709/Y.1331, February 2016: Interfaces for the "G.709/Y.1331, February 2016: Interfaces for the
Optical Transport Network (OTN)"; Optical Transport Network (OTN)";
} }
leaf-list odu-type-list { leaf-list odu-type-list {
type identityref { type identityref {
base odu-type; base odu-type;
} }
skipping to change at page 26, line 26 skipping to change at page 26, line 23
"G.709/Y.1331, February 2016: Interfaces for the "G.709/Y.1331, February 2016: Interfaces for the
Optical Transport Network (OTN)"; Optical Transport Network (OTN)";
} }
leaf ts-list { leaf ts-list {
type string { type string {
pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?" pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?"
+ "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)"; + "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)";
} }
description description
"A list of available tributary slots ranging "A list of available tributary slots ranging
between 1 and 4095. If multiple values or from 1 to 4095. If multiple values or
ranges are given, they all must be disjoint ranges are given, they all must be disjoint
and must be in ascending order. and must be in ascending order.
For example 1-20,25,50-1000."; For example 1-20,25,50-1000.";
reference reference
"RFC 7139: GMPLS Signaling Extensions for Control "RFC 7139: GMPLS Signaling Extensions for Control
of Evolving G.709 Optical Transport Networks"; of Evolving G.709 Optical Transport Networks";
} }
} }
grouping otn-label-step { grouping otn-label-step {
description description
"Label step for OTN, is dependent on the range-type, "Label step for OTN, dependent on the range-type,
must be used together with the following groupings: must be used together with the following groupings:
otn-label-range-info and otn-label-start-end. "; otn-label-range-info and otn-label-start-end. ";
choice range-type { choice range-type {
description description
"OTN label range type, either TPN range or TS range"; "OTN label range type, either TPN range or TS range";
case trib-port { case trib-port {
leaf otn-tpn { leaf otn-tpn {
when "../../../range-type = 'trib-port'" { when "../../../range-type = 'trib-port'" {
description description
"valid only when range-type represented by trib-port"; "valid only when range-type represented by trib-port";
skipping to change at page 29, line 48 skipping to change at page 29, line 47
Email: victor.lopezalvarez@telefonica.com Email: victor.lopezalvarez@telefonica.com
Yunbo Li Yunbo Li
China Mobile China Mobile
Email: liyunbo@chinamobile.com Email: liyunbo@chinamobile.com
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-teas-yang-te-types]
Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"Traffic Engineering Common YANG Types", draft-ietf-teas-
yang-te-types-13 (work in progress), November 2019.
[ITU-Tg7044] [ITU-Tg7044]
International Telecommunication Union, "Hitless adjustment International Telecommunication Union, "Hitless adjustment
of ODUflex(GFP)", ITU-T G.7044, October 2011. of ODUflex(GFP)", ITU-T G.7044, October 2011.
[ITU-Tg709] [ITU-Tg709]
International Telecommunication Union, "Interfaces for the International Telecommunication Union, "Interfaces for the
optical transport network", ITU-T G.709, March 2020. optical transport network", ITU-T G.709, March 2020.
[ITU-Tgsup43] [ITU-Tgsup43]
International Telecommunication Union, "Transport of IEEE International Telecommunication Union, "Transport of IEEE
skipping to change at page 31, line 19 skipping to change at page 31, line 19
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"Common YANG Data Types for Traffic Engineering",
RFC 8776, DOI 10.17487/RFC8776, June 2020,
<https://www.rfc-editor.org/info/rfc8776>.
[Telcordia] [Telcordia]
Telcordia, "Synchronous Optical Network Transport Systems: Telcordia, "Synchronous Optical Network Transport Systems:
Common Generic Criteria, Issue 5", Telcordia GR-253-CORE, Common Generic Criteria, Issue 5", Telcordia GR-253-CORE,
October 2009. October 2009.
10.2. Informative References 10.2. Informative References
[I-D.ietf-ccamp-client-signal-yang] [I-D.ietf-ccamp-client-signal-yang]
Zheng, H., Guo, A., Busi, I., Snitser, A., Lazzeri, F., Zheng, H., Guo, A., Busi, I., Snitser, A., Lazzeri, F.,
Xu, Y., Zhao, Y., Liu, X., and G. Fioccola, "A YANG Data Xu, Y., Zhao, Y., Liu, X., and G. Fioccola, "A YANG Data
Model for Transport Network Client Signals", draft-ietf- Model for Transport Network Client Signals", draft-ietf-
ccamp-client-signal-yang-02 (work in progress), May 2020. ccamp-client-signal-yang-03 (work in progress), July 2020.
[I-D.ietf-ccamp-l1csm-yang] [I-D.ietf-ccamp-l1csm-yang]
Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D. Lee, Y., Lee, K., Zheng, H., Dios, O., and D. Ceccarelli,
Ceccarelli, "A YANG Data Model for L1 Connectivity Service "A YANG Data Model for L1 Connectivity Service Model
Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-11 (work in (L1CSM)", draft-ietf-ccamp-l1csm-yang-12 (work in
progress), March 2020. progress), September 2020.
[I-D.ietf-ccamp-otn-topo-yang] [I-D.ietf-ccamp-otn-topo-yang]
Zheng, H., Busi, I., Liu, X., Belotti, S., and O. Dios, "A Zheng, H., Busi, I., Liu, X., Belotti, S., and O. Dios, "A
YANG Data Model for Optical Transport Network Topology", YANG Data Model for Optical Transport Network Topology",
draft-ietf-ccamp-otn-topo-yang-10 (work in progress), draft-ietf-ccamp-otn-topo-yang-10 (work in progress),
March 2020. March 2020.
[I-D.ietf-ccamp-otn-tunnel-model] [I-D.ietf-ccamp-otn-tunnel-model]
Zheng, H., Busi, I., Belotti, S., Lopezalvarez, V., and Y. Zheng, H., Busi, I., Belotti, S., Lopez, V., and Y. Xu,
Xu, "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel- "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel-
model-10 (work in progress), March 2020. model-11 (work in progress), September 2020.
[I-D.ietf-ccamp-transport-nbi-app-statement] [I-D.ietf-ccamp-transport-nbi-app-statement]
Busi, I., King, D., Zheng, H., and Y. Xu, "Transport Busi, I., King, D., Zheng, H., and Y. Xu, "Transport
Northbound Interface Applicability Statement", draft-ietf- Northbound Interface Applicability Statement", draft-ietf-
ccamp-transport-nbi-app-statement-10 (work in progress), ccamp-transport-nbi-app-statement-11 (work in progress),
November 2019. July 2020.
[I-D.ietf-netmod-artwork-folding]
Watsen, K., Auerswald, E., Farrel, A., and Q. WU,
"Handling Long Lines in Inclusions in Internet-Drafts and
RFCs", draft-ietf-netmod-artwork-folding-12 (work in
progress), January 2020.
[RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. [RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D.
Ceccarelli, "Framework for GMPLS and PCE Control of G.709 Ceccarelli, "Framework for GMPLS and PCE Control of G.709
Optical Transport Networks", RFC 7062, Optical Transport Networks", RFC 7062,
DOI 10.17487/RFC7062, November 2013, DOI 10.17487/RFC7062, November 2013,
<https://www.rfc-editor.org/info/rfc7062>. <https://www.rfc-editor.org/info/rfc7062>.
[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
J. Drake, "Traffic Engineering Extensions to OSPF for J. Drake, "Traffic Engineering Extensions to OSPF for
GMPLS Control of Evolving G.709 Optical Transport GMPLS Control of Evolving G.709 Optical Transport
Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014, Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014,
<https://www.rfc-editor.org/info/rfc7138>. <https://www.rfc-editor.org/info/rfc7138>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
Appendix A. Examples of OTN Label Ranges Appendix A. Examples of OTN Label Ranges
This appendix provides some examples of how the TPN and TS label This appendix provides some examples of how the TPN and TS label
ranges described in Table 3 and Table 4 of [RFC7139] can be ranges described in Table 3 and Table 4 of [RFC7139] can be
represented in YANG using the groupings defined in this document. represented in YANG using the groupings defined in this document.
It also considers the OTUk links in addition to HO-ODUk links. It also considers the OTUk links in addition to HO-ODUk links.
The JSON code examples provided in this appendix provides some The JSON code examples provided in this appendix provides some
embedded comments following the conventions in section 3.2 of [I- embedded comments following the conventions in section 3.2 of
D.ietf-ccamp-transport-nbi-app-statement] and have been folded using [I-D.ietf-ccamp-transport-nbi-app-statement] and have been folded
the tool in [I-D.ietf-netmod-artwork-folding]. using the tool in [RFC8792].
========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ==========
{ {
"examples of label-restrictions for different OTN Links": [ "examples of label-restrictions for different OTN Links": [
{ {
"// ": "HO-ODU1 or OTU1 Link", "// ": "HO-ODU1 or OTU1 Link",
"label-restrictions": { "label-restrictions": {
"label-restriction": [ "label-restriction": [
{ {
 End of changes. 64 change blocks. 
177 lines changed or deleted 168 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/