draft-ietf-mpls-tp-rosetta-stone-03.txt   draft-ietf-mpls-tp-rosetta-stone-04.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: May 2011 L. Andersson (Ed) Expires: December 2011 L. Andersson (Ed)
Ericsson Ericsson
N. Sprecher (Ed) N. Sprecher (Ed)
Nokia Siemens Networks Nokia Siemens Networks
November 28, 2010 June 2, 2011
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-03 draft-ietf-mpls-tp-rosetta-stone-04
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 November 1, 2010. This Internet-Draft will expire on December 1, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 7, line 7 skipping to change at page 7, line 7
3.6. Co-routed bidirectional path: 3.6. 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. Both directions are
setup, monitored and protected as a single entity. A transport setup, monitored and protected as a single entity. A transport
network path is typically co-routed. network path is typically co-routed.
3.7. Domain: 3.7. Domain:
A domain represents a collection of entities (for example network A domain represents a collection of entities (for example network
elements) that are grouped for a particular purpose, examples of elements) that are grouped for a particular purpose, examples of
which are administrative and/or managerial responsibilities, trust which are administrative and/or managerial responsibilities, trust
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.8. Layer network: 3.8. 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
skipping to change at page 10, line 34 skipping to change at page 10, line 34
A layer network, consisting of a section layer network and a A layer network, consisting of a section layer network and a
physical layer network as defined in [ITU-T_G.805], that provides physical layer network as defined in [ITU-T_G.805], that provides
sections (two-port point-to-point connections) to carry the sections (two-port point-to-point connections) to carry the
aggregate of network-transport path or network-service layers on aggregate of network-transport path or network-service layers on
various physical media. various physical media.
3.25. Unidirectional path: 3.25. Unidirectional path:
A path that supports traffic flow in only one direction. A path that supports traffic flow in only one direction.
[editor: from: [RFC5860] ] [editor: from: [RFC5860]]
3.26. Failure: 3.26. Failure:
[editor: this is not in [RFC5860] but added for completeness] [editor: this is not in [RFC5860] but added for completeness]
The fault cause persisted long enough to consider the ability of an The fault cause persisted long enough to consider the ability of an
item to perform a required function to be terminated. The item may item to perform a required function to be terminated. The item may
be considered as failed; a fault has now been detected. See also be considered as failed; a fault has now been detected. See also
[ITU-T_G.806]. [ITU-T_G.806].
skipping to change at page 11, line 23 skipping to change at page 11, line 23
3.29. MPLS Transport Profile (MPLS-TP): 3.29. MPLS Transport Profile (MPLS-TP):
The set of MPLS functions used to support packet transport services The set of MPLS functions used to support packet transport services
and network operations. and network operations.
3.30. MPLS Section: 3.30. MPLS Section:
A network segment between two LSRs that are immediately adjacent at A network segment between two LSRs that are immediately adjacent at
the MPLS layer. the MPLS layer.
[editor: from: [RFC5921] and [RFC5951] ] [editor: from: [RFC5921] and [RFC5951]]
3.31. MPLS-TP NE: 3.31. MPLS-TP NE:
A network element (NE) that supports MPLS-TP functions. A network element (NE) that supports MPLS-TP functions.
3.32. MPLS-TP network: 3.32. MPLS-TP network:
A network in which MPLS-TP NEs are deployed A network in which MPLS-TP NEs are deployed
3.33. Equipment Management Function (EMF): 3.33. Equipment Management Function (EMF):
skipping to change at page 12, line 40 skipping to change at page 12, line 40
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.41. Operations System (OS): 3.41. Operations System (OS):
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.
[editor: from: draft-busi-mpls-tp-oam-framework-00 [1] ] [editor: from: draft-busi-mpls-tp-oam-framework-00 [1]]
[editor: OAM flow: to be added in future revision of this document.] [editor: OAM flow: to be added in future revision of this document.]
3.42. Maintenance Entity 3.42. Maintenance Entity
A Maintenance Entity can be viewed as the association of two (or A Maintenance Entity can be viewed as the association of two (or
more) Maintenance End Points (MEPs), that should be configured and more) Maintenance End Points (MEPs), that should be configured and
managed in order to bound the OAM responsibilities of an OAM flow managed in order to bound the OAM responsibilities of an OAM flow
[editor: definition?] across a network or sub-network, i.e. a [editor: definition?] across a network or sub-network, i.e. a
transport path or segment, in the specific layer network that is transport path or segment, in the specific layer network that is
skipping to change at page 14, line 39 skipping to change at page 14, line 39
. An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [5] section 3.4.; . An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [5] section 3.4.;
. An MPLS-TP TCM MEP for higher-level TCMs, defined in [5] sections . An MPLS-TP TCM MEP for higher-level TCMs, defined in [5] sections
3.3. and 3.5. 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.
[editor: check definitions in draft-ietf-mpls-tp-survive-fwk [2]]
[editor: the following are definitions from G.8101 which should be [editor: the following are definitions from G.8101 which should be
defined only if they will cause misunderstanding. It is not usefull defined only if they will cause misunderstanding. It is not usefull
to define them if the definition is the same in IETF and ITU-T, TBD] to define them if the definition is the same in IETF and ITU-T, TBD]
===== [ITU-T_G.8101] ===== ===== [ITU-T_G.8101] =====
3.1 access point 3.1 access point
3.2 adapted information 3.2 adapted information
skipping to change at page 19, line 25 skipping to change at page 19, line 25
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. specification of MPLS Transport Profile.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Busi, I., Niven-Jenkins, B., et al., "MPLS-TP OAM Framework [1] Busi, I., Niven-Jenkins, B., et al., "MPLS-TP OAM Framework
and Overview", draft-ietf-mpls-tp-oam-framework-01, july 2009 and Overview", draft-ietf-mpls-tp-oam-framework-01, july 2009
[2] Sprecher, N., Farrel, A., "Survivability Framework", draft-
ietf-mpls-tp-survive-fwk-06, June 2010
[RFC5654] B. Niven-Jenkins, et al., "Requirements of an MPLS [RFC5654] B. Niven-Jenkins, et al., "Requirements of an MPLS
Transport Profile", September 2009 Transport Profile", September 2009
[RFC5921] Bocci, M., Bryant, S., Levrau, L., "A Framework for MPLS [RFC5921] Bocci, M., Bryant, S., Levrau, L., "A Framework for MPLS
in Transport Networks", July 2010 in Transport Networks", July 2010
[RFC5860] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM [RFC5860] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM
in MPLS Transport Networks", May 2010 in MPLS Transport Networks", May 2010
[RFC5951] Gray, E., Mansfield, S., et al., "MPLS TP Network [RFC5951] Gray, E., Mansfield, S., et al., "MPLS TP Network
skipping to change at page 20, line 42 skipping to change at page 20, line 42
[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 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
Authors' Addresses Authors' Addresses
Huub van Helvoort (Editor) Huub van Helvoort (Editor)
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
Email: hhelvoort@huawei.com Email: huub.van.helvoort@huawei.com
Loa Andersson (Editor) Loa Andersson (Editor)
Ericsson Ericsson
Email: loa.andersson@ericsson.com Email: loa.andersson@ericsson.com
Nurit Sprecher (Editor) Nurit Sprecher (Editor)
Nokia Siemens Networks Nokia Siemens Networks
Email: nurit.sprecher@nsn.com Email: nurit.sprecher@nsn.com
Contributing Authors' Addresses Contributing Authors' Addresses
 End of changes. 11 change blocks. 
9 lines changed or deleted 14 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/