draft-ietf-ccamp-mw-yang-02.txt   draft-ietf-ccamp-mw-yang-03.txt 
CCAMP Working Group J. Ahlberg CCAMP Working Group J. Ahlberg
Internet-Draft Ericsson AB Internet-Draft Ericsson AB
Intended status: Standards Track M. Ye Intended status: Standards Track M. Ye
Expires: April 26, 2018 Huawei Technologies Expires: August 30, 2018 Huawei Technologies
X. Li X. Li
NEC Laboratories Europe NEC Laboratories Europe
K. Kawada
NEC Corporation
CJ. Bernardos
Universidad Carlos III de Madrid
D. Spreafico D. Spreafico
Nokia - IT Nokia - IT
M. Vaupotic M. Vaupotic
Aviat Networks Aviat Networks
October 23, 2017 February 26, 2018
A YANG Data Model for Microwave Radio Link A YANG Data Model for Microwave Radio Link
draft-ietf-ccamp-mw-yang-02 draft-ietf-ccamp-mw-yang-03
Abstract Abstract
This document defines a YANG data model for control and management This document defines a YANG data model for control and management
of the radio link interfaces, and their connectivity to packet of the radio link interfaces, and their connectivity to packet
(typically Ethernet) interfaces in a microwave/millimeter wave node. (typically Ethernet) interfaces in a microwave/millimeter wave node.
The data nodes for management of the interface protection The data nodes for management of the interface protection
functionality is broken out into a separate and generic YANG data functionality is broken out into a separate and generic YANG data
model in order to make it available also for other interface types. model in order to make it available also for other interface types.
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 [RFC2119].
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 April 26, 2018. This Internet-Draft will expire on August 30, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology and Definitions . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology and Definitions . . . . . . . . . . . . . . . 3
1.2. Tree Structure . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Microwave Radio Link YANG Data Model. . . . . . . . . . . . . 4 3. Microwave Radio Link YANG Data Model. . . . . . . . . . . . . 4
3.1. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Explanation of the Microwave Data Model . . . . . . . . . 5 3.2. Explanation of the Microwave Data Model . . . . . . . . . 6
4. Microwave Radio Link YANG Module . . . . . . . . . . . . . . 6 4. Microwave Radio Link YANG Module . . . . . . . . . . . . . . 6
5. Interface Protection YANG Module . . . . . . . . . . . . . . 30 5. Interface Protection YANG Module . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. Normative References . . . . . . . . . . . . . . . . . . 37 8.1. Normative References . . . . . . . . . . . . . . . . . . 38
8.2. Informative References . . . . . . . . . . . . . . . . . 37 8.2. Informative References . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Appendix A. Example: 1+0 and 2+0 configuration instances. . . . . 40
Appendix B. Contributors. . . . . . . . . . . . . . . . . . . . . 43
1. Terminology and Definitions Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
The following terms are used in this document:
Carrier Termination (CT) is an interface for the capacity provided
over the air by a single carrier. It is typically defined by its
transmitting and receiving frequencies.
Radio Link Terminal (RLT) is an interface providing packet capacity
and/or TDM capacity to the associated Ethernet and/or TDM interfaces
in a node and used for setting up a transport service over a
microwave/millimeter wave link.
The following acronyms are used in this document:
ACM Adaptive Coding Modulation
ATPC Automatic Transmit Power Control
CM Coding Modulation
CT Carrier Termination
RLT Radio Link Terminal
RTPC Remote Transmit Power Control
XPIC Cross Polarization Interference Cancellation
MIMO Multiple-Input Multiple-Output
2. Introduction 1. Introduction
This document defines a YANG data model for management and control of This document defines a YANG data model for management and control of
the radio link interface(s) and the relationship to packet (typically the radio link interface(s) and the relationship to packet (typically
Ethernet) and/or TDM interfaces in a microwave/millimeter wave node. Ethernet) and/or TDM interfaces in a microwave/millimeter wave node.
ETSI EN 302 217 series defines the characteristics and requirements ETSI EN 302 217 series defines the characteristics and requirements
of microwave/millimeter wave equipment and antennas. Especially ETSI of microwave/millimeter wave equipment and antennas. Especially ETSI
EN 302 217-2 [EN 302 217-2] specifies the essential parameters for EN 302 217-2 [EN302217-2] specifies the essential parameters for
the systems operating from 1.4GHz to 86GHz. The data model includes the systems operating from 1.4GHz to 86GHz. The data model includes
configuration and state data according to the new Network Management configuration and state data according to the new Network Management
Datastore Architecture [NMDA]. Datastore Architecture [NMDA].
The design of the data model follows the framework for management and The design of the data model follows the framework for management and
control of microwave and millimeter wave interface parameters defined control of microwave and millimeter wave interface parameters defined
in [I-D.ietf-ccamp-microwave-framework]. This framework identifies in [I-D.ietf-ccamp-microwave-framework]. This framework identifies
the need and the scope of the YANG data model, the use cases and the need and the scope of the YANG data model, the use cases and
requirements that the model needs to support. Moreover, it provides requirements that the model needs to support. Moreover, it provides
a detailed gap analysis to identify the missing parameters and a detailed gap analysis to identify the missing parameters and
functionalities of the existing and established models to support the functionalities of the existing and established models to support the
skipping to change at page 3, line 35 skipping to change at page 3, line 14
The design of the data model follows the framework for management and The design of the data model follows the framework for management and
control of microwave and millimeter wave interface parameters defined control of microwave and millimeter wave interface parameters defined
in [I-D.ietf-ccamp-microwave-framework]. This framework identifies in [I-D.ietf-ccamp-microwave-framework]. This framework identifies
the need and the scope of the YANG data model, the use cases and the need and the scope of the YANG data model, the use cases and
requirements that the model needs to support. Moreover, it provides requirements that the model needs to support. Moreover, it provides
a detailed gap analysis to identify the missing parameters and a detailed gap analysis to identify the missing parameters and
functionalities of the existing and established models to support the functionalities of the existing and established models to support the
specified use cases and requirements, and based on that recommends specified use cases and requirements, and based on that recommends
how the gaps should be filled with the development of the new model. how the gaps should be filled with the development of the new model.
According to the conclusion of the gap analysis, the structure of the According to the conclusion of the gap analysis, the structure of the
data model is based on the structure defined in data model is based on the structure defined in
[I-D.ahlberg-ccamp-microwave-radio-link] and it augments [RFC7223bis] [I-D.ahlberg-ccamp-microwave-radio-link] and it augments [RFC7223bis]
to align with the same structure for management of the packet to align with the same structure for management of the packet
interfaces. More specifically, the model will include interface interfaces. More specifically, the model will include interface
layering to manage the capacity provided by a radio link terminal for layering to manage the capacity provided by a radio link terminal for
the associated Ethernet and TDM interfaces, using the principles for the associated Ethernet and TDM interfaces, using the principles for
interface layering described in RFC 7223 bis as a basis. interface layering described in [RFC7223bis] as a basis.
The data nodes for management of the interface protection The data nodes for management of the interface protection
functionality is broken out into a separate and generic YANG data functionality is broken out into a separate and generic YANG data
module in order to make it available also for other interface types. module in order to make it available also for other interface types.
The designed YANG data model uses established microwave equipment The designed YANG data model uses established microwave equipment
and radio standards, such as ETSI EN 302 217-2, and the IETF: Radio and radio standards, such as ETSI EN 302 217-2, and the IETF: Radio
Link Model[I-D.ahlberg-ccamp-microwave-radio-link] and the ONF: Link Model[I-D.ahlberg-ccamp-microwave-radio-link] and the ONF:
Microwave Modeling[ONF-model] as the basis for the definition of the Microwave Modeling[ONF-model] as the basis for the definition of the
detailed leafs/parameters, and proposes new ones to cover identified detailed leafs/parameters, and proposes new ones to cover identified
gaps which are analysed in[I-D.ietf-ccamp-microwave-framework]. gaps which are analyzed in[I-D.ietf-ccamp-microwave-framework].
1.1. Terminology and Definitions
The following terms are used in this document:
Carrier Termination (CT) is an interface for the capacity provided
over the air by a single carrier. It is typically defined by its
transmitting and receiving frequencies.
Radio Link Terminal (RLT) is an interface providing packet capacity
and/or TDM capacity to the associated Ethernet and/or TDM interfaces
in a node and used for setting up a transport service over a
microwave/millimeter wave link.
The following acronyms are used in this document:
ACM Adaptive Coding Modulation
ATPC Automatic Transmit Power Control
CM Coding Modulation
CT Carrier Termination
RLT Radio Link Terminal
RTPC Remote Transmit Power Control
XPIC Cross Polarization Interference Cancellation
MIMO Multiple-Input Multiple-Output
1.2. Tree Structure
A simplified graphical representation of the data model is used in
chapter 3.1 of this this document. The meaning of the symbols in
these diagrams is defined in [YANG-TREE].
2. 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 [RFC2119].
3. Microwave Radio Link YANG Data Model 3. Microwave Radio Link YANG Data Model
3.1. YANG Tree 3.1. YANG Tree
module: ietf-microwave-radio-link module: ietf-microwave-radio-link
+--rw radio-link-protection-groups +--rw radio-link-protection-groups
| +--rw protection-group* [name] | +--rw protection-group* [name]
| +--rw name string | +--rw name string
| +--rw protection-architecture-type? identityref | +--rw architecture-type? identityref
| +--rw protection-members* if:interface-ref | +--rw members* if:interface-ref
| +--rw protection-operation-type? enumeration | +--rw operation-type? enumeration
| +--rw working-entity* if:interface-ref | +--rw working-entity* if:interface-ref
| +--rw revertive-wait-to-restore? uint16 | +--rw revertive-wait-to-restore? uint16
| +--rw hold-off-timer? uint16 | +--rw hold-off-timer? uint16
| +--rw protection-status? identityref | +--rw status? identityref
| +---x protection-external-commands | +---x external-commands
| +---w input | +---w input
| +---w protection-external-command? identityref | +---w external-command? identityref
+--rw xpic-pairs {xpic}? +--rw xpic-pairs {xpic}?
| +--rw xpic-pair* [name] | +--rw xpic-pair* [name]
| +--rw name string | +--rw name string
| +--rw enabled? boolean | +--rw enabled? boolean
| +--rw xpic-members* if:interface-ref | +--rw members* if:interface-ref
+--rw mimo-groups {mimo}? +--rw mimo-groups {mimo}?
+--rw mimo-group* [name] +--rw mimo-group* [name]
+--rw name string +--rw name string
+--rw enabled? boolean +--rw enabled? boolean
+--rw mimo-members* if:interface-ref +--rw members* if:interface-ref
augment /if:interfaces/if:interface: augment /if:interfaces/if:interface:
+--rw id? string +--rw id? string
+--rw mode identityref +--rw mode identityref
+--rw carrier-terminations* if:interface-ref +--rw carrier-terminations* if:interface-ref
+--rw rlp-groups* +--rw rlp-groups*
| -> /radio-link-protection-groups/protection-group/name | -> /radio-link-protection-groups/protection-group/name
+--rw xpic-pairs* -> /xpic-pairs/xpic-pair/name +--rw xpic-pairs* -> /xpic-pairs/xpic-pair/name
| {xpic}? | {xpic}?
+--rw mimo-groups* -> /mimo-groups/mimo-group/name +--rw mimo-groups* -> /mimo-groups/mimo-group/name
| {mimo}? | {mimo}?
skipping to change at page 5, line 48 skipping to change at page 6, line 21
+--ro max-rltm? power +--ro max-rltm? power
+--ro min-tltm? power +--ro min-tltm? power
+--ro max-tltm? power +--ro max-tltm? power
3.2. Explanation of the Microwave Data Model 3.2. Explanation of the Microwave Data Model
The leafs in the Interface Management Module augmented by Radio Link The leafs in the Interface Management Module augmented by Radio Link
Terminal (RLT) and Carrier Termination (CT) are not always Terminal (RLT) and Carrier Termination (CT) are not always
applicable. applicable.
"/interfaces/interface/enabled" is not applicable for RLT. Enable and "/interfaces/interface/enabled" is not applicable for RLT. Enable
disable of an interface is done in the constituent CTs. and disable of an interface is done in the constituent CTs.
The packet related measurements "in-octets", "in-unicast-pkts", "in- The packet related measurements "in-octets", "in-unicast-pkts", "in-
broadcast-pkts", "in-multicast-pkts", "in-discards", "in-errors", broadcast-pkts", "in-multicast-pkts", "in-discards", "in-errors",
"in-unknown-protos", "out-octets", "out-unicast-pkts", "out- "in-unknown-protos", "out-octets", "out-unicast-pkts", "out-
broadcast-pkts", "out-multicast-pkts", "out-discards", "out-errors" broadcast-pkts", "out-multicast-pkts", "out-discards", "out-errors"
are not within the scope of the microwave radio link domain and are not within the scope of the microwave radio link domain and
therefore not applicable for RLT and CT. therefore not applicable for RLT and CT.
4. Microwave Radio Link YANG Module 4. Microwave Radio Link YANG Module
<CODE BEGINS> file "ietf-microwave-radio-link.yang" <CODE BEGINS> file "ietf-microwave-radio-link@2018-02-26.yang"
module ietf-microwave-radio-link { module ietf-microwave-radio-link {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-microwave-radio-link"; namespace "urn:ietf:params:xml:ns:yang:ietf-microwave-radio-link";
prefix mrl; prefix mrl;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
reference "RFC7223bis";
} }
import ietf-interface-protection { import ietf-interface-protection {
prefix ifprot; prefix ifprot;
} }
import iana-if-type { import iana-if-type {
prefix ianaift; prefix ianaift;
} }
skipping to change at page 6, line 32 skipping to change at page 7, line 7
import ietf-interface-protection { import ietf-interface-protection {
prefix ifprot; prefix ifprot;
} }
import iana-if-type { import iana-if-type {
prefix ianaift; prefix ianaift;
} }
organization organization
"Internet Engineering Task Force (IETF) CCAMP WG"; "Internet Engineering Task Force (IETF) CCAMP WG";
contact contact
"WG List: <mailto:ccamp@ietf.org> "WG List: <mailto:ccamp@ietf.org>
ID-draft authors: ID-draft authors:
Jonas Ahlberg (jonas.ahlberg@ericsson.com); Jonas Ahlberg (jonas.ahlberg@ericsson.com);
Min Ye (amy.yemin@huawei.com); Min Ye (amy.yemin@huawei.com);
Xi Li (Xi.Li@neclab.eu); Xi Li (Xi.Li@neclab.eu);
Koji Kawada (k-kawada@ah.jp.nec.com)
Carlos J. Bernardos (cjbc@it.uc3m.es)
Daniela Spreafico (daniela.spreafico@nokia.com) Daniela Spreafico (daniela.spreafico@nokia.com)
Marko Vaupotic (Marko.Vaupotic@aviatnet.com)"; Marko Vaupotic (Marko.Vaupotic@aviatnet.com)";
description description
"This is a module for the entities in "This is a module for the entities in
a generic microwave system."; a generic microwave system.
revision 2017-10-23 { Copyright (c) 2018 IETF Trust and the persons identified as
description authors of the code. All rights reserved.";
"Break out protection functionality to a generic module
and update to follow the new NMDA style."; revision 2018-02-26 {
reference ""; description "Update with respect to the YANG Guideline";
} reference "RFC XXXX: A YANG Data Model for Microwave Radio Link";
revision 2017-06-21 {
description
"Updated draft revision with updates of some descriptions to
increase clarity and some minor adjustments of the model.";
reference "";
}
revision 2016-12-22 {
description
"Draft revision covering a complete scope for configuration
and state data for radio link interfaces.";
reference "";
}
revision 2016-10-29 {
description
"Draft revision.";
reference "";
} }
/* /*
* Features * Features
*/ */
feature xpic { feature xpic {
description description
"Indicates that the device supports XPIC."; "Indicates that the device supports XPIC.";
reference "ETSI TR 102 311"; reference "ETSI TR 102 311";
skipping to change at page 19, line 24 skipping to change at page 19, line 24
} }
leaf maximum-nominal-power { leaf maximum-nominal-power {
type power { type power {
range "-99..40"; range "-99..40";
} }
units "dBm"; units "dBm";
mandatory true; mandatory true;
description description
"Selected output power in RTPC mode and selected "Selected output power in RTPC mode and selected
maximum output power in ATPC mode. Minimum ouput maximum output power in ATPC mode. Minimum output
power in ATPC mode is the same as the system power in ATPC mode is the same as the system
capability, available-min-output-power."; capability, available-min-output-power.";
reference "ETSI EN 302 217-1"; reference "ETSI EN 302 217-1";
} }
leaf atpc-lower-threshold { leaf atpc-lower-threshold {
when "../power-mode = 'atpc'"; when "../power-mode = 'atpc'";
type power { type power {
range "-99..-30"; range "-99..-30";
} }
skipping to change at page 24, line 23 skipping to change at page 24, line 23
default "disabled"; default "disabled";
description description
"Enable (client/radio) or disable (disabled) "Enable (client/radio) or disable (disabled)
the RF loop, which loops the signal back to the RF loop, which loops the signal back to
the client side or the radio side."; the client side or the radio side.";
} }
container capabilities { container capabilities {
config false; config false;
description description
"Capabilities of the the installed equipment and "Capabilities of the installed equipment and
some selected configurations."; some selected configurations.";
leaf min-tx-frequency { leaf min-tx-frequency {
type uint32; type uint32;
units "kHz"; units "kHz";
description description
"Minimum Tx frequency possible to use."; "Minimum Tx frequency possible to use.";
} }
leaf max-tx-frequency { leaf max-tx-frequency {
skipping to change at page 27, line 48 skipping to change at page 27, line 48
*/ */
container radio-link-protection-groups { container radio-link-protection-groups {
description description
"Configuration of radio link protected groups (1+1) of "Configuration of radio link protected groups (1+1) of
carrier terminations in a radio link. More than one carrier terminations in a radio link. More than one
protected group per radio-link-terminal is allowed."; protected group per radio-link-terminal is allowed.";
uses ifprot:protection-groups { uses ifprot:protection-groups {
refine protection-group/protection-members { refine protection-group/members {
must "/if:interfaces/if:interface[if:name = current()]" must "/if:interfaces/if:interface[if:name = current()]"
+ "/if:type = 'mrl:carrier-termination'" { + "/if:type = 'mrl:carrier-termination'" {
description description
"The type of a protection member must be "The type of a protection member must be
'carrier-termination'."; 'carrier-termination'.";
} }
} }
refine protection-group/working-entity { refine protection-group/working-entity {
must "/if:interfaces/if:interface[if:name = current()]" must "/if:interfaces/if:interface[if:name = current()]"
+ "/if:type = 'mrl:carrier-termination'" { + "/if:type = 'mrl:carrier-termination'" {
skipping to change at page 28, line 44 skipping to change at page 28, line 44
"Name used for identification of the XPIC pair."; "Name used for identification of the XPIC pair.";
} }
leaf enabled { leaf enabled {
type boolean; type boolean;
default "false"; default "false";
description description
"Enable(true)/disable(false) XPIC"; "Enable(true)/disable(false) XPIC";
} }
leaf-list xpic-members { leaf-list members {
type if:interface-ref; type if:interface-ref;
must "/if:interfaces/if:interface[if:name = current()]" must "/if:interfaces/if:interface[if:name = current()]"
+ "/if:type = 'mrl:carrier-termination'" { + "/if:type = 'mrl:carrier-termination'" {
description description
"The type of a xpic-member must be "The type of a member must be 'carrier-termination'.";
'carrier-termination'.";
} }
min-elements 2; min-elements 2;
max-elements 2; max-elements 2;
description description
"Association to XPIC pairs used in the radio link "Association to XPIC pairs used in the radio link
terminal."; terminal.";
} }
} }
} }
skipping to change at page 29, line 36 skipping to change at page 29, line 36
"Name used for identification of the MIMO group."; "Name used for identification of the MIMO group.";
} }
leaf enabled { leaf enabled {
type boolean; type boolean;
default "false"; default "false";
description description
"Enable(true)/disable(false) MIMO"; "Enable(true)/disable(false) MIMO";
} }
leaf-list mimo-members { leaf-list members {
type if:interface-ref; type if:interface-ref;
must "/if:interfaces/if:interface[if:name = current()]" must "/if:interfaces/if:interface[if:name = current()]"
+ "/if:type = 'mrl:carrier-termination'" { + "/if:type = 'mrl:carrier-termination'" {
description description
"The type of a mimo-member must be "The type of a member must be 'carrier-termination'.";
'carrier-termination'.";
} }
min-elements 2; min-elements 2;
description description
"Association to a MIMO group if used in the radio "Association to a MIMO group if used in the radio
link terminal."; link terminal.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
5. Interface Protection YANG Module 5. Interface Protection YANG Module
The data nodes for management of the interface protection The data nodes for management of the interface protection
functionality is broken out from the Microwave Radio Link Module functionality is broken out from the Microwave Radio Link Module
into a separate and generic YANG data module in order to make it into a separate and generic YANG data module in order to make it
available also for other interface types. available also for other interface types.
<CODE BEGINS> file "ietf-interface-protection.yang" <CODE BEGINS> file "ietf-interface-protection@2018-02-26.yang"
module ietf-interface-protection { module ietf-interface-protection {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-interface-protection"; namespace "urn:ietf:params:xml:ns:yang:ietf-interface-protection";
prefix ifprot; prefix ifprot;
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
reference "RFC7223bis";
} }
organization organization
"Internet Engineering Task Force (IETF) CCAMP WG"; "Internet Engineering Task Force (IETF) CCAMP WG";
contact contact
"WG List: <mailto:ccamp@ietf.org> "WG List: <mailto:ccamp@ietf.org>
ID-draft authors: ID-draft authors:
Jonas Ahlberg (jonas.ahlberg@ericsson.com); Jonas Ahlberg (jonas.ahlberg@ericsson.com);
Min Ye (amy.yemin@huawei.com); Min Ye (amy.yemin@huawei.com);
Xi Li (Xi.Li@neclab.eu); Xi Li (Xi.Li@neclab.eu);
Koji Kawada (k-kawada@ah.jp.nec.com)
Carlos J. Bernardos (cjbc@it.uc3m.es)
Daniela Spreafico (daniela.spreafico@nokia.com) Daniela Spreafico (daniela.spreafico@nokia.com)
Marko Vaupotic (Marko.Vaupotic@aviatnet.com)"; Marko Vaupotic (Marko.Vaupotic@aviatnet.com)";
description description
"This is a module for the entities in "This is a module for the entities in
a generic interface protection mechanism."; a generic interface protection mechanism.
Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved.";
revision 2017-10-19 { revision 2018-02-26 {
description description "Update with respect to the YANG Guideline";
"Draft revision."; reference "RFC XXXX: A YANG Data Model for Microwave Radio Link";
reference "";
} }
/* /*
* Protection architecture type identities * Protection architecture type identities
*/ */
identity protection-architecture-type { identity protection-architecture-type {
description description
"protection architecture type"; "protection architecture type";
reference "ITU-T Rec. G.808.1"; reference "ITU-T Rec. G.808.1";
skipping to change at page 32, line 29 skipping to change at page 32, line 29
reference "ITU-T Rec. G.808.1"; reference "ITU-T Rec. G.808.1";
} }
identity forced-switch{ identity forced-switch{
base protection-external-commands; base protection-external-commands;
description description
"A switch action initiated by an operator command. "A switch action initiated by an operator command.
It switches normal traffic signal to the protection It switches normal traffic signal to the protection
transport entity and forces it to remain on that transport entity and forces it to remain on that
entity even when criteria for switching back to entity even when criteria for switching back to
the orignal entity are fulfilled."; the original entity are fulfilled.";
reference "ITU-T Rec. G.808.1"; reference "ITU-T Rec. G.808.1";
} }
identity lockout-of-protection{ identity lockout-of-protection{
base protection-external-commands; base protection-external-commands;
description description
"A switch action temporarily disables access to the "A switch action temporarily disables access to the
protection transport entity for all signals."; protection transport entity for all signals.";
reference "ITU-T Rec. G.808.1"; reference "ITU-T Rec. G.808.1";
} }
skipping to change at page 33, line 16 skipping to change at page 33, line 16
description description
"A switch action to test if the APS communication is "A switch action to test if the APS communication is
operating correctly. It is lower priority than any 'real' operating correctly. It is lower priority than any 'real'
switch request.."; switch request..";
reference "ITU-T Rec. G.808.1"; reference "ITU-T Rec. G.808.1";
} }
identity clear{ identity clear{
base protection-external-commands; base protection-external-commands;
description description
"A action clears all switch commands."; "An action clears all switch commands.";
reference "ITU-T Rec. G.808.1"; reference "ITU-T Rec. G.808.1";
} }
/* /*
* Protection Groups * Protection Groups
*/ */
grouping protection-groups { grouping protection-groups {
description description
"Configuration of protected groups (1+1) of interfaces "Configuration of protected groups (1+1) of interfaces
skipping to change at page 33, line 46 skipping to change at page 33, line 46
leaf name { leaf name {
type string; type string;
description description
"Name used for identification of the protection group"; "Name used for identification of the protection group";
} }
leaf protection-architecture-type { leaf protection-architecture-type {
type identityref{ type identityref{
base protection-architecture-type; base protection-architecture-type;
} }
default "one-plus-one-type"; default "ifprot:one-plus-one-type";
description description
"The type of protection architecture used, e.g. one "The type of protection architecture used, e.g. one
interface protecting one or several other interfaces."; interface protecting one or several other interfaces.";
reference "ITU-T Rec. G.808.1"; reference "ITU-T Rec. G.808.1";
} }
leaf-list protection-members { leaf-list members {
type if:interface-ref; type if:interface-ref;
min-elements 2; min-elements 2;
description description
"Association to a group of interfaces configured for "Association to a group of interfaces configured for
protection and used by a higher-layer-interface."; protection and used by a higher-layer-interface.";
} }
leaf protection-operation-type { leaf operation-type {
type enumeration { type enumeration {
enum "non-revertive" { enum "non-revertive" {
description description
"In non revertive operation, the traffic does not "In non revertive operation, the traffic does not
return to the working interface if the switch requests return to the working interface if the switch requests
are terminated."; are terminated.";
reference "ITU-T Rec. G.808.1"; reference "ITU-T Rec. G.808.1";
} }
enum "revertive" { enum "revertive" {
description description
skipping to change at page 34, line 36 skipping to change at page 34, line 36
reference "ITU-T Rec. G.808.1"; reference "ITU-T Rec. G.808.1";
} }
} }
default "non-revertive"; default "non-revertive";
description description
"The type of protection operation, i.e. revertive "The type of protection operation, i.e. revertive
or non-revertive operation."; or non-revertive operation.";
} }
leaf-list working-entity { leaf-list working-entity {
when "../protection-operation-type = 'revertive'"; when "../operation-type = 'revertive'";
type if:interface-ref; type if:interface-ref;
min-elements 1; min-elements 1;
description description
"The interfaces over which the traffic normally should "The interfaces over which the traffic normally should
be transported over when there is no need to use the be transported over when there is no need to use the
protecting interface."; protecting interface.";
} }
leaf revertive-wait-to-restore { leaf revertive-wait-to-restore {
when "../protection-operation-type = 'revertive'"; when "../operation-type = 'revertive'";
type uint16; type uint16;
units "seconds"; units "seconds";
default "0"; default "0";
description description
"The time to wait before switching back to the working "The time to wait before switching back to the working
interface if protection-operation-type is revertive."; interface if operation-type is revertive.";
reference "ITU-T Rec. G.808.1"; reference "ITU-T Rec. G.808.1";
} }
leaf hold-off-timer { leaf hold-off-timer {
type uint16; type uint16;
units "milliseconds"; units "milliseconds";
default "0"; default "0";
description description
"Time interval after the detection of a fault and its "Time interval after the detection of a fault and its
confirmation as a condition requiring the protection confirmation as a condition requiring the protection
switching procedure."; switching procedure.";
reference "ITU-T Rec. G.808.1"; reference "ITU-T Rec. G.808.1";
} }
leaf protection-status { leaf status {
type identityref { type identityref {
base protection-states; base protection-states;
} }
description description
"Status of the protection, in a group of interfaces "Status of the protection, in a group of interfaces
configured in a protection mode."; configured in a protection mode.";
reference "ITU-T Rec. G.808.1"; reference "ITU-T Rec. G.808.1";
} }
action protection-external-commands { action external-commands {
input { input {
leaf protection-external-command { leaf external-command {
type identityref { type identityref {
base protection-external-commands; base protection-external-commands;
} }
description description
"Execution of protection external commands for "Execution of protection external commands for
trouble shooting purpose."; trouble shooting purpose.";
} }
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
6. Security Considerations 6. Security Considerations
The YANG module defined in this memo is designed to be accessed via The YANG module specified in this document defines a schema for data
the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the that is designed to be accessed via network management protocols such
secure transport layer and the mandatory-to-implement secure as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
transport is SSH [RFC6242]. The NETCONF access control model is the secure transport layer, and the mandatory-to-implement secure
[RFC6536] provides the means to restrict access for particular transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
NETCONF users to a pre-configured subset of all available NETCONF is HTTPS, and the mandatory-to-implement secure transport is TLS
protocol operations and content. [RFC5246].
There are a number of data nodes defined in the YANG module which are The NETCONF access control model [RFC6536] provides the means to
restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., <editconfig>) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:
Interfaces of type radio-link-terminal:
/if:interfaces/if:interface/carrier-terminations,
/if:interfaces/if:interface/rlp-groups,
/if:interfaces/if:interface/xpic-pairs,
/if:interfaces/if:interface/mimo-groups, and
/if:interfaces/if:interface/tdm-connections:
These lists represent the configuration of the radio-link-terminal
and it need to match the configuration of the radio-link-terminal
on the other side of the radio link. Unauthorized access to these
data nodes could interrupt the ability to forward traffic.
Interfaces of type carrier-termination:
/if:interfaces/if:interface/carrier-id,
/if:interfaces/if:interface/tx-enabled,
/if:interfaces/if:interface/tx-frequency,
/if:interfaces/if:interface/rx-frequency,
/if:interfaces/if:interface/duplex-distance,
/if:interfaces/if:interface/channel-separation,
/if:interfaces/if:interface/power-mode,
/if:interfaces/if:interface/maximum-nominal-power,
/if:interfaces/if:interface/atpc-lower-threshold,
/if:interfaces/if:interface/atpc-upper-threshold,
/if:interfaces/if:interface/coding-modulation-mode,
/if:interfaces/if:interface/selected-cm,
/if:interfaces/if:interface/selected-min-acm,
/if:interfaces/if:interface/selected-max-acm,
/if:interfaces/if:interface/if-loop, and
/if:interfaces/if:interface/rf-loop:
These data nodes represent the configuration of the
carrier-termination and it need to match the configuration of the
carrier-termination on the other side of the carrier. Unauthorized
access to these data nodes could interrupt the ability to forward
traffic.
Radio link protection:
/radio-link-protection-groups/protection-group:
This list of protection groups and the constituent data nodes
represents the configuration of the protection of carrier
terminations. Unauthorized access to these data nodes could
interrupt the ability to forward traffic or remove the ability to
perform a necessary protection switch.
XPIC:
/xpic-pairs:
This list represents the XPIC configuration of a pair carriers.
Unauthorized access to these data nodes could interrupt the ability
to forward traffic.
MIMO:
/mimo-groups:
This list represents the MIMO configuration of multiple carriers.
Unauthorized access to these data nodes could interrupt the ability
to forward traffic.
The security considerations of [RFC7223bis] also apply to this The security considerations of [RFC7223bis] also apply to this
document. document.
7. IANA Considerations 7. IANA Considerations
TBD. It is proposed that IANA should assign new URIs from the
"IETF XML Registry" [RFC3688] as follows:
URI: urn:ietf:params:xml:ns:yang:ietf-microwave-radio-link
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-interface-protection
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace.
It is proposed that IANA should record YANG module names in the
"YANG Module Names" registry [RFC6020] as follows:
Name: ietf-microwave-radio-link
Namespace: urn:ietf:params:xml:ns:yang:ietf-microwave-radio-link
Prefix: mrl
Reference: RFC xxxx
Name: ietf-interface-protection
Namespace: urn:ietf:params:xml:ns:yang:ietf-interface-protection
Prefix: ifprot
Reference: RFC xxxx
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC7223bis] [RFC7223bis]
Bjorklund, M., "A YANG Data Model for Interface Bjorklund, M., "A YANG Data Model for Interface
Management", draft-bjorklund-netmod-rfc7223bis-00 Management", draft-bjorklund-netmod-rfc7223bis-00
(work in progress), September 2017. (work in progress), September 2017.
[EN 302 217-2] [EN302217-2]
ETSI, "Fixed Radio Systems; Characteristics and ETSI, "Fixed Radio Systems; Characteristics and
requirements for point to-point equipment and antennas; requirements for point to-point equipment and antennas;
Part 2: Digital systems operating in frequency bands from Part 2: Digital systems operating in frequency bands from
1 GHz to 86 GHz; Harmonised Standard covering the 1 GHz to 86 GHz; Harmonised Standard covering the
essential requirements of article 3.2 of Directive essential requirements of article 3.2 of Directive
2014/53/EU", EN 302 217-2 V3.1.1, May 2017. 2014/53/EU", EN 302 217-2 V3.1.1, May 2017.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, <https://www.rfc-
editor.org/info/rfc3688>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
March 2012.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<http://www.rfc-editor.org/info/rfc8040>.
8.2. Informative References 8.2. Informative References
[NMDA] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [NMDA] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
Wilton, R. "Network Management Datastore Architecture", and R. Wilton, "Network Management Datastore
draft-ietf-netmod-revised-datastores-05 (work in Architecture", draft-ietf-netmod-revised-datastores-10
progress), October 2017. (work in progress), January 2018.
[I-D.ahlberg-ccamp-microwave-radio-link] [I-D.ahlberg-ccamp-microwave-radio-link]
Ahlberg, J., Carlson, J., Lund, H., Olausson, T., Ye, M., Ahlberg, J., Carlson, J., Lund, H., Olausson, T., Ye, M.,
and M. Vaupotic, "Microwave Radio Link YANG Data Models", and M. Vaupotic, "Microwave Radio Link YANG Data Models",
draft-ahlberg-ccamp-microwave-radio-link-01 (work in draft-ahlberg-ccamp-microwave-radio-link-01 (work in
progress), May 2016. progress), May 2016.
[I-D.ietf-ccamp-microwave-framework] [I-D.ietf-ccamp-microwave-framework]
Ahlberg, J., Contreras, L., Ye, M., Vaupotic, M., Ahlberg, J., Contreras, L., Ye, M., Vaupotic, M.,
Tantsura, J., Kawada, K., Li, X., Akiyoshi, I., C. Tantsura, J., Kawada, K., Li, X., Akiyoshi, I., C.
Bernardos, and D. Spreafico, "A framework for Management Bernardos, and D. Spreafico, "A framework for Management
and Control of microwave and millimeter wave interface and Control of microwave and millimeter wave interface
parameters", draft-ietf-ccamp-microwave-framework-02 parameters", draft-ietf-ccamp-microwave-framework-05
(work in progress), October 2017. (work in progress), October 2017.
[ONF-model] "Microwave Modeling - ONF Wireless Transport Group", [ONF-model] "Microwave Modeling - ONF Wireless Transport Group",
May 2016. May 2016.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<http://www.rfc-editor.org/info/rfc6242>. <http://www.rfc-editor.org/info/rfc6242>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012, DOI 10.17487/RFC6536, March 2012,
<http://www.rfc-editor.org/info/rfc6536>. <http://www.rfc-editor.org/info/rfc6536>.
[YANG-TREE] Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-06 (work in progress),
February 2018.
Appendix A. Example: 1+0 and 2+0 configuration instances
This section gives simple examples of 1+0 and 2+0 instance using the
YANG module defined in this draft. The examples are not intended as
a complete module for 1+0 and 2+0 configuration.
A.1 1+0 instance
Figure A-1 shows a 1+0 example.
/--------- Radio Link ---------\
Near End Far End
+---------------+ +---------------+
| Radio Link | | Radio Link |
| Terminal - A | | Terminal - B |
| | | |
| | | |
| +-----------+ | | +-----------+ |
| | | | Carrier A | | | |
| | Carrier | |<--------->| | Carrier | |
| |Termination| | | |Termination| |
| | -1 | | | | -1 | |
| +-----------+ | | +-----------+ |
| | | |
| | | |
+---------------+ +---------------+
\--- Microwave Node ---/ \--- Microwave Node ---/
Figure A-1 1+0 example
The following instance shows the 1+0 configuration of Near End node.
"interface": [
{
//RLT-A
"name": "RLT-A",
"description": "Radio Link Terminal A",
"type": "mrl:radio-link-terminal",
"id": "RLT-A",
"mode": "one-plus-zero",
"carrier-terminations": [
"RLT-A:CT-1",
],
}
{
//CT-1
"name": "RLT-A:CT-1",
"description": "Carrier Termination 1",
"type": "mrl:carrier-termination",
"carrier-id": "A",
"tx-enabled": true,
"tx-oper-status": on
"tx-frequency": 10728000,
"duplex-distance": 644000,
"channel-separation": 28,
"polarization": not-specified,
"power-mode": rtpc,
"coding-modulation-mode": 0,
"selected-cm": "qam-512"
},
]
A.2 2+0 instance
Figure A-2 shows a 2+0 example.
/--------- Radio Link ---------\
Near End Far End
+---------------+ +---------------+
| Radio Link | | Radio Link |
| Terminal -A | | Terminal -B |
| | | |
| | | |
| +-----------+ | | +-----------+ |
| | | | Carrier A | | | |
| | Carrier | |<--------->| | Carrier | |
| |Termination| | | |Termination| |
| | -1 | | | | -1 | |
| +-----------+ | | +-----------+ |
| | | |
| +-----------+ | | +-----------+ |
| | | | Carrier B | | | |
| | Carrier | |<--------->| | Carrier | |
| |Termination| | | |Termination| |
| | -2 | | | | -2 | |
| +-----------+ | | +-----------+ |
| | | |
+---------------+ +---------------+
\--- Microwave Node ---/ \--- Microwave Node ---/]
Figure A-2 2+0 example
The following instance shows the 2+0 configuration of Near End node.
"interface": [
{
//RLT-A
"name": "RLT-A",
"description": "Radio Link Terminal A",
"type": "mrl:radio-link-terminal",
"id": "RLT-A",
"mode": "two-plus-zero",
"carrier-terminations": [
"RLT-A:CT-1",
"RLT-A:CT-2"
],
}
{
//CT-1
"name": "RLT-A:CT-1",
"description": "Carrier Termination 1",
"type": "mrl:carrier-termination",
"carrier-id": "A",
"tx-enabled": true,
"tx-oper-status": on
"tx-frequency": 10728000,
"duplex-distance": 644000,
"channel-separation": 28,
"polarization": not-specified,
"power-mode": rtpc,
"coding-modulation-mode": 0,
"selected-cm": "qam-512"
},
{
//CT-2
"name": "RLT-A:CT-2",
"description": "Carrier Termination 2",
"type": "mrl:carrier-termination",
"carrier-id": "B",
"tx-enabled": true,
"tx-oper-status": on
"tx-frequency": 10618000,
"duplex-distance": 644000,
"channel-separation": 28,
"polarization": not-specified,
"power-mode": rtpc,
"coding-modulation-mode": 0,
"selected-cm": "qam-512"
},
]
Appendix B. Contributors
Koji Kawada
NEC Corporation
1753, Shimonumabe Nakahara-ku
Kawasaki, Kanagawa 211-8666
Japan (JPN)
Email: k-kawada@ah.jp.nec.com
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain (ESP)
Email: cjbc@it.uc3m.es
Authors' Addresses Authors' Addresses
Jonas Ahlberg Jonas Ahlberg
Ericsson AB Ericsson AB
Lindholmspiren 11 Lindholmspiren 11
Goeteborg 417 56 Goeteborg 417 56
Sweden Sweden (SWE)
Email: jonas.ahlberg@ericsson.com Email: jonas.ahlberg@ericsson.com
Ye Min Ye Min
Huawei Technologies Huawei Technologies
No.1899, Xiyuan Avenue No.1899, Xiyuan Avenue
Chengdu 611731 Chengdu 611731
P.R.China P.R.China (CHN)
Email: amy.yemin@huawei.com Email: amy.yemin@huawei.com
Xi Li Xi Li
NEC Laboratories Europe NEC Laboratories Europe
Kurfursten-Anlage 36 Kurfursten-Anlage 36
Heidelberg 69115 Heidelberg 69115
Germany Germany (DEU)
Email: Xi.Li@neclab.eu Email: Xi.Li@neclab.eu
Koji Kawada
NEC Corporation
1753, Shimonumabe Nakahara-ku
Kawasaki, Kanagawa 211-8666
Japan
Email: k-kawada@ah.jp.nec.com
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Email: cjbc@it.uc3m.es
Daniela Spreafico Daniela Spreafico
Nokia - IT Nokia - IT
Via Energy Park, 14 Via Energy Park, 14
Vimercate (MI) 20871 Vimercate (MI) 20871
Italy Italy (ITA)
Email: daniela.spreafico@nokia.com Email: daniela.spreafico@nokia.com
Marko Vaupotic Marko Vaupotic
Aviat Networks Aviat Networks
Motnica 9 Motnica 9
Trzin-Ljubljana 1236 Trzin-Ljubljana 1236
Slovenia Slovenia (SVN)
Email: Marko.Vaupotic@Aviatnet.com Email: Marko.Vaupotic@Aviatnet.com
 End of changes. 63 change blocks. 
177 lines changed or deleted 424 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/