draft-ietf-mpls-tp-rosetta-stone-12.txt   draft-ietf-mpls-tp-rosetta-stone-13.txt 
MPLS Working Group H. van Helvoort (Ed) MPLS Working Group H. van Helvoort (Ed)
Internet Draft Huawei Technologies Internet Draft Huawei Technologies
Intended status: Informational Intended status: Informational
Expires: March 2014 L. Andersson (Ed) Expires: April 2014 L. Andersson (Ed)
Huawei Technologies Huawei Technologies
N. Sprecher (Ed) N. Sprecher (Ed)
Nokia Siemens Networks Nokia Solutions and Networks
September 6, 2013 October 20, 2013
A Thesaurus for the Terminology used in Multiprotocol Label A Thesaurus for the Terminology used in Multiprotocol Label
Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's
Transport Network Recommendations. Transport Network Recommendations.
draft-ietf-mpls-tp-rosetta-stone-12 draft-ietf-mpls-tp-rosetta-stone-13
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any 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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 6, 2014. This Internet-Draft will expire on April 20, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
MPLS-TP is based on a profile of the MPLS and PW procedures as MPLS Transport Profile (MPLS-TP) is based on a profile of the MPLS
specified in the MPLS-TE and (MS-)PW architectures developed by the and Pseudowire (PW) procedures as specified in the MPLS-TE, PW and
IETF. The ITU-T has specified a Transport Network architecture. Multi-Segment Pseudowire (MS-PW) architectures developed by the
Internet Engineering Task Force (IETF). The International
Telecommunications Union Telecommunications Standardization Sector
(ITU-T) has specified a Transport Network architecture.
This document provides a thesaurus for the interpretation of MPLS-TP This document provides a thesaurus for the interpretation of MPLS-TP
terminology within the context of the ITU-T Transport Network terminology within the context of the ITU-T Transport Network
recommendations. Recommendations.
It is important to note that MPLS-TP is applicable in a wider set of It is important to note that MPLS-TP is applicable in a wider set of
contexts than just Transport Networks. The definitions presented in contexts than just Transport Networks. The definitions presented in
this document do not provide exclusive nor complete interpretations this document do not provide exclusive nor complete interpretations
of MPLS-TP concepts. This document simply allows the MPLS-TP terms of MPLS-TP concepts. This document simply allows the MPLS-TP terms
to be applied within the Transport Network context. to be applied within the Transport Network context.
Table of Contents Table of Contents
1 Introduction 4 1 Introduction 4
1.1 Contributing Authors 4 1.1 Contributing Authors 4
1.2 Abbreviations 4 1.2 Abbreviations 4
1.3 5 2 Terminology 6
2 Terminology 5 2.1 MPLS-TP Terminology Sources 6
2.1 MPLS-TP Terminology Sources 5 2.2 ITU-T Transport Network Terminology Sources 6
2.2 ITU-T Transport Network Terminology Sources 5
2.3 Common Terminology Sources 6 2.3 Common Terminology Sources 6
3 Thesaurus 6 3 Thesaurus 6
3.1 Associated bidirectional path: 6 3.1 Associated bidirectional path: 6
3.2 Bidirectional path: 6 3.2 Bidirectional path: 7
3.3 Client layer network: 6 3.3 Client layer network: 7
3.4 Communication Channel (CC): 6 3.4 Communication Channel: 7
3.5 Concatenated Segment: 7 3.5 Concatenated Segment: 7
3.6 Control Plane: 7 3.6 Control Plane: 7
3.7 Co-routed bidirectional path: 7 3.7 Co-routed bidirectional path: 7
3.8 Data Communication Network (DCN): 7 3.8 Data Communication Network (DCN): 8
3.9 Defect: 7 3.9 Defect: 8
3.10 Domain: 7 3.10 Domain: 8
3.11 Embedded Communication Channel (ECC): 8 3.11 Embedded Communication Channel (ECC): 8
3.12 Equipment Management Function (EMF): 8 3.12 Equipment Management Function (EMF): 8
3.13 Failure: 8 3.13 Failure: 8
3.14 Fault: 8 3.14 Fault: 9
3.15 Layer network: 8 3.15 Layer network: 9
3.16 Link: 9 3.16 Link: 9
3.17 Maintenance Entity (ME): 9 3.17 Maintenance Entity (ME): 9
3.18 Maintenance Entity Group (MEG): 9 3.18 Maintenance Entity Group (MEG): 10
3.19 Maintenance Entity Group End Point (MEP): 10 3.19 Maintenance Entity Group End Point (MEP): 10
3.20 Maintenance Entity Group Intermediate Point (MIP): 10 3.20 Maintenance Entity Group Intermediate Point (MIP): 11
3.21 Management Communication Channel (MCC): 10 3.21 Management Communication Channel (MCC): 11
3.22 Management Communication Network (MCN): 10 3.22 Management Communication Network (MCN): 11
3.23 Monitoring 11 3.23 Monitoring 11
3.23.1 Path Segment Tunnel (PST): 11 3.23.1 Path Segment Tunnel (PST): 12
3.23.2 Sub-Path Maintenance Element (SMPE): 11 3.23.2 Sub-Path Maintenance Element (SPME): 12
3.23.3 Tandem Connection: 11 3.23.3 Tandem Connection: 12
3.24 MPLS Section: 12 3.24 MPLS Section: 13
3.25 MPLS Transport Profile (MPLS-TP): 12 3.25 MPLS Transport Profile (MPLS-TP): 13
3.26 MPLS-TP NE: 12 3.26 MPLS-TP NE: 13
3.27 MPLS-TP network: 12 3.27 MPLS-TP network: 13
3.28 MPLS-TP Recovery: 12 3.28 MPLS-TP Recovery: 13
3.28.1 End-to-end recovery: 12 3.28.1 End-to-end recovery: 13
3.28.2 Link recovery: 12 3.28.2 Link recovery: 13
3.28.3 Segment recovery: 12 3.28.3 Segment recovery: 13
3.29 MPLS-TP Ring Topology: 13 3.29 MPLS-TP Ring Topology: 13
3.29.1 MPLS-TP Logical Ring: 13 3.29.1 MPLS-TP Logical Ring: 14
3.29.2 MPLS-TP Physical Ring: 13 3.29.2 MPLS-TP Physical Ring: 14
3.30 OAM flow: 13 3.30 OAM flow: 14
3.31 Operations System (OS): 13 3.31 Operations System (OS): 14
3.32 Path: 13 3.32 Path: 14
3.33 Protection priority: 13 3.33 Protection priority: 14
3.34 Section Layer Network: 14 3.34 Section Layer Network: 14
3.35 Segment: 14 3.35 Segment: 15
3.36 Server layer: 14 3.36 Server layer: 15
3.37 Server MEPs: 14 3.37 Server MEPs: 15
3.38 Signaling Communication Channel (SCC): 15 3.38 Signaling Communication Channel (SCC): 16
3.39 Signaling Communication Network (SCN): 15 3.39 Signaling Communication Network (SCN): 16
3.40 Span: 15 3.40 Span: 16
3.41 Sublayer: 15 3.41 Sublayer: 16
3.42 Transport Entity: 15 3.42 Transport Entity: 16
3.42.1 Working Entity: 16 3.42.1 Working Entity: 16
3.42.2 Protection Entity: 16 3.42.2 Protection Entity: 17
3.42.3 Recovery entity: 16 3.42.3 Recovery entity: 17
3.43 Transmission media layer: 16 3.43 Transmission media layer: 17
3.44 Transport Network: 16 3.44 Transport Network: 17
3.45 Transport path: 16 3.45 Transport path: 17
3.46 Transport path layer: 16 3.46 Transport path layer: 17
3.47 Transport service layer: 17 3.47 Transport service layer: 18
3.48 Unidirectional path: 17 3.48 Unidirectional path: 18
4 Guidance on the Application of this Thesaurus 17 4 Guidance on the Application of this Thesaurus 18
5 Management Considerations 17 5 Management Considerations 18
6 Security Considerations 18 6 Security Considerations 18
7 IANA Considerations 18 7 IANA Considerations 19
8 Acknowledgments 18 8 Acknowledgments 19
9 References 18 9 References 19
9.1 Normative References 18 9.1 Normative References 19
9.2 Informative References 20 9.2 Informative References 20
1 Introduction 1 Introduction
Multiprotocol Label Switching - Transport Profile (MPLS-TP) has been Multiprotocol Label Switching - Transport Profile (MPLS-TP) has been
developed by the IETF to facilitate the Operation, Administration developed by the IETF to facilitate the Operation, Administration
and Management of Label Switched Paths (LSPs) in a Transport Network and Management of Label Switched Paths (LSPs) to be used in a
environment as defined by the ITU-T. Transport Network environment as defined by the ITU-T.
The ITU-T has specified a Transport Network architecture for the The ITU-T has specified a Transport Network architecture for the
transfer of signals from different technologies. This architecture transfer of signals from different technologies. This architecture
forms the basis of many Recommendations within the ITU-T. forms the basis of many Recommendations within the ITU-T.
Because of the difference in historic background of MPLS, and Because of the difference in historic background of MPLS, and
inherently MPLS-TP (the Internet) and the Transport Network (ITU inherently MPLS-TP (the Internet) and the Transport Network (ITU
telecommunication Sector), the terminology used is different. Telecommunication Sector), the terminology used is different.
This document provides a thesaurus for the interpretation of ITU-T This document provides a thesaurus for the interpretation of MPLS-TP
Transport Network terminology within the context of the MPLS-TP. terminology within the context of the ITU-T Transport Network
This allows MPLS-TP documents to be generally understood by those Recommendations. This allows MPLS-TP documents to be generally
familiar with MPLS RFCs. The definitions presented in this document understood by those familiar with MPLS RFCs. The definitions
do not provide exclusive or complete interpretations of the ITU-T presented in this document do not provide exclusive or complete
Transport Network concepts. interpretations of the ITU-T Transport Network concepts.
1.1 Contributing Authors 1.1 Contributing Authors
Italo Busi, Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven Italo Busi, Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven
Levrau, Dinesh Mohan, Stuart Bryant, Dan Frost, Matthew Bocci, Levrau, Dinesh Mohan, Stuart Bryant, Dan Frost, Matthew Bocci,
Vincenzo Sestito, Vigoureux, Yaacov Weingarten Vincenzo Sestito, Vigoureux, Yaacov Weingarten
1.2 Abbreviations 1.2 Abbreviations
CC Communications Channel
CE Customer Edge CE Customer Edge
DCC Data Communication Channel
DCN Data Communication Network DCN Data Communication Network
ECC Embedded Communication Channel ECC Embedded Communication Channel
EMF Equipment Management Function EMF Equipment Management Function
EMS Element Management System
GAL Generic Associated Channel Label
NEF Network Element Function
LER Label Edge Router
LSR Label Switching Router
MCC Management Communication Channel MCC Management Communication Channel
MCN Management Communication Network MCN Management Communication Network
ME Maintenance Entity ME Maintenance Entity
MEG Maintenance Entity Group MEG Maintenance Entity Group
MEP Maintenance Entity Group End Point MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point MIP Maintenance Entity Group Intermediate Point
skipping to change at page 5, line 18 skipping to change at page 5, line 30
MEG Maintenance Entity Group MEG Maintenance Entity Group
MEP Maintenance Entity Group End Point MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point MIP Maintenance Entity Group Intermediate Point
MPLS Multiprotocol Label Switching MPLS Multiprotocol Label Switching
MPLS-TP MPLS Transport Profile MPLS-TP MPLS Transport Profile
MS-PW Multi-Segment Pseudowire
NE Network Element NE Network Element
OAM Operations, Administration and Maintenance OAM Operations, Administration, and Maintenance
OSS Operations Support System
PM Performance Monitoring PM Performance Monitoring
PST Path Segment Tunnel PST Path Segment Tunnel
PW Pseudowire
S-PE PW Switching Provider Edge
SCC Signaling Communication Channel SCC Signaling Communication Channel
SCN Signaling Communication Network SCN Signaling Communication Network
SPME Sub-Path Maintenance Element SPME Sub-Path Maintenance Element
T-PE PW Terminating Provider Edge
TCM Tandem Connection Monitoring TCM Tandem Connection Monitoring
2 Terminology 2 Terminology
2.1 MPLS-TP Terminology Sources 2.1 MPLS-TP Terminology Sources
MPLS-TP terminology is principally defined in [RFC3031]. Other MPLS-TP terminology is principally defined in [RFC3031]. Other
documents provide further key definitions including [RFC4397]. documents provide further key definitions including [RFC4397].
2.2 ITU-T Transport Network Terminology Sources 2.2 ITU-T Transport Network Terminology Sources
The ITU-T Transport Network is specified in a number of The ITU-T Transport Network is specified in a number of
recommendations: generic functional architectures and requirements Recommendations: generic functional architectures and requirements
are specified in [ITU-T_G.805], [ITU-T_G.806], and [ITU-T_G.872]. are specified in [ITU-T_G.805], [ITU-T_G.806], and [ITU-T_G.872].
ITU-T Recommendation [ITU-T_G.8101] contains an overview of the ITU-T Recommendation [ITU-T_G.8101] contains an overview of the
Terms and Definitions for transport MPLS. Terms and Definitions for transport MPLS.
2.3 Common Terminology Sources 2.3 Common Terminology Sources
The work in this document builds on the shared view of MPLS The work in this document builds on the shared view of MPLS
requirements. requirements. It is intended to provide a source for common MPLS-TP
terminology. In general the original terminology is used.
The following sources are used: The following sources are used:
IETF framework and requirements RFCs: [RFC6371], [RFC6372], IETF framework and requirements RFCs: [RFC6371], [RFC6372],
[RFC5654], [RFC5921], [RFC5860], [RFC5951], [RFC3031] and [RFC4397]. [RFC5654], [RFC5921], [RFC5860], [RFC5951], [RFC3031] and [RFC4397].
ITU-T architecture and requirements Recommendations: [ITU-T_G.8101], ITU-T architecture and requirements Recommendations: [ITU-T_G.8101],
[ITU-T_G.805], [ITU-T_G.806], [ITU-T_G.872], [ITU-T G.7710] and [ITU-T_G.805], [ITU-T_G.806], [ITU-T_G.872], [ITU-T G.7710] and
[ITU-T Y.2611]. [ITU-T Y.2611].
3 Thesaurus 3 Thesaurus
3.1 Associated bidirectional path: 3.1 Associated bidirectional path:
A path that supports traffic flow in both directions but that is A path that supports traffic flow in both directions but that is
constructed from a pair of unidirectional paths (one for each constructed from a pair of unidirectional paths (one for each
direction) that are associated with one another at the path's direction) that are associated with one another at the path's
ingress/egress points. The forward and backward directions are ingress/egress points. An associated bidirectional path needs not
setup, monitored, and protected independently. As a consequence, be a single management and operational entity. The forward and
they may or may not follow the same route (links and nodes) across backward directions are setup, monitored, and protected
the network. independently. As a consequence, they may or may not follow the
same route (links and nodes) across the network.
3.2 Bidirectional path: 3.2 Bidirectional path:
A path that supports traffic flow in two opposite directions, i.e. A path that supports traffic flow in two opposite directions, i.e.
the forward and backward direction. the forward and backward direction.
3.3 Client layer network: 3.3 Client layer network:
In a client/server relationship (see [ITU-T_G.805]), the client In a client/server relationship (see [ITU-T_G.805]), the client
layer network receives a (transport) service from the lower server layer network receives a (transport) service from the lower server
layer network (usually the layer network under consideration). layer network (usually the layer network under consideration).
3.4 Communication Channel (CC): 3.4 Communication Channel:
A logical channel between network elements (NEs) that can be used - A logical channel between network elements (NEs) that can be used -
e.g. - for management plane application or control plane e.g. - for management plane application or control plane
applications. The physical channel supporting the CC is technology applications. The physical channel supporting the Communication
specific. See [RFC5951] APPENDIX A. Channel is technology specific. See [RFC5951] Appendix A.
3.5 Concatenated Segment: 3.5 Concatenated Segment:
A serial-compound link connection as defined in [ITU-T_G.805]. A A serial-compound link connection as defined in [ITU-T_G.805]. A
concatenated segment is a contiguous part of an LSP or multi-segment concatenated segment is a contiguous part of an LSP or MS-PWthat
PW that comprises a set of segments and their interconnecting nodes comprises a set of segments and their interconnecting nodes in
in sequence. See also "Segment". sequence. See also "Segment".
3.6 Control Plane: 3.6 Control Plane:
Within the scope of [RFC5654], the control plane performs transport Within the scope of [RFC5654], the control plane performs transport
path control functions. Through signalling, the control plane sets path control functions. Through signalling, the control plane sets
up, modifies and releases transport paths, and may recover a up, modifies and releases transport paths, and may recover a
transport path in case of a failure. The control plane also transport path in case of a failure. The control plane also
performs other functions in support of transport path control, such performs other functions in support of transport path control, such
as routing information dissemination. as routing information dissemination. It is possible to operate an
MPLS-TP network without using a Control Plane.
3.7 Co-routed bidirectional path: 3.7 Co-routed bidirectional path:
A path where the forward and backward directions follow the same A path where the forward and backward directions follow the same
route (links and nodes) across the network. Both directions are route (links and nodes) across the network. A co-routed
setup, monitored and protected as a single entity. A transport bidirectional path is managed and operated as a single entity. Both
network path is typically co-routed. directions are setup, monitored and protected as a single entity. A
transport network path is typically co-routed.
3.8 Data Communication Network (DCN): 3.8 Data Communication Network (DCN):
A network that supports Layer 1 (physical layer), Layer 2 (data-link A network that supports Layer 1 (physical layer), Layer 2 (data-link
layer), and Layer 3 (network layer) functionality for distributed layer), and Layer 3 (network layer) functionality for distributed
management communications related to the management plane, for management communications related to the management plane, for
distributed signaling communications related to the control plane, distributed routing and signaling communications related to the
and other operations communications (e.g., order-wire/voice control plane, and other operations communications (e.g., order-
communications, software downloads, etc.). wire/voice communications, software downloads, etc.).
3.9 Defect: 3.9 Defect:
The situation for which the density of anomalies has reached a level The situation for which the density of anomalies has reached a level
where the ability to perform a required function has been where the ability to perform a required function has been
interrupted. Defects are used as input for Performance Monitoring interrupted. Defects are used as input for Performance Monitoring
(PM), the control of consequent actions, and the determination of (PM), the control of consequent actions, and the determination of
fault cause. See also [ITU-T_G.806]. fault cause. See also [ITU-T_G.806].
3.10 Domain: 3.10 Domain:
A domain represents a collection of entities (for example network A domain represents a collection of entities (for example network
skipping to change at page 8, line 12 skipping to change at page 8, line 37
relationships, addressing schemes, infrastructure capabilities, relationships, addressing schemes, infrastructure capabilities,
aggregation, survivability techniques, distributions of control aggregation, survivability techniques, distributions of control
functionality, etc. Examples of such domains include IGP areas and functionality, etc. Examples of such domains include IGP areas and
Autonomous Systems. Autonomous Systems.
3.11 Embedded Communication Channel (ECC): 3.11 Embedded Communication Channel (ECC):
A logical operations channel between network elements (NEs) that can A logical operations channel between network elements (NEs) that can
be utilized by multiple applications (e.g., management plane be utilized by multiple applications (e.g., management plane
applications, control plane applications, etc.). The physical applications, control plane applications, etc.). The physical
channel supporting the ECC is technology specific. An example of channel supporting the ECC is technology specific. An example of a
physical channels supporting the ECC is a DCC channel within SDH. physical channel supporting the ECC is a Data Communication Channel
(DCC) within SDH.
3.12 Equipment Management Function (EMF): 3.12 Equipment Management Function (EMF):
The management functions within an NE. See [ITU-T G.7710]. The equipment management function (EMF) provides the means through
which an element management system (EMS) and other managing entities
manage the network element function (NEF). See [ITU-T G.7710].
3.13 Failure: 3.13 Failure:
The fault cause persisted long enough to consider the ability of an A failure is a detected fault. A failure will be declared when the
item to perform a required function to be terminated. The item may fault cause persisted long enough to consider the ability of an item
be considered as failed; a fault has now been detected. See also to perform a required transport function to be terminated. The item
[ITU-T_G.806]. may be considered as failed; a fault has now been detected. See
also [ITU-T_G.806]. A failure can be used as a trigger for
corrective actions.
3.14 Fault: 3.14 Fault:
A Fault is the inability of a function to perform a required action. A Fault is the inability of a transport function to perform a
This does not include an inability due to preventive maintenance, required action. This does not include an inability due to
lack of external resources, or planned actions. See also [ITU- preventive maintenance, lack of external resources, or planned
T_G.806]. actions. See also [ITU-T_G.806].
3.15 Layer network: 3.15 Layer network:
Layer network is defined in [ITU-T_G.805]. A layer network provides Layer network is defined in [ITU-T_G.805]. A layer network provides
for the transfer of client information and independent operation of for the transfer of client information and independent operation of
the client OAM. A layer network may be described in a service the client OAM. A layer network may be described in a service
context as follows: one layer network may provide a (transport) context as follows: one layer network may provide a (transport)
service to a higher client layer network and may, in turn, be a service to a higher client layer network and may, in turn, be a
client to a lower-layer network. A layer network is a logical client to a lower-layer network. A layer network is a logical
construction somewhat independent of arrangement or composition of construction somewhat independent of arrangement or composition of
skipping to change at page 9, line 7 skipping to change at page 9, line 35
may topologically belong to more than one layer network, depending may topologically belong to more than one layer network, depending
on the actions it takes on the encapsulation associated with the on the actions it takes on the encapsulation associated with the
logical layers (e.g., the label stack), and thus could be modeled as logical layers (e.g., the label stack), and thus could be modeled as
multiple logical elements. A layer network may consist of one or multiple logical elements. A layer network may consist of one or
more sublayers. For additional explanation of how layer networks more sublayers. For additional explanation of how layer networks
relate to the OSI concept of layering, see Appendix I of [ITU-T relate to the OSI concept of layering, see Appendix I of [ITU-T
Y.2611]. Y.2611].
3.16 Link: 3.16 Link:
A physical or logical connection between a pair of LSRs that are A physical or logical connection between a pair of Label Switching
adjacent at the (sub)layer network under consideration. A link may Routers (LSRs) that are adjacent at the (sub)layer network under
carry zero, one or more LSPs or PWs. A packet entering a link will consideration. A link may carry zero, one or more LSPs or PWs. A
emerge with the same label stack entry values. packet entering a link will emerge with the same label stack entry
values.
A link as defined in [ITU-T_G.805] is used to describe a fixed A link as defined in [ITU-T_G.805] is used to describe a fixed
relationship between two ports. relationship between two ports.
3.17 Maintenance Entity (ME): 3.17 Maintenance Entity (ME):
A Maintenance Entity (ME) can be viewed as the association of two A Maintenance Entity (ME) can be viewed as the association of two
(or more) Maintenance Entity Group End Points (MEPs), that should be (or more) Maintenance Entity Group End Points (MEPs), that should be
configured and managed in order to bound the OAM responsibilities of configured and managed in order to bound the OAM responsibilities of
an OAM flow across a network or sub-network, i.e. a transport path an OAM flow across a network or sub-network, i.e. a transport path
or segment, in the specific layer network that is being monitored or segment, in the specific layer network that is being monitored
and managed. See also [RFC6371] section 3.1 and [ITU-T G.8113.1], and managed. See also [RFC6371] section 3.1 and [ITU-T G.8113.1],
[ITU-T G.8113.2] clause 6.1. [ITU-T G.8113.2] clause 6.1.
A Maintenance Entity may be defined to monitor and manage A Maintenance Entity may be defined to monitor and manage
bidirectional or unidirectional point-to-point connectivity or bidirectional or unidirectional point-to-point connectivity or
point-to-multipoint connectivity in an MPLS-TP layer network. point-to-multipoint connectivity in an MPLS-TP layer network.
Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity Therefore, in the context of a MPLS-TP LSP ME or PW ME Label Edge
(defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can Routers (LERs) and PW Terminating Provider Edges (T-PEs) can be MEPs
be MIPs. In the case of Tandem Connection Maintenance Entity while LSRs and PW Switching Provider Edges (S-PEs) can be MIPs. In
(defined below), LSRs and S-PEs can be either MEPs or MIPs. the case of a ME for a Tandem Connection, LSRs and S-PEs can be
either MEPs or MIPs.
The following properties apply to all MPLS-TP MEs: The following properties apply to all MPLS-TP MEs:
OAM entities can be nested but not overlapped. = OAM entities can be nested but not overlapped.
Each OAM flow is associated to a unique Maintenance Entity. = Each OAM flow is associated to a unique Maintenance Entity.
OAM packets are subject to the same forwarding treatment as the data = OAM packets are subject to the same forwarding treatment as the
traffic, but they are distinct from the data traffic. data traffic, but they are distinct from the data traffic by the
Generic Associated Channel Label (GAL).
3.18 Maintenance Entity Group (MEG): 3.18 Maintenance Entity Group (MEG):
A Maintenance Entity Group is defined, for the purpose of connection A Maintenance Entity Group is defined, for the purpose of connection
monitoring, between a set of connection points within a connection. monitoring, between a set of connection points within a connection.
This set of connection points may be located at the boundary of one This set of connection points may be located at the boundary of one
administrative domain or a protection domain, or the boundaries of administrative domain or a protection domain, or the boundaries of
two adjacent administrative domains. The MEG may consist of one or two adjacent administrative domains. The MEG may consist of one or
more Maintenance Entities (ME). See also [RFC6371] section 3.1 and more Maintenance Entities (ME). See also [RFC6371] section 3.1 and
[ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.2. [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.2.
skipping to change at page 10, line 23 skipping to change at page 11, line 11
be transferred to its corresponding peer or sink MEP, or to an be transferred to its corresponding peer or sink MEP, or to an
intermediate MIP that is part of the ME. See also [RFC6371] section intermediate MIP that is part of the ME. See also [RFC6371] section
3.3 and [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.3. 3.3 and [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.3.
A sink MEP terminates all the OAM packets that it receives A sink MEP terminates all the OAM packets that it receives
corresponding to its ME and does not forward them further along the corresponding to its ME and does not forward them further along the
path. path.
All OAM packets coming into a source MEP are tunnelled via label All OAM packets coming into a source MEP are tunnelled via label
stacking and are not processed within the ME as they belong either stacking and are not processed within the ME as they belong either
to the client network layers or to an higher TCM level. to the client network layers or to a higher Tandem Connection
Monitoring (TCM) level.
A MEP in a tandem connection is not coincident with the termination A MEP in a tandem connection is not coincident with the termination
of the MPLS-TP transport path (LSP or PW), though it can monitor its of the MPLS-TP transport path (LSP or PW), though it can monitor its
connectivity (e.g. count packets). A MEP of an MPLS-TP network connectivity (e.g. count packets). A MEP of an MPLS-TP network
transport path is coincident with transport path termination and transport path is coincident with transport path termination and
monitors its connectivity (e.g. count packets). monitors its connectivity (e.g. counts packets).
An MPLS-TP sink MEP can notify a fault condition to its MPLS-TP An MPLS-TP sink MEP can notify a fault condition to its MPLS-TP
client layer network. client layer network.
3.20 Maintenance Entity Group Intermediate Point (MIP): 3.20 Maintenance Entity Group Intermediate Point (MIP):
A Maintenance Entity Group Intermediate Point (MIP) is a point A Maintenance Entity Group Intermediate Point (MIP) is a point
between the two MEPs in an ME and is capable of responding to some between the two MEPs in an ME and is capable of responding to some
OAM packets and forwarding all OAM packets while ensuring fate OAM packets and forwarding all OAM packets while ensuring fate
sharing with data plane packets. A MIP responds only to OAM packets sharing with data plane packets. A MIP responds only to OAM packets
that are sent on the ME it belongs to and that are addressed to the that are sent on the ME it belongs to and that are addressed to the
MIP, it does not initiate OAM messages. See also [RFC6371] section MIP, it does not initiate OAM messages. See also [RFC6371] section
3.4 and [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.4. 3.4 and [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.4.
3.21 Management Communication Channel (MCC): 3.21 Management Communication Channel (MCC):
A CC dedicated for management plane communications. A Communication Channel dedicated for management plane
communications.
3.22 Management Communication Network (MCN): 3.22 Management Communication Network (MCN):
A DCN supporting management plane communication is referred to as a A DCN supporting management plane communication is referred to as a
Management Communication Network (MCN). Management Communication Network (MCN).
3.23 Monitoring 3.23 Monitoring
Monitoring is applying OAM functionality to verify and to maintain Monitoring is applying OAM functionality to verify and to maintain
the performance and the quality guarantees of a transport path. the performance and the quality guarantees of a transport path.
There is a need to not only monitor the whole transport path (e.g. There is a need to not only monitor the whole transport path (e.g.
LSP or MS-PW), but also arbitrary parts of transport paths. The LSP or MS-PW), but also arbitrary parts of transport paths. The
connection between any two arbitrary points along a transport path connection between any two arbitrary points along a transport path
is described in three ways: is described in one of three ways:
- as a Path Segment Tunnel, - as a Path Segment Tunnel,
- as a Sub-Path Maintenance Element, and - as a Sub-Path Maintenance Element, or
- as a Tandem Connections. - as a Tandem Connection.
3.23.1 Path Segment Tunnel (PST): 3.23.1 Path Segment Tunnel (PST):
A path segment is either a segment or a concatenated segment. Path A path segment is either a segment or a concatenated segment. Path
Segment Tunnels (PSTs) are instantiated to provide monitoring of a Segment Tunnels (PSTs) are instantiated to provide monitoring of a
portion of a set of co-routed transport paths (LSPs or MS-PWs). portion of a set of co-routed transport paths (LSPs or MS-PWs).
Path segment tunnels can also be employed to meet the requirement to Path segment tunnels can also be employed to meet the requirement to
provide Tandem Connection Monitoring, see Tandem Connection. provide Tandem Connection Monitoring, see Tandem Connection.
3.23.2 Sub-Path Maintenance Element (SMPE): 3.23.2 Sub-Path Maintenance Element (SPME):
To monitor, protect, and manage a portion (i.e., segment or To monitor, protect, and manage a portion (i.e., segment or
concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be
instantiated. A hierarchical LSP instantiated for this purpose is instantiated. A hierarchical LSP instantiated for this purpose is
called a Sub-Path Maintenance Element (SPME). Note that by called a Sub-Path Maintenance Element (SPME). Note that by
definition an SPME does not carry user traffic as a direct client. definition an SPME does not carry user traffic as a direct client.
An SPME is defined between the edges of the portion of the LSP that An SPME is defined between the edges of the portion of the LSP that
needs to be monitored, protected or managed. The SPME forms a MPLS- needs to be monitored, protected or managed. The SPME forms a MPLS-
TP Section that carries the original LSP over this portion of the TP Section that carries the original LSP over this portion of the
skipping to change at page 12, line 48 skipping to change at page 13, line 40
3.28.2 Link recovery: 3.28.2 Link recovery:
MPLS-TP link recovery refers to the recovery of an individual link MPLS-TP link recovery refers to the recovery of an individual link
(and hence all or a subset of the LSPs routed over the link) between (and hence all or a subset of the LSPs routed over the link) between
two MPLS-TP nodes. For example, link recovery may be provided by two MPLS-TP nodes. For example, link recovery may be provided by
server layer recovery. server layer recovery.
3.28.3 Segment recovery: 3.28.3 Segment recovery:
MPLS-TP Segment recovery refers to the recovery of an LSP segment MPLS-TP Segment recovery refers to the recovery of an LSP segment
(i.e., segment and concatenated segment in the language of (i.e., segment and concatenated segment) between two nodes and is
[RFC5654]) between two nodes and is used to recover from the failure used to recover from the failure of one or more links or nodes.
of one or more links or nodes.
An LSP segment comprises one or more contiguous hops on the path of
the LSP. [RFC5654] defines two terms. A "segment" is a single hop
along the path of an LSP, while a "concatenated segment" is more
than one hop along the path of an LSP.
3.29 MPLS-TP Ring Topology: 3.29 MPLS-TP Ring Topology:
In an MPLS-TP ring topology, each LSR is connected to exactly two In an MPLS-TP ring topology, each LSR is connected to exactly two
other LSRs, each via a single point-to-point bidirectional MPLS-TP other LSRs, each via a single point-to-point bidirectional MPLS-TP
capable link. A ring may also be constructed from only two LSRs capable link. A ring may also be constructed from only two LSRs
where there are also exactly two links. Rings may be connected to where there are also exactly two links. Rings may be connected to
other LSRs to form a larger network. Traffic originating or other LSRs to form a larger network. Traffic originating or
terminating outside the ring may be carried over the ring. Client terminating outside the ring may be carried over the ring. Client
network nodes (such as Customer Edges (CEs)) may be connected network nodes (such as Customer Edges (CEs)) may be connected
skipping to change at page 13, line 33 skipping to change at page 14, line 28
An MPLS-TP physical ring is constructed from a set of LSRs and An MPLS-TP physical ring is constructed from a set of LSRs and
physical data links that form a ring topology. physical data links that form a ring topology.
3.30 OAM flow: 3.30 OAM flow:
An OAM flow is the set of all OAM packets originating with a An OAM flow is the set of all OAM packets originating with a
specific source MEP that instrument one direction of a MEG (or specific source MEP that instrument one direction of a MEG (or
possibly both in the special case of data plane loopback). possibly both in the special case of data plane loopback).
3.31 Operations System (OS): 3.31 Operations Support System (OSS):
A system that performs the functions that support processing of A system that performs the functions that support processing of
information related to operations, administration, maintenance, and information related to operations, administration, maintenance, and
provisioning (OAM&P) for the networks, including surveillance and provisioning (OAM&P) for the networks, including surveillance and
testing functions to support customer access maintenance. testing functions to support customer access maintenance.
3.32 Path: 3.32 Path:
See Transport path. See Transport path.
3.33 Protection priority: 3.33 Protection priority:
Fault conditions (e.g., signal failed), external commands (e.g, Fault conditions (e.g., signal failed), external commands (e.g,
forced switch, manual switch) and protection states (e.g., no forced switch, manual switch) and protection states (e.g., no
request) are defined to have a relative priority with respect to request) are defined to have a relative priority with respect to
each other. Priority is applied to these conditions/command/states each other. Priority is applied to these conditions/command/states
locally at each endpoint and between the two endpoints. locally at each end point and between the two end points.
3.34 Section Layer Network: 3.34 Section Layer Network:
A section layer is a server layer (which may be MPLS-TP or a A section layer is a server layer (which may be MPLS-TP or a
different technology) that provides for the transfer of the section- different technology) that provides for the transfer of the section-
layer client information between adjacent nodes in the transport- layer client information between adjacent nodes in the transport-
path layer or transport-service layer. A section layer may provide path layer or transport-service layer. A section layer may provide
for aggregation of multiple MPLS-TP clients. Note that [ITU- for aggregation of multiple MPLS-TP clients. Note that [ITU-
T_G.805] defines the section layer as one of the two layer networks T_G.805] defines the section layer as one of the two layer networks
in a transmission-media layer network. The other layer network is in a transmission-media layer network. The other layer network is
skipping to change at page 14, line 28 skipping to change at page 15, line 23
layer networks. layer networks.
Physical media layer networks are concerned with the actual fibres, Physical media layer networks are concerned with the actual fibres,
metallic wires or radio frequency channels which support a section metallic wires or radio frequency channels which support a section
layer network. layer network.
3.35 Segment: 3.35 Segment:
A link connection as defined in [ITU-T_G.805]. A segment is the A link connection as defined in [ITU-T_G.805]. A segment is the
part of an LSP that traverses a single link or the part of a PW that part of an LSP that traverses a single link or the part of a PW that
traverses a single link (i.e., that connects a pair of adjacent traverses a single link (i.e., that connects a pair of adjacent S-
{Switching|Terminating} Provider Edges). See also "Concatenated PEs and/or T-PEs). See also "Concatenated Segment".
Segment".
3.36 Server layer: 3.36 Server layer:
A server layer is a layer network in which transport paths are used A server layer is a layer network in which transport paths are used
to carry a customer's (individual or bundled) service (may be point- to carry a customer's (individual or bundled) service (may be point-
to-point, point-to-multipoint or multipoint-to-multipoint services). to-point, point-to-multipoint or multipoint-to-multipoint services).
In a client/server relationship (see [ITU-T_G.805]) the server layer In a client/server relationship (see [ITU-T_G.805]) the server layer
network provides a (transport) service to the higher client layer network provides a (transport) service to the higher client layer
network (usually the layer network under consideration). network (usually the layer network under consideration).
skipping to change at page 15, line 24 skipping to change at page 16, line 20
. An MPLS-TP TCM MEP for higher-level TCMs, defined in [RFC6371] . An MPLS-TP TCM MEP for higher-level TCMs, defined in [RFC6371]
sections 3.3. and 3.5. sections 3.3. and 3.5.
The server MEP can run appropriate OAM functions for fault The server MEP can run appropriate OAM functions for fault
detection, and notifies a fault indication to the MPLS-TP layer detection, and notifies a fault indication to the MPLS-TP layer
network. network.
3.38 Signaling Communication Channel (SCC): 3.38 Signaling Communication Channel (SCC):
A CC dedicated for control plane communications. The SCC may be used A Communication Channel dedicated for control plane communications.
for GMPLS/ASON signaling and/or other control plane messages (e.g., The SCC may be used for GMPLS/ASON signaling and/or other control
routing messages). plane messages (e.g., routing messages).
3.39 Signaling Communication Network (SCN): 3.39 Signaling Communication Network (SCN):
A DCN supporting control plane communication is referred to as a A DCN supporting control plane communication is referred to as a
Signaling Communication Network (SCN). Signaling Communication Network (SCN).
3.40 Span: 3.40 Span:
A span is synonymous with a link. A span is synonymous with a link.
skipping to change at page 17, line 25 skipping to change at page 18, line 25
4 Guidance on the Application of this Thesaurus 4 Guidance on the Application of this Thesaurus
As discussed in the introduction to this document, this thesaurus is As discussed in the introduction to this document, this thesaurus is
intended to bring the concepts and terms associated with MPLS-TP intended to bring the concepts and terms associated with MPLS-TP
into the context of the ITU-T's Transport Network architecture. into the context of the ITU-T's Transport Network architecture.
Thus, it should help those familiar with MPLS to see how they may Thus, it should help those familiar with MPLS to see how they may
use the features and functions of the Transport Network in order to use the features and functions of the Transport Network in order to
meet the requirements of MPLS-TP. meet the requirements of MPLS-TP.
This lexicography should not be used in order to obtain or derive
definitive definitions of GMPLS terms. To obtain definitions of
GMPLS terms that are applicable across all GMPLS architectural
models, the reader should refer to the RFCs listed in the references
sections of this document. [RFC3945] provides an overview of the
GMPLS architecture and should be read first.
5 Management Considerations 5 Management Considerations
The MPLS-TP based network requires management. The MPLS-TP The MPLS-TP based network requires management. The MPLS-TP
specifications described in [RFC5654], [RFC5860], [RFC5921], specifications described in [RFC5654], [RFC5860], [RFC5921],
[RFC5951], [RFC6371], [RFC6372], [ITU-T G.8110.1] and [ITU-T [RFC5951], [RFC6371], [RFC6372], [ITU-T G.8110.1] and [ITU-T
G.7710], include considerable efforts to provide operator control G.7710], include considerable efforts to provide operator control
and monitoring, as well as Operations, Administration and and monitoring, as well as Operations, Administration and
Maintenance (OAM) functionality. Maintenance (OAM) functionality.
These concepts are, however, out of scope of this document. These concepts are, however, out of scope of this document.
skipping to change at page 18, line 29 skipping to change at page 19, line 20
The authors would like to thank all members of the teams (the Joint The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF and the Working Team, the MPLS Interoperability Design Team in IETF and the
MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS Transport Profile. We would in particular like specification of MPLS Transport Profile. We would in particular like
to acknowledge the contributions by Tom Petch to improve the quality to acknowledge the contributions by Tom Petch to improve the quality
of this draft. of this draft.
9 References 9 References
9.1 Normative References 9.1 Normative References
[RFC3031] E. Rosen, et al., "Requirements of an MPLS Transport [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol
Profile", January 2001. Label Switching Architecture", January 2001.
[RFC5654] B. Niven-Jenkins, et al., "Requirements of an MPLS [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., et al.,
Transport Profile", September 2009. "Requirements of an MPLS Transport Profile", September
2009.
[RFC5860] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM [RFC5860] Vigoureux, M., Ward, D., Betts, M., "Requirements for OAM
in MPLS Transport Networks", May 2010. in MPLS Transport Networks", May 2010.
[RFC5921] Bocci, M., Bryant, S., Levrau, L., "A Framework for MPLS [RFC5921] Bocci, M., Bryant, S., Frost, D, et al., "A Framework for
in Transport Networks", July 2010. MPLS in Transport Networks", July 2010.
[RFC5951] Gray, E., Mansfield, S., et al., "MPLS TP Network [RFC5951] Lam, K., Gray, E., Mansfield, S., "Network Management
Management Requirements", September 2010. Requirements for MPLS-based Transport Networks", September
2010.
[RFC6371] Busi, I., Allan, D., "Operations, Administration, and [RFC6371] Busi, I., Allan, D., "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks", Maintenance Framework for MPLS-Based Transport Networks",
September 2011. September 2011.
[RFC6372] Sprecher, N., Farrel, A., "MPLS Transport Profile (MPLS- [RFC6372] Sprecher, N., Farrel, A., "MPLS Transport Profile (MPLS-
TP) Survivability Framework", September 2011. TP) Survivability Framework", September 2011.
For information on the availability of the following documents, For information on the availability of the following documents,
please see http://www.itu.int please see http://www.itu.int
skipping to change at page 19, line 28 skipping to change at page 20, line 21
[ITU-T_G.806] ITU-T Recommendation G.806 (03/2006), "Characteristics [ITU-T_G.806] ITU-T Recommendation G.806 (03/2006), "Characteristics
of transport equipment - Description methodology and of transport equipment - Description methodology and
generic functionality." generic functionality."
[ITU-T_G.872] ITU-T Recommendation G.872 (11/2001), "Architecture of [ITU-T_G.872] ITU-T Recommendation G.872 (11/2001), "Architecture of
optical transport networks." optical transport networks."
[ITU-T G.7710] ITU-T Recommendation G.7710 (07/2007), "Common [ITU-T G.7710] ITU-T Recommendation G.7710 (07/2007), "Common
equipment management function requirements." equipment management function requirements."
[ITU-T_G.8101] ITU-T Recommendation G.8101/Y.1355 (12/2006), "Terms [ITU-T_G.8101] ITU-T Recommendation G.8101/Y.1355 (09/2013), "Terms
and definitions for transport MPLS." and definitions for MPLS Transport Profile."
[ITU-T G.8110.1] ITU-T Recommendation G.8110.1/Y.1370.1 (12/2011), [ITU-T G.8110.1] ITU-T Recommendation G.8110.1/Y.1370.1 (12/2011),
"Architecture of the Multi-Protocol Label Switching "Architecture of the Multi-Protocol Label Switching
transport profile layer network." transport profile layer network."
[ITU-T G.8113.1] ITU-T Recommendation G.8113.1/Y.1372.1 (11/2012), [ITU-T G.8113.1] ITU-T Recommendation G.8113.1/Y.1372.1 (11/2012),
"Operations, Administration and Maintenance mechanism "Operations, Administration and Maintenance mechanism
for MPLS-TP in Packet Transport Network (PTN)." for MPLS-TP in Packet Transport Network (PTN)."
[ITU-T G.8113.2] ITU-T Recommendation G.8113.2/Y.1372.2 (11/2012), [ITU-T G.8113.2] ITU-T Recommendation G.8113.2/Y.1372.2 (11/2012),
"Operations, administration and maintenance mechanisms "Operations, administration and maintenance mechanisms
for MPLS-TP networks using the tools defined for for MPLS-TP networks using the tools defined for
MPLS." MPLS."
[ITU-T Y.2611] ITU-T Recommendation Y.2611 (12/2006), "High-level [ITU-T Y.2611] ITU-T Recommendation Y.2611 (12/2006), "High-level
architecture of future packet-based networks." architecture of future packet-based networks."
9.2 Informative References 9.2 Informative References
[RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", October 2004.
[RFC4397] I. Bryskin, A. Farrel, "A Lexicography for the [RFC4397] I. Bryskin, A. Farrel, "A Lexicography for the
Interpretation of Generalized Multiprotocol Label Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within the Context of the Switching (GMPLS) Terminology within the Context of the
ITU-T's Automatically Switched Optical Network (ASON) ITU-T's Automatically Switched Optical Network (ASON)
Architecture", February 2006. Architecture", February 2006.
[RFC6941] L. Fang, B. Niven-Jenkins, S. Mansfield, R. Graveman, [RFC6941] L. Fang, B. Niven-Jenkins, S. Mansfield, R. Graveman,
"MPLS Transport Profile (MPLS-TP) Security Framework", "MPLS Transport Profile (MPLS-TP) Security Framework",
April 2013. April 2013.
Authors' Addresses Authors' Addresses
Huub van Helvoort (Editor) Huub van Helvoort (Editor)
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
Email: Huub.van.Helvoort@huawei.com Email: Huub.van.Helvoort@huawei.com
Loa Andersson (Editor) Loa Andersson (Editor)
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
Email: loa@mail01.huawei.com Email: loa@mail01.huawei.com
Nurit Sprecher (Editor) Nurit Sprecher (Editor)
Nokia Siemens Networks Nokia Solutions and Networks
Email: nurit.sprecher@nsn.com Email: nurit.sprecher@nsn.com
 End of changes. 81 change blocks. 
174 lines changed or deleted 204 lines changed or added

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